LiteLLM 8 大核心功能拆解：提示词实测清单 + DeepSeek / Kimi 多模型对比（2026）

先给结论：LiteLLM 不是「又一个模型」，它是一个网关。模型还是那些模型——DeepSeek、Kimi、豆包、通义千问、Claude、GPT——LiteLLM 做的是在你和它们中间插一层，把「换模型」从改代码变成改配置，把「花了多少钱」从月底对账变成实时看板。

我为什么开始用它，起点其实很朴素。我手上有五六个自己写的小工具，写文案脚本调 DeepSeek，写长文档摘要调 Kimi，写代码助手调 Claude，一个电商后台的选品工具调豆包。每接一家，代码里就多一套 SDK、一套字段名、一套错误码、一套计费口径。月底账单出来，我只能对着 Excel 一行行猜"这三个钱是谁花的"。

用上 LiteLLM 之后，最值钱的不是"少写了几百行适配代码"，而是我第一次能一眼看出 Token 到底花在哪。下面这 8 个功能，我按自己实际用到的顺序拆，不按官方文档的章节顺序。

一、统一 SDK：换模型只改一个字符串

这是最基础的一层。安装完之后，你调任何厂商都是同一个函数：

pip install litellm

from litellm import completion

response = completion(
    model="deepseek/deepseek-chat",
    messages=[{"role": "user", "content": "帮我把这段产品文案改得更口语一点"}]
)
print(response.choices[0].message.content)

要换成 Kimi，改成 moonshot/kimi-k2.6；要换成豆包，改成 volcengine/doubao-pro；要换成通义，改成 dashscope/qwen-max。业务代码一个字都不用动，返回结构也完全一致：choices[0].message.content、usage、model，换谁都长这样。

我在用的时候踩的第一个坑是：provider 前缀最好写全，别偷懒只写模型名。写 gpt-4o 有可能能解析，但 openai/gpt-4o 和 azure/gpt-4o 不会有歧义。第二个坑是它统一的是接口，不是凭据——DeepSeek 的 key 还是 DEEPSEEK_API_KEY，Kimi 的还是 MOONSHOT_API_KEY，每个厂商的都得配。

还有个被低估的功能：错误归一化。LiteLLM 把所有厂商的错误都映射成 OpenAI 那套异常体系，所以你一个 try/except 就能兜住所有情况：

import litellm

try:
    litellm.completion(model="moonshot/kimi-k2.6", messages=msgs)
except litellm.AuthenticationError as e:
    print("密钥不对：", e)
except litellm.RateLimitError as e:
    print("被限流了：", e)
except litellm.APIError as e:
    print("上游挂了：", e)

之前我用 DeepSeek 的时候，429 是 RateLimitError；用 Kimi 的时候，限流是塞在返回体里的一个 code 字段，得自己 if 判断。统一之后这段逻辑就删了。

二、Proxy 网关：一个端点挡住所有应用

SDK 模式解决的是「我这个应用怎么调模型」。Proxy 模式解决的是「我们整个团队怎么调模型」。

pip install 'litellm[proxy]'

# 最小启动
litellm --model deepseek/deepseek-chat
# 已经在 http://localhost:4000 监听

然后你的客户端只需要改 base_url：

from openai import OpenAI

client = OpenAI(api_key="sk-任意字符串", base_url="http://localhost:4000")
resp = client.chat.completions.create(
    model="deepseek/deepseek-chat",
    messages=[{"role": "user", "content": "你好"}]
)

关键在于 api_key 那一栏填的是网关发给你的虚拟密钥，不是 DeepSeek 的真 key。真正的厂商密钥躺在网关的配置里，谁也拿不到。

我用它最爽的一点是：任何会 OpenAI 格式的东西都能指过来。curl 可以、LangChain 可以、Cursor 可以、甚至公司里那些老得不想改的内部脚本，改一行 base_url 就接上了。我现在的做法是把网关地址写进统一的 .env，团队里谁要接模型，只改配置不改代码。

但 Proxy 模式不是「装完就能跑」，这一点我得提前说清楚：它强依赖 PostgreSQL 和 Redis。Postgres 存虚拟密钥、预算和用量账本，Redis 管跨进程的限流状态和缓存。我第一次 pip install 完直接 litellm --model ... 起来，页面能开但一切调用报数据库连接错误，排查了半天才明白是这俩还没配。想要能跑生产的版本，这套依赖躲不掉。

