上周三把项目里的 Qwen 模型从 qwen-max（底层还是 Qwen 2.5 时代的）升到 qwen3.8-max，本以为改个 model 参数就完事了。结果跑了一晚上，第二天早上看日志——一堆 400 Bad Request 和莫名其妙的输出截断。折腾了两天才全部理顺。

结论先给：Qwen 3.8 和 Qwen 2.5 系列虽然都走 OpenAI 兼容协议，但在 tool_choice 行为、thinking 模式参数、max_tokens 默认值、流式输出格式上存在 4 处不向后兼容的变更。如果你的代码是对着 Qwen 2.5 写的，迁移时至少要改 3 个地方，不然必出问题。

评测维度

这次对比主要看迁移相关的兼容性问题，不是跑 benchmark 比谁聪明（那种文章已经够多了）。我关注的是：

1. API 请求参数兼容性——哪些参数改了、废弃了、新增了
2. 响应格式差异——流式 chunk 结构有没有变
3. 工具调用行为——function calling 的解析逻辑是否一致
4. 默认值变更——不传某些参数时行为是否相同
5. 错误码和错误信息——报错格式有没有变

评测结果对比表

第一梯队问题：thinking 模式引发的连锁反应

这是最坑的一个。Qwen 3.8 引入了类似 Claude 的 extended thinking 能力，但它的实现方式跟你预期的不一样。

当你用聚合 API 平台（比如 OpenRouter 或 ofox.io）调用bailian/qwen3.8-max时，如果请求体里带了enable_thinking: true（或者某些 SDK 默认带上了这个参数），返回的流式 chunk 会多一个字段：

{ "choices": [{ "delta": { "reasoning_content": "让我分析一下...", "content": "" } }] }

问题在于：很多解析代码只读delta.content，直接忽略了reasoning_content。结果就是——模型明明在思考，你这边收到的全是空字符串，最后拼出来一个空响应。

我第一天看到日志里全是空 response 的时候，还以为是 token 用完了。实际上模型输出了一大堆，只是都跑到reasoning_content里去了。

修复方案：要么显式传enable_thinking: false，要么更新你的流式解析逻辑：

for chunk in stream: delta = chunk.choices[0].delta text = delta.content or "" thinking = getattr(delta, "reasoning_content", "")

第二梯队问题：tool_choice 行为漂移

这个问题比较隐蔽。同样传tool_choice: "auto"，Qwen 2.5 时代模型会比较"克制"——大概 60% 的情况下选择直接回答而不调工具。但 qwen3.8-max 的倾向性明显变了，我测了 50 个 case，有 43 个都触发了 tool call。

这导致我的一个客服 bot 出了问题：用户问"你好"，模型也要去调一下搜索工具，然后返回一堆无关内容。

graph TD A[用户输入: 你好] --> B{tool_choice: auto} B -->|Qwen 2.5| C[直接回复: 你好，有什么可以帮你的？] B -->|Qwen 3.8| D[调用 search_tool] D --> E[返回搜索结果 + 生成回复] E --> F[用户体验: 响应慢 + 内容冗余]

修复方案：对不需要工具的对话轮次，显式传tool_choice: "none"。或者在 system prompt 里加一句"只有用户明确需要查询信息时才使用工具"——但说实话 prompt 层面的约束不如参数层面靠谱。

第三梯队问题：max_tokens 默认值翻了 4 倍

这个不会让你的代码报错，但会让你的账单报警。

Qwen 2.5 系列 max_tokens 默认 2048，qwen3.8-max 默认 8192。如果你的场景本来只需要几百 token 的回复（比如分类、抽取、打标签），不显式设 max_tokens 的话，模型可能会"自由发挥"输出很长的内容。

按百炼官方 2026 年 7 月的定价，qwen3.8-max 输出 ¥0.012/千 token。一个请求从输出 500 token 变成输出 4000 token，单次成本就从 ¥0.006 涨到 ¥0.048。一天跑 10 万次的话：

旧成本：100,000 × 0.006 = ¥600/天 新成本：100,000 × 0.048 = ¥4,800/天

差了 8 倍。当然实际不会每次都打满 8192，但我观察到平均输出长度确实从 ~400 token 涨到了 ~1200 token（模型变啰嗦了）。

不同需求怎么选

迁移 checklist

我把踩过的坑整理成一个清单，迁移前逐项检查：

1. ✅ 所有请求显式设置max_tokens（别依赖默认值）
2. ✅ 流式解析代码适配reasoning_content字段
3. ✅ 如果不需要 thinking 模式，显式传enable_thinking: false
4. ✅ 检查tool_choice逻辑，必要时从 "auto" 改为条件判断
5. ✅ 更新错误处理，增加thinking_mode_conflict错误码
6. ✅ 跑一轮回归测试，重点看工具调用和输出长度

聚合平台兼容性实测

因为我的项目同时用了多个模型（Claude 做复杂任务，Qwen 做轻量任务），所以是通过聚合 API 统一调用的。测了一下不同平台对 Qwen 3.8 新参数的支持情况：

说实话我也不确定 OpenRouter 那边是 bug 还是还没适配完，反正我 6 月 28 号测的时候reasoning_content在某些 SDK 里会被吞掉。后来换了 ofox.io 的bailian/qwen3.8-max通道就正常了，参数原样透传到百炼。

调用代码长这样（改个 base_url 就行）：

from openai import OpenAI client = OpenAI( api_key="your-key", base_url="https://api.ofox.io/v1" )

resp = client.chat.completions.create( model="bailian/qwen3.8-max", messages=[{"role": "user", "content": "..."}], max_tokens=2048, extra_body={"enable_thinking": False} )

一个实际报错的例子

迁移第一天遇到的真实报错，贴出来给大家参考：

Error code: 400 - {'error': {'message': 'enable_thinking and response_format json_object cannot be used together', 'type': 'thinking_mode_conflict', 'code': 'invalid_request'}}

这个意思是：如果你开了 thinking 模式，就不能同时用response_format: {"type": "json_object"}。Qwen 2.5 没有 thinking 模式所以不存在这个冲突，但迁移后如果某个 SDK 默认带了enable_thinking: true，你原来好好的 JSON mode 就会炸。

小结

Qwen 3.8 的能力确实比 2.5 强不少（尤其是推理和工具调用），但迁移不是无痛的。最核心的三个改动：thinking 模式、tool_choice 倾向性、max_tokens 默认值——任何一个没处理好都会影响线上服务。

我的建议是：先在测试环境跑完整个 case 集，重点观察输出长度和工具调用频率的变化，确认没问题再切生产。别像我一样直接上线然后第二天早上对着满屏空响应发呆。

其实阿里这边模型迭代速度挺快的，从 qwen3.5 到 qwen3.6 到 qwen3.7 再到 qwen3.8，几乎每个月一个版本。好处是能力一直在涨，坏处就是……API 行为也一直在变。做好版本锁定和兼容层，比追最新版本更重要。