27B稠密模型单卡部署：200K上下文评测

一、先看结论

这次评测要回答一个问题：约22GB显存的消费级显卡，能否在本地运行27B稠密模型并处理200K上下文。原始材料给出的显存数字之间存在矛盾。因此，200K上下文能否稳定运行，目前还不能下结论，需要先测出KV缓存的真实斜率。

二、被评测的模型与部署方式

• 模型结构：27B参数的稠密模型。推理时每个token都要激活全部权重，所以显存占用主要取决于参数量和量化位宽，无法靠跳过部分专家来省显存。
• 权重量化：主权重采用4比特中等质量量化。量化后文件约17GB，常驻显存的权重约15.1GB。
• 注意力架构：模型共64层，按16组组织，每组包含3层门控线性注意力和1层全注意力。只有16个全注意力层需要传统KV缓存，其余层维护固定大小的循环状态，因此缓存不随上下文线性增长。
• 多Token预测（MTP）：训练时内置MTP头。推理时，MTP头额外猜测后续若干token，主模型批量验证并采纳命中的部分，从而摊薄每个token的解码开销。

三、显存预算：KV缓存数字对不上

原始评测给出的显存分解如下。

组件	记录值
模型权重（4比特）	约15.1GB
KV缓存（8比特，200K）	约3.5GB
线性注意力状态与计算缓冲	约1.2GB
运行时与驱动	约1GB
合计	约20.8GB

问题出在KV缓存这一项。同一份材料还写道，8比特KV量化下每个token约占34KB。按这个斜率计算，200K上下文的KV缓存约为34KB × 200,000 ≈ 6.8GB，而不是3.5GB。3.5GB对应的斜率只有约17.5KB/token，两者相差约一倍。

两种数字分别会得出不同结论：

• 采用3.5GB：合计约20.8GB，在22GB卡上只剩约1GB余量，200K可以运行，但余量极窄。
• 采用6.8GB：合计约24.1GB，超过卡的可用容量，200K无法在该配置下稳定运行。

原材料还给出，同规模纯全注意力模型的斜率约为130KB/token，200K时约26GB。这个对比与34KB/token的比值约为3.8倍，与“近4倍”的说法一致。但3.5GB这个实测值的来源没有说明，它可能对应更少的上下文、不同的KV位宽或不同的层配置。在确认之前，本文不采信任何一组单独的数字。

四、复现前先固定变量

原材料未给出驱动、运行时版本和具体参数，读者无法直接复现。复现前至少应记录以下内容：

• 显卡驱动版本，推理运行时的版本与提交号；
• 权重量化格式与KV缓存位宽（8比特）；
• 批大小，原文称其已收敛到最小，需要记录具体数值；
• 测试上下文长度、提示词与采样参数（温度、top_p等）；
• 供电与散热状态，包括功耗限制、温度与风扇策略。

测量显存的思路很直接。先建立短上下文基线，再按梯度增加上下文长度，每档记录峰值显存，最后拟合斜率：

for ctx_len in [8K, 32K, 64K, 128K, 200K]:
    load_model(weight_bits=4, kv_bits=8, batch=1)
    peak = measure_vram_peak(ctx_len)     # 从驱动或运行时读取，不只看系统面板
    record(ctx_len, peak, free = total - peak)
slope = linear_fit(ctx_len, peak)         # 每token显存增量，应接近34KB或17.5KB之一
assert free(200K) > margin                # margin由团队自行设定

测得的斜率若与架构推算明显不符，应先检查配置，而不是直接采信某一组数字。

五、速度：57 token/s的测试条件

原文报告编码任务的生成速度约为57 token/s。这个数值对单人交互式编码来说是合理的，但材料没有给出测试时的上下文长度、批大小和采样参数，也没有说明MTP是否开启、命中率是多少。因此，它目前只能视为待复现的参考值。

测速时应注