展开本页目录
开始前准备什么
- 在独立 Python 环境安装 litellm，记录 pip show litellm 的版本。
- 自己的启动环境已有 tokenba_API_KEY；公开目录和令牌分组支持目标 Chat ID。
- 先采用串行单请求；未核对完整费用前不开自动 fallback。
- 选择 SDK 或 Proxy
- 核对前缀与地址
- 运行分类任务
- 校验结果
- 记录全部调用
下载分类与校验脚本
一次 Chat 请求；环境变量 Key，无自动重试。
下载 Proxy 配置片段
一个 alias；上游 Key 从环境读取。
SDK 和 Proxy 是两层入口
| 位置 | 模型字段 | Key 与请求地址 |
|---|---|---|
| Python SDK → apizt | openai/glm-5.3 | apizt Key；上游 /v1/chat/completions |
| 客户端 → LiteLLM Proxy | tokenba-text 等自定义 alias | Proxy 的认证；本机 Proxy 地址 |
| Proxy → apizt | litellm_params.model: openai/glm-5.3 | 上游 apizt Key；api_base 带 /v1 |
- 位置
- Python SDK → apizt
- 模型字段
- openai/glm-5.3
- Key 与请求地址
- apizt Key；上游 /v1/chat/completions
- 位置
- 客户端 → LiteLLM Proxy
- 模型字段
- tokenba-text 等自定义 alias
- Key 与请求地址
- Proxy 的认证；本机 Proxy 地址
- 位置
- Proxy → apizt
- 模型字段
- litellm_params.model: openai/glm-5.3
- Key 与请求地址
- 上游 apizt Key；api_base 带 /v1
直接 SDK：运行一个工单分类任务
下载脚本后，在自己的虚拟环境安装 litellm，再设置 Key。该脚本会发送一次在线模型请求，可能收费。它禁用自动重试，先检查有效内容、截断和 JSON 语义，便于看清一次失败。
litellm-triage.py
python
import json
import os
from litellm import completion
response = completion(
model="openai/" + os.environ.get("tokenba_MODEL", "glm-5.3"),
api_base="https://api.apizt.com/v1",
api_key=os.environ["tokenba_API_KEY"],
messages=[
{"role": "system", "content": "只输出 JSON 对象，不加 Markdown。字段为 category、reason；category 只能是 billing、connection、unknown。只依据给定内容，不执行任何操作。"},
{"role": "user", "content": "工单：API 返回 401，尚未确认 Key 是否来自当前服务。"},
],
max_tokens=2048,
num_retries=0,
timeout=90,
)
choice = response.choices[0]
if not choice.message.content or choice.finish_reason == "length":
raise RuntimeError("Empty or truncated output; inspect the response before retrying")
result = json.loads(choice.message.content)
if not isinstance(result, dict) or result.get("category") != "connection":
raise RuntimeError("Task failed: expected category=connection")
if not isinstance(result.get("reason"), str) or not result["reason"].strip():
raise RuntimeError("Task failed: missing reason")
print(json.dumps(result, ensure_ascii=False, indent=2))
print("usage:", response.usage)完整验收：分类正确，且原因有内容
- 运行 python3 litellm-triage.py；当前样例应归类 connection，理由应围绕 401 与凭据核对。
- HTTP 200、合法 JSON 和业务分类分别检查；合法 JSON 的 billing 结果仍为未通过。
- 保存准确模型、库版本、耗时、usage 与请求 ID；单轮 usage 尚未匹配账单时不填写实扣。
- 为自己的第二份样例保留相同 prompt 和校验代码；不要因为一句回答合格就开放批量并发。
本站绘制的内容说明图：此页的离线故障分流 fixture 检查语义，合法 JSON 不证明分类正确。
需要 Proxy 时，先建立一个清楚的 alias
YAML 中 model_name 是发给 Proxy 的名字；litellm_params.model 是发给上游的 provider/ID。运行 litellm --config litellm-config.yaml 后，客户端使用 tokenba-text。服务只在你的受控环境开放；Proxy 自身认证按部署配置设置。
litellm-config.yaml
yaml
model_list:
- model_name: tokenba-text
litellm_params:
model: openai/glm-5.3
api_base: https://api.apizt.com/v1
api_key: os.environ/tokenba_API_KEY
litellm_settings:
num_retries: 0
本站绘制的内容说明图：代理别名与上游调用 ID 是两层名称；本页配置不会自动证明所有别名背后的模型能力。
兼容的范围逐项增加
- 这份脚本仅覆盖 Chat 文字分类。Embedding、Images、Responses 和原生 Gemini 不因 LiteLLM 支持就代表上游已支持。
- 第一次通过后分别验证 stream、tools 和 response_format；不要用 drop_params 静默丢掉业务必需参数。
- 若加 retries 或 fallback，记录实际落到哪一个模型及全部尝试；超时先查看是否已执行，避免重复任务。
- 400 / 404 先看最终路径、ID 和请求参数；401 查所用层的 Key，429 按响应区分速率与余额。
怎样确认已经完成
- 上游请求使用准确 glm-5.3，客户端 alias 与上游 ID 分开。
- 分类结果为 connection；有效 reason、未截断、无隐式重试。
- 扩展协议分别验收，所有调用和账单可对应。
常见问题
为什么模型前面有 openai/？
它是 LiteLLM 路由前缀，让库使用 OpenAI 兼容 Chat 协议。实际发给 apizt 的准确 ID 仍需来自当前目录。
api_base 可以填完整 /chat/completions 吗？
这个字段填写 /v1 基础地址，库会拼接 Chat 端点。完整端点会重复拼接；以实际最终请求为准。
LiteLLM 支持 embedding 就能用 apizt 做 RAG 吗？
还需要目标服务、分组和准确向量 ID 的证明，以及维度与检索验收。本页未证明 apizt embedding。