LiteLLM 是啥玩意儿，先给你掰开揉碎说清楚

说实话，LiteLLM 就是把几百种 LLM API 用 OpenAI 那套接口给统一了。

别kan名字拗口，核心价值其实hen简单——省事儿。

上手容易，功Neng强大，特别适合小微团队。

想想以前每换个模型，dou要改一堆 SDK、写一堆适配层，真是麻烦得要死。

有了 LiteLLM，你只管改个 model 名字，别的全交给网关搞定。

准备工作：环境装好别慌

我这边用的是 WSL，其他系统也行，只要装 Docker 就行。

Ru果你只是想验证一下效果，用 Python 脚本 pip 安装就够了官方文档里有说明，哈哈，我这里不细聊。

不过要是真上线，Docker 部署才是王道。

Docker‑Compose 快速起步

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
    environment:
      # 替换成你自己的 API Key
      - DEEPSEEK_API_KEY=sk-your-deepseek-key
      - DASHSCOPE_API_KEY=sk-your-qwen-key
    command: 
    restart: always

这文件就是 LiteLLM 的“大脑”，定义模型怎么映射。

模型映射配置文件示例

model_list:
  # DeepSeek
  - model_name: deepseek
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: "os.environ/DEEPSEEK_API_KEY"
  # 通义千问
  - model_name: qwen
    litellm_params:
      model: dashscope/qwen-max
      api_key: "os.environ/DASHSCOPE_API_KEY"
router_settings:
  routing_strategy: simple-shuffle
  enable_fallbacks: true
  fallbacks:
    - {"deepseek": }
general_settings:
  master_key: sk-admin-

这个配置里干了两件事：

一是把 DeepSeek 和 Qwen 挂进去；二是设置了故障自动切换——DeepSeek 挂了就自动走 Qwen。

你Ke以往里再加上 Mistral、Gemini，只要填对对应的 model 名和 API Key 就行。

启动容器，一键搞定

docker-compose up -d

不出意外的话，你会kan到容器悄悄跑起来日志里会打印 DEBUG 信息，说明Yi经进入 detailed_debug 模式啦。

先测健康，再发请求——一步到位 健康检查接口

curl localhost:4000/health/readiness

返回类似：

{
    "status": "healthy",
    "db": "Not connected",
    "cache": null,
    "litellm_version": "...",
    "log_level": "DEBUG",
    ...
}

kan到 status 是 healthy，就算成功部署啦！害，你是不是也跟我一样激动？哈哈。

Zui基础的 Chat 完成请求

curl --request POST \
  --url localhost:4000/v1/chat/completions \
  --header 'Authorization: Bearer sk-admin-' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "deepseek",
    "messages": 
}'

正常情况下会收到类似：

{
   "id":"chatcmpl-...",
   "object":"chat.completion",
   "created":...,
   "choices":,
   ...
}

C# 调用小案例

var client = new OpenAIClient(
    new OpenAIClientOptions {
        Endpoint = new Uri
    },
    new ApiKeyCredential
);

这个代码段不多说你们自行玩儿就行。

常见坑 & 调优技巧

- 环境变量写错钥匙会导致所有请求dou返回 401。别慌，把键名和前缀对齐就好。

- Docker 暴露端口冲突？改下 compose 文件里的 ports 映射即可。记得宿主机防火墙也要开通对应端口。

- Ru果使用自定义模型，需要在 litellm_params 裏加上 `api_base` 指向对应的服务地址，不然会找不到路由。

- 开启 `is_detailed_debug` Neng让日志geng肥，但生产环境Zui好关掉，否则日志太嗨会占磁盘。

为什么说 LiteLLM 是当红炸子鸡？

社区活跃度高，插件生态丰富；还Neng直接统计 Token 用量，设置预算上限——团队协作省心又省钱。

AWS、Azure 那些大厂的网关功Neng倒是强，但自托管成本高。相较之下 LiteLLM 小而美，上手快，又Neng随时迁移到云原生平台，真是灵活得不要不要的。

选型小建议：到底该不该用 LiteLLM？

- 团队技术栈Yi经熟悉 Docker & Python/Node，那直接搬进来吧。别忘了把 health check 加进 CI 流程里监控一下状态。

- Ru果你们Yi经在用 Envoy 或者 Higress 那套成熟网关，并且需要高级流量治理，那么Ke以考虑 OneAPI 或者自己在 Envoy 上写 Filter。LiteLLM geng像是“轻量级代理”。咱就是说两者Ke以并存，用 LiteLLM Zuo模型聚合，用 Envoy Zuo流量层面的大保镖。

收尾：从容面对新模型浪潮

总的来说LiteLLM 把繁琐的适配工作全部抽离出来让业务代码只需要改一个 model 名字，就Neng玩转新模型。以后 DeepSeek V4、Qwen3、甚至还有未知的国产大模型，只要挂到配置文件里你们根本不用动业务代码——这才叫真正的“从容”。

P.S.

- 想kankangeng完整的特性列表，Ke以去官方文档翻翻；我这儿不贴链接，你自己搜呗 😜。

P.P.S.

- Zui后提醒一句：别忘了给你的 master_key 加点安全措施，不然别人随便调你的网关，那可真是尴尬呀！哈哈，好啦，这篇就先写到这儿。祝你玩转 LiteLLM，AI 项目飞起！ 🚀

---