LiteLLM 中配置 GPT-6 Luna 代理路由

一句话结论

LiteLLM 的发布说明提供将 gpt-6-luna 注册到代理模型列表的配置，并说明了其 GPT-6 请求家族兼容路径。

适用场景

• 适合的任务：通过 LiteLLM Proxy 暴露 GPT-6 Luna 模型别名、集中管理 API 凭证与路由。

• 不适合的任务：将文章中针对 GPT-6 Sol 的请求示例误认为 Luna 的完整请求示例。

• 适用的模型版本：gpt-6-luna。

• 适用的客户端、Agent 或 API：LiteLLM Proxy；LiteLLM 文档还提及 Python SDK。

• 推荐的推理档位和参数：文章称默认 reasoning effort 为 medium；若使用 temperature，须搭配 reasoning_effort: "none"，并按所用 LiteLLM 版本核验参数处理。

可直接使用的内容

LiteLLM Proxy 模型配置

model_list:
  - model_name: gpt-6-luna
    litellm_params:
      model: openai/gpt-6-luna
      api_key: os.environ/OPENAI_API_KEY

将该条目加入 config.yaml。原文后续的 curl/Responses API 请求样例使用的是 gpt-6-sol，所以这里不将其改写或声称为来源已给出的 Luna 请求样例。

来源中的兼容说明

• 文章称 LiteLLM 将 GPT-6 名称按 GPT-5 请求家族处理，因此无需单独镜像升级即可适配 max_completion_tokens 与 reasoning 参数。

• 文档列出 v1.101.0 起支持相关请求参数处理；模型成本映射更新需按文中说明刷新。

• 对多轮 Agent 工作流，文章建议通过 /v1/responses 保留 reasoning state。

复现配置与证据边界

• 这是 LiteLLM 集成方的配置说明，不是 OpenAI 官方 API 文档；部署前应核对 LiteLLM 当前版本、模型映射与路由行为。

• 本文记录了可见的 Luna 模型路由配置；来源里的 API 请求示例明确调用 Sol，不可当作 Luna 已验证的调用。

• API 密钥通过环境变量引用，不要将密钥值写入配置文件或提交到仓库。