一个反直觉的结果

435GB 的模型。64GB 的内存，理论上不可能。

但我跑起来了—— tok/s，和笔算结果一分不差。

接下来模型吐出了个、第四个、第五个…，从第一个到最终一个，全是 ?，?，?，?，?，。

不是中文不好。不是英文不行，是从第一个字符开始，全部损坏。

我盯着屏幕沉默了大概 秒。那种感觉很难形容——如果你也调试过那种“明明逻辑是对的但就是不 work”的 bug，你应该懂。这时你既兴奋，又困惑，还有一点绝望。

但这正是排查最迷人的地方。怎么说呢，如果一跑就通，你什么也学不到。只有它坏了你才被迫去理解它的每一层是怎么工作的。

为什么我觉得这事能成

先交代背景。怎么说呢，

前几天 Unsloth发了 GLM‑ 的 GGUF 版。GLM‑ 是智谱最新的旗舰——753B 参数，个专家，MoE 架构。

Mac Studio。就一台笔记本：

┌────────────────────────────────────────────────────────┐│ AMD Strix Halo 笔记本 │├────────────────────────────────────────────────────────┤│ CPU: AMD Ryzen AI MAX+ ││ GPU: AMD Radeon 8060S ││ 内存: 64GB DDR5 ││ 硬盘: × 1TB NVMe SSD ││ 程序: Windows │└────────────────────────────────────────────────────────┘

64GB 内存，435GB 的模型文件，看起来像倍数差距。如果你在群里说“我打算用笔记本跑 753B”，大概会收到一屏幕的问号——比我的模型输出还多。

但 MoE 有一个关键特性：每次推理只激活 % 的参数。753B 参数里只有约21B参与计算。435GB 的模型文件里只需热读取13GB，其余可以安心躺在 SSD 上。

┌─────────────────── 理论计算 ───────────────────┐│ ││ 激活参数 = 专家 × 层 × .75MB ││ = .2GB ││ ││ SSD 顺序读取 = 2GB/s ││ ││ ┌────────────┬──────────┬──────────┐ ││ │ 缓存命中 | 磁盘读取 |估算速度 | ││ ├────────────┼──────────┼──────────┤ ││ │ % | .66GB | tok/s | ││ │ % | .32GB | tok/s | ││ │ % | .64GB | .75tok/s| ││ └────────────┴──────────┴──────────┘ ││ ││ 只要缓存命中 ≥ %。可达 tok/s+ ╚═══════════════════════════════════╝

tok/s足够慢，却足够用！

至于类比一下。就像一个打字速度一般的同事，不太快，但沟通没问题。

理论上通用，上手动手！

说到第一关，加载成功。速度完美

下载 Unsloth 的 UD-Q4_K_XL量化版，共435GB；llama.cpp b10107 HIP版加载。说起来，

I srv llama_server: model loaded

• "435GB 模型。只用了43GB就加载完成"

为什么能这么高效？mmap按需加载让大模型在小内存上撑起自己！话说回来，

程序状态变换图示：

# 加载过程中 CPU 使用率与内存使用变化
时间 / 内存 / CPU %
0s /8G/10%
30s/35G/60%
60s/43G/80%
120s/43G/70%
…


关键点： 1. mmap实现按需加载；2. SSD顺序读优先；3. 内核分页机制自动调度页缺失；


发送首请求 & 输出回报：
# 首轮请求
{
“speed”: “tok/s”,// 与理论值吻合 ✅
“output”: “?，?，?，?，?，?，” // 全部问号 ❌
}
速度对了只差输出正确。问题不在硬件，也不在加载方式，而是在某条计算方法上出现 bug。排查正式开始，

嫌疑人全景图表​


现象 
可能原因 
排除方法 



全是?tokenizer 损坏 && HF词表逐条比对全为?
量化格式 bug对比标准 Q4_K_M全为?HIP 库计算错误对比纯 CPU版本全为?话说回来，启动参数异常逐一排除--flash-attn/-t/--no-mmap/--cont-batch全为?版本未更新升级b10142含 Indexer 修复全为?网站差异对比 Linux/Windows结果
😝

Tokenizer 损坏导致词表缺失
Quantization 格式错误导致权重解码错误
HIP 错误导致矩阵乘法误差
启动参数错误导致代码方法偏移
Indexer Bug导致 token 方法错误
Windows vs Linux 浮点行为不同导致数值误差
👎

逐条验证词表一致性
标准 Q4_K_M 对照测试无乱码
纯 CPU 与 HIP 两版输出一致无误差区分 

-> 所有已排除 ✗


嫌疑人列表

