1. 项目概述：LiteLLM 是什么，它解决的不是“模型调用”而是“模型调度”的本质问题

LiteLLM 这个名字刚出现时，很多人第一反应是“又一个轻量级 LLM 框架？”——其实完全想偏了。它压根不训练模型、不优化推理速度、不压缩参数，甚至不碰模型权重文件。它干的是一件更底层、更琐碎、但在真实业务中每天要重复上百次的事：统一调度不同厂商、不同协议、不同认证方式、不同返回结构的大模型 API。你可以把它理解成大模型世界的“HTTP 客户端抽象层”，但比 HTTP 客户端难得多——因为 OpenAI 的/v1/chat/completions、Anthropic 的/messages、Google 的/v1beta/models/{model}:generateContent、Ollama 的/api/chat，它们的请求体字段名、响应嵌套层级、流式数据格式、错误码定义、重试逻辑、token 计数规则，全都不一样。我去年在某跨平台智能客服项目里，光是写一个能同时对接 4 家模型服务商的通用封装层，就写了 370 行条件判断和字段映射代码，还漏掉了 Azure OpenAI 的api-version头和 Groq 的temperature必填校验。LiteLLM 就是把这堆“脏活累活”提前干完了。它不替代你选模型，但它让你换模型时，不用改一行业务逻辑代码；它不提升单次调用性能，但它让整个系统的模型策略切换从“停机发布”变成“配置热更新”。对中小团队来说，它省下的不是开发时间，而是技术决策成本——你不再需要为每个新接入的模型单独招一个熟悉其 SDK 的工程师。它的核心价值，从来不在“轻”，而在“通”。

2. 核心设计思路拆解：为什么 LiteLLM 不做模型推理，却成了工程落地的隐形枢纽

2.1 本质定位：API 网关层的语义标准化，而非计算层优化

很多初学者会误以为 LiteLLM 是为了“加速本地小模型运行”，这是根本性误解。它的 GitHub README 第一行就写着：“A drop-in replacement for OpenAI's API that supports 100+ LLMs”。关键词是“drop-in replacement”（即插即用替换）和“supports”（支持），而不是“runs”（运行）或“hosts”（托管）。它本身不加载模型权重，不启动 CUDA 上下文，不管理 GPU 显存。它就是一个 Python 进程里的“协议翻译器”：接收标准 OpenAI 格式的请求（比如{"model": "gpt-4o", "messages": [...]}），根据内部路由规则，将其转换成目标服务商要求的格式（比如 Anthropic 需要{"model": "claude-3-5-sonnet-20240620", "messages": [...], "max_tokens": 4096}），发出去，再把原始响应（比如 Anthropic 返回的{"content": [{"type": "text", "text": "..." }], "usage": {...}}）重新包装成 OpenAI 风格（{"choices": [{"message": {"content": "..."}}, ...], "usage": {...}}）。这个过程看似简单，实则暗藏大量工程陷阱。比如，OpenAI 的stream字段是布尔值，而 Gemini 的流式接口必须用Content-Type: text/event-stream头且响应是纯文本 SSE 格式；Ollama 的keep_alive参数在 LiteLLM 中被映射为--keep-alive命令行参数，但实际调用时需通过subprocess启动进程并维持长连接。LiteLLM 的聪明之处在于，它把所有这些差异都封装进一个个ModelResponse类和completion()函数的参数签名里，对外暴露的永远是litellm.completion(model="anthropic/claude-3-haiku", messages=[...])这种统一接口。这种设计直接规避了“为每个模型写一套 SDK”的泥潭，让业务代码彻底与供应商解耦。

2.2 架构分层：三层抽象如何实现“一次编码，百处适配”

LiteLLM 的内部架构清晰划分为三层，每一层都对应一个关键工程痛点：

• 最上层：统一 API 接口层（litellm.completion,litellm.embedding,litellm.image_generation）
  这是开发者唯一需要接触的入口。它强制所有模型调用都遵循 OpenAI 的参数命名习惯（model,messages,temperature,max_tokens），哪怕底层是 Google 的 Gemini 或本地的 Llama.cpp。这种“强约定”看似限制自由，实则极大降低了认知负荷。我见过太多团队，同一个项目里temperature有的叫temp，有的叫sampling_temperature，有的甚至要传{"top_p": 0.9, "top_k": 40}这种复合结构。LiteLLM 用一层薄薄的参数归一化，就把混乱收束了。

