1. 先搞清楚“烧Token”到底烧在了哪里很多人用 Codex 这类工具接入 DeepSeek 后，发现 API 调用费用（Token 消耗）远超预期，或者干脆报错，任务根本跑不起来。这通常不是 DeepSeek 模型本身的问题，而是配置、调用方式或中间代理层（如 LiteLLM）的设置不当导致的。“烧 Token”这个说法很形象，但背后至少对应三种情况：无效调用：每次请求都因为配置错误（如模型名不对、API Key 无效）而失败，但请求本身依然消耗了 Token 额度。超额消耗：请求成功了，但因为提示词（Prompt）过长、参数设置不合理或开启了“思考模式”（Reasoning），导致单次请求消耗的 Token 数远超你的预估。代理层问题：通过 LiteLLM 等代理网关调用时，代理自身的路由、重试或日志记录机制可能导致重复计费或调用失败。所以，解决“烧 Token”问题的第一步，不是急着换模型或调参数，而是先定位消耗点。你需要像排查流水账单一样，确认钱到底花在了“无效的错误请求”上，还是“成功但昂贵的大额请求”上。2. 环境与工具准备：最小化你的测试链路在开始调试之前，我建议你把调用链路简化到极致。不要一上来就在复杂的 Codex 图形界面或集成环境里折腾。先用最直接的方式验证 DeepSeek API 本身是否工作。2.1 获取并验证你的 DeepSeek API Key这是所有问题的起点。去 DeepSeek 官网注册并获取 API Key。拿到 Key 后，不要直接填到 Codex 或 LiteLLM 里，先用一个最简单的 Python 脚本或curl命令测试一下。使用curl命令直接测试（最推荐，依赖最少）：curl -X POST https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer your_actual_deepseek_api_key_here" \ -d '{ "model": "deepseek-chat", "messages": [ {"role": "user", "content": "Hello, say something short."} ], "max_tokens": 10 }'把your_actual_deepseek_api_key_here替换成你的真实 Key。这个命令直接调用 DeepSeek 官方接口，绕过了所有中间层。关键点：看状态码：如果返回200，并且有正常的 JSON 响应，说明你的 API Key 是有效的，网络也是通的。看错误信息：401 Unauthorized：API Key 错误或已失效。403 Forbidden：可能涉及区域限制、账户被封禁或请求频率超限。特别注意：如果错误信息包含country或organization has been disabled，这通常是账户或区域策略问题，需要联系 DeepSeek 支持或检查账户状态，与 Codex 或 LiteLLM 配置无关。400 Bad Request：请求格式有问题，比如模型名写错、JSON 格式不对。常见的400错误如param incorrect或maximum context length exceeded，都指向你的请求参数本身。看响应内容：成功的响应里会包含usage字段，明确告诉你这次请求消耗了多少prompt_tokens和completion_tokens。记下这个数字，作为基准。2.2 理解 LiteLLM 的角色（如果使用）LiteLLM 是一个很棒的通用代理，它让你能用 OpenAI 的格式调用上百种模型，包括 DeepSeek。但这也引入了一层复杂度。Codex 很多时候是通过配置 LiteLLM 来接入 DeepSeek 的。核心关系要理清：你的 Codex/App - 调用 - LiteLLM 代理（本地或远程）- 转发请求 - DeepSeek 官方 API“烧 Token”的问题可能出在任何一个箭头环节。安装与基础配置 LiteLLM：如果你确定要或已经在使用 LiteLLM，先在命令行环境里把它配置好。# 安装 litellm pip install litellm # 设置环境变量（临时） export DEEPSEEK_API_KEY="your_actual_deepseek_api_key_here" # 运行一个最简单的 LiteLLM 测试脚本 test_deepseek.py# test_deepseek.py import os from litellm import completion # 确保环境变量已设置 os.