轻量路由库（litelm）提取自轻量大模型集成库（litellm）的路由与转换核心，仅用约2900行代码和两个依赖（openai、httpx）实现。litellm 原本在多个提供商之间路由大语言模型调用并转换消息格式，但这部分核心被埋在100k+行代理服务器、缓存层与成本跟踪等多数用户从不使用的功能之下。litelm 仅抽取调用路径，涵盖模型路由、消息翻译、流式、工具调用及嵌入，不含 Router 类、代理或缓存。

litelm 用约 2900 行代码、2 个依赖（openai、httpx）实现了 litellm 的路由与格式转换。

litellm 负责跨服务商路由 LLM 调用、在消息格式之间转换。但核心逻辑埋在 10 万行以上的代理服务器、缓存层、成本统计和几十个多数人根本用不到的功能底下。litelm 只抽出调用路径——模型路由、消息转换、流式输出、工具调用、embeddings——别的都不要。没有 Router 类，没有代理，没有缓存。

安装

pip install litelm 只装 openai + httpx；pip install litelm[anthropic] 加装 anthropic SDK；pip install litelm[bedrock] 加装 boto3；pip install litelm[all] 装全部。

用法

基础 completion：litelm.completion("openai/gpt-4o", messages=[{"role": "user", "content": "Hello!"}])，取 response.choices[0].message.content。

流式：litelm.completion("groq/llama-3.1-70b-versatile", messages=[...], stream=True)，逐块打印 chunk.choices[0].delta.content。

Embeddings：litelm.embedding("openai/text-embedding-3-small", input=["hello world"])。

每个函数都有异步版本：acompletion、aembedding、aresponses、atext_completion。

API 与 litellm 对齐——函数名、参数、返回类型都一样。如果你现在用 litellm，只要把 import 里的 litellm 换成 litelm。

有什么 / 没什么

| litellm | litelm | | --- | --- | | 模型路由（provider/model → 正确端点） | ✓ ✓ | | 消息转换（Anthropic、Bedrock、Cloudflare、Mistral） | ✓ ✓ | | 流式 + streamchunkbuilder | ✓ ✓ | | 工具调用（function calling） | ✓ ✓ | | Embeddings | ✓ ✓ | | 文本补全 | ✓ ✓ | | OpenAI Responses API | ✓ ✓ | | Mock responses | ✓ ✓ | | Router（负载均衡、fallback） | ✓ ✗ | | 代理服务器 | ✓ ✗ | | 缓存 / 预算 / 成本统计 | ✓ ✗ | | Token 计数 | ✓ ✗ | | 图像生成、音频、OCR、微调 | ✓ ✗ | | Agents、guardrails、调度器 | ✓ ✗ |

服务商

用 provider/model-name 语法路由到 19 个服务商。任何 OpenAI 兼容端点都能通过 api_base 使用。

| 服务商 | 环境变量 | Handler | 已验证 | | --- | --- | --- | --- | | OpenAI | OPENAIAPIKEY | OpenAI SDK | 是 | | Anthropic | ANTHROPICAPIKEY | 自定义 | 是 | | Groq | GROQAPIKEY | OpenAI 兼容 | 是 | | Mistral | MISTRALAPIKEY | 自定义 | 是 | | xAI | XAIAPIKEY | OpenAI 兼容 | 是 | | OpenRouter | OPENROUTERAPIKEY | OpenAI 兼容 | 是 | | Azure | AZUREAPIKEY | OpenAI SDK（Azure） | 是 | | Bedrock | AWSACCESSKEYID | 自定义 | 否 | | Cloudflare | CLOUDFLAREAPITOKEN | 自定义 | 否 | | Together | TOGETHERAIAPIKEY | OpenAI 兼容 | 否 | | Fireworks | FIREWORKSAPIKEY | OpenAI 兼容 | 否 | | DeepSeek | DEEPSEEKAPIKEY | OpenAI 兼容 | 否 | | Perplexity | PERPLEXITYAIAPIKEY | OpenAI 兼容 | 否 | | DeepInfra | DEEPINFRAAPITOKEN | OpenAI 兼容 | 否 | | Gemini | GEMINIAPIKEY | OpenAI 兼容 | 否 | | Cohere | COHEREAPI_KEY | OpenAI 兼容 | 否 | | Ollama | — | OpenAI 兼容 | 否 | | vLLM | — | OpenAI 兼容 | 否 | | LM Studio | — | OpenAI 兼容 | 否 |

API 密钥

为对应服务商设置环境变量，例如 export OPENAI_API_KEY=sk-...、export ANTHROPIC_API_KEY=sk-ant-...。

也可以直接传入：litelm.completion("openai/gpt-4o", messages=[...], api_key="sk-...")，或用 api_base="http://localhost:8000/v1" 指定端点。

错误处理

所有服务商错误都映射到 litelm 的异常层级。从 litelm 导入 ContextWindowExceededError、RateLimitError、AuthenticationError，用 try/except 分别捕获：提示过长就截断重试，限流就退避，密钥错误就报错。