• 中间层：适配器路由层（litellm.main.py中的get_llm_provider和get_api_base）
  这是 LiteLLM 的“大脑”。它根据model字符串前缀（如"gpt-4o"→"openai"，"claude-3-haiku"→"anthropic"，"llama-3-8b"→"ollama"）动态选择对应的适配器模块。每个适配器（如litellm/llms/anthropic/anthropic.py）只负责两件事：一是把标准输入转成自家协议，二是把自家响应转回标准输出。这种“一个模型一个适配器”的设计，让新增模型支持变得极其简单——你只需要复制一个模板文件，填入 3~5 个关键字段映射关系，就能完成接入。我们团队曾用 2 小时就完成了对某国产大模型私有 API 的适配，核心工作就是搞清它怎么传system_prompt（放在messages[0].content还是独立system字段）和怎么解析finish_reason（是"stop"还是"length"）。

• 最底层：网络通信与重试层（基于httpx.AsyncClient的异步封装）
  这里藏着 LiteLLM 真正的硬核能力。它不是简单用requests.get()，而是深度定制了异步 HTTP 客户端：支持自定义超时（timeout=60.0）、连接池复用、自动重试（num_retries=3）、熔断降级（fallbacks=["gpt-3.5-turbo"]）、以及最重要的——token 使用量精准统计。很多开源方案只返回response.usage.total_tokens，但 LiteLLM 能精确拆分prompt_tokens和completion_tokens，甚至对流式响应也能实时累加。这直接关系到成本核算——没有这个能力，你根本没法做按 token 计费的精细化运营。

2.3 关键取舍：为什么放弃“本地模型推理”，专注“API 协议桥接”

LiteLLM 团队在早期就做了个非常清醒的决定：绝不涉足模型加载与推理引擎。这个取舍背后是深刻的工程权衡。本地模型推理（如 llama.cpp、llm.c、vLLM）涉及 CUDA 版本兼容、量化精度选择（Q4_K_M vs Q5_K_S）、KV Cache 内存管理、PagedAttention 实现等复杂问题，每个方向都是一个博士课题。而 API 调度的难点在于“碎片化”而非“高精尖”——它要处理的是 100+ 家服务商的文档差异、认证方式（API Key、Bearer Token、JWT、OAuth2）、速率限制头（X-RateLimit-Remaining）、错误重试策略（指数退避还是固定间隔）、以及各种奇奇怪怪的非标字段（比如某厂商要求X-Request-ID必须是 UUID4 格式）。前者需要算法专家，后者需要资深 API 工程师。LiteLLM 选择了后者，因为它直击中小企业最痛的点：模型供应商随时可能变更、下线、涨价，你的系统必须能无缝切换，而不是推倒重来。我们有个客户，原用 Azure OpenAI，因合规要求必须迁移到某国产云厂商。如果没 LiteLLM，他们得重写所有 prompt 工程模块、重测所有测试用例、重新训练 RAG 的 chunking 策略；用了 LiteLLM，只改了一行配置model="qwen2-72b"，重启服务，全部 OK。这种“可迁移性”，才是它成为事实标准的核心原因。

3. 核心细节与实操要点：从零开始搭建一个生产级 LiteLLM 代理服务

3.1 环境准备与依赖安装：为什么推荐pip install 'litellm[extra]'

LiteLLM 的基础包litellm只包含核心路由和 OpenAI/Anthropic 等主流适配器。但真实生产环境远比这复杂。比如你要对接本地 Ollama，就需要ollama包；要用 Google Vertex AI，就得装google-auth；要支持 Azure OpenAI 的 RBAC 权限校验，得有azure-identity。这就是为什么官方强烈推荐pip install 'litellm[extra]'——方括号里的extra是一个“可选依赖集合”，它会自动安装所有已知模型后端所需的 SDK。我实测过，不带[extra]直接pip install litellm，当你第一次调用litellm.completion(model="ollama/llama3")时，会抛出ModuleNotFoundError: No module named 'ollama'，然后你得去查文档、装包、再试，循环往复。而[extra]一次性解决所有依赖，省下至少半小时排查时间。另外，务必注意 Python 版本：LiteLLM 1.40+ 要求 Python 3.9+，因为用到了typing.Union的新语法和asyncio.timeout。我们曾在一个遗留项目（Python 3.8）上强行降级到 LiteLLM 1.35，结果发现它不支持gemini-1.5-flash的新 streaming 格式，最终还是升级了解释器。所以，环境检查的第一步永远是python --version和pip list | grep litellm。

