3-bit量化的大模型，真能写出一款《打砖块》游戏？

使用3-bit量化的大模型写出一款《打砖块》游戏！球拍能移动，小球会反弹，砖块也能被逐个击碎。即便把模型压缩到2-bit甚至1-bit，有些模型依然能完成这样的任务。

在本地AI社区，这类演示已经越来越常见。只要游戏能够正常运行，再配上漂亮的Tokens/s数字，似乎就足以证明低比特量化的价值。

但最近，Level1Techs却对这种测试方法产生了怀疑。

一个模型最终成功写出了游戏，究竟是模型本身足够聪明，还是外围的Agent框架在不断纠错？量化过程中损失的那些精度，真的没有影响模型能力吗？

为了弄清楚这些问题，他找来了NVIDIA GB300、RTX PRO 6000 Blackwell和DGX Spark等硬件，试图追踪模型在不同精度、不同计算环境下的每一次预测变化。

模型能写游戏，不代表量化没有代价

在过去的本地AI测试中，Tokens/s几乎是最常出现的指标。

同样一个模型，在RTX 3090上每秒能输出多少Token，经过4-bit、3-bit量化后又能提升多少，都是玩家非常关心的问题。

Level1Techs也经常使用《打砖块》游戏作为测试任务。他甚至准备过一份超过6000 Token的提示词，要求模型按照特定约束完成游戏开发。

如今，即使是高度量化的模型，也有机会交出一份能够运行的代码。不过，随着AI Agent越来越普及，最终结果已经很难完整反映模型本身的表现。例如，一个模型生成了错误的代码，Agent框架可能会通过测试、反馈和重新执行将其修复。用户最后看到的仍然是一款正常运行的游戏，却不知道模型经历了多少次错误。

对于普通娱乐任务，这种差异或许影响有限。但当AI开始承担自动编程、调用外部工具、执行复杂工作流等任务时，细微的输出变化可能造成完全不同的后果。

Level1Techs 因此决定深入模型的Token生成过程，看看量化到底改变了什么。

开发PowerTool，逐个追踪模型预测的Token

为此，他开发了PowerTool，并准备了名为Quinception的测试数据集。

这套工具记录同一模型在不同权重格式、硬件和运行配置下的推理过程，然后逐个比较模型对下一个Token的预测。

为了尽可能排除随机性，测试没有采用常见的随机采样，而是让模型每次选择得分最高的Token。

不同配置还会接收到完全相同的历史文本，确保比较发生在同一个预测位置。

如果两个配置选择了不同的Token，PowerTool就会标记这个分歧点，并展示后续约100个Token的生成情况。

这样一来，研究者就能进一步判断，某次预测变化究竟只是换了一种表达，还是破坏了代码、JSON结构或者工具调用指令。

当然，这种方法需要保存大量中间数据。Level1Techs 透露，如果没有铠侠提供的大量闪存存储设备，整个测试很难完成。

测试平台也相当豪华，包括搭载Blackwell Ultra架构的GB300、RTX PRO 6000 Blackwell，以及搭载GB10的DGX Spark。

虽然这些设备都属于NVIDIA Blackwell家族，但其计算能力、底层架构细节和软件执行路径存在差异。

特别是在FP4计算方面，测试观察到了不同平台之间明显的行为差异。

意外发现：FP8 KV Cache竟然破坏了工具调用结构

真正值得关注的结果，出现在GB300的测试中。

研究者首先发现，混合NVFP4权重配置改变的下一Token选择，比其他受测权重格式更多。

这意味着，模型虽然仍然能够生成看似合理的内容，但内部的预测路径已经发生变化。

更有意思的情况发生在KV Cache上。

研究者专门挑选了6个具有挑战性的生成起点。在这些案例中，作为参考的BF16配置都能生成结构正确的输出。

但更换精度配置后，结果发生了明显变化。

使用FP8 KV Cache时，6个案例中有5个生成了结构错误的工具调用。

相比之下，使用混合NVFP4权重时，有1个案例出现结构错误，另有2个案例在记录到后续100个Token时仍未完成输出。

需要强调的是，这6个案例经过刻意筛选，属于容易出现问题的困难样本，不能据此认为FP8 KV Cache在日常使用中的错误率高达83%。此外，100个Token内尚未完成输出，也不能直接判定任务失败。

但实验揭示了一个容易被忽视的现象：即使某种量化方案改变的Token数量较少，也有可能恰好影响关键的结构字符，导致整个工具调用失效。

对于需要连续执行任务的Agent而言，一个错误的括号、一段不完整的参数结构，都可能让工作流中断。

研究者还发现了另一个意外情况。

同一个模型，即使不修改量化设置，仅仅把Tensor Parallelism从TP1改成TP2，也可能产生不同的Token预测结果。

他推测，这很可能与浮点计算的舍入误差有关。由于不同并行方式会改变计算和累加顺序，最终可能导致两个得分非常接近的Token交换排名。当然，也无法完全排除底层实现问题。

换句话说，即使模型权重完全相同，硬件配置和计算路径的变化，仍可能影响模型的最终输出。

以后测本地AI，Tokens/s可能远远不够

经过这轮实验，Level1Techs提出，希望本地AI社区建立更加透明、可复现的模型质量评估体系。

除了公布推理速度，还应当明确测试所用的模型Checkpoint、硬件配置、软件版本和计算内核，并提供相对于高精度参考模型的变化数据。

例如，可以利用KL散度衡量预测概率分布的偏移，通过Top-1不一致率统计下一Token选择发生变化的频率，再结合实际生成内容，检查代码和工具调用能否正常执行。

这些指标能够帮助开发者进一步判断，一项量化或者推理优化技术究竟付出了多少质量代价。

当然，低精度计算的价值依然非常明显。NVFP4等技术能够大幅降低模型运行所需的存储和计算资源，而且在不少任务中仍能保持很好的表现。

只是随着本地AI开始承担越来越复杂的任务，模型的可靠性也需要被认真衡量。

尤其是在Agent应用中，单次调用的细微错误可能沿着工作流不断传递，最终影响整个任务。

PowerTool目前还只是一个起点。他已经在Level1Techs论坛分享相关数据和工具，希望社区用户继续分析不同分歧案例，区分无关紧要的文字变化与真正影响任务执行的错误。

对于本地AI玩家来说，这项研究也提供了一个新的观察角度。

当一款量化模型以更少的内存、更高的速度完成任务时，除了关注它每秒输出多少Token，或许还应该看看：在那些肉眼看不到的预测过程中，它究竟改变了什么，又有没有在某个关键步骤悄悄出错。