Qwen3.8-Flash-Next 和 Qwen3.8-27B 怎么配置：我们踩过的坑和实测对比

我们自己部署了两个 Qwen3.8 模型：Qwen3.8-Flash-Next 和 Qwen3.8-27B-FP8，接进 Claude Code，让它们在 Claude 手下当"子代理"干活，读文件、改代码、跑测试。

两个模型的来头都不小。Qwen3.8-Flash-Next 是 MoE 架构，总参数 125B，每次推理只激活其中 6B，官方公布的 SWE-bench Pro 成绩是 62.5；Qwen3.8-27B-FP8 是 27B 的稠密模型，同一项成绩 61.7。放在同期的对比表里，这两个分数都在前排。

可用了一段时间，我们的感受是 Flash-Next 又慢又差，有时候输出是完全空白，低等错误不断。分数和体感差得这么远，我们就把官方模型卡找出来，一项一项对照自己的配置。结果查出了三个问题，改完之后又做了一轮测试。下面把过程、配置方法和测试数据都整理出来，也在用这两个模型的朋友可以直接参考。

一、我们查出了三个问题

先简单说一下我们的链路。Claude Code 发出的请求是 Anthropic 的格式，而部署模型用的推理服务 vLLM 只认 OpenAI 的格式，中间需要一个翻译。我们用的是 LiteLLM，它是一个代理，收到 Claude Code 的请求，转换格式后再发给 vLLM。模型的各项参数，也都写在 LiteLLM 的配置文件里。

第一个问题：思考模式被关掉了。 配置文件里两个模型都写着 enable_thinking: false。而模型卡上写得很清楚，这两个模型默认开启思考模式，卡上所有 agentic 编程成绩，包括 SWE-bench Pro、DeepSWE、Terminal Bench，都是在思考模式下、用 Claude Code 跑出来的。我们一直在用的，是成绩单上没有测过的那个模式。

模型卡里还专门有一段提醒，大意是：在多轮 agent 任务中，降低推理强度未必能缩短总耗时，单轮是快了，但分析不足会导致失败更多、反复重试，总时间和 token 消耗反而可能增加。

第二个问题：采样参数用错了一套。 模型卡给了两套推荐参数，思考模式一套，非思考模式一套。我们关了思考，发出去的 temperature 却是 1.0，这是思考模式的推荐值，也恰好是 Claude Code 的默认值，它就这么顺带发过去了。非思考模式推荐的 presence_penalty 1.5 也没有设。官方说明过，这个参数在非思考模式下是用来防止模型无限重复的。我们遇到的输出很差、原地绕圈，很可能就出在这里。

第三个问题：当初关思考，是为了躲一个报错。 查到这里我们也好奇，思考模式为什么会被关掉。试着打开之后，Flash-Next 的服务端马上返回一个 400 错误：

意思是它不认识 high 这个推理档位。Qwen3.8 的 reasoning_effort 只接受 low、medium、xhigh 三个值。可我们从来没有设过 high。抓了一次请求才发现，Claude Code 每个请求都自带一个 thinking 预算，LiteLLM 在转换格式时，自动把它翻译成了 reasoning_effort=high。而且这个值是跟着请求走的，优先级高于配置文件，配置文件里写什么都压不住它。

这三个问题串起来就清楚了：中间件的一次自动翻译引发报错，为了绕开报错关掉了思考，关掉思考之后参数又没跟着换。每一步当时看都是合理的临时处理，叠在一起，模型就被用成了另一个样子。

二、这两个模型该怎么配

改配置之前，先把涉及的几个概念讲清楚，后面的参数才看得懂。

思考模式和它的三个开关

思考模式是指模型在给出正式回答之前，先输出一段推理过程，相当于先打草稿再答题。开了思考，模型会先分析问题、列出思路、检查自己的推理，然后才动手写答案。代价是输出的内容多了，耗时也长了。在模板里，这个开关叫 enable_thinking。

reasoning_effort 控制思考的深度，也就是草稿打多长。Qwen3.8 有三档：low、medium、xhigh，默认是最高的 xhigh。档位越高，模型想得越多，遇到难题越稳，也越慢。

preserve_thinking 决定多轮对话里，前几轮的思考内容要不要保留下来。agent 干活是一轮接一轮的，读完文件再改代码，改完再跑测试。如果每一轮的思考都被丢掉，模型每次都要从头想一遍自己之前为什么这么做。官方默认开启这个选项，理由是决策更一致、减少重复推理。另外，历史内容保持不变，服务端的缓存也更容易复用，能省一部分计算。