3.2 配置文件设计：litellm.yaml如何实现“模型即配置”

LiteLLM 最强大的能力之一，是把模型路由逻辑从代码里抽出来，变成纯 YAML 配置。这不仅是运维友好，更是架构演进的关键。一个典型的litellm.yaml长这样：

model_list: - model_name: gpt-4o litellm_params: model: gpt-4o api_key: sk-... api_base: https://api.openai.com/v1 - model_name: claude-3-haiku litellm_params: model: claude-3-haiku-20240307 api_key: sk-ant-api03-... - model_name: llama3-8b litellm_params: model: ollama/llama3 api_base: http://localhost:11434 - model_name: qwen2-72b litellm_params: model: qwen/qwen2-72b-instruct api_key: your-qwen-key api_base: https://dashscope.aliyuncs.com/api/v1 # 全局 fallback 策略：当主模型失败时，自动降级 litellm_settings: fallbacks: - gpt-4o: [gpt-3.5-turbo] - claude-3-haiku: [claude-2.1]

这个配置的价值在于：它让模型策略变成了可版本控制、可灰度发布的配置项。你可以把litellm.yaml放进 Git，每次模型切换都走 Code Review；可以为不同环境（dev/staging/prod）维护不同配置；甚至可以用 Consul 或 etcd 动态下发配置，实现秒级模型切换。我们有个项目，线上突发gpt-4o限流，运维同学直接在配置中心把fallbacks改成gpt-4o: [gpt-4-turbo]，30 秒后流量就切过去了，业务无感。而如果这些逻辑硬编码在 Python 里，每次修改都要走 CI/CD 流水线，至少 5 分钟。这里有个关键细节：model_name是你在业务代码里调用时用的名字（litellm.completion(model="gpt-4o", ...)），而litellm_params.model才是实际发给服务商的模型 ID。这种双层命名，让你可以自由映射——比如把gpt-4o这个业务名，指向 Azure 上的gpt-4o-2024-05-13（带版本号），避免服务商悄悄升级导致行为突变。

3.3 启动代理服务：litellm --config litellm.yaml背后的进程管理

LiteLLM 自带一个开箱即用的 FastAPI 代理服务，命令就是litellm --config litellm.yaml。它会在http://0.0.0.0:4000启动一个标准 OpenAI 兼容的 API 服务。但直接这么跑，在生产环境是危险的。我们必须加上几个关键参数：

• --port 4000：显式指定端口，避免默认端口冲突；
• --host 0.0.0.0：绑定到所有网卡，供外部访问；
• --api_key sk-litellm-xxx：为代理服务本身设置一个密钥，所有请求必须带Authorization: Bearer sk-litellm-xxx，否则拒绝。这是最基础的安全屏障，防止你的代理被公开扫描滥用；
• --debug：仅开发时开启，它会打印每一步的请求/响应详情，对调试字段映射错误至关重要；
• --timeout 60：全局超时设为 60 秒，避免某个慢模型拖垮整个服务。

更重要的是进程管理。别用nohup litellm ... &这种原始方式。我们生产环境一律用systemd（Linux）或pm2（Node.js 生态常用，但也可托管 Python 进程）。一个典型的systemdservice 文件/etc/systemd/system/litellm.service：

[Unit] Description=LiteLLM Proxy Service After=network.target [Service] Type=simple User=llm WorkingDirectory=/opt/litellm ExecStart=/usr/bin/python3 -m litellm --config /opt/litellm/litellm.yaml --port 4000 --host 0.0.0.0 --api_key sk-litellm-prod-2024 --timeout 60 Restart=always RestartSec=10 Environment=PATH=/usr/bin:/usr/local/bin Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target

启用它：sudo systemctl daemon-reload && sudo systemctl enable litellm && sudo systemctl start litellm。这样做的好处是：进程崩溃自动重启、日志统一收集（journalctl -u litellm -f）、资源限制（可加MemoryLimit=2G）、以及最重要的——优雅关闭。当你要更新配置时，sudo systemctl reload litellm会发送SIGTERM，LiteLLM 会等待当前所有请求处理完再退出，不会中断正在 stream 的响应。

