北京
“每生成一个 token，它都会把模型的所有权重从头到尾完整读一次。”一位开发者在分享自己的测试结论时这样写道。这句话揭开了大语言模型在单用户场景下推理延迟的关键——不是参数量、不是浮点运算次数，而是权重在显存里占了多少字节。
他把 4B 参数模型以 INT8 精度量化（权重文件约 4.0 GB）和 8B 参数模型以 INT4 精度量化（约 4.3 GB）放在同一张 GPU 上跑。结果是：4B‑INT8 每个 token 耗时 5.98 ms，8B‑INT4 耗时 6.50 ms，速度几乎一样，尽管前者的参数数量只有后者的一半。实验者原本以为一个 4B 模型应该比 8B 快接近一倍，实际第一轮测量却只有 1.24–1.36 倍的提速。他差点就此得出结论：“切到 4B 换不来多少收益”。
问题不在模型，而在测量方式。那轮对比里，4B 一侧背了两个包袱：使用了不同的量化核（该核在这张 GPU 上解包效率更低），并且适配器仍以外部挂载方式运行，每个生成步骤都多算一个小矩阵乘法。后来他把 4B 模型也改用与 8B 侧相同的量化方案，并把适配器合并进模型本体，再测——速度差立刻拉大到 2.3 倍。2.35 倍的差距在错误设定下可以完全消失，甚至反转。
为什么权重文件的字节数决定了速度？因为当批量大小等于 1（只给一个用户生成）时，每产出一个 token，计算单元读显存的时间远长于实际运算时间。整份权重都要被读一遍，读写量就是权重的字节总数；内存带宽直接成为瓶颈，生成速度与权重字节数成反比。这就是为何 4.0 GB 和 4.3 GB 几乎一样快，而 8B‑INT8 模型（约 8 GB）会慢上一大截。
这个发现对选卡和选模型的决策影响很直接：如果做单用户低延迟部署，盯着内存带宽比盯着 TFLOPS 更有用。再看那些标注着参数规模的模型卡，真正该对比的是它们在不同量化精度下的“字节数”。两张参数量相差一倍的卡，通过不同的量化等级可以把实际读取量拉至同一水平，速度也就拉平了。
实验者最后提醒，任何关于模型快慢的结论都必须先把部署条件对齐——相同的 GPU、相同的量化核、相同的批量大小、相同的适配器合并状态。一次没有对齐的比较，就能让 2 倍的性能差伪装成“几乎没有区别”，让选型完全跑偏。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
