本地大模型怎么测才可复现：KUN 的测试方法
先问“能不能用”而不是“能不能跑”；先建基线再加变量；粗扫后再加密。所有数字都能追到原始日志。这些规则来自一次次踩坑。
三条原则
1. 问“能不能用”，不是“能不能跑起来”。 “6GB 能跑 35B”没有意义。要问的是：能不能达到实际可用？卡住它的是权重、KV cache、内存还是速度？结论是“能加载但慢到没用”，同样值得写。
2. 先有基线，再加变量。
先用官方 llama.cpp 建基线，再依次摸 -ngl、上下文、KV 量化的边界，最后才试非官方的优化。顺序反过来，变快了也不知道是谁的功劳。
3. 先粗扫，再在拐点加密。 先粗扫一遍（比如 0/10/20/30/全部），找到边界再在附近细测。不为填满表格去跑：3 种硬件 × 6 个模型 × 3 种量化 × 2 个框架 × 3 种上下文，就是 324 组。
踩过的坑
- 测不到的差异：第一次测 KV 量化用了默认上下文，只有约 640 token，显存差 6 MiB，等于没测。拉到 16K 才看出省了 492 MiB。
- 噪声当结论：
-ngl 10比-ngl 0慢 4%，但这在同批次噪声范围内，只能说“没变快”。 - 元数据会骗人：一个标着 Q4_K_M 的文件，实际张量里 Q8_0 占 34%、F32 占 49%。文章里要写实际的量化名（UD-Q4_K_XL），说明是混合精度。
- 采样太粗：显存每秒采一次，几乎只抓到常驻值，抓不到瞬时峰值。这种数字只能说明“没超 6GB”。
每篇文章都会写清楚
- 硬件、驱动、框架 commit、编译参数；
- 模型文件名和量化；
- 完整命令；
- 哪些是我们自己测的，哪些引用了官方或别人的数据。