GPT-5.6 中转配置指南：如何正确解锁 Ultra 模型

最近，不少自建 API 中转服务的玩家在折腾 GPT-5.6 的时候遇到了一个很坑的问题：明明源站支持的是顶配版 Ultra 模型，但是经过中转层（比如 NewAPI 或者 Sub2API）后，总是莫名其妙地被“阉割”成了 Max，甚至更拉胯的 Xhigh。这直接导致体验大打折扣，花了真金白银买的高级模型，结果用成了低配版，谁受得了？

今天我们就来扒一扒这里的坑，顺便给大家提供几个实测可行的解决思路。

问题根源：为什么会被“降级”？

首先得明白，这通常不是源站的问题，而是中转层的“模型映射（Model Mapping）”机制在作祟。

1. 默认映射规则冲突：很多中转工具为了兼容性，默认内置了一套模型重写规则。例如，它可能不认识 gpt-5.6-ultra 这个具体的 ID，为了防止调用报错，程序会自动把这个奇怪的 ID 转换成它认识的、或者是你认为“兼容”的模型，比如 gpt-5.6-max。
2. 通配符匹配太宽松：在 NewAPI 配置中，如果你设置了类似 gpt-5.6-* 的通配符指向某个渠道，且该渠道只支持 Max，那 Ultra 发过来也会被强行按 Max 处理。
3. 渠道定义的优先级：Sub2api 这类工具在解析订阅或上游配置时，可能会读取到错误的模型列表。如果上游返回的模型列表里没有明确标注 Ultra，Client 在请求时可能会被中间件“修正”为列表中存在的最高级（即 Max 或 Xhigh）。

解决方案一：NewAPI 的精准渠道配置

如果你用的是 NewAPI，解决思路是“强行指定”，绕过自动映射。

• 步骤 1：进入 NewAPI 后台，编辑对应的渠道。
• 步骤 2：在“模型映射”或者“自定义模型列表”中，不要使用通配符。手动输入完整的模型名称：gpt-5.6-ultra。
• 步骤 3：检查“重定向”设置。确保没有开启“自动补全模型名”或者“模型重定向”之类的功能，这通常是导致映射到 Max 的罪魁祸首。
• 步骤 4：保存后，不要忘了到“令牌”页面，把你用的 Token 的模型权限也勾选上 gpt-5.6-ultra。有时候是 Token 没权限，系统自动给了它能用的最高级 Max。

解决方案二：Sub2API 的高级修改

Sub2API 这种工具通常用于把订阅转为 API，它的坑主要在于解析逻辑。

• 修改模型列表：在转换配置中，查看生成的“模型列表”字段。如果只有 Max 和 Xhigh，手动把 gpt-5.6-ultra 加进去。
• 禁用“强制模型映射”：检查配置文件中是否有类似 force_model 或 map_model 的选项，确保它是关闭的。我们需要的是透传，而不是由中间件来告诉我该用什么模型。
• 直连测试：先不经过 Sub2API，直接用 curl 或者 Postman 对中转上游（也就是提供 GPT-5.6 的那个裸 API）进行一次请求。如果上游能返回 Ultra，但 Sub2API 出来的不行，那就是 100% 的转换配置问题，死磕上面的模型列表设置即可。

解决方案三：客户端请求头的骚操作

有时候问题出在客户端。有些客户端喜欢“自作聪明”地把你输入的模型名改成它认为对的。

• 指定 model 参数：在发起 API 请求时，Body 里的 model 字段必须死死写为 gpt-5.6-ultra，注意大小写和连字符。
• 检查 OpenAI 客户端库：如果你在写代码调用，检查一下用的 SDK 是否有版本限制或默认的 Model 重置逻辑。建议直接用原生的 HTTP 请求调试，确认不是库的问题。

总结

遇到这种“Max 当 Ultra 卖”的情况，核心就在透传。中转服务应该是一个透明的管道，而不是一个自作主张的过滤器。只要把中转层的自动映射关掉，手动写死模型列表，这个问题基本上就能解决。大家如果还有其他奇葩的映射问题，欢迎在评论区交流！