采样参数

模型生成文字，是一个词一个词往外蹦的。每一步它都会给所有候选词打一个概率，然后从中挑一个。下面这几个参数，管的就是"怎么挑"。

temperature（温度） 调节概率分布的"尖锐程度"。温度低，高概率的词更占优势，输出更稳定、更保守；温度高，低概率的词也有机会被选中，输出更多样，也更容易跑偏。

top_p 是按累计概率划一条线。设成 0.95，就是把候选词按概率从高到低排，累加到 95% 为止，剩下那些概率很低的词直接不考虑。

top_k 是按数量划线。设成 20，就是每一步只在概率最高的 20 个词里挑。

presence_penalty 是对重复的惩罚。一个词只要之前出现过，再出现时就会被扣分，模型因此倾向于换个说法、往前推进，不容易原地打转。

repetition_penalty 也是防重复，思路类似，扣分方式不同。Qwen3.8 两种模式下都推荐 1.0，也就是不启用。

官方推荐值

两套参数的思路很好理解。思考模式下，模型有草稿兜底，温度可以放高一点，让它在推理时多探索几条路。非思考模式没有草稿，就要收紧：温度降到 0.7，top_p 降到 0.8，再加上 presence_penalty 1.5 防止它陷进重复里。我们改前的配置，是非思考模式配上了思考模式的温度，还拿掉了防重复的那道保险，两头都没占着。

我们的建议

如果是在 Claude Code 这类 agent 场景里用，建议开思考模式，采样参数用思考那一套，reasoning_effort 根据需要选。我们的服务器是自己的，不在乎 token，所以直接用了最高档 xhigh。

如果因为速度或者别的原因确实要关思考，一定要把参数整套换成非思考那一套，尤其别漏了 presence_penalty 1.5。后面的测试会看到，光是把这套参数配对，效果就已经有明显改善。

如果中间经过 LiteLLM 转发，还要额外处理 reasoning_effort 被翻译成 high 的问题，不然一开思考就报错。

具体怎么改

LiteLLM 的配置文件改成下面这样（地址换成自己的，Qwen3.8-27B-FP8 同样处理）：

- model_name: qwenflash  litellm_params:    model: hosted_vllm/qwen3.8-flash-next    api_base: http://:/v1    api_key: none    reasoning_effort: xhigh    temperature: 1.0    top_p: 0.95    extra_body: {"top_k": 20, "chat_template_kwargs": {"enable_thinking": true, "preserve_thinking": true}}litellm_settings:  drop_params: true  callbacks: qwen_hook.proxy_handler_instance

drop_params: true 的作用是，遇到后端不支持的参数就直接丢掉，免得报错。最后一行 callbacks 挂了一个我们自己写的钩子，用来解决 high 的问题。

前面说过，请求里带的 reasoning_effort 会覆盖配置文件，所以只改配置文件不够，得在请求真正发出去之前把它改掉。LiteLLM 提供了一个 async_pre_call_hook，会在请求发往 vLLM 之前执行，我们就在这里动手：

from litellm.integrations.custom_logger import CustomLoggerclass QwenEffortFix(CustomLogger):    async def async_pre_call_hook(self, user_api_key_dict, cache, data, call_type):        model = str(data.get("model", ""))        if model.startswith("qwen"):            eff = data.get("reasoning_effort")            if eff not in ("low", "medium", "xhigh"):                data["reasoning_effort"] = "xhigh"            data.pop("thinking", None)            data["temperature"] = 1.0            data["top_p"] = 0.95        return dataproxy_handler_instance = QwenEffortFix()

它做了三件事：凡是 Qwen3.8 不认的档位，一律改成 xhigh；删掉 Anthropic 格式特有的 thinking 字段，vLLM 不认识它；再把 temperature 和 top_p 强制写成思考模式的推荐值。最后这一步是我们的取舍，好处是不管客户端传什么都不会跑偏，坏处是客户端想改也改不了。

另外有两个 Windows 上的小坑。一是 LiteLLM 在 Windows 上会用系统默认的 GBK 编码读配置文件，yaml 里只要写了中文注释，启动时就会报 UnicodeDecodeError，所以配置文件只能用纯英文。二是启动 LiteLLM 时要把钩子文件所在的目录加进 PYTHONPATH，否则配置里的 callbacks 找不到这个模块。

三、改完效果怎么样

配置改完，我们想知道到底好了多少，就自己做了一轮小测试。