三、虚拟密钥 + 预算 + 限流：治理三件套

这是我用得最多的功能，也是最容易被低估的功能。

网关可以给自己签发内部密钥（也是 sk- 开头），每个密钥身上可以挂：

允许调用的模型——市场部那把只能调 deepseek/deepseek-chat，摸不到 gpt-5.5-pro
消费上限——按天或按月，到额就停
速率限制——TPM / RPM 双维度卡
元数据标签——用来做成本归因，比如 {"team":"content"}

我现在的配置大概是这样：市场部的 key 每天额度 50 块，超了直接停；研发的 key 不限速，但记账；一条跑批量任务的 key 单独挂个 tag，方便月底看它到底烧了多少。

这里有个安全上的好处经常被忽略：如果哪把虚拟密钥泄漏了，你 revoke 的只是一把虚拟密钥，厂商的真密钥根本不用动。我自己在做电商后台的时候，那把 key 是写死在配置里的，泄漏过一次——换了一把虚拟密钥，十分钟搞定，厂商那边一个字没变。

版本上要注意一个变化：v1.83.14 开始支持按团队成员粒度设预算了，不再只能按 key / 按团队。也就是说"张三这个月最多用 200"这种需求，现在是原生支持的，不用自己写中间件。v1.84.0-rc.1 还修了多 Pod 并行时的预算计数漂移——这条对多实例部署很关键，否则你以为的"到 500 就停"实际上会超。

四、Router：路由策略和故障回退

Router 是 LiteLLM 的技术核心。原理很简单：在配置里给多个部署起同一个 model_name，它们就自动成一组。

model_list:
  - model_name: default
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY
  - model_name: default
    litellm_params:
      model: moonshot/kimi-k2.6
      api_key: os.environ/MOONSHOT_API_KEY
  - model_name: premium
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: simple-shuffle
  fallbacks:
    - default: ["premium"]

业务侧永远只写 model="default"。网关自己决定走 DeepSeek 还是 Kimi，DeepSeek 挂了自动切 Kimi，两个都挂了按 fallbacks 切 premium。我实测下来的体感是：DeepSeek 在高峰期限流是常态，接了 fallback 之后业务侧基本无感，这个链条救过我好几次线上问题。

可选的路由策略有几种，我按推荐顺序说：simple-shuffle（官方明确写的是推荐的生产策略）、least-busy（挑最闲的部署）、latency-based-routing（按延迟挑）、usage-based-routing（按用量挑）。

顺带说个我在 v1.83.14 里看到的新东西：Adaptive Routing，这是个可选开启的策略，它在原有回退之上，按各部署近期的延迟和错误历史加权。意思就是某个部署正在变慢或者开始抽风，路由会自己少往那儿派。v1.103.0（2026 年 9 月 27 日）又加了 Fuse 和 Capability 两种路由，前者是把多个部署熔断成一个整体，后者是按模型能力（比如支不支持工具调用、支不支持 JSON 模式）来选。

还有两个能力值得单独提：A/B 测试和流量镜像。前者是按比例把流量分给新模型；后者是把线上流量复制一份打到新模型上，但结果不给用户看，只用来收集对比数据。这两个功能在评估"要不要把生产流量切到新模型"的时候价值极高。

五、成本追踪：把账单从黑盒变成仪表盘

这是我用 LiteLLM 之后最大的收获，也是我最推荐的功能。

LiteLLM 内置了所有支持模型的定价表（可以覆盖成自己的费率，或者加个内部结算毛利），然后按虚拟密钥 / 团队 / 用户 / 单次请求四个维度记账。数据可以导到 Prometheus、Langfuse、Datadog，或者直接查 Postgres。日预算和月预算可以同时跑，各自独立窗口，还能配 Slack webhook 到额告警。

我拿它干的第一件事，是把同一个提示词在不同模型上跑一遍，看真实成本差多少。拿 LiteLLM v1.83.14 release notes 里官方成本表的数据（每百万 token，输入/输出）举例：

