ChatGPT-Next-Web项目自定义模型部署中的OpenAI与Azure版本隔离问题解析

在ChatGPT-Next-Web项目的实际部署中，开发者经常需要通过CUSTOM_MODELS环境变量来自定义可用的AI模型列表。近期有用户反馈了一个典型问题：当使用-all参数排除默认模型后，虽然成功添加了指定的AI服务模型，但系统仍会自动显示对应的云版本模型，这与用户期望的纯净AI服务模型环境产生了冲突。

问题本质分析

该问题的核心在于项目默认的模型加载逻辑。系统内置的模型列表包含两类同源异构模型：

1. 原生AI服务接口版本（如gpt-4o@ai_service）
2. 云服务版本（如gpt-4o@cloud）

即使用户通过-all参数清空默认列表，再显式添加+gpt-4o这样的通用标识时，系统仍会理解为需要加载该模型的所有可用变体。

解决方案实现

经过社区验证，正确的隔离方式是在模型名称后显式指定服务提供商标识。具体语法为：

CUSTOM_MODELS=-all,+gpt-4@ai_service,+gpt-4o@ai_service

这种写法通过@ai_service后缀明确限定了模型版本来源，系统将：

• 仅加载AI服务官方接口的指定模型
• 完全跳过云服务版本
• 保持其他自定义模型（如Gemini、Claude等）的正常加载

进阶配置建议

对于需要混合多厂商模型的场景，建议采用分层配置策略：

1. 先用-all清空默认列表
2. 按需添加带厂商标识的核心模型
3. 补充无冲突的第三方模型

示例配置：

CUSTOM_MODELS=-all,+gpt-4@ai_service,+claude-3.5-sonnet,+gemini-1.5-pro

技术原理延伸

这种现象本质上反映了项目对模型标识的解析策略：

1. 未指定厂商时采用"或"逻辑（加载所有适配器）
2. 指定厂商时采用"精确匹配"逻辑
3. 配置参数的解析顺序遵循从左到右的覆盖原则

理解这一机制后，开发者可以更精准地控制运行时模型列表，满足企业级部署中对服务商、版本、接口类型的精细化管理需求。