我们挑了 6 道中等难度的编程题：LRU 缓存、带括号的四则运算、拓扑排序、支持 . 和 * 的正则匹配、单词拆分求全部解、数据流中位数。每道题配了隐藏的单元测试，模型写完代码直接跑测试判对错，同时记录耗时和输出的 token 数。

配置分三档：

旧配置：关思考，temperature 1.0，没有 presence_penalty，也就是我们改之前的状态

关思考但参数配对：还是关思考，参数换成官方非思考那一套

新配置：开思考 xhigh，参数用官方思考那一套

之所以加中间这一档，是想把两件事分开看：光把参数配对能改善多少，再开思考又能改善多少。

先看旧配置。两个模型在旧配置下都是最差的一档。Qwen3.8-27B-FP8 有一道错得很低级：题目要求方法名叫 add，它没照做。这类指令遵循上的失误，和参数没配好有很大关系。

再看中间那一档。不开思考，只把参数换成官方推荐的那一套，Flash-Next 就从 5 题变成了 6 题全对，27B 从 4 题变成 5 题，耗时几乎没变。这是成本最低的一步改进，改几个数字就行。

然后是开思考。Flash-Next 在 xhigh 下同样 6 题全对，但代价很明显：平均每题从 9 秒左右涨到 57 秒，token 用量多了近 10 倍。最极端的是单词拆分那道题，它想了 214 秒，输出了 13,668 个 token。

Qwen3.8-27B-FP8 开了 xhigh 反而少对了一题。仔细看失败原因，一道是写了指数复杂度的解法，超过了 60 秒的判题时限；另一道还是方法名不合规。这更像是 27B 自身能力的边界，配置帮不上忙。

这里要说明一下测试的局限。6 道题的样本很小，每道题只跑了一次，一题之差就是 17% 的通过率，所以这张表只能看方向，不能当成精确的分数。而且这些都是一次性问答式的题目，模型读完题直接写答案。思考模式真正发挥作用的场景是多轮 agent 任务，读文件、改代码、跑测试、看报错再改，官方那段提醒针对的也是这种场景，而一次性问答测不出来。

所以我们又补了一个真实的多轮任务：让 Claude Code 派给 Qwen3.8-Flash-Next 一个三步的活，先读一个文件找 bug，再改一行代码，最后新建单元测试并运行。新配置下它 44 秒做完，两个测试都通过，改动范围和任务要求完全一致。整个过程里多轮工具调用、思考内容的回传都正常，没有再出现 400。

四、速度上的一个意外

我们原本以为，关思考至少能换来速度，这也是当初能接受关思考的一个理由。后来绕过 LiteLLM、直连 vLLM 测了一下同一道题的输出速度：

关思考反而慢了三到五倍。原因我们还没有确认，只有一个猜测，和一种叫"投机解码"的加速技术有关。

大模型平时生成文字，每出一个词都要把整个模型完整算一遍，这是它慢的主要原因。投机解码的做法是，先用一个很小、很快的预测模块一口气猜出后面几个词，再让大模型一次性检查这几个词对不对。猜对的直接采用，猜错的地方从大模型自己的结果接着往下写。猜得越准，一次能确认的词越多，速度就越快。Qwen3 之后的一些模型自带这样的预测模块，叫 MTP（多 token 预测），vLLM 部署时可以打开它来提速。

我们的猜测是：思考过程里的文字，比如"首先……然后检查一下……"，套路性比较强，小模块更容易猜中，所以开思考时加速效果好；而关掉思考后直接输出的代码和答案，猜中率可能低一些。不过这个猜测解释不了三到五倍这么大的差距，我们也没有查看服务端的配置和猜中率数据去验证，所以只能算一个待查的线索。

还要补充的是，我们的服务器是多人共用的，同一个请求在不同时间的速度能差到 5 倍，这部分波动和配置无关，也可能混进了上面的测量里。但至少在我们的环境里，关思考并没有带来速度上的好处，之前感觉到的"慢"，有一部分正是关思考造成的。

五、两个模型怎么选

最后附上官方模型卡公布的成绩，都是思考模式、Claude Code 环境下的数据：

数据来自 ModelScope 上的官方模型卡，粗体是该行最高分，我们没有独立复现。官方没有公布非思考模式的成绩，所以关掉思考之后这些分数会掉多少，没有官方数字可查。

两个模型之间，能对比的 10 项里 Qwen3.8-Flash-Next 全部高于 Qwen3.8-27B，差距最大的是 agent 类任务，DeepSWE 高出 16.5 分，Toolathlon 高出 6.4 分。我们自己的测试结果也是 Flash-Next 更好。所以我们现在日常用 Flash-Next，27B 留作备用。