moonshot/kimi-k2.6：$0.95 / $4.00，上下文 262,144
gpt-5.4-nano：$0.20 / $1.25，上下文 272,000
bedrock/.../zai.glm-5：$1.00 / $3.20，上下文 200,000
gpt-5.5：$5.00 / $30.00，上下文 1,050,000

光看这个表你可能没感觉，但接上看板之后我看到的是另一回事：我那条"产品文案口语化"的提示词，一个月跑下来 78% 的请求其实用 nano 级模型就够了，我一直在用 Kimi 干这个活。知道之后改配置，一天省下来的钱比我一整个月省下来的都多。

管理后台的 Spend Logs 页面能按模型和 TTFT（首 token 时间）排序，v1.83.14 加的这个排序项我天天用——看一眼哪些模型响应慢，哪些模型把预算吃掉了。

六、缓存：精确匹配和语义匹配是两回事

LiteLLM 支持两种缓存。后端可以选内存、磁盘、Redis、Redis Cluster、S3、谷歌云存储，语义缓存还支持 Qdrant。

精确缓存是同样的输入直接返回上次的结果，零 token 成本。语义缓存则是先算 embedding，语义接近的问题也命中——这个需要你在模型列表里额外配一个 embedding 模型。

提示词场景里这两个用得完全不一样。我自己的划分标准是：固定模板 + 变量替换的（比如"把这句商品名改写成 3 个短句"），走精确缓存；FAQ / 知识库问答的，走语义缓存。我实测过一条固定模板的批量改写任务，缓存一开，那部分请求的费用直接归零。

但语义缓存我踩过坑：客服场景千万别裸开。两个用户问法接近但问的是不同订单，语义缓存把 A 的答案给了 B。我现在的做法是给不同场景的缓存打隔离前缀，宁可多花点钱也不串单。

七、可观测性 + 护栏：让提示词能被质检

LiteLLM 支持 20 多个日志和观测后端：Langfuse、Prometheus、OpenTelemetry、Datadog、MLflow、Arize Phoenix、Weights & Biases、Sentry、Helicone 等等，接法就是在配置里挂一个 success_callback 列表。

但我要重点说的是 LLM-as-a-Judge 护栏——v1.83.14 加的，可以在网关层挂一个裁判模型，按你写的 rubric 给每次调用的输出打分，不合格直接拦。

这个功能跟提示词放在一起才有意思。我现在的做法是：把关键业务提示词的输出质量标准写成 rubric（比如"必须包含价格区间"、"不得出现绝对化用语"、"不得承诺发货时效"），让网关每次调用都过一遍裁判模型。提示词从"写完就扔"变成了"有验收标准的资产"。

这里有个必须注意的坑：裁判模型不要用被测模型自己。同一个模型判自己，基本等于没判——它会给自己打高分。我单独挂了一把便宜的键给裁判用，而且这个裁判用的是另一家厂商的模型。

八、MCP 网关 + Agent 网关：今年新加的两块

这两块是 2026 年才加进来的，也是 LiteLLM 跟传统 API 网关拉开差距的地方。

MCP 网关把所有 MCP 工具收到同一个端点后面，按密钥和按团队控制谁能调哪个工具。Agent 拿到的是你明确授权的那部分，不是全部工具都敞着。这对我很关键——我写过一篇 MCP 实战教程，里面提到 MCP 最大的隐患就是工具权限太开放，网关这一层正好补上。

Agent 网关则是把 Agent 调用也纳入同一套日志和访问控制。支持 A2A 协议、Vertex AI Agent Engine、LangGraph、Azure AI Foundry、Bedrock AgentCore、Pydantic AI。Agent Hub（v1.80.0）负责注册和共享 Agent，A2A Agent Gateway（v1.80.8）负责 Agent 互相调用。v1.83.14 还加了 /v1/memory 的 CRUD 端点，Agent 的记忆可以直接存在网关里。

另外两个值得知道的：LiteLLM Lens（2026 年 10 月 1 日开放早期访问）专门用来记录 agent 集群的调用轨迹；liteagents SDK 提供跟 Claude Agent SDK 一样的 query() 接口，可以在 Deep Agents、Claude Agent SDK、Codex、Pydantic AI、OpenCode 之间换 harness 而不动模型和工具——目前还在 alpha。

版本节奏很快，这是最容易吃暗亏的地方

