Codex接入DeepSeek后Token消耗失控？LiteLLM网关配置实战解决-平芜编程栈

如果你正在使用 Codex 或 Claude Code 这类 AI 编程助手，并且为了追求更优的成本和性能，将后端模型切换到了 DeepSeek，那么你很可能正面临一个棘手的问题：Token 消耗速度远超预期，账单在不知不觉中飙升。

这并非个例。许多开发者在成功将 Codex 接入 DeepSeek 后，最初的兴奋很快被“Token 怎么用得这么快？”的困惑所取代。表面上看，DeepSeek 的 API 调用成功了，代码补全、对话问答一切正常，但后台的用量统计却像开了闸的水龙头，止不住地流。问题往往不在于 DeepSeek 模型本身，而在于集成链路中的一个关键环节被忽略了。

本文将深入剖析“Codex 接入 DeepSeek 后疯狂烧 Token”这一现象的根源。核心结论先行：问题的症结大概率出在缺乏一个具备流量控制、成本管理和错误重试机制的“智能网关”上。直接、裸连 API 的方式，让每一次请求、每一次超时重试、每一次非预期的大上下文交互，都在直接消耗你的 Token 额度。而解决之道，就是引入一个轻量级但功能强大的中间层——这正是LiteLLM这类工具的核心价值。

我们将从一个具体的错误场景出发，拆解 Token 消耗失控的几种常见模式，然后通过一步步的实战，展示如何利用 LiteLLM 搭建一个管理网关，不仅解决“烧 Token”的问题，更能实现多模型路由、失败回退、用量监控等生产级功能。读完本文，你将获得一套可立即部署的解决方案，让你在享受 DeepSeek 强大能力的同时，牢牢掌控成本。

1. 问题诊断：你的 Token 到底被谁“烧”掉了？

在着手解决之前，我们必须先弄清楚 Token 被异常消耗的几种典型场景。盲目优化往往事倍功半。

1.1 场景一：无限制的重试风暴

这是最常见也是最隐蔽的消耗源。当网络出现波动、DeepSeek API 暂时性限流或返回非 200 状态码时，如果你的客户端代码简单地采用了“失败即重试”的策略，且没有设置重试次数上限、退避机制和重试条件过滤，就会引发灾难。

错误示例（伪代码逻辑）：

# 危险的重试逻辑 def call_deepseek_with_retry(prompt, max_retries=10): for i in range(max_retries): try: response = requests.post(api_url, json=payload) if response.status_code == 200: return response.json() else: # 对任何非200状态码都重试 time.sleep(1) # 简单的固定间隔 continue except Exception as e: time.sleep(1) continue return None

问题分析：

400 Bad Request（参数错误）：例如api error: 400 param incorrect。这种错误是客户端的请求格式问题，重试多少次都不会成功，但每次重试都会消耗 Token（因为请求已送达API并计费）。
429 Too Many Requests（限流）：如果立即重试，会加剧限流，形成恶性循环。
5xx 服务器错误：可能需要稍后重试，但无退避机制的密集重试会给服务器带来压力。

每一次重试，只要请求包含了你的 API Key 和消息体，DeepSeek 的计费系统就可能将其视为一次有效请求并进行 Token 计数。你的 Token 就在这种无意义的循环中被快速耗尽。

1.2 场景二：上下文管理失控与“长尾”消耗

DeepSeek 模型有上下文窗口限制（如 128K Tokens）。Codex 等助手为了理解当前文件，可能会将整个文件内容、多个相关文件甚至聊天历史都塞进上下文。

消耗过程：

初始请求：你问了一个关于functionA的问题，Codex 将functionA所在的 500 行文件内容作为上下文发送。消耗 Token: X。
后续对话：你接着问functionA里的一个细节。理想情况下，助手应该能利用之前的上下文。但如果集成方式不当，每次对话都可能被处理为一个全新的、包含全部历史消息的请求。
“长尾”效应：一次对话来回 10 次，如果每次都是全量上下文，总消耗 Token ≈ 10X。而如果助手能智能地管理上下文（例如只发送最近几轮对话和必要代码块），总消耗可能只有 2X-3X。

