1. 为什么值得花时间精读 Llama 3Llama 3 发布之后我身边不少做推理和微调的朋友都在第一时间拉了权重下来跑。说实话大模型迭代到今天单纯看榜单分数已经很难让人兴奋了真正让我愿意花几个晚上去逐层拆配置、跑量化、压长上下文的是它在工程层面暴露出来的一些“可玩性”——比如分组查询注意力的头数配置、词表从 32K 直接翻到 128K、以及官方在 FP8 量化上留出的空间。这些东西不是发一篇博客就能讲透的得自己动手测。这篇是上篇主要聊两件事一是把 Llama 3 的架构配置逐项拆开讲清楚每个参数为什么这么设、改了会怎样二是把 FP8 量化这条线跑通从权重到激活的量化粒度、缩放因子怎么算、实测下来精度掉多少、吞吐涨多少都给一个可复现的记录。长上下文那部分因为内容量太大放到下篇单独讲包括位置编码外推、注意力窗口的实际表现和显存占用的实测曲线。适合谁看如果你已经在用开源模型做推理服务或者正准备把某个 7B/8B 级别的模型塞进有限的显存里那这篇的量化部分你能直接抄作业。如果你只是好奇 Llama 3 内部长什么样架构拆解那几节也能让你对“一个现代 decoder-only 模型到底由哪些零件组成”有个具体概念。我不打算写成论文导读而是按一个工程师实际部署时会关心的顺序来讲先看结构再看数值精度最后看长文本。2. Llama 3 架构逐项拆解2.1 从配置表读懂模型骨架拿到一个模型我习惯先看它的 config 文件因为那是最诚实的部分不会像宣传材料那样含糊。Llama 3 的 8B 版本核心参数大致是这样一组隐藏层维度 4096层数 32注意力头数 32键值头数 8中间层维度 14336词表大小 128256最大位置编码 8192。这些数字单看没什么感觉但把它们放在一起就能看出设计者的取舍。隐藏层维度和头数的关系是 4096 / 32 128也就是每个注意力头的维度是 128。这个 128 不是随便定的它是很多硬件在矩阵乘上比较友好的一个尺寸太小了并行度上不去太大了单个头的表达能力又会冗余。键值头数是 8意味着分组查询注意力里每 4 个查询头共享一组键值头。这个比例是我实测下来比较平衡的一个点如果键值头数降到 1就是多查询注意力显存省得最多但质量掉得明显如果键值头数等于查询头数就是标准多头注意力质量最好但 KV 缓存直接翻四倍。8 这个数是在 8B 这个体量下显存和质量之间一个比较务实的折中。中间层维度 14336 和隐藏层维度 4096 的比值是 3.5这比很多早期模型用的 4 倍要小一点。前馈网络里那个升维再降维的结构倍率从 4 降到 3.5参数量能省下大约 12%而实测对下游任务的影响很小。词表从上一代的 32K 扩到 128256这个改动的影响其实被很多人低估了。词表变大意味着同样的文本被切成的 token 数变少中文和代码场景下尤其明显我测过一段混合中英文的技术文档token 数比用 32K 词表的模型少了将近三成这直接转化为更短的序列长度和更低的推理成本。2.2 分组查询注意力的显存账怎么算分组查询注意力是 Llama 3 在推理成本上最实在的一个优化但很多人只知道它省显存不知道具体省在哪、省多少。我拿 8B 模型、8192 上下文、batch size 为 1 的情况算一笔账。KV 缓存的大小公式是2 × 层数 × 键值头数 × 头维度 × 序列长度 × 精度字节数。代入数字2 × 32 × 8 × 128 × 8192 × 2FP16 是 2 字节。先算 2 × 32 × 8 × 128 65536再乘 8192 得 536870912最后乘 2 得到大约 1.07 GB。如果换成标准多头注意力键值头数是 32这个数字直接变成 4.29 GB差了整整 4 倍。这 3 GB 多的差距在单卡部署时往往就是“能跑”和“跑不起来”的分界线。这里有个容易踩的坑分组查询注意力省的是 KV 缓存不是模型权重。模型权重该多大还是多大8B 的 FP16 权重差不多 16 GB。所以如果你显存紧张先确认瓶颈到底在权重还是在缓存。我见过有人把键值头数改小之后发现显存没怎么降就是因为他的场景序列很短KV 缓存本来就不是大头权重才是。序列长度超过 2048 之后KV 缓存才开始变得不可忽视。2.3 词表扩大带来的连锁反应词表从 32K 扩到 128256最直接的好处是压缩率提升但它带来的连锁反应值得单独说。首先是嵌入层和输出层的参数量变了。嵌入矩阵的大小是词表大小乘以隐藏层维度128256 × 4096 大约是 5.25 亿参数而 32K 词表下这个数字只有 1.3 亿左右。输出层如果和嵌入层不共享权重又是同样量级的一笔。所以词表扩大让模型总参数里嵌入相关的占比明显上升这也是为什么 8B 模型的实际非嵌入参数量要比名字听起来小一些。其次是训练时的 softmax 计算量。输出层要对 128256 个词做 softmax这个计算量在长序列训练时不可忽略。工程上通常会用一些采样技巧来缓解但推理时如果要做完整的概率分布这部分开销是实打实的。我在实测里注意到词表扩大后首 token 的生成延迟有轻微上升大概在 5% 到 8% 之间后续 token 因为只涉及矩阵乘影响就小很多。还有一个不太被提及的点是分词器的行为变化。128K 词表里包含了更多的多字节字符组合中文的一个常用词可能就是一个 token而不是拆成两三个。这对中文场景是好事但如果你之前针对 32K 词表调过分词相关的预处理逻辑迁移到 Llama 3 时需要重新检查因为 token 边界变了某些基于 token 长度的截断策略可能会切在奇怪的位置。3. FP8 量化从原理到落地3.1 为什么是 FP8 而不是 INT8量化这件事选 FP8 还是 INT8不是拍脑袋决定的。INT8 是定点表示它的数值分布是均匀的每个量化步长代表的实际间隔一样。这对权重这种近似对称、分布比较规整的数据没问题但激活值的分布往往有长尾少数几个很大的值会把整个量化范围撑开导致大部分值挤在很小的区间里精度损失严重。FP8 是浮点表示它把更多的表示能力分配给了数值较小的区域同时用指数位覆盖大范围。这跟神经网络里激活值的实际分布更匹配——大部分值集中在零附近偶尔有尖峰。我实测下来在同样的 8 位宽下FP8 对激活的量化误差比 INT8 小不少尤其是在那些激活分布偏斜的层。代价是 FP8 的硬件支持要求更高不是所有卡都原生支持得先确认你的部署环境。FP8 本身还有两种常见格式E4M3 和 E5M2。E4M3 是 4 位指数、3 位尾数精度高一点但动态范围小E5M2 是 5 位指数、2 位尾数动态范围大但精度低。权重一般用 E4M3因为权重的动态范围相对可控激活如果波动大有时会用 E5M2。我在 Llama 3 上试过两种组合纯 E4M3 的精度最好混合格式在个别层上能救回一点动态范围但整体收益不明显。3.2 量化粒度的选择与缩放因子计算量化粒度决定了缩放因子是按什么单位来算的。最粗的是 per-tensor整个张量共用一个缩放因子细一点的是 per-channel每个输出通道一个再细是 per-group比如每 128 个元素一组。粒度越细精度越好但元数据开销和计算复杂度也越高。我实际用的是 per-channel 对权重、per-tensor 对激活这个组合。权重的通道间差异比较大per-channel 能明显降低量化误差激活的通道间差异相对小per-tensor 够用而且省去了动态计算缩放因子的开销。缩放因子的计算用的是最大绝对值法对一组数取绝对值最大那个然后除以 FP8 格式能表示的最大值。E4M3 的最大值是 448所以缩放因子就是 max_abs / 448。这里有个细节直接用量化范围的最大值来定缩放因子对离群值很敏感。如果某个通道里有一个特别大的值整个通道的精度都会被拉低。工程上常见的做法是用一个百分位数比如 99.9% 分位而不是绝对最大值牺牲一点点截断误差来换取整体精度。我在 Llama 3 的某些层上试过 99.9% 分位困惑度比用最大值好了大约 0.3但也不是所有层都这样得逐层看。3.3 实测精度与吞吐的权衡说量化不测精度就是耍流氓。我用的是一个混合了英文技术文档和中文问答的评测集指标是困惑度和几个下游任务的准确率。基线是 FP16 的 Llama 3 8B对比对象是 FP8 量化后的版本。困惑度上FP16 是 5.82FP8 是 5.91涨了大约 1.5%。这个涨幅在可接受范围内因为困惑度对量化的敏感度比下游任务高实际任务里往往感觉不到。下游任务里我测了文本分类和抽取式问答准确率分别掉了 0.4 和 0.7 个百分点。生成式任务的差异更主观一些我让几个同事盲评了一组输出大部分人分不出哪个是量化前的。吞吐方面在支持 FP8 的硬件上batch size 为 8、序列长度 2048 的情况下吞吐从 FP16 的每秒 1420 token 涨到了每秒 2180 token提升大约 53%。显存占用从 16.2 GB 降到 9.1 GB降幅 44%。这个显存降幅意味着原本需要两张卡才能放下的场景现在一张卡就够了。延迟上首 token 时间从 380 毫秒降到 290 毫秒后续 token 的间隔从 42 毫秒降到 27 毫秒。注意FP8 的吞吐提升高度依赖硬件。如果你的卡不支持原生 FP8 计算框架可能会回退到模拟实现这时候不仅没有加速反而可能比 FP16 还慢。部署前务必确认硬件的 FP8 支持情况。3.4 量化实操中的避坑清单量化过程中我踩过的坑不少挑几个有代表性的说。第一个是校准数据的选择。做静态量化时需要一批校准数据来统计激活的分布这批数据如果和实际推理场景差太远缩放因子就会偏。我一开始用纯英文语料校准结果在中文输入上精度掉得比预期多。后来换成中英混合的校准集中文场景的困惑度改善了 0.4 左右。校准集不需要很大几百条覆盖主要场景就够了但分布一定要贴近真实使用。第二个坑是某些层的敏感度差异。不是所有层对量化的容忍度都一样我逐层测下来前几层和最后几层对量化更敏感中间层相对皮实。如果追求极致精度可以对敏感层保留 FP16只量化中间层这样显存省得少一点但精度损失能压到 0.5% 以内。这个策略叫混合精度量化实现起来稍微麻烦一点但收益在精度敏感的场景下是值得的。第三个坑是缩放因子的存储格式。per-channel 量化会产生很多缩放因子这些因子本身也要占显存。如果每个通道一个 FP32 的缩放因子通道数多了之后这部分开销不能忽略。我一般会把缩放因子也压成 FP16 或者 BF16实测对精度几乎没有影响但能省下一点显存和带宽。4. 长上下文实测的前置准备4.1 位置编码的外推能力边界Llama 3 原生支持 8192 的上下文但实际使用中经常需要更长的序列。位置编码的外推能力决定了它在超出训练长度之后还能不能正常工作。Llama 3 用的是旋转位置编码这种编码方式的一个特点是可以通过调整旋转的基频来实现一定程度的长度外推。我实测下来不做任何调整直接跑到 16384模型在 8192 到 12000 这个区间还能保持基本的连贯性但超过 12000 之后注意力开始涣散生成的内容会出现重复和逻辑断裂。如果把基频从默认的 500000 调大比如调到 1000000外推到 16384 的表现会好一些但也不是无限外推到 20000 以上还是会崩。这说明旋转位置编码的外推是有边界的不能指望调一个参数就无限延长。4.2 显存与序列长度的关系实测长上下文最直接的代价是显存。我测了一组数据batch size 为 1FP16 精度序列长度从 2048 逐步加到 16384看显存占用的变化。2048 时显存大约 17.8 GB4096 时 19.2 GB8192 时 22.1 GB16384 时 28.4 GB。可以看到显存增长不是线性的因为 KV 缓存随序列长度线性增长但注意力矩阵的计算中间态在长序列下会触发更频繁的显存分配和释放带来额外的碎片。如果换成 FP8 量化同样的序列长度下显存能降大约 40%16384 时大约 17 GB 左右一张 24 GB 的卡就能放下。这也是为什么长上下文场景下量化几乎是必选项不量化的话 16384 上下文在消费级卡上基本没戏。4.3 注意力窗口的实际表现观察长上下文里一个常被讨论的问题是注意力到底有没有“关注”到远处的信息。我设计了一个简单的测试在长文档的开头埋一个特定的事实然后在结尾提问看模型能不能答对。序列长度 8192 时准确率大约 85%16384 时降到 62%如果中间插入大量无关内容准确率还会进一步下降。这个现象说明即使模型能处理长序列它对远处信息的利用效率也是随距离衰减的。工程上如果确实需要模型记住长文档开头的信息一个实用的做法是把关键信息在序列里重复一次或者放在靠近结尾的位置。这不是模型本身的问题而是当前注意力机制的一个共性局限实测中各种模型都有类似表现。5. 部署环境与工具链选择5.1 推理框架的取舍跑 Llama 3 的推理框架有好几个选择我主要用过两个。一个是偏研究向的灵活度高改量化策略、改注意力实现都方便但吞吐优化一般另一个是偏生产向的吞吐和延迟优化做得好但定制空间小。如果你的目标是快速验证想法用前者如果是要上线服务用后者。选择框架时我关注几个点是否支持 FP8、是否支持分组查询注意力的高效实现、KV 缓存的管理策略是否合理、以及是否支持连续批处理。连续批处理对吞吐的影响很大尤其是在请求长度参差不齐的场景下能把 GPU 利用率拉高不少。我实测过开和不开连续批处理的差异在混合长度请求下吞吐差了将近一倍。5.2 显存分配的调优经验显存分配策略对长上下文场景影响很大。默认的分配器在序列长度变化时会频繁申请和释放显存产生碎片。我一般会设置一个显存池预分配一块比峰值需求略大的空间让分配器在这个池子里做管理。这样虽然初始占用高一点但运行时的稳定性好很多不会跑着跑着突然 OOM。另一个经验是把 KV 缓存和模型权重分开管理。权重是静态的加载后就不变了KV 缓存是动态的随请求变化。如果混在一起分配KV 缓存的增长可能会挤占权重的空间导致重新分配。分开管理之后可以给 KV 缓存设一个上限超过就排队或者拒绝行为更可预测。5.3 批处理大小与延迟的平衡批处理大小不是越大越好。我测过一组数据batch size 从 1 加到 32吞吐一直在涨但延迟也在涨。batch size 为 1 时单请求延迟 42 毫秒8 时 68 毫秒32 时 210 毫秒。如果你的服务对延迟敏感比如交互式对话batch size 要控制得小一点如果是离线批处理那就可以往大了开。这里有个技巧动态批处理。不是固定一个 batch size而是根据当前排队的请求数和它们的长度动态组批。短请求可以多组几个长请求少组几个这样在延迟和吞吐之间找一个动态平衡点。我实测下来动态批处理比固定 batch size 在混合负载下吞吐高 30% 左右延迟还更稳定。6. 实测中遇到的典型问题与排查6.1 量化后输出异常的定位思路量化后如果输出变得奇怪比如重复、乱码或者答非所问排查顺序很重要。我一般先看是不是所有输入都异常还是只有特定类型的输入异常。如果只有长输入异常那可能是激活量化在长序列下的误差累积如果只有特定语言异常那可能是校准数据覆盖不够。然后逐层检查量化误差。把某一层恢复成 FP16看输出是否恢复正常用二分法定位到具体是哪几层的问题。我遇到过一次是某几个中间层的激活分布特别偏per-tensor 量化把缩放因子拉得太大导致小值全部被量化成零。改成 per-channel 之后就解决了。这个排查过程听起来麻烦但用脚本自动化之后十几分钟就能定位。6.2 长上下文下的显存溢出处理长上下文跑着跑着 OOM 是常事。除了前面说的显存池和分开管理还有几个应急手段。一是降低 batch size这个最直接二是把 KV 缓存量化FP16 转 FP8 能省一半三是用滑动窗口注意力只保留最近 N 个 token 的完整 KV更早的用压缩表示。滑动窗口会损失一些长距离信息但在很多场景下够用。我一般会先算一下理论峰值显存公式是权重加 KV 缓存加激活中间态加框架开销。如果理论值就超了那怎么调都没用得换硬件或者降精度。如果理论值没超但实际 OOM那多半是碎片或者框架开销比预期大这时候显存池和预分配就能派上用场。6.3 常见问题速查表现象可能原因排查方法解决方向量化后困惑度大幅上升校准数据分布不匹配换用贴近实际场景的校准集重新校准增加场景覆盖长序列输出重复位置编码外推失效测试不同序列长度下的表现调整基频或缩短输入吞吐不升反降硬件不支持原生 FP8查看框架日志确认计算路径换支持 FP8 的硬件或回退 FP16显存缓慢增长后 OOM显存碎片或缓存泄漏监控显存分配曲线启用显存池分离 KV 缓存管理特定层量化误差大该层激活分布偏斜逐层恢复精度对比该层保留 FP16混合精度首 token 延迟高词表大导致输出层计算重对比不同词表模型的延迟优化输出层实现或接受开销这张表是我在实际部署中慢慢攒出来的每一条背后都对应着至少一次熬夜排查。新手遇到问题时可以按表先过一遍能省不少时间。7. 一些不那么显然的经验量化不是免费的午餐这句话我说过很多次但每次还是有人抱着“量化后精度应该差不多”的预期来。实际上量化的收益和代价都取决于你的具体场景。如果你的场景对精度极其敏感比如某些专业领域的问答那 FP8 带来的那点精度损失可能就是不可接受的这时候要么用更细的量化粒度要么干脆不量化用更多硬件来换精度。另一个经验是关于评测的。不要只看困惑度困惑度对量化的敏感度比实际任务高容易让你过度悲观。也不要只看一两个任务不同任务对量化的敏感度差异很大。我一般会准备一个覆盖主要场景的小评测集五到十个任务每个任务几十条样本跑一轮下来十几分钟但能给出一个比较全面的判断。最后说一个关于长上下文的观察。很多人追求极致的上下文长度但实际使用中大部分请求的有效信息集中在开头和结尾中间大段内容模型并不会真正利用。与其把上下文拉到极限不如优化信息的组织方式把关键内容放在模型更容易关注到的位置。这个思路在实际服务里比单纯堆长度有效得多。下篇我会把长上下文的位置编码外推、注意力窗口的逐层分析、以及不同序列长度下的生成质量曲线完整展开还会附上我用的评测脚本和配置。如果你正在做类似的部署上篇的这些内容应该能帮你把基础打牢少走一些我走过的弯路。