工具调用

定义 tools，形如 {"type": "function", "function": {"name": "get_weather", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}}}，然后调用 litelm.completion("openai/gpt-4o", messages=[{"role": "user", "content": "Weather in Paris?"}], tools=tools, tool_choice="required")。结果在 response.choices[0].message.tool_calls[0]，可读取 tool_call.function.name 和 tool_call.function.arguments。

自定义 / 本地服务商

任何 OpenAI 兼容服务器都能用 api_base 接入。vLLM：litelm.completion("openai/my-model", messages=[...], api_base="http://localhost:8000/v1")。Ollama：litelm.completion("ollama/llama3", messages=[...], api_base="http://localhost:11434/v1")。LM Studio：litelm.completion("openai/local-model", messages=[...], api_base="http://localhost:1234/v1")。

开发透明度

litelm 是人工主导、AI 辅助的软件。大部分代码用 Claude Code 配合 Claude Opus 4.6/4.7 写成。2026-05-14 之后的代码通过 Pi 使用 GPT-5.5 编写。兼容性声明基于测试和维护者审阅，与 AI 作者身份无关。

上游核验

维护者核验，2026-09-11：从 649eb2d 到 9a715df2 审阅了 LiteLLM 的路由/格式化变更。这次审计分诊了 360 个核心路径提交，检查了上游测试中可能相关的行为，并以测试先行方式修复了由此产生的兼容性缺口。本地范围测试：262 通过、55 跳过；所有 45 个可用服务商实时测试和全部 10 个 DSPy 冒烟测试在当前依赖锁定下也都通过。

这只证明 litelm 声明范围内的路由/格式化/DSPy 表面，不代表完全兼容 litellm。

状态

Alpha。自有测试 262 个通过。当前范围内的 LiteLLM 9a715df2 基线有 75 个移植测试通过，没有残留的、可修复的断言或运行时失败。

DSPy 即插即用已验证——全部 7 条执行路径都经过实机证明（Predict、CoT、带类型签名、流式、embeddings、工具调用、多输出）。

测试

uv run --extra all pytest tests/ -x --ignore=tests/ported --timeout=10 跑 262 个非实时测试；bash scripts/ported_contract.sh 跑 49 个快速上游契约测试；uv run --extra all pytest tests/test_live.py -m live --timeout=30 跑 45 个实时服务商测试；uv run pytest tests/test_dspy_smoke.py -m live --timeout=60 跑 10 个 DSPy 集成测试。

社区对该精简版 LiteLLM 项目的创意表示欣赏，但多数人质疑其移除核心功能与贬低原项目的宣传方式，少数人认为在人工智能编程时代这类库本身已无存在必要。

认为砍掉成本追踪和缓存等功能削弱了核心价值

• 不少用户指出，被作者视为“臃肿”而移除的 token 消耗统计、流式传输和缓存，恰恰是他们在生产环境中选用 LiteLLM 的关键理由，移除后项目定位尴尬（较多人）。 > 被你修剪掉的东西恰恰是我要在平台里部署 LiteLLM 的原因，跨服务按客户追踪花销很重要（@9dev）

质疑“LiteLLM Without the Bloat”的命名与宣传方式

• 多人认为标语带有贬低其他开源项目之意，若真有技术价值无需靠踩踏开源项目来营销，且容易引起混淆，建议改名或删掉标语（较多人）。 > 第一印象是这个标语该拿掉，有价值的东西不需要靠贬低其他开源项目来给自己找理由（@nperez）

建议重写或充实 README 以说明真实收益

• 读者希望作者手写而非生成 README，并明确列出除减少代码行数和依赖之外的实际好处，例如延迟或内存占用的降低，而不是仅仅强调“更小”（较多人）。 > 减少代码和依赖是酷，但最好能说明它是否带来了更低延迟或内存需求等额外好处（@freshtake）

认为在 AI 辅助编程时代自行开发客户端更合理

• 部分开发者表示，用前沿模型花几十分钟就能写出符合自己标准的路由或客户端，通用库的护城河很低，真正有价值的是技术思路而非具体库（少数人）。 > 这是用前沿大模型花三十分钟做的项目，看不出有人会去用别人的路由，技术值钱但库不值钱（@arjie）

希望保留通过插件机制扩展功能的灵活性

• 有用户提议用插件或扩展架构来按需实现缓存与成本统计，这样既能保持核心精简，又不丢失企业级需求（少数人）。 > 还有其他缩减体积的办法，比如提供插件接口，同时 token 计数其实很有用（@tway235）

有价值的补充

• 项目依赖的 httpx 库已不再积极维护，目前由 Pydantic 团队接手并规划了后续版本。
• 不同大模型服务商罕见地普遍兼容“OpenAI 兼容”接口规范，这种程度的互操作性在其他软件领域其实很少见，反映出人工智能接口标准化的特殊现象（@asveikau）