直接调用 API 时，上下文管理的责任完全落在了客户端。如果客户端逻辑不够优化，就会产生大量的冗余 Token 消耗。

1.3 场景三：非预期触发与配置误解

流式响应（Streaming）：启用流式响应时，一些库或自定义客户端可能处理不当，导致连接提前中断或重复读取，从而触发额外的请求或计费。
模型参数误解：例如，错误地启用了 DeepSeek-Reasoner 模型的thinking模式（thinking={"type": "enabled"}），该模式会输出模型的推理过程，这会显著增加输出 Token 的数量，而你可能并不需要这些内容。
免费额度与禁用组织：搜索热词中出现的api error: 400 this organization has been disabled.和token exchange failed: token endpoint returned status 403 forbidden: country等错误，通常意味着账户、地域或支付问题。在解决这些问题之前，盲目的重试调用同样是无效的 Token 消耗。

1.4 核心结论

Token 异常消耗的本质是“缺乏缓冲层和管理策略”。你的应用程序直接面对 DeepSeek API，所有流量的细节、错误和成本都暴露无遗。我们需要一个“智能管家”站在中间，它负责：控制流量、管理上下文、重试策略、监控用量。这就是 LiteLLM Proxy（AI Gateway）要扮演的角色。

2. 解决方案核心：LiteLLM 网关架构解析

LiteLLM 不仅仅是一个统一的 LLM 调用 SDK，其Proxy（AI Gateway）功能才是解决成本失控问题的利器。它在你和 DeepSeek API 之间插入了一个透明代理层。

2.1 传统直连架构 vs. LiteLLM 网关架构

维度	传统直连架构	LiteLLM 网关架构
请求路径	App → DeepSeek API	App → LiteLLM Proxy → DeepSeek API
重试控制	由 App 实现，难以统一	由网关统一配置（次数、退避、条件）
限流与熔断	需自行实现，复杂	网关内置，可配置每秒请求数（RPS）限制
上下文管理	App 全权负责，易冗余	可结合网关进行初步的请求过滤和裁剪
多模型/降级	硬编码在 App 中，变更需发布	网关动态路由，支持主备模型自动切换
成本监控	依赖各平台后台，滞后	网关提供实时日志和用量统计
配置管理	API Key 等散落在客户端	集中配置在网关，客户端仅需网关地址

2.2 LiteLLM 如何拦截“烧 Token”行为

智能重试：网关可以配置只对特定错误（如网络超时、5xx错误）进行重试，而对客户端错误（4xx）立即失败返回，避免无意义消耗。
请求缓存：对于完全相同的提示词（prompt），网关可以配置缓存，直接返回缓存结果，对调试和重复问题特别有效。
用量统计与预算：网关可以按项目、用户或API Key维度统计Token消耗，并设置软预算，超标后告警或阻断。
统一错误处理：将 DeepSeek 特定的错误信息转换为统一的格式，方便客户端处理，减少因解析错误导致的重复请求。

接下来，我们将通过实战，搭建这样一个网关，并配置它来保护你的 DeepSeek Token。

3. 环境准备与 LiteLLM 安装

3.1 基础环境要求

Python: 3.8 或更高版本。这是 LiteLLM 的运行基础。
包管理工具:pip（Python 自带）或pipenv/poetry（推荐用于项目管理）。
操作系统: Windows, macOS, Linux 均可。本文以 Linux/macOS 命令行示例为主，Windows 用户可在 PowerShell 或 WSL 中操作。
DeepSeek API Key: 你需要一个有效的 DeepSeek API Key。请前往 DeepSeek 官方平台注册并获取。

3.2 安装 LiteLLM

创建并进入一个干净的虚拟环境是最佳实践，可以避免包依赖冲突。

