Composer2.5反代后模型能力大幅下降

背景

随着大语言模型（LLM）应用的普及，许多开发者和用户会通过反向代理（reverse proxy）方式将模型服务部署到自己的应用中，以实现更低延迟、更高可控性或特定业务适配。composer2.5 是一个被社区关注的开源模型或工具，而 Grokbuild 等平台则提供了集成系统提示词（system prompt）的调用环境。当一个模型从原生平台（如 Grokbuild）迁移至自建的反代服务后，其输出质量可能出现显著变化，这一现象引发了社区对“反代降智”的讨论。LINUX DO·AI 论坛上的这篇帖子正是围绕这一议题展开。

核心内容

帖子标题为“composer2.5反代出来以后，是不是会降智？”，作者在正文中描述了以下现象：

• 在 Grokbuild 平台中使用 composer2.5 时，模型表现比较正常。
• 通过 cpa 反向代理将模型服务引出后，模型能力出现大幅下滑。
• 当被问及“模型是什么”时，模型有时回答自己是 DeepSeek（ds），有时是 Qwen，有时是智谱（Zhipu），甚至出现各种乱码。

作者因此提出猜想：会不会是因为 Grokbuild 内部存在系统提示词（system prompt）能够约束模型的行为逻辑，而反代出来之后失去了这些提示词，导致模型“放飞自我”？该帖子共有 3 位用户参与讨论，截至阅读时仍为完整主题。

关键要点

• 用户通过 cpa 反代将 composer2.5 模型部署到自有环境后，模型回答的稳定性与准确性明显下降。
• 模型在身份声明上出现混乱，自行切换为不同模型（ds、qwen、zhipu），这可能是由于模型在没有系统提示词约束时无法确定自身角色，从而随机调用内部知识中的模型名称。
• 出现乱码表明输出内容可能被截断、编码错误或模型处于无引导状态，进一步佐证了系统提示词的重要性。
• 核心观点：Grokbuild 内置的系统提示词扮演了关键的角色，能够“框住”模型的行为；反代后失去这一约束，模型便表现出不一致和“降智”。

意义与影响

该帖子揭示了在使用大语言模型时，系统提示词对于维持模型行为一致性的基础作用。即便模型本身能力不变，缺少了精心设计的提示词引导，其输出也可能变得不可靠、甚至偏离主要任务。这对于希望将模型集成到自建应用中的开发者来说是一个重要提醒：仅靠模型权重是不够的，必须配套适当的提示工程（prompt engineering）来保持稳定。此外，cpa 反代等工具在传递请求时可能丢失上下文信息或系统消息，从而导致模型“失忆”或“降智”。未来反代理工具或许需要增加对系统提示词的自动透传或兜底机制，而用户也应在反代配置中显式加入系统提示词，并测试其效果。这一讨论也侧面反映了闭源模型（如某些商业 API）与开源模型在可控性上的差异，但本案例中的 composer2.5 本身可能也需要更鲁棒的默认行为设计。