# Qwen3.8-Flash-Next 和 Qwen3.8-27B 怎么配置：我们踩过的坑和实测对比 > 龙虾AGI通用实验室 · 2026-09-28 我们自己部署了两个 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 错误： 400 Unexpected reasoning effort high. Supported types are xhigh(default), medium, and low. 意思是它不认识 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，也就是不启用。 ## 官方推荐值 参数 思考模式 非思考模式 我们改前实际发的 temperature 1.0 0.7 1.0 top_p 0.95 0.80 未设 top_k 20 20 未设 presence_penalty 0.0 1.5 未设（等于 0） repetition_penalty 1.0 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 CustomLoggerclassQwenEffortFix(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.0data["top_p"] = 0.95returndataproxy_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，参数用官方思考那一套 之所以加中间这一档，是想把两件事分开看：光把参数配对能改善多少，再开思考又能改善多少。 模型 配置 通过 平均耗时/题 总输出 token 失败原因 Qwen3.8-Flash-Next 旧配置 5/6 10.9 秒 1,949 中位数算错 Qwen3.8-Flash-Next 关思考但参数配对 6/6 9.3 秒 2,059 无 Qwen3.8-Flash-Next 新配置 xhigh 6/6 56.8 秒 19,706 无 Qwen3.8-27B-FP8 旧配置 4/6 19.8 秒 2,100 四则运算解析错；方法名没按要求叫 add Qwen3.8-27B-FP8 关思考但参数配对 5/6 20.3 秒 2,050 四则运算算错 Qwen3.8-27B-FP8 新配置 xhigh 4/6 29.8 秒 4,230 单词拆分超时；方法名又没叫 add 先看旧配置。两个模型在旧配置下都是最差的一档。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 测了一下同一道题的输出速度： 模式 输出速度 关思考 12 到 20 token/s 开思考（low 档） 63 到 83 token/s 关思考反而慢了三到五倍。原因我们还没有确认，只有一个猜测，和一种叫"投机解码"的加速技术有关。 大模型平时生成文字，每出一个词都要把整个模型完整算一遍，这是它慢的主要原因。投机解码的做法是，先用一个很小、很快的预测模块一口气猜出后面几个词，再让大模型一次性检查这几个词对不对。猜对的直接采用，猜错的地方从大模型自己的结果接着往下写。猜得越准，一次能确认的词越多，速度就越快。Qwen3 之后的一些模型自带这样的预测模块，叫 MTP（多 token 预测），vLLM 部署时可以打开它来提速。 我们的猜测是：思考过程里的文字，比如"首先……然后检查一下……"，套路性比较强，小模块更容易猜中，所以开思考时加速效果好；而关掉思考后直接输出的代码和答案，猜中率可能低一些。不过这个猜测解释不了三到五倍这么大的差距，我们也没有查看服务端的配置和猜中率数据去验证，所以只能算一个待查的线索。 还要补充的是，我们的服务器是多人共用的，同一个请求在不同时间的速度能差到 5 倍，这部分波动和配置无关，也可能混进了上面的测量里。但至少在我们的环境里，关思考并没有带来速度上的好处，之前感觉到的"慢"，有一部分正是关思考造成的。 ## 五、两个模型怎么选 最后附上官方模型卡公布的成绩，都是思考模式、Claude Code 环境下的数据： 基准 Qwen3.8-Flash-Next Qwen3.8-27B Qwen3.7-Plus DeepSeek-V4-Flash Claude Opus 4.6 (Max) SWE-bench Pro 62.5 61.7 55.8 56.0 53.4 DeepSWE 1.1 58.7 42.2 16.5 54.4 -- SWE-bench Multilingual 81.0 73.8 75.8 -- 77.5 NL2Repo-Bench 48.1 42.3 41.1 54.2 47.6 Terminal Bench 2.1 -- 73.0 64.0 -- 78.2 CoWorkBench 73.9 70.7 65.1 45.1 68.2 Toolathlon Verified 73.5 67.1 50.6 70.3 -- IFBench 81.3 79.5 79.1 79.2 62.5 GPQA Diamond 91.7 89.2 90.3 90.8 91.3 LiveCodeBench v6 91.9 90.3 89.6 90.6 88.8 HLE 35.9 30.8 34.7 33.8 40.0 数据来自 ModelScope 上的官方模型卡，粗体是该行最高分，我们没有独立复现。官方没有公布非思考模式的成绩，所以关掉思考之后这些分数会掉多少，没有官方数字可查。 两个模型之间，能对比的 10 项里 Qwen3.8-Flash-Next 全部高于 Qwen3.8-27B，差距最大的是 agent 类任务，DeepSWE 高出 16.5 分，Toolathlon 高出 6.4 分。我们自己的测试结果也是 Flash-Next 更好。所以我们现在日常用 Flash-Next，27B 留作备用。 ![](images/81cc49/img_001.png) 我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。 如果你也在自己**跑模型、写代码、做项目**， 或者使用**Claude**和**Claude code**， 欢迎**点赞关注转发**一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，有一定门槛。 ![](images/81cc49/img_002.jpg)