# 1. 创建项目目录并进入 mkdir litellm-proxy-deepseek && cd litellm-proxy-deepseek # 2. 创建 Python 虚拟环境（可选但强烈推荐） python -m venv venv # 3. 激活虚拟环境 # Linux/macOS: source venv/bin/activate # Windows: # venv\Scripts\activate # 4. 升级 pip pip install --upgrade pip # 5. 安装 litellm pip install litellm

安装完成后，可以通过以下命令验证：

python -c "import litellm; print(f'LiteLLM version: {litellm.__version__}')"

4. 最小化启动：你的第一个 LiteLLM 代理网关

我们先跑通一个最简单的网关，验证基础功能。

4.1 设置环境变量

将你的 DeepSeek API Key 设置为环境变量。这样比硬编码在代码中更安全。

# 在当前终端会话中设置（临时） export DEEPSEEK_API_KEY='your_actual_deepseek_api_key_here' # 对于Windows PowerShell: # $env:DEEPSEEK_API_KEY='your_actual_deepseek_api_key_here' # 永久设置（添加到 ~/.bashrc, ~/.zshrc 或系统环境变量） # echo 'export DEEPSEEK_API_KEY=your_key' >> ~/.bashrc # source ~/.bashrc

4.2 创建配置文件`config.yaml`

LiteLLM 代理通过 YAML 文件进行配置。创建一个config.yaml文件：

# config.yaml model_list: - model_name: deepseek-chat # 给这个模型配置起个别名，客户端将使用这个别名 litellm_params: model: deepseek/deepseek-chat # LiteLLM 内部识别的模型标识符 api_key: os.environ/DEEPSEEK_API_KEY # 从环境变量读取Key api_base: https://api.deepseek.com # DeepSeek API 地址 # 你可以在这里添加更多模型作为备份或用于不同用途 # - model_name: deepseek-coder # litellm_params: # model: deepseek/deepseek-coder # api_key: os.environ/DEEPSEEK_API_KEY # 通用设置 litellm_settings: drop_params: true # 丢弃客户端发送的未识别参数，避免错误 set_verbose: true # 开启详细日志，调试时有用

关键解释：

model_name: 这是暴露给客户端的“虚拟模型名”。你的 Codex 或其它应用将向http://网关地址/v1/chat/completions发送请求，并在请求体中指定"model": "deepseek-chat"。
litellm_params.model: 必须使用deepseek/前缀，这是 LiteLLM 识别 DeepSeek 模型的约定。
api_key:os.environ/DEEPSEEK_API_KEY是一种安全引用方式，避免密钥泄露在配置文件中。

4.3 启动代理服务器

使用以下命令启动网关，默认监听在http://0.0.0.0:4000。

litellm --config ./config.yaml

如果一切正常，你将看到类似以下的输出：

INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:4000 (Press CTRL+C to quit) LiteLLM: Proxy running on http://0.0.0.0:4000

4.4 测试网关连通性

打开另一个终端，使用curl命令测试网关是否工作：

curl -X POST http://localhost:4000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-1234" \ # LiteLLM 代理的认证可自定义，这里用任意值 -d '{ "model": "deepseek-chat", "messages": [ {"role": "user", "content": "Hello, what is the capital of France?"} ], "max_tokens": 50 }'

预期成功响应：

{ "id": "chatcmpl-xxx", "object": "chat.completion", "created": 1234567890, "model": "deepseek/deepseek-chat", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "The capital of France is Paris." }, "finish_reason": "stop" }], "usage": { "prompt_tokens": 15, "completion_tokens": 7, "total_tokens": 22 } }

注意响应中的model字段显示的是实际模型deepseek/deepseek-chat，但你的请求使用的是别名deepseek-chat。同时，usage字段清晰地展示了本次请求消耗的 Token 数，这是成本监控的基础。

至此，一个最基本的、能工作的 LiteLLM 代理网关已经搭建完成。但这还不够，它还没有解决我们开头提到的“烧 Token”问题。接下来，我们将为这个网关注入“防烧”能力。

5. 核心防御配置：给网关装上“节流阀”和“保险丝”