我把这几个月的 release 节点列出来，你就能感觉到它动得多快：

v1.102.1（2026-09-27）：稳定线补丁
v1.103.0（2026-09-27）：配置文件所有权、Fuse / Capability 路由、网关加固
v1.104.0（2026-10-03）：Claude Opus 5.5 和 GPT-6 支持、强制 master key、stdio MCP 默认关闭
v1.105.0（2026-10-11）：Claude Sonnet 5.5 和 GPT-6.1 Sol、跨八家供应商的 /v1/decisions 决策 API、litellm.agent()、带 Agent Traces 的 Lens

顺便说个细节：v1.104.0 开始 stdio MCP 默认是关的，要开得显式打开。我有个项目升级后工具列表突然空了，查了半天才想起来是这个默认值变了。这种坑，你不知道就等着懵。

我踩过的 5 个坑

这几个都是我实际栽过跟头的，不是抄文档：

第一，不锁版本。我用 pip install litellm 装完就没管，有天早上发现行为变了——某个模型的路由策略默认不一样了。LiteLLM 同时维护好几条 stable 线，官方建议选一条线钉住它的最新补丁，不要追 newest tag。生产环境更要用带 cosign 签名的镜像，stable tag 是过 12 小时压测才发出来的。

第二，以为 Proxy 装完就能跑。上面说过，Postgres 和 Redis 是硬依赖。

第三，客户端 api_key 填错。填成厂商真 key 会 401，填成任意字符串反而是对的（网关校验的是虚拟密钥）。这个反直觉，我第一次调了半小时。

第四，超时。Agent 跑十几步的时候，客户端和网关的 HTTP 超时都得调到 5 分钟以上，并且开流式。不然前端报错、后端还在烧 token——这个坑是纯烧钱。我后来在客户端断开时主动 cancel 请求，才把这类浪费压下去。

第五，预算告警不配。等账单来了才发现某个测试 key 被循环调用。限额和告警要一起上，别只上一个。

安全：2026 年这半年出的两件事，你必须知道

这部分我单独拎出来讲，因为很多人只看功能不看安全。

2026 年 3 月的供应链攻击。1.82.7 和 1.82.8 两个版本被投毒。攻击者通过 Trivy 的 CI/CD 管线下手，包里塞了窃取凭据的代码（针对 SSH key、云凭据、K8s secret、.env 文件、加密钱包）、K8s 横向移动工具链，还有一个通过 systemd 服务实现的持久化后门。1.82.8 会在每一个 Python 解释器启动时通过 .pth 文件执行。当时它月下载量约 9500 万，爆炸半径相当大。所幸两个版本都被从 PyPI 撤下并发布了安全版本。

2026 年 4 月的 SQL 注入。CVE-2026-42208，CVSS 评分 9.3（严重），披露后 36 小时内就在真实环境被利用。补丁发得很快，但这个时间线本身就说明了问题：一个下载量巨大的包，攻击面也巨大。

官方后续的处置是：所有 Docker 镜像用 cosign 签名，stable tag 经 12 小时负载测试。但这些是"以后"的事，你手上的版本是"现在"的事。我的做法是三条：锁死具体版本 + 用 lock 文件；通过私有 registry 装，预扫描；订阅 GitHub security advisories 和 OSV。有合规要求的环境，还要考虑它不发送任何遥测数据这一点——提示词和数据都留在你自己的服务器上，官方 about 页写得很明确。

横向对比：什么时候该选谁

我把主要几个选项摆在一起。这是官方 pricing 页和文档里的信息（2026 年 10 月），加上我自己用下来的判断：

方案	托管方式	加价	我的判断
LiteLLM	自己部署（云 / 本地 / K8s / 气隙环境）	无 token 加价	功能最全，代价是要自己运维 Postgres + Redis
OpenRouter	托管	5.5%	不想运维就选它，但请求过它的服务器
Cloudflare AI Gateway	托管	5%	已在 Cloudflare 体系内的话很顺
Portkey	托管或自建（2026-03 转 Apache 2.0）	—	2026-05 被 Palo Alto 收购，将改名 Prisma AIRS AI Gateway
Helicone	托管	—	2026-03 并入 Mintlify，代码进维护模式，新项目别选了
One-API / New API	自建，Go 单二进制	无	国内轻量中转场景的轻量答案，SQLite 就够
Bifrost	自建	—	护栏、RBAC、审计日志这些在它的付费版

