如果你在尝试将 Codex 连接到自托管的 DeepSeek 模型时，遇到了请求被错误地发送到/v1/responses端点，导致 Token 被不断消耗却无法获得有效回复的问题，那么这篇文章就是为你准备的。这是一个在社区中相当典型的配置问题，根源在于 Codex 客户端与 LiteLLM 代理服务器之间的 API 路径不匹配。简单来说，Codex 期望的 API 路径与 LiteLLM 默认暴露的路径不一致，导致请求“迷路”，从而触发一系列错误和无效的 Token 消耗。本文将直接切入主题，先解释问题现象和根本原因，然后提供一个经过验证的、一劳永逸的解决方案。我们不会停留在概念层面，而是会给出具体的配置步骤、验证命令以及一套完整的排查流程。无论你是想在本地开发环境集成，还是搭建一个稳定的内部服务，都能通过本文找到清晰的路径。1. 核心能力速览与问题定位在深入解决方案之前，我们先快速梳理一下整个技术栈的核心组件和当前面临的核心矛盾。组件角色与功能在本问题中的状态DeepSeek 模型目标AI模型，提供代码生成、对话等能力。可以是官方API或自托管版本。自托管，通过特定端口（如30000）提供类OpenAI API服务。LiteLLM通用AI模型代理层。它将不同厂商的API（如OpenAI、Anthropic、自托管模型）统一成标准的OpenAI API格式。已部署，作为中间代理，接收Codex请求并转发给自托管的DeepSeek。Codex (客户端)一个利用大模型进行代码辅助的工具/CLI。它按照OpenAI API规范发送请求。配置了指向LiteLLM代理的OPENAI_BASE_URL和OPENAI_API_KEY。问题核心Codex 发送请求的终点路径与 LiteLLM 转发的终点路径不匹配。Codex 试图访问/v1/responses，而 DeepSeek 服务或 LiteLLM 配置的终点是/v1/chat/completions。问题现象复现： 当你使用类似codex --provider openai --model deepseek-70b -q “Hello”的命令时，会在客户端看到404 litellm.NotFoundError错误，同时在 LiteLLM 的服务端日志中，会发现它试图访问一个https://your_model_ip:30000/v1/responses的地址并失败。根本原因： 某些 Codex 客户端版本或配置，可能会使用 OpenAI 的非标准或特定端点（如/v1/responses用于某些异步操作）。然而，标准的自托管模型服务（包括通过 LiteLLM 代理的）通常只暴露/v1/chat/completions或/v1/completions这样的标准端点。这个路径不匹配导致请求无法被正确处理，但鉴权可能已通过，从而造成 Token 被扣除或请求被计费。2. 适用场景与使用边界本解决方案主要适用于以下场景：开发者本地环境：希望在个人开发机上，使用 Codex 等工具调用本地或内网部署的 DeepSeek 模型，进行代码补全、解释或调试。团队内部服务：搭建一个内部 AI 辅助平台，让团队成员可以通过统一的 Codex 配置接入公司内网的私有模型。成本与隐私控制：避免直接使用昂贵的商用 API，或出于数据隐私考虑，需要所有请求在内部网络完成。使用边界与注意事项：模型授权：确保你部署的 DeepSeek 模型拥有合法的使用授权。如果是官方 API，请遵守其使用条款；如果是开源版本的自托管，请遵守对应的开源协议。网络安全：自托管服务通常在内网运行。如果需对外暴露，务必配置好防火墙、身份认证（如 API Key）和 HTTPS 加密，防止未授权访问和中间人攻击。性能考量：自托管模型的性能取决于你的硬件（GPU、内存）。对于大型模型（如 70B 参数），需要足够的显存和内存支持。功能完整性：通过 LiteLLM 代理接入，可能无法 100% 复现原始 API 的所有高级功能（如某些流式输出格式、特定参数）。需要以测试为准。3. 环境准备与前置条件在开始修复之前，请确保你的基础环境已经就绪。操作系统：Linux (Ubu