我们将修改config.yaml，增加重试、限流、缓存等关键配置。

5.1 配置智能重试策略

在model_list的每个模型配置下，添加litellm_params的retry策略。

# config.yaml (增强版) model_list: - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-coder # 这里以coder模型为例，chat模型同理 api_key: os.environ/DEEPSEEK_API_KEY api_base: https://api.deepseek.com # ！！！核心重试配置 ！！！ retry: # 定义重试逻辑 # 重试次数：最多2次（加上原始请求，总共最多3次调用） # 设置较低值，防止无限重试消耗Token num_retries: 2 # 重试延迟策略：指数退避，避免雪崩 # 第一次重试等待 1秒，第二次等待 2秒 delay: 1 backoff_factor: 2 # 仅对以下状态码进行重试 # 429: 限流，稍后重试是合理的 # 500, 502, 503, 504: 服务器内部错误或临时不可用 # 注意：不包括 400, 401, 403, 404 等客户端错误 status_codes: [429, 500, 502, 503, 504] # 对哪些异常进行重试 exceptions: [Timeout, ConnectionError]

这个配置如何防止“烧 Token”？

num_retries: 2：将重试次数限制在可控范围。假设一个错误请求本身消耗 100 Tokens，无限制重试可能消耗上千。现在最多只消耗 300 Tokens（1次原始+2次重试）。
status_codes白名单：这是最关键的一环。它明确告诉网关：只有遇到服务器端错误（5xx）或限流（429）时才重试。对于400 Bad Request（参数错误）、401 Unauthorized（密钥错误）、403 Forbidden（组织被禁用/地域限制）等客户端错误，网关将立即返回失败，绝不重试，从而避免了因配置错误导致的 Token 浪费。

5.2 配置请求限流（Rate Limiting）

在全局litellm_settings或针对特定模型配置model_info来设置速率限制。

# config.yaml (续) model_list: - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY api_base: https://api.deepseek.com retry: num_retries: 2 delay: 1 backoff_factor: 2 status_codes: [429, 500, 502, 503, 504] exceptions: [Timeout, ConnectionError] # 模型级别的速率限制 model_info: # 限制该模型每秒最多处理 10 个请求 # 防止客户端bug或异常流量导致突发大量请求 rpm: 600 # Requests per minute (10 RPS) # 也可以设置 tpm (Tokens per minute) 限制，但需要网关计算，负载较高 general_settings: # 全局速率限制（可选，与模型级别互补） # 对整个代理服务器的总请求速率进行限制 master_key: sk-1234 # 设置一个主密钥，用于管理API max_parallel_requests: 50 # 最大并行请求数，防止过载

限流的作用：

防误操作：如果前端或客户端代码出现 Bug，在一个循环内疯狂发送请求，限流会将其拦截在网关层，DeepSeek API 端只会收到有限数量的请求，避免了 Token 的灾难性消耗。
平滑流量：避免应用突发流量对 DeepSeek API 造成冲击，从而减少因触发 API 限流（429）而导致的重试。

5.3 （可选）启用请求缓存

对于开发、调试阶段，或者回答高度重复的问题（如固定的系统提示词），缓存可以节省大量 Token。

litellm_settings: drop_params: true set_verbose: true # 启用缓存 cache: true cache_params: type: "local" # 使用内存缓存，简单易用。生产环境可考虑 redis ttl: 3600 # 缓存生存时间，单位秒（1小时） # 缓存键的生成规则：基于模型名和消息内容 caching_groups: ["model", "messages"]

缓存如何工作？当两个请求的model和messages完全相同时，第二个请求将直接从网关缓存中返回结果，不会向 DeepSeek API 发起真实调用，Token 消耗为 0。这对于减少重复问题的成本立竿见影。

5.4 完整配置文件示例

将以上配置组合起来，得到一个功能完善的config.yaml：