延迟这块官方给了组数字：LiteLLM 的 Rust 网关（beta）p99 只增加 0.66 毫秒，同一个 AI Gateway Bench 里 Portkey 增加 2.29 毫秒、Bifrost 增加 4.54 毫秒。这是官方自己跑的数据，测试脚本是公开的，你可以自己复现。

我的选型结论很直接：只有一个应用、调一家厂商，别上 LiteLLM，直接用官方 SDK 更干净。多应用多团队要治理、要记账、要回退，LiteLLM 是当前综合最优解。个人做中转站、想弄兑换码那套中文玩法，One-API 系更省事。合规要求高但又不想自己运维，选 Portkey 的托管版，它把 SOC2 / HIPAA / ISO 27001 这些都包了。

另外补一个数据点：LiteLLM 不是孤岛。Promptfoo 这个评测框架就用它做 provider 路由——也就是说很多人在用的工具底下跑的就是 LiteLLM。想知道怎么给提示词写回归测试，可以看我之前写的 Promptfoo 实测对比。

提示词接进网关：8 条可以直接抄的清单

标题里说了提示词，这里给一个我认为最能落地的部分。提示词的治理不该只靠 code review，应该靠网关——因为网关是所有调用必经的地方，在这一层加检查，业务代码一行不用改。

第一，提示词模板化 + 版本号。模板进 Git，改动走 PR，别在业务代码里拼字符串。

第二，固定模板的调用开精确缓存。模板本身不变、只有变量变，缓存命中率会很高，费用直接砍。

第三，用 LLM-as-a-Judge 给提示词输出做质检。rubric 写成可读的中文规则，裁判模型用另一家厂商的。

第四，长上下文场景开服务端提示词压缩。v1.83.14 加的 server-side prompt compression，会在请求发往上游模型前自动压缩长输入，官方点名的适用场景就是 Claude Code、RAG 和文档类负载，客户端不用改。

第五，按模型分组看成本。同一条提示词在 DeepSeek、Kimi、豆包上跑的成本能差好几倍，看板比感觉靠谱。

第六，用流量镜像做提示词 A/B。新提示词先镜像跑一周，对比通过率再切正式流量。

第七，回退链要连提示词一起考虑。同一条提示词在 DeepSeek 上能出结构化 JSON，换成 Kimi 未必行。回退到备选厂商之前，先确认那条提示词在备选厂商上能跑通，否则回退会把一个报错换成一个静默的错误。

第八，敏感信息过滤。LiteLLM 的护栏家族里有 Presidio 做 PII 掩码、还有提示注入检测，配合 /v1/memory 里的 Agent 记忆一起用——记忆里存的东西一旦有泄漏，风险是持续的。

提示词本身的写法我另写过一篇完整的：AI 提示词工程完全指南（含 50 个实战模板），还有按 10 大场景分类的 100 个实战 prompt。那两篇讲的是"怎么写"，这篇讲的是"写完之后怎么让它一直好"。

最后

LiteLLM 本身不是什么新鲜东西了，2023 年 7 月就开源了。但 2026 年它确实长成了这个生态里绕不开的一层——Netflix、NVIDIA、Okta、AT&T、IBM、SAP、NASA 都在用，官网案例里写 AT&T 把编码成本降了 56%。四个主流 Agent 框架（LangChain、CrewAI、DSPy、LlamaIndex）底下都有它。

不过我最想说的不是它多强，是它把一件原本靠人自觉的事变成了配置。换模型、限预算、看成本、故障回退、输出质检——以前这些散在每个人的代码里和各人的自觉里，现在收在一张 YAML 上。

如果你手上已经有两把以上的模型 API key，我建议先花一个下午把 SDK 模式跑通（十分钟的事），再决定要不要上 Proxy。别一上来就搭网关，先用 SDK 感受一下"统一接口"这件事到底省不省事。

想了解模型本身怎么选，我写过一篇国产大模型 5 款横评，还有 AI API 供应商价格对比；想把提示词和网关一起玩转，从 Kimi 完整使用指南和 DeepSeek V3 三十天实战开始也行。