上周五凌晨三点，Qwen2.5-32B-Instruct-GGUF 在 sidecar 里把我的日志清洗任务卡死了

上周五凌晨三点，Qwen2.5-32B-Instruct-GGUF 在 sidecar 里把我的日志清洗任务卡死了

上周五凌晨三点，我盯着 Grafana 里那个红得发紫的 P99 延迟曲线发呆。我们的日志清洗 sidecar 跑的是 Qwen2.5-32B-Instruct-GGUF q4_k_m，部署在 GKE 的 n2-standard-8 里，限制 16Gi 内存。平时跑得好好的，那晚突然全挂了——不是 OOM，是 CPU 飙到 100% 卡住不动，health check 连续失败被 kubelet kill 重启。

事情得从周三说起。

发现

leader 甩过来个需求：把 Java 服务吐出来的那种半结构化异常堆栈——夹杂着中文业务码、英文类名、十六进制内存地址、甚至还有 base64 编码的 protobuf 片段——用大模型抽成标准 JSON 入 ClickHouse。本来用正则 + grok 能搞定 80%，剩下 20% 太杂，leader 非要上大模型「一劳永逸」。

我选 Qwen2.5-32B-Instruct 主要是看中它对中英混排代码 token 的理解。HuggingFace 上下载的 bartowski 量化版，q4_k_m，模型卡写着 context 32k，实际跑起来发现只要不超过 8k tokens 输出就稳。Prompt 精心调过：system prompt 里塞了 JSON Schema、少样例、甚至还用了「如果不确定字段请填 null 别瞎编」这种负向约束。

周三下午上线，canary 10% 流量跑了两小时，指标漂亮：提取准确率 94.7%（人工抽样 200 条），P99 延迟 1.2s，吞吐 45 req/s。我还发了条 slack 炫耀：「这破模型居然能把 com.xxx.biz.OrderService.createOrder:127 里的行号单独拎出来。」

猜测

周四晚上十点，告警响了。不是延迟告警，是 sidecar 容器重启频次告警。我爬起来看日志，发现一个诡异现象：所有卡死的请求，输入里都带有一种特定模式——中文业务错误码（类似 ERR_订单状态异常_001）紧跟着十六进制地址（0x7f8a3c00），中间没有任何分隔符。

```

ERR_订单状态异常_0010x7f8a3c00

```

正常日志里中间至少有个空格或冒号。但那天上游某个新发布的微服务把分隔符吃了，恰好撞上这批脏数据。

我第一反应：context window 溢出了？去查 token 计数，最长输入也就 3.2k tokens，离 32k 早着呢。第二反应：GGUF 量化导致的数值不稳定？把 temperature 从 0.1 调到 0.3 试了下，居然跑通了。但 temperature 0.3 输出 JSON 格式不稳定，经常漏括号、多逗号，不能直接入库。

验证

周五凌晨两点，我在本地用 llama.cpp 跑同一个 GGUF 文件，复现了卡死。关键发现：卡死不是无限生成，而是在生成到某个特定 token 时，logits 里出现了全 -inf，导致采样器陷入死循环。

用 llama-server --logit-bias 把那个位置的 token 强制 mask 掉，居然能跑通。但这治标不治本——下次遇到新的脏数据组合怎么办？

我把输入切片，二分查找定位到最小复现单元：

```

ERR_订单状态异常_0010x7f8a3c00

```

只有这一行，temperature 0.1 必卡死，0.3 正常。把 _001 改成 _002 就正常。把 0x 改成 0X 也正常。

有意思的是，用 HuggingFace 原版 transformers 跑 fp16 同模型，temperature 0.1 完全正常。说明是 GGUF 量化的锅。

排除

我先怀疑是 q4_k_m 的量化方案问题。换了 bartowski 的 q5_k_m、q6_k、甚至 IQ4_XS，全复现。换 llama.cpp 官方转换的 q4_k_m 也复现。说明不是量化精度问题，而是量化后的权重分布在某个极端输入下触发了数值下溢。

又试了下 llama.cpp 的 mirostat 采样器，温度 0.1 下也能跑通，但输出质量肉眼可见变差——JSON 字段名都开始幻觉。

这时候同事老张（坐我对面那位）扔过来句：「你试过在 prompt 里强制加个空格分隔符吗？」

我改了下预处理：正则把 ([\u4e00-\u9fff])([0-9a-fA-F]{8,}) 替换成 \1 \2。重新跟测，temperature 0.1 彻底正常，P99 回到 1.3s，准确率没掉。

再猜

但这只是绕过，不是解决。根因在哪？

我把那个触发卡死的 token 序列 dump 出来，找 tokenizer 对应的 id。Qwen2.5 用的 tiktoken 变体，ERR_订单状态异常_0010x7f8a3c00 被切成 47 个 token。在第 31 个 token（对应 0x7 的一部分）处，模型输出 logits 的 max 值只有 -12.4，而正常情况下这一位置通常在 -2 到 -4 之间。

量化后的权重矩阵在某些稀有 token 组合下，累积误差把 logit 压到了 -inf 附近。temperature 0.1 时 softmax 直接把概率压成 0，采样器找不到可用 token 就卡住。temperature 0.3 时 softmax 还有残留概率，能侥幸跳过去。

这解释了为什么 fp16 没事——fp16 动态范围够大，累积误差不至于下溢。

最终解决

没办法改模型权重，只能工程绕过。最后方案三层：

预处理层：Go 里加个轻量 tokenizer（用 shlex 变体），检测中文紧跟十六进制无分隔的情况，强制插空格。延迟增加 0.3ms，可忽略。

兜底层：sidecar 里跑两个实例，主实例 temperature 0.1，备用实例 temperature 0.3 + mirostat 2.0。主实例超时 2s 熔断走备用，备用输出再走一遍 JSON 修复器（自己写的状态机，比大模型靠谱）。

观测层：Prometheus 记录 llm_sampling_fallback_total，Grafana 面板加行，下次再涨我第一时间知道。

上线后跑了三天，fallback 率 0.07%，P99 稳在 1.4s 以内。leader 问我为啥不直接上 temperature 0.3，我说：「0.3 生成的 JSON 我还得写修复器，不如 0.1 稳，修复器我只写一次。」

说实话，这事儿让我对开源模型量化部署有了新认知：量化不是无损压缩，是有损压缩，损在你意想不到的长尾分布上。下次谁再跟我说「q4_k_m 生产可用无感知」，我直接甩这个 Grafana 截图给他看。

对了，还有个细节：Qwen2.5 的 tokenizer 对中文数字单位（万、亿）切分很激进，导致业务码里的 _001 被切成 _ 00 1 三个 token，这放大了量化误差传播。如果你也在用它处理类似混合码，建议先跑一遍 tokenizer 统计，看看有没有这种「低频 token 组合高频出现」的模式。

想问问大伙儿：你们在生产环境跑量化模型时，遇到过类似「特定 token 组合触发数值下溢」的坑吗？是靠预处理绕过，还是真改了推理引擎代码？

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。