model_list: - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY api_base: https://api.deepseek.com retry: num_retries: 2 delay: 1 backoff_factor: 2 status_codes: [429, 500, 502, 503, 504] exceptions: [Timeout, ConnectionError] model_info: rpm: 600 # 配置一个备用模型（例如 deepseek-coder），在主模型失败时自动切换 - model_name: deepseek-coder-backup litellm_params: model: deepseek/deepseek-coder api_key: os.environ/DEEPSEEK_API_KEY api_base: https://api.deepseek.com retry: num_retries: 1 status_codes: [429, 500, 502, 503, 504] litellm_settings: drop_params: true set_verbose: false # 生产环境建议关闭详细日志 cache: true cache_params: type: "local" ttl: 1800 # 30分钟 caching_groups: ["model", "messages"] # 成功回调，可用于记录日志和用量到数据库 # success_callback: ["posthog", "langfuse", "custom_callback"] general_settings: master_key: sk-my-master-key-123 # 请务必修改为一个强密钥 max_parallel_requests: 50

使用增强版配置重启网关：

litellm --config ./config.yaml --port 4000

6. 客户端改造：将 Codex/Claude Code 指向你的网关

现在，网关已经就绪。你需要修改 Codex 或 Claude Code 等客户端的配置，使其不再直接调用 DeepSeek API，而是调用你的 LiteLLM 网关。

6.1 通用配置原理

大多数兼容 OpenAI API 的客户端（包括 Codex 的常见配置）都需要修改两个核心参数：

API Base URL: 从https://api.deepseek.com改为你的网关地址，如http://localhost:4000或https://your-gateway-domain.com。
API Key: 使用你在general_settings中设置的master_key（例如sk-my-master-key-123），或者如果未设置master_key，可以传递任意值（如sk-1234），因为网关配置中未开启强制鉴权。生产环境务必设置并校验master_key。
Model Name: 使用你在config.yaml中定义的model_name（如deepseek-chat），而不是原始的deepseek/deepseek-chat。

6.2 示例：在环境变量中配置

这是最灵活的方式，无需修改客户端代码。

# 设置客户端环境变量 export OPENAI_API_BASE=http://localhost:4000/v1 export OPENAI_API_KEY=sk-my-master-key-123 # 与网关的master_key一致 # 注意：有些客户端可能使用 DEEPSEEK_API_BASE，请根据客户端文档调整。

6.3 示例：在 Python 代码中配置

如果你的 Codex 集成是基于 Python SDK 的。

# 原始直接调用 DeepSeek 的代码 # from openai import OpenAI # client = OpenAI(api_key="your_deepseek_key", base_url="https://api.deepseek.com") # 修改为调用 LiteLLM 网关 from openai import OpenAI # 指向本地网关 client = OpenAI( api_key="sk-my-master-key-123", # 网关的 master_key base_url="http://localhost:4000/v1" # 注意 /v1 后缀 ) # 使用网关定义的模型别名 response = client.chat.completions.create( model="deepseek-chat", # 不是 deepseek/deepseek-chat messages=[{"role": "user", "content": "写一个Python快速排序函数"}], max_tokens=500 ) print(response.choices[0].message.content)

6.4 示例：在 Claude Code 或 VSCode 插件中配置

这类工具通常在设置（Settings）或配置文件（如~/.codex/config.json）中提供 API 端点配置项。

你需要找到类似API Endpoint、Base URL或Custom API Server的配置项，将其值设置为http://localhost:4000/v1（或你的远程网关地址）。在API Key字段填入网关的master_key。在Model字段填入deepseek-chat。

重要提示：修改配置后，重启你的 IDE 或插件以确保配置生效。

7. 监控与验证：如何确认 Token 消耗已受控？

配置完成后，如何验证网关确实在起作用并保护了你的 Token？以下是几种方法。

7.1 查看网关日志

启动网关时添加--debug标志可以获得更详细的日志。

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

观察日志输出，你会看到：