真凶浮现 → 网站差异 Linux 正常、Windows乱码 ↩️🤖🛠️⚙️💡👀👨‍💻👩‍💻👓📈🧑‍🔬🧑‍🔬💻💾🧪📢🤝😎😄🕵️‍♂️📖🚨🙅🥵🥶⛏️🚥🌈⛽🏗️🌱🚢🚢🌹❇️😃✅✔️🛋🔗➰🎉✍🏼📊🔍✨


'此表仅用于快速定位，可根据实际情况调整'






 以下章节依次剖析每位嫌疑人并给出最终结论。👇点击展开查看细节👇
◦ 嫌疑一号：Tokenizer …，◦ 嫌疑二号：量化格式 …，◦ 嫌疑三号：HIP 库 …，◦ 嫌疑四号：参数设置 …，◦ 嫌疑五号：版本更新 …，'...…....'
‘’
**…**
​
​
​
​
​
​
​
…，…老实说，​
**现在名单清空**：


tokenizer ✅ 排除词表。条零差异

量化格式 ✅ 标准 Q4_K_M 一样乱码

HIP 库 ✅ pure CPU 一样乱

参数设置 ✅ flash-attn / no-mmap / cont-batch 等全部无效

版本更新 ✅ b10142 Indexer 修复未改变结果
* 真凶* ：网站差异 Windows vs Linux ❗
**Linux 正常、Windows 糜糕** – 唯一剩下的网站因素决定输错与否。按理说，---
#### 为什么 Linux 正常？老实说，同一份源码，同一个模型，同一种量化。在 CPU-only 模式下一切都一样，只剩编译器与 OS 决定浮点行为。---
#### 真凶浮现


MVC 默认 /fp:precise 与 GCC/Clang 默认 -fno-fast-math 存有舍入模式、FMA 精度及累加顺序等细微区别；

MVC 在 FMA 中使用不同指令集或调整策略；

Larger intermediate precision 在 x86_64 SSE/X 方法下与 ARM 或其他程序结构有所区别；

C++ 标准库中 math.h 函数实现也因编译器而异。

**主要结论**：MLA absorbed 方法极度敏感于这些细节。一点误差即可把 softmax 概率分布彻底颠倒，从而选错 token —— 所有输出都变成 '?' 或其它乱码，这不是 Windows 差劲，而是 **MLA 假设所有网站浮点行为一致** — 实际并非如此。

需要修正或显式指定浮点模式来保证跨网站一致性！"
"
"
"
"
"
"
"
---
#### 给你的建议



下面列出几条可选方案还有成本与收益：


NVIDIA GPU ：KTransformers + CUDA → best experience on Windows.

X86_64 CPU-only on Linux → 可行但速度有限.

MackOS‑style Metal path → 在 macOS 上工作正常，无此 bug.

KTransformers + CUDA on NVIDIA 显卡绕过 llama.cpp 主方法 → 在 Windows 上表现优越.

= Colibri on low‑cost CPUs -> 可以跑通但速度慢。










如果你不想等修复 —— 短期旁路建议：







.


Bug 修复后未来路线图
 

给你的机器正名：Strix Halo 并非废铁！

若你正在使用类似 AMD Strix Halo 笔记本，这篇排查会让你信心倍增：



调整方向 
原理 
难度 
预期增益 



bigger KV cache compression from FP16 to INT8 → 更少显存占用 && 更高并发。
LRA 改进提高热专家命中率。从 ~% 提高到 ~%，相当于多出 ~10k tokens 每秒。
$★★★$ 
$+~tok/s$ 


'route prefetching based on router logits'
—提前读入即将需要的专家权重。
'async preload via ' 加速 I/O。
$★★★$ 
$+~tok/s$ 


*更多调整思路请参见原文末尾*











Cores&&，&&，&&，&&，&“'>主要特点”
✦✦✦✦✦✦✦✦✦
❧
;size="width",height="height",width="width",height="height",width="width"。height="height",width="width",height="height",width="width",height ="height";size ="width".width.height.width.height.width.height.width.width.height>



;size = "" size = "" size =""
size =""";

"





-->
©



以上内容仅为示例展示。请根据自己的具体机型自行填写相关信息


最终一句话 🚀

如果你正在折腾本地大模型，请把这段记录留作备忘——只要找到对应网站特性，即可轻松解决。

如有新的进展，我会及时在评论区更新。怎么说呢，

祝大家早日跑通属于自己的“大模型”。不要被一次次奇怪乱码困扰！


#GLM#llama.cpp#MoE#大模型部署#753B#Windows#浮点精度#endnotesupportenjoyingtechreadingthanksreadertopicscommunitycontributionshareupdatequestionhelpfulfeedbacklikeShareAllrightgoodbye!