3.4 业务代码集成：如何用 3 行代码接入现有系统

假设你有一个用 Flask 写的旧系统，里面原来直接调用 OpenAI：

# 旧代码：硬编码 OpenAI import openai openai.api_key = "sk-..." response = openai.ChatCompletion.create( model="gpt-4o", messages=[{"role": "user", "content": "你好"}] )

换成 LiteLLM，只需三步：

1. 安装依赖：pip install litellm
2. 设置环境变量（或在代码里硬编码，但不推荐）：

   export LITELLM_API_KEY="sk-litellm-prod-2024" export LITELLM_BASE_URL="http://localhost:4000"

3. 替换调用：

   import litellm # 一行代码，完全兼容 OpenAI 的参数 response = litellm.completion( model="gpt-4o", # 这里用的是 litellm.yaml 里的 model_name messages=[{"role": "user", "content": "你好"}] )

看到没？连messages的结构都不用改。response.choices[0].message.content这种取值方式，和 OpenAI SDK 完全一致。这就是“drop-in replacement”的威力。更进一步，如果你的系统已经用了 OpenAI 的AsyncOpenAI，LiteLLM 也提供litellm.acompletion()，用法一模一样，只是把await openai.chat.completions.create(...)换成await litellm.acompletion(...)。我们有个实时对话系统，原来用asyncio.gather()并发调用 5 个 OpenAI 请求，改成 LiteLLM 后，只改了导入语句和函数名，性能监控数据显示 P95 延迟反而下降了 12%，因为 LiteLLM 的异步客户端做了连接池优化。

提示：首次集成时，务必开启--debug参数，并用curl手动测试代理服务是否正常：

curl -X POST "http://localhost:4000/v1/chat/completions" \ -H "Authorization: Bearer sk-litellm-prod-2024" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "测试"}] }'

如果返回{"error": {"message": "Authentication error", ...}}，说明--api_key没配对；如果返回{"error": {"message": "Model not found", ...}}，说明litellm.yaml里的model_name和调用时传的不一致。

4. 实操过程与核心环节实现：从本地调试到生产部署的完整链路

4.1 本地开发调试：用litellm --debug抓住每一个字段映射错误

本地调试是 LiteLLM 落地最关键的环节。很多问题不是模型不工作，而是字段映射错了。比如，你传了temperature=0.7，但某国产模型实际需要sampling_temperature=0.7，LiteLLM 默认会忽略这个字段，导致模型用默认值（可能是 1.0）生成，结果天马行空。--debug参数就是你的“显微镜”。启动命令：

litellm --config litellm.yaml --debug --port 4000

然后发一个请求：

curl -X POST "http://localhost:4000/v1/chat/completions" \ -H "Authorization: Bearer sk-litellm-prod-2024" \ -H "Content-Type: application/json" \ -d '{"model": "qwen2-72b", "messages": [{"role": "user", "content": "你好"}], "temperature": 0.3}'

你会在终端看到类似这样的详细日志：

DEBUG:litellm:Received request for model=qwen2-72b DEBUG:litellm:Mapping input: temperature=0.3 -> sampling_temperature=0.3 DEBUG:litellm:Sending request to https://dashscope.aliyuncs.com/api/v1/chat/completions DEBUG:litellm:Request body: {"model": "qwen/qwen2-72b-instruct", "input": {"messages": [...]}, "parameters": {"sampling_temperature": 0.3}} DEBUG:litellm:Response status: 200 DEBUG:litellm:Response body: {"output": {"text": "你好！很高兴见到你。"}, "usage": {"input_tokens": 5, "output_tokens": 12}} DEBUG:litellm:Mapping response to OpenAI format...

看到Mapping input和Mapping response这两行，你就知道 LiteLLM 是否正确识别并转换了你的参数。如果日志里没有Mapping input: temperature=0.3，说明该模型适配器还没支持temperature字段，你需要去 GitHub 提 Issue 或自己 PR。我们曾遇到某模型把max_tokens解析成max_gen_len，但 LiteLLM 的适配器里写的是max_new_tokens，结果模型一直忽略这个参数。通过--debug日志，3 分钟就定位到问题，改一行代码提交 PR，当天就被合并。