请求路由：INFO: litellm.proxy.proxy_server: Received request for model: deepseek-chat。
缓存命中：INFO: litellm._logging: cache hit for model=deepseek-chat。这表明请求未到达 DeepSeek API，节省了 Token。
重试事件：WARNING: litellm.llms.openai: Retrying request...。可以看到重试触发的条件和次数。
最终响应和用量：日志会输出最终的usage信息，这是你成本核算的依据。

7.2 模拟故障场景进行测试

我们可以编写一个简单的测试脚本，模拟客户端错误和服务器错误，观察网关行为。

# test_gateway_behavior.py import requests import json import time GATEWAY_URL = "http://localhost:4000/v1/chat/completions" HEADERS = { "Content-Type": "application/json", "Authorization": "Bearer sk-my-master-key-123" } def test_client_error(): """测试客户端错误（400）是否被重试""" print("测试1: 发送错误参数触发400...") payload = { "model": "deepseek-chat", "messages": [{"role": "user", "content": "hello"}], "max_tokens": "invalid_string" # 错误的参数类型，应触发400 } try: resp = requests.post(GATEWAY_URL, headers=HEADERS, json=payload, timeout=10) print(f"状态码: {resp.status_code}") print(f"响应体: {resp.text[:200]}") # 观察网关日志，应该看到一次失败请求，没有重试日志。 except Exception as e: print(f"请求异常: {e}") def test_success(): """测试正常请求""" print("\n测试2: 发送正常请求...") payload = { "model": "deepseek-chat", "messages": [{"role": "user", "content": "法国的首都是哪里？"}], "max_tokens": 50 } try: resp = requests.post(GATEWAY_URL, headers=HEADERS, json=payload, timeout=10) print(f"状态码: {resp.status_code}") data = resp.json() print(f"回答: {data['choices'][0]['message']['content']}") print(f"Token用量: {data['usage']}") except Exception as e: print(f"请求异常: {e}") if __name__ == "__main__": test_client_error() time.sleep(1) test_success()

运行此脚本，并对照网关日志，你可以清晰地看到：

对于test_client_error，网关收到 DeepSeek 返回的 400 错误后，会直接将该错误返回给客户端，不会重试。
对于test_success，网关正常转发请求并返回结果。

7.3 对比使用网关前后的账单

最直接的证据来自 DeepSeek 平台本身的用量统计。在接入网关并运行一段时间后（例如一天），对比接入前后相同时段的 Token 消耗趋势。如果配置得当，你应该能观察到：

总体消耗下降：由于避免了错误重试和缓存命中，总 Token 数会减少。
消耗曲线平滑：由于限流，突发的高消耗峰值会被削平。

8. 高级策略与生产环境最佳实践

基本的防烧 Token 配置已经完成。但要用于生产环境，还需要考虑更多。

8.1 多模型路由与故障转移

LiteLLM 网关支持设置多个模型，并配置优先级和故障转移。当主模型（如deepseek-chat）失败或达到速率限制时，可以自动切换到备用模型（如deepseek-coder或其他厂商的模型）。

model_list: - model_name: deepseek-primary litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY model_info: rpm: 300 - model_name: deepseek-backup litellm_params: model: deepseek/deepseek-coder api_key: os.environ/DEEPSEEK_API_KEY model_info: rpm: 300 - model_name: openai-backup # 甚至可以切换到OpenAI作为终极备份 litellm_params: model: gpt-3.5-turbo api_key: os.environ/OPENAI_API_KEY litellm_settings: # 设置路由策略：按顺序尝试，直到成功 routing_strategy: "simple-shuffle" # 或使用更复杂的权重和优先级 # routing_strategy: "usage-based-routing"

8.2 基于预算的熔断

LiteLLM 企业版支持更高级的预算管理和熔断。社区版可以通过结合外部监控和脚本实现类似功能。核心思想是：监控一段时间内的 Token 消耗，超过阈值后，自动修改网关配置或通过 API 禁用特定模型/用户的访问。

8.3 持久化日志与审计

将网关的访问日志、Token 用量记录到文件或数据库中，便于后续分析和审计。

