内容提要
文章解释专家缓存不适用于稠密模型:MoE每Token仅激活约3B参数,可缓存热点专家;而Qwen3.8-27B每Token需计算全部27B权重,按Token搬运权重受PCIe带宽限制。作者在16GB显存上实现稠密推理引擎,通过显存预算规划、零拷贝放置、12种GGUF量化块原位GEMV、单流子层融合及分块注意力显著降低延迟,但整网端到端吞吐仍待实测。
延伸解读
MoE 缓存思路为何在稠密模型上失效
文章用带宽账说明关键差异:MoE 每 Token 仅激活约 3B 参数,相邻 Token 常命中同一批专家,缓存热点专家可减少权重搬运;而 Qwen3.8-27B 每 Token 需计算全部 27B 权重,若 8GB 显存下约 6GiB 权重留在主机内存,按 PCIe 4.0 x16 实测有效带宽 25–28GB/s 计算,单 Token 传输就需 200ms 以上,解码被压到 4 tok/s 以下。因此稠密模型不能照搬按 Token 换入权重的缓存策略。
16GB 显存的关键是预算核算而非“能装下”
文章强调不能只看模型体积。14.24GB 权重之外,还要计入 16 层全注意力 KV Cache(8K 上下文约 512MiB、32K 约 2GiB)、48 层 Gated DeltaNet 循环状态(每序列约 149.6MiB,且需双缓冲)、工作区、传输暂存和安全余量。作者用容量规划器按真实可用显存核算,超出时直接报错而不自动截断上下文或降级 KV 精度,避免触发共享显存分页导致速度骤降。
原位量化计算与单流融合的实际收益
文章显示,CUDA 直接处理 12 种 GGUF 混合量化块可避免展开 FP16 副本;在 RTX 5060 Ti 16GB 上,IQ4_XS、Q5_K、Q6_K 矩阵的有效权重带宽达 330–375GiB/s,GPU 实时量化激活相比 Host 预量化仅增加约 0.003ms。执行层面,将 FFN 子层排入单条 CUDA Stream 并复用约 161.6KiB 工作区,使测试子层耗时下降约 10%;长上下文注意力采用两阶段分块归约,32K 上下文下单层从 29.954ms 降至 4.040ms。
当前结论的边界:单算子验证不等于整网吞吐
文章明确区分已跑通的单算子微基准与尚未完成的整网指标。GGUF 解析、显存规划、12 种格式原位 GEMV、FFN 子层、循环块和全注意力层已有实机数值验证,但 64 层 27B 真实模型的端到端 tok/s、TTFT、显存峰值和逐层 Logits 差分仍待测试;Prefill 批量 GEMM 与同条件 A/B 对比也未完成。因此不能由单层耗时累加推导整网速度,读者应把文中数据视为阶段性工程证据。
Q&A
为什么专家缓存机制在稠密模型(如Qwen3.8-27B)上会失效?
专家缓存依赖MoE模型每Token仅激活少量参数(如Qwen3.6-35B-A3B仅激活约3B参数),可缓存热点专家。而稠密模型每Token需计算全部27B权重,无跨Token权重局部性,按Token搬运权重受PCIe带宽限制,导致解码速度极低。
在16GB显存下运行27B稠密模型,显存预算应该如何规划?
需核算峰值显存:GPU驻留权重 + 全注意力KV Cache + 循环层状态 + 持久工作区 + max(Prefill临时区, Decode临时区) + 传输暂存区 + 安全余量。以真实可用显存为准,不依赖标称容量;拆分核算Full Attention KV与Gated DeltaNet循环状态;若超出容量直接报错,不自动降级。
如何让CUDA直接计算GGUF混合量化块而不展开为FP16?
在CUDA/PTX中实现12种GGUF量化格式的原位GEMV核函数,激活值实时量化为Q8_F32S,利用dp4a指令;K-quant系列直接读取原始块并计算修正项,I-quant系列维护微型码本在寄存器内查表拼装,避免生成整矩阵反量化表。
单流子层融合和分块注意力如何降低推理延迟?
将FFN子层操作排入单条CUDA Stream,复用工作区,减少同步开销,实测单子层耗时降低约10%。长上下文全注意力采用两阶段分块归约:短上下文单阶段在线Softmax,长上下文分块计算局部结果再跨块合并,32K上下文下单层注意力加速比达7.41倍。
在16GB显存上加载14.24GB权重时,如何避免主机内存膨胀和显存浪费?
采用零拷贝放置:只读mmap打开GGUF文件,张量批量写入CUDA设备Arena,上传后对映射区间执行页面释放(Trim),使进程RSS降至约108MiB;排除第65层MTP权重;显存不足时支持单矩阵输出行切分,前缀行驻留GPU,后缀行引用mmap视图。
目前这个稠密推理引擎的实测性能如何?还有哪些未完成的工作?
已实测单矩阵GEMV、FFN子层、循环块和全注意力层的延迟与数值精度,例如IQ4_XS矩阵有效带宽达329.90GiB/s,FFN子层耗时约0.596ms。但整网64层端到端吞吐(tok/s)和首字延迟(TTFT)尚未实测,Prefill批量GEMM优化及与llama.cpp的A/B对比仍在推进中。