4.2 生产环境部署：Nginx 反向代理 + TLS 加密的最小安全集

LiteLLM 代理服务本身不带 HTTPS，生产环境必须前置反向代理。我们用 Nginx，配置极简：

upstream litellm_backend { server 127.0.0.1:4000; } server { listen 443 ssl http2; server_name llm-api.yourcompany.com; ssl_certificate /etc/letsencrypt/live/llm-api.yourcompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/llm-api.yourcompany.com/privkey.pem; location /v1/ { proxy_pass http://litellm_backend/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 重要：透传 Authorization 头，LiteLLM 靠它鉴权 proxy_pass_request_headers on; } # 拒绝所有非 /v1/ 路径的请求，防扫描 location / { return 404; } }

这个配置实现了三个关键安全目标：

1. 传输加密：所有流量走 HTTPS，防止 API Key 在传输中被嗅探；
2. 请求头透传：proxy_pass_request_headers on确保Authorization: Bearer sk-litellm-prod-2024能到达 LiteLLM 进程；
3. 路径收敛：只开放/v1/前缀，其他路径一律 404，大幅减少攻击面。

注意：LiteLLM 的--api_key是服务级密钥，用于验证谁有权调用这个代理；而业务方调用时，Authorization头里传的，是你配置在litellm.yaml里的各家模型的api_key（如sk-ant-api03-...）。这两个密钥层级不同，不能混淆。我们曾有个安全审计发现，有人把模型的api_key直接当--api_key用了，导致所有用户都能用这个密钥调用任意模型，立刻下线整改。

4.3 成本监控与用量分析：如何用litellm.success_callback实现细粒度记账

LiteLLM 最被低估的能力之一，是它的回调钩子（callback）。通过litellm.success_callback = ["logging", "custom_logger"]，你可以在每次成功调用后，拿到完整的response对象，里面包含精确的prompt_tokens和completion_tokens。我们用这个做了个简单的成本计算器：

import litellm from datetime import datetime def cost_calculator( kwargs, # 调用时的原始参数 completion_response, # LiteLLM 返回的响应 start_time, end_time # 调用耗时 ): model = kwargs["model"] prompt_tokens = completion_response["usage"]["prompt_tokens"] completion_tokens = completion_response["usage"]["completion_tokens"] # 按模型查单价表（单位：美元/千 token） pricing = { "gpt-4o": {"input": 0.005, "output": 0.015}, "claude-3-haiku": {"input": 0.00025, "output": 0.00125}, "qwen2-72b": {"input": 0.0008, "output": 0.0008} # 国产模型通常便宜 } if model in pricing: cost = (prompt_tokens * pricing[model]["input"] + completion_tokens * pricing[model]["output"]) / 1000 print(f"[{datetime.now().isoformat()}] {model} cost: ${cost:.6f} " f"(p:{prompt_tokens}, c:{completion_tokens})") litellm.success_callback = [cost_calculator]

把这个脚本和litellm.yaml放一起，启动时加--callbacks cost_calculator，所有调用的成本就实时打印出来了。更进一步，你可以把cost发到 Prometheus，用 Grafana 做大盘监控，看哪个业务线 token 消耗最多，哪个模型性价比最高。我们有个客户，靠这个发现了 RAG 检索模块的top_k=10设置过大，导致每次查询都多花了 3 倍 prompt tokens，调整后月成本直降 40%。

4.4 故障演练与熔断测试：用litellm.fallbacks和litellm.num_retries构建韧性

生产环境没有不挂的服务。LiteLLM 的fallbacks和num_retries是构建韧性的两大支柱。我们做过一次故障演练：手动iptables -A OUTPUT -d api.openai.com -j DROP，模拟 OpenAI 服务不可达。预期行为是：当gpt-4o调用失败 3 次后，自动降级到gpt-3.5-turbo。但第一次演练失败了——因为num_retries默认是 0，必须显式配置。我们在litellm.yaml里加了：

litellm_settings: num_retries: 3 fallbacks: - gpt-4o: [gpt-3.5-turbo, claude-2.1]

再次演练，成功。但又发现新问题：降级后，gpt-3.5-turbo的max_tokens是 4096，而gpt-4o是 16384，业务代码里传了max_tokens=10000，结果gpt-3.5-turbo直接报错max_tokens must be <= 4096。这说明 fallback 不是无损的。解决方案有两个：

1. 在业务层做参数适配：调用前检查当前模型的litellm.get_model_info(model)，动态调整max_tokens；
2. 在 LiteLLM 层做兜底：用litellm.input_callback钩子，在请求发出前拦截并修正参数。

我们选了方案 2，写了个input_callback：

def max_tokens_guard(kwargs): model = kwargs["model"] max_tokens = kwargs.get("max_tokens", 4096) # 对 gpt-3.5-turbo，强制 cap 到 4096 if model == "gpt-3.5-turbo" and max_tokens > 4096: kwargs["max_tokens"] = 4096 print(f"Warning: capped max_tokens to 4096 for {model}") litellm.input_callback = [max_tokens_guard]

现在，无论业务代码传多大的max_tokens，系统都能安全降级。这种“防御性编程”，是 LiteLLM 在生产环境站稳脚跟的关键。

5. 常见问题与排查技巧实录：那些文档里不会写的坑和解法

5.1 典型问题速查表：从 401 到 429，每个错误码背后的真相

这个表格是我们团队踩坑半年总结出来的。特别强调一点：LiteLLM 的 429 错误，99% 是上游服务商的限流，不是 LiteLLM 自己限流。LiteLLM 本身不内置速率限制（除非你用litellm.set_verbose(True)开启了日志限流），它只是忠实地把上游的 429 透传回来。所以看到 429，第一反应不是调 LiteLLM 配置，而是去查对应服务商的 dashboard。

5.2 高级避坑技巧：三个文档里绝不会提，但能救你命的经验

技巧一：model_name命名不要用斜杠/，用中划线-
LiteLLM 内部用model.split("/")来解析模型名。如果你在litellm.yaml里写model_name: "my-company/gpt-4o"，那么litellm.completion(model="my-company/gpt-4o")会被解析成 provider=my-company，model=gpt-4o，然后 LiteLLM 去找my-company这个适配器，当然找不到。正确做法是model_name: "my-company-gpt-4o"，然后在litellm_params里指定真实的model: "gpt-4o"。我们吃过这个亏，花了 2 小时 debug，最后发现是命名规范问题。

技巧二：流式响应（stream=True）必须用litellm.stream_chunk_builder()处理
很多新手以为stream=True返回的就是标准的 SSE 流，直接for chunk in response:就行。错。LiteLLM 的流式响应是一个 generator，但每个chunk是一个dict，不是字符串。你必须用litellm.stream_chunk_builder()把它们组装成完整的choices[0].delta.content。官方文档里这段代码藏得很深：

response = litellm.completion(model="gpt-4o", messages=[...], stream=True) for chunk in response: # chunk 是 {'choices': [{'delta': {'content': 'h'}, 'index': 0}]} # 你需要手动拼接 content content = litellm.stream_chunk_builder(chunk) # 这个函数帮你搞定 print(content, end="", flush=True)

不这么做，你会得到一堆碎片化的字符，无法组成完整句子。

技巧三：litellm.token_counter()是唯一可信的 token 计数器
别信tiktoken或transformers的 tokenizer。不同模型对同一段文本的 token 计数可能差 10%。LiteLLM 提供了litellm.token_counter(model="gpt-4o", text="hello world")，它调用的是各家模型官方的计数 API（如 OpenAI 的/v1/chat/completions带max_tokens=1的试探请求），结果 100% 准确。我们做 RAG 的 chunk size 控制，全部用这个函数，确保切分的 chunk 绝对不会超模型上下文窗口。

5.3 性能调优实录：从 200ms 到 80ms 的三次关键优化

我们有个高并发摘要服务，P95 延迟从 200ms 降到 80ms，靠的是三次精准优化：

1. 第一次：启用连接池
   默认 LiteLLM 每次请求都新建 HTTP 连接，开销巨大。在litellm.yaml里加：

   litellm_settings: connection_pool: true

   效果：延迟下降 35ms（165ms → 130ms）。原理是复用 TCP 连接，避免三次握手和 TLS 握手。

2. 第二次：禁用verify（仅内网）
   我们的 Ollama 服务在内网，