启用日志文件：启动时使用--log-file参数。
使用回调函数：配置success_callback和failure_callback，将每次请求的详细信息发送到你的日志系统或数据库。

8.4 安全加固

强制 Master Key 认证：务必在general_settings中设置复杂的master_key，并在客户端使用它。
网络隔离：不要将网关（0.0.0.0:4000）直接暴露在公网。使用 Nginx/Apache 进行反向代理，配置 SSL/TLS (HTTPS)，并设置 IP 白名单或防火墙规则。
定期轮换 API Key：定期更新 DeepSeek API Key 和环境变量。

8.5 性能与高可用

使用 Redis 缓存：将cache_params.type改为redis，以支持分布式部署和更大的缓存容量。
多实例部署：使用 Docker 容器化 LiteLLM 代理，并通过负载均衡器（如 Nginx）部署多个实例，提高可用性和吞吐量。
健康检查：为网关配置健康检查端点（/health），便于负载均衡器管理。

9. 常见问题排查清单

即使配置了网关，你可能还会遇到一些问题。以下是快速排查指南。

问题现象	可能原因	排查步骤	解决方案
网关启动失败，提示端口占用	端口 4000 已被其他进程使用	`lsof -i :4000`或`netstat -ano \| findstr :4000`(Win)	更改启动端口：`litellm --config config.yaml --port 4001`
客户端请求网关返回`401 Unauthorized`	1. 网关设置了`master_key`，但客户端未提供或提供错误。 2.`Authorization`请求头格式错误。	1. 检查网关配置的`master_key`。 2. 检查客户端请求头是否为`Bearer <master_key>`。	1. 确保客户端使用的 key 与网关`master_key`一致。 2. 确保请求头格式正确。
客户端请求网关返回`404 Not Found`	请求的 URL 路径不正确。	检查客户端配置的`base_url`。LiteLLM 代理的聊天补全端点通常是`/v1/chat/completions`。	确保`base_url`以`/v1`结尾，例如`http://localhost:4000/v1`。
网关日志显示`Invalid API Key`	DeepSeek API Key 未设置或错误。	1. 检查环境变量`DEEPSEEK_API_KEY`是否已设置且正确。 2. 在网关日志中查看错误详情。	1. 重新设置正确的 API Key。 2. 确认 Key 是否有额度或是否被禁用。
请求成功但响应慢	1. 网络问题。 2. 开启了流式响应 (`stream=true`) 但客户端处理慢。 3. 模型负载高。	1. 使用`ping`或`curl`测试到网关和 DeepSeek API 的网络延迟。 2. 检查客户端是否在处理流式数据时阻塞。	1. 优化网络或使用离你更近的服务器部署网关。 2. 对于非实时场景，关闭`stream`。 3. 考虑使用缓存。
Token 用量仍然很高	1. 缓存未生效。 2. 客户端发送的请求上下文过大。 3. 限流配置 (`rpm`) 过高。	1. 检查网关日志是否有`cache hit`。 2. 分析客户端发送的消息长度。 3. 检查`config.yaml`中的`rpm`值。	1. 确认`cache: true`且`caching_groups`设置正确。 2. 优化客户端代码，减少不必要的上下文。 3. 适当调低`rpm`值。
网关返回`429 Too Many Requests`	客户端请求频率超过了网关配置的`rpm`限制。	查看网关日志，确认触发了速率限制。	1. 调整客户端请求频率。 2. 如需临时提高，可增加`rpm`值，但需注意 DeepSeek API 本身的限制。

通过本文的步骤，你不仅解决了 Codex 接入 DeepSeek 后“烧 Token”的燃眉之急，更是引入了一个具备生产级弹性和可观测性的 AI 网关架构。这套方案的价值超越了单次问题的解决，它为你管理所有 LLM API 调用提供了一个统一的控制平面。你可以在此基础上，轻松地接入更多模型（如 OpenAI、Claude、国内大模型），实施更精细的成本分摊、审计和调度策略，从而让 AI 能力真正稳定、可控、经济地服务于你的开发工作流。