本地部署 QwQ-32B 回答变笨：昇腾 MindIE 排查清单

在昇腾 300I DUO 上把 QwQ-32B 跑起来，显存吃到 160G 左右、利用率 70% 以上，出字速度也不慢，可是一让它写代码就明显「降智」，和网页版体验差距很大。换成本身更擅长代码的蒸馏模型后略有改善，但依旧啰嗦、答不到点上。

这类情况在自建推理服务里非常常见。多数时候不是「这张卡带不动 32B」，而是模型文件、推理参数、服务链路里某一环没对齐。下面按排查成本从低到高排一遍，大部分问题在前三步就能定位。

先判断是「模型差」还是「部署错」

网页版通常背后是更大的模型、官方调好的系统提示词，还可能挂了工具调用；本地跑的是 32B 开源权重，能力有差距是正常的。但如果出现下面这些现象，就基本可以判定是部署侧的问题，而不是模型本身：

• 代码语法频繁出错、括号和缩进混乱；
• 答非所问，或者答到一半突然中断；
• 同一个问题多次提问，质量波动极大；
• 简单逻辑题也推不明白，但闲聊很流畅。

建议固定一道中等难度的题作为基准，例如「用 Python 写一个带超时和指数退避重试的 HTTP 客户端，并给出两个测试用例」。每次改配置都用同一道题对比，否则很容易凭感觉判断。

原因一：跑的是量化权重而不自知

从模型仓库拉权重时，很容易下到别人量化好的版本，或者推理框架默认加载了低比特权重。量化对代码类任务特别不友好，位宽降下来最先崩的就是长逻辑和细节记忆。

检查方法很简单，看模型目录里的配置文件：

ls -lh /path/to/model
python -c "import json;c=json.load(open('/path/to/model/config.json'));print(c.get('quantization_config'), c.get('torch_dtype'))"

如果 quantization_config 里有 bits、quant_method 之类的字段，或者文件名带 w8a8、awq、gptq、Q4_K_M 等后缀，那就是量化版本。想验证影响，用同一道题分别跑一份全精度权重和一份量化权重，差距通常一眼可见。

另外要注意，显存占用高不代表没量化。32B 模型 bf16 权重约 64GB，剩下的显存大多是推理框架按比例预分配的 KV Cache。所以 160G 这个数字既不能证明用了全精度，也不能证明做了量化，必须直接看权重文件。

原因二：推理链被截断，思考没走完

QwQ 属于先输出思考过程、再给结论的推理模型。如果服务端或前端的最大输出长度设置得太小（比如 1024 或 2048），模型会在思考中途被强行掐断，最终答案自然是残缺甚至错误的——表现出来就是「笨」。

处理方式：

• 把单次响应的 max_tokens 提到 8192 以上，复杂任务给到 16k；
• 服务端的 maxSeqLen / maxInputTokenLen 要一起放大，否则请求会被直接截断；
• 前端如果默认隐藏思考过程，注意看返回体里是否只有空的 content，真正的内容被切到了别的字段里。

原因三：采样参数没生效，或前端配置被覆盖

很多人是在 Open WebUI 界面里调温度，但如果服务端适配层没有把采样参数透传下去，界面上的改动就完全无效——这正是「调了温度没什么用」的典型原因。

先绕开前端，直接打后端接口验证：

curl http://<host>:<port>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwq-32b",
    "messages": [{"role":"user","content":"用 Python 写一个带重试的 HTTP 客户端"}],
    "temperature": 0.6,
    "top_p": 0.95,
    "max_tokens": 8192
  }'

接口路径和字段以所用推理框架的官方文档为准。如果直连后端效果明显好于走前端，问题就在前端参数映射；如果两边一样差，就去查服务端。

关于取值，QwQ 官方模型卡给过一组推荐区间，大致是 temperature 在 0.5～0.7、top_p 0.95 左右，重复惩罚保持接近 1.0，具体请以模型卡最新说明为准。推理模型对参数比较敏感，温度拉得太高会明显发散。

原因四：对话模板和上下文长度对不上

这一类问题最隐蔽。模型权重自带特定的对话模板（各种特殊 token），如果推理框架加载时用了默认模板，或者模板里对 system 角色处理不一致，模型收到的其实是一段「格式错乱」的输入，输出质量会断崖式下跌。

排查要点：

• 确认服务端加载的是该模型自带的 tokenizer_config.json / chat template，而不是框架默认模板；
• 推理模型通常不建议塞复杂的 system prompt 和 few-shot 示例，官方一般建议直接给问题，需要时用一句中性的角色描述即可；
• 检查上下文窗口：前端或框架的默认 num_ctx 可能只有 2048 或 4096，多轮对话很快被截断，模型「忘记」前面说过的要求，看起来就像不会写代码。

昇腾 + MindIE 栈上的额外注意点

使用 MindIE 这类昇腾原生推理栈时，与通用教程（例如给 Ollama、llama.cpp 用的那套调参建议）往往不能直接照搬，重点看这几处：

• 模型配置文件里的权重路径、maxSeqLen、npuMemSize、批量大小是否与实际硬件匹配；
• 启动日志里打印的加载精度和量化方式，是否与预期一致；
• 昇腾的推理镜像、驱动、MindIE 版本之间有明显配套关系，版本错配会导致算子回退甚至精度异常；
• 这类栈的配置项和推荐值随版本变化较快，遇到具体字段务必查对应版本的官方文档。

如果排查到这里仍然没有头绪，直接带着日志和完整请求体找厂商技术支持，比自己盲试参数高效得多。

换模型之前先想清楚

用 DeepSeek-R1-Distill-Qwen-32B 感觉「好一点但仍然啰嗦」，这个结果符合预期：蒸馏模型的表达能力受限于 32B 底座，在代码任务上本来就明显弱于原版大模型。同一量级下换模型通常只能带来小幅改善，真正拉开差距的是参数规模和后训练质量。

所以更务实的路径是：先把上面四项排查做完，确认现有部署已经跑到该模型的上限，再考虑换模型或加规模。如果最终目标只是要一个能稳定写代码、长期在线的助手，而不是研究国产卡上的推理部署，把这类工具放到远端长期开机的机器上运行，也是常见的替代思路，能省掉大量环境对齐的功夫。

小结

按这个顺序走一遍，基本能定位问题：

1. 看权重文件，确认是否量化、精度是多少；
2. 放大 max_tokens 和服务端序列长度，确保推理链完整；
3. 用 curl 直连后端，确认采样参数真的生效；
4. 核对对话模板和上下文窗口，排除格式与截断问题；
5. 以上都正常，再考虑换模型或加算力。

每次只改一个变量，用同一道基准题对比输出，比反复「感觉好像好一点」可靠得多。