1. 基准测试只能告诉你“现在多快”不能告诉你“为什么快”如果你跑过一个参数规模稍大的模型推理服务应该碰到过这样的场景同一个模型在显卡 A 上速度不错换到显卡 B 上却慢了一截同一个服务前几个请求响应很快上下文变长之后却肉眼可见地变慢官方文档里写的吞吐数字在自己的业务数据上一测差了不止一倍。这些问题如果只是靠反复测试去定位效率会非常低。因为你每次调整参数、切换框架、换部署环境都得重新跑一遍压力测试。测试结果不稳定还会遇到网络波动、并行任务互相抢占、数据前后处理耗时等干扰因素。就算你把面板数据截图截下来也只能证明“这一秒钟它跑成了这样”说明不了为什么更预测不了下一次调整之后会变成什么样。这就是我强调“从第一性原理建模”的原因性能建模不是给你一个精确的数字而是给你一条从底层机制推导到上层指标的计算链条。链条大致长这样模型要执行哪些计算每个 token 经过模型时理论上消耗多少浮点运算量这些计算在硬件上分发时瓶颈是算力、显存带宽还是内存容量自回归解码的串行依赖是怎么把理论算力拖到实际水位之下的模型规模、上下文长度、批处理大小分别会推高哪一项成本。只要链条理解对了很多性能现象不需要实测就能解释个七八成。比如“长上下文后变慢”这几乎不可能是算力不够更像是注意力计算量随长度平方增长加上 KV 缓存挤占了显存带宽。这两个原因在模型里是分开的但表现都是“变慢”。如果你不建模只盯着压力测试数字去看很容易把两个问题当成一个处理。所以我的第一个建议是不要丢掉基准测试但也不要把它当成第一工具。基准测试是用来“验证模型预测”的不是用来“发现规律”的。真正能帮你做选型和调优的是一个能解释因果的计算模型。当然第一性原理建模不是万能药。要把它用起来你得先理解几个核心概念FLOPs、HBM 带宽、自回归延迟、KV 缓存、缩放规律。下面逐个展开讲清楚它们分别卡住的是哪一段性能。2. 先把计算成本算清楚一个 token 经过模型时到底消耗了多少 FLOPs2.1 Transformer 的两大部分注意力层和前馈层要给 LLM 性能建模第一步是准确估算计算量。虽然现代 LLM 在结构上各有各的变体比如不同的归一化方式、不同的注意力变体、不同的激活函数但绝大多数主流模型仍然基于 Transformer 的基本架构。一个 Transformer 层基本由两部分构成自注意力模块将输入向量投影成 Q、K、V然后做注意力计算再投影输出前馈网络模块先升维再激活最后降维。从矩阵乘法的角度看这两部分的计算量大头都比较好统计。对于一个隐藏维度为 d 的模型单个 token 经过单个 Transformer 层时的乘法次数是自注意力的 Q/K/V 投影和输出投影4 个 d x d 的矩阵乘法前馈网络通常从 d 升维到 4d再降维回 d相当于两个 d x 4d 和 4d x d 的矩阵乘法加上嵌入层映射和最后的输出映射也可以摊到每个 token 上。把这些系数合并起来会出现一个被反复引用的近似结果一个基于 Transformer 的稠密语言模型每个 token 的前向传播大约需要 2N 次浮点运算FLOPs后向传播大约是它的 2 倍也就是 4N。训练一个 token 的总计算量约为 6N。这里的 N 是模型参数数量。2.2 为什么“每 token 约 2N FLOPs”有参考价值这个公式很粗但在工程估算阶段非常有效。它把模型结构、层数、头数等细节全部折叠成一个参数总数 N让不同模型之间可以直接对比。举例来说一个 7B 参数量模型每处理一个 token 的前向推理理论计算量约是 14G FLOPs。如果显卡能持续提供 30TFLOPs 的有效算力那理想情况下每秒钟约能处理 2000 个 token。真实场景当然达不到这个值因为还有访存、调度、内核启动、PCIe 传输等各种开销。但是用这个数量级去反推你至少能判断一个推理框架的性能到底还有多少提升空间。很多人在部署模型时看到一个“每秒生成 20 个 token”的数字觉得已经不错了。但用上面的方法一算就会发现真实利用率可能只有百分之几。这不是“模型太大跑不动”而是瓶颈根本没有被定位到正确的资源上。需要说明的是这个近似公式对 MoE 模型要分开处理。MoE 的参数量里只有部分参数在每次前向推理中被激活所以严格来说N 应该替换成“单次推理实际激活的参数数”而不是总参数量。否则算出来的理论吞吐会严重偏低。2.3 注意力计算一个容易忽略的平方项除了粗粒度的大头 FLOPs注意力模块内部还有一项二次复杂度序列长度 T 的平方。标准的自注意力机制需要为每个 token 计算与其他所有 token 之间的相似度。对于一个长度为 T 的序列注意力分数矩阵的大小是 T x T计算量随 T 的平方增长。在短序列场景下这个平方项不算什么。但序列长度从 2K 涨到 8K、再从 8K 涨到 32K 时注意力部分的计算量就变成不可忽略了。这也是为什么近两年的推理框架和模型架构都在想办法缓解长上下文开销比如各种线性注意力方案、稀疏注意力、KV 缓存复用、分页 KV 等。如果想把模型性能建模得更准建议把注意力计算单独列出来对于标准多头注意力注意力分数与权重矩阵的计算量约是4 * L * d * T的线性项以及2 * L * d * T^2的平方项其中 L 是层数d 是隐藏维度在实际工程中真正更容易成为瓶颈的其实是 KV 缓存带来的显存占用这个放在后面说。写代码的时候你可以用一个简单的函数快速估算不同配置下的理论 FLOPsdef estimate_training_flops(num_params: int, num_tokens: int) - float: 粗略估算稠密 Transformer 训练一个 token 集所需的 FLOPs return 6.0 * num_params * num_tokens def estimate_inference_flops_one_token(num_params: int) - float: 估算一次前向解码耗时, 单位是 FLOPs/token return 2.0 * num_params这段代码不是为了做精确仿真而是为了让“性能预测”变成可以用数字快速比较的东西。后面所有经验法则几乎都能挂在这两个公式之上。3. 从 FLOPs 到真实耗时内存带宽常常才是真正的瓶颈3.1 为什么算力那么高模型却跑不快理论 FLOPs 只是第一步。真正部署时要回答的问题是这个计算量需要多少时间如果模型权重完全驻留在显存里并且每一步计算都只跟算力相关那问题很简单耗时 FLOPs / 算力。但现实中一个被广泛忽略的因素是模型每前向一次都要把所有参与计算的权重从显存搬到计算单元里。搬移速度受显存带宽限制而带宽通常远低于算力的增长速率。所以推理性能的下限往往由访存决定单 token 理论最小耗时 ≈ 参数量 × 每个参数字节数 / 显存带宽举例来说一个 7B 模型如果使用 FP16 权重占用约 14GB。假设显存带宽为 800GB/s那么每生成一个 token 最少需要14GB / 800GB/s ≈ 17.5 毫秒换算下来上限大约为 57 token/s。如果实际推理速度离这个上限还很远说明主要问题不在权重访存而可能在注意力计算、内核启动、框架调度或显存容量不足导致的缓存抖动上。现实情况是很多推理框架已经能逼近这个带宽上限。如果模型是 70B 级别FP16 权重约 140GB单 GPU 的带宽再高也难以承载必须做多卡张量并行。此时每块卡处理一部分权重总带宽增加但还要额外考虑卡间通信。通信比例会随着并行度提高而上升到了一定规模后“多卡一起算”带来的收益会被通信开销抵消继续加卡并不能线性提升速度。3.2 自回归解码一次只能生成一个 token 的串行约束另一个关键约束是自回归解码。LLM 推理是一个“逐步生成”的过程每一步生成一个 token前一步的结果是后一步的输入。这个串行依赖关系使得你没办法像训练那样把一批短序列整体并行算完。它的影响体现在两个方面延迟变高第一个 token 需要处理完整的输入上下文之后每新增一个 token都需要重新计算整个上下文上的注意力分布。理论上每一步的 QKV 投影可以复用前一步的中间结果但实际工程要做缓存和优化复杂度不低吞吐受限如果单次只处理一个请求GPU 的算力利用率会非常低。要提高吞吐通常要引入批处理。批处理能让 GPU 同时在多个请求上执行矩阵乘法从而摊薄固定开销提高算力利用率和吞吐量。批处理也不是越大越好。batch size 增大后KV 缓存的大小会线性增长显存占用快速上升。一旦超过显存容量性能会断崖式下跌。所以在做容量规划时有两个数一定要先算单条序列在给定上下文长度下的 KV 缓存大小批处理 N 条序列时 KV 缓存总占用。KV 缓存的估算公式大概是2K和V × 层数 × 注意力头数 × 头维度 × 序列长度 × 每个元素字节数。折叠成参数语言它跟模型层数、头数、隐藏维度、上下文长度都相关不能只用参数量 N 估算。3.3 算力、带宽、容量三者决定的性能区间把 FLOPs、带宽、KV 缓存放在一起一个实际推理场景的性能边界就比较清楚了资源维度关键问题典型瓶颈表现计算量FLOPs单 token 计算量大不大算力利用率长期很低带宽权重和 KV 缓存加载快不快单 token 耗时逼近带宽上限显存容量KV 缓存和并发请求会不会爆显存批处理一加大就 OOM 或急剧变慢调优时先判断当前最接近哪个边界再决定优化方向。如果接近带宽边界可以考虑量化、权重共享、减少 KV 缓存占用例如用 INT8/INT4 量化或滑动窗口注意力如果还有大量算力余量则可以做更大的批处理或提升并发如果显存容量不足则需要调整上下文长度、批处理大小或用更高效的位置编码和缓存淘汰策略。这也是为什么“第一性原理建模”能帮助定位瓶颈它先把资源维度拆开再根据实际测试数据做判断。你不需要在 GPU 面板上盯着一堆看起来很复杂的指标只需要回答三个问题它的理论上限多少当前距离哪个上限最远现在是在浪费算力还是在逼近带宽4. 缩放规律模型能力与性能预测之间的桥4.1 损失函数与参数、数据之间的幂律关系前面讲的都是“跑得快不快”但性能建模还有一个更重要的维度这个模型到底能学到什么程度如果在部署前无法预估更大模型带来的收益你就很难回答“该选 7B 还是 70B”的问题。缩放规律来自 Google 等在 2020 年前后做的系统研究。核心观点是在计算预算固定的前提下模型参数量 N、训练数据量 D、最终的交叉熵损失 L 之间存在近似幂律关系参数规模越大损失越低训练数据越多损失越低两者之间存在一个平衡点而不是简单地“一味加大模型或一味加数据”。这个规律在学术界已经有较多验证常被引用的结论是模型参数量和训练数据应该按大致相同的比例增长。对于一个受限的计算预算更合理的做法通常是同时扩大参数和数据而不是只堆其中一个。4.2 从缩放规律得到三条实用判断把这个规律落实成工程实践能得到三条值得记住的判断小模型在小数据上训练效果不会因为模型足够小而忽略。小模型需要足够的数据才能发挥出自身容量。数据不够的时候损失下降会非常慢大模型如果数据不够多出的参数会形成冗余不会等比例转化为能力。所以直接买一个已经用大量数据训好的大模型 API往往比自己在小数据上微调一个大模型更靠谱推理成本和模型能力的权衡是显式的。参数扩大一倍前向推理的 FLOPs 大致翻倍吞吐也会明显下降但如果缩放规律显示能力提升不显著那不如选已经充分训练的小模型。这也是很多项目在实践中采用“小模型优先”的原因。不是小模型比大模型强而是小模型在有限成本和有限算力约束下更容易达到“够用”的水平。判断“够不够用”当然需要基准测试但判断“提升多少才算值得”就需要缩放规律给出的趋势作为参考。4.3 数据质量缩放规律没说清楚的部分这里要特别指出缩放规律的边界。它假设训练数据是从同一分布中充分采样但真实场景几乎不会满足这个假设。数据质量、重复度、领域覆盖、去重策略、预处理管线、课程学习顺序等都会让实际的 loss 曲线偏离理论规律。换句话说用缩放规律做“能力天花板”估算可以用它预测“某个数据清洗方案能带来多少提升”就超出了它的适用范围。更稳妥的说法是缩放规律适合做规模化判断不适合做具体训练计划的精度预测。先用它选一个参数规模的档位再用小规模实验来验证数据和超参策略最终上线前用目标评估集做一次完整测评。这样组合起来的做法本质上就是“第一性原理趋势 小样本验证”的闭环。它对性能建模的价值不只是预测更是帮助团队在决策之前就砍掉明显不合理的选项避免把大量预算花在大概率无效的路线上。5. 拿一张纸搭起性能模型的骨架从单次请求到批处理5.1 三步建模法先定输入再定瓶颈最后实测校准当你要给自己手头的应用做一个性能模型时我建议先用三步法搭一个粗糙版本而不是一上来就问“用什么工具做压力测试”。第一步定义任务形态。是单轮问答、多轮对话还是长文档摘要输入 token 和输出 token 的典型数量各是多少这些数字直接决定计算量和 KV 缓存占用。第二步写出瓶颈等式。根据当前目标平台先分别估算在给定参数量和量化位宽下单 token 的前向耗时是多少在给定序列长度下KV 缓存需要多少显存在给定 batch size 下注意力计算量会不会超过权重访存的时间。把这三个数算出来就能知道瓶颈大概率落在哪里。第三步在机器上做一次最小验证。不用压测工具跑复杂场景只跑一个几十条请求的样例集记录真实的输入 token 数、输出 token 数、时延。把实测值跟模型预测值放在一起看差值太大的部分就是值得深入研究的地方。一个常见的建模表格可以这样设计配置项模型参数量化位宽输入长度输出长度batch size预测时延实测时延差异原因本地小模型1.5BFP165122001待估待测待定位本地大模型7BINT85122001待估待测待定位服务端并发7BFP16102451216待估待测待定位这张表的价值不在于第一行算得准而在于它逼着你在测试之前明确边界条件。很多人做性能测试时只记录“速度是多少”遗漏了输入长度、输出长度、batch size、上下文窗口等关键信息结果测试数据完全不可复用。5.2 单 token 验证法最稳定、最该先做的小样本测试性能建模有一个容易出错的地方一上来就测“每秒处理多少个请求”这种大吞吐指标。这个指标受并发数、排队、前后处理影响很大波动也大不适合作为第一轮的判断依据。我更建议先测单 token 延迟。做法很简单固定一个请求输入固定的 prompt连续生成固定数量的 token记录每次生成一个 token 的平均耗时。这个数字主要反映模型前向推理的底层速度受调度影响小多跑几次就能得到一个比较稳定的参考值。拿到单 token 延迟后再乘以输出长度得到纯模型生成耗时然后加上输入 prompt 的 prefill 耗时得到一个近似单请求总时延。最后再加入并发和批处理的影响估算整个服务的吞吐能力。这个顺序是从稳定、可控的小指标逐步扩大到复杂指标。如果一开始就测复杂指标定位问题会难得多。5.3 小样本验证后需要检查哪些环节以下是我在实际项目中常用的一组检查顺序适合作为排查链路使用看现象是速度慢、延迟高、吞吐低还是显存不稳定看输入输入 token 数是多少上下文长度有没有隐性增长prompt 里是否包含超长文档看配置批处理大小、并发数、量化位宽、精度设置看资源显存占用是否接近上限GPU 利用率是否长期很低CPU 是否有瓶颈看日志是否有重算、重复加载、缓存未命中、频繁重新分配显存看框架版本同一模型在不同推理框架或不同 CUDA 版本下的性能差异可能很大。其中容易出问题的是第一和第二步。很多“突然变慢”的现象其实是输入 prompt 变长导致的注意力计算量增加而不是模型或框架出了问题。遇到这种情况先查输入长度和 KV 缓存再考虑优化结构。5.4 一个可复用的性能估算函数到这里你可以把前面所有概念浓缩成一个非常简单的估算流程。以推理单 token 为例def estimate_one_token_latency_ms( params_b: float, # 参数量单位十亿 precision_bytes: float, # 每个权重占用的字节数 bandwidth_gbs: float # 显存带宽单位GB/s ) - float: weight_size params_b * 1e9 * precision_bytes / 1024**3 latency_ms weight_size / bandwidth_gbs * 1000 return latency_ms # 示例7B模型FP16A100约1.5TB/s print(estimate_one_token_latency_ms(7, 2, 1500)) # 约9.3ms这个函数没有处理注意力计算、层数、序列长度所以不要拿它做精确预测。它真正的价值在于给“模型能不能跑得动”做一个快速判断。把精度从 2 字节降到 0.5 字节单 token 耗时能大幅下降把参数量从 7B 提到 70B耗时也会倍增。模型部署前的选型讨论用这个数量级先对齐预期会顺畅很多。6. 建模的边界与长期维护不要把近似公式当成万能法则6.1 哪些情况会让模型预测失效第一性原理建模在不同场景下的准确度差别很大。在单 GPU、单请求、模型权重能够完全放入显存、没有复杂并行依赖的场景下预测能相当精准。但在下面这些情况下模型会失效或者至少偏差很大多卡并行时通信开销占比可能比计算出力还高使用投机解码、KV 缓存复用、前缀缓存、动态批处理等优化手段后实际 token 生成流程已经不再是简单的前向计算MoE 模型的实际激活参数远小于总参数直接用总参数量会严重高估延迟服务端有排队、限流、多租户共享资源时单个请求的时延和吞吐都不能从单次前向推导出来不同框架对算子融合、内存分配、内核编译的优化程度差异大同一模型在不同框架下耗时可能差好几倍。所以能建模是好事但建模前一定要确认边界条件。更安全的做法是把它当成“估算上限和数量级”的工具不要当成精确仿真器。6.2 性能模型需要持续校准而不是一次性建完很多团队第一次建性能模型时热情很高模型跑几轮数据表也整理好了但一个月后就过期了。原因是模型换了、推理框架升级了、数据分布变了、硬件环境调整了所有实测数据都失去参考意义。性能建模不是一次性任务它是一个需要持续维护的“活文档”。我的建议是把关键配置记录在版本管理工具里包括模型版本、框架版本、CUDA 版本、量化位宽、batch size、输入长度分布每次模型或环境变化后至少重新跑一次最小样例更新性能基线表不只记录平均值还要记录 P95 和 P99因为 LLM 推理服务的 tail 延迟经常比平均值重要得多把建模用的脚本和配置也纳入版本管理避免下次重建时找不到计算口径。从工程经验看真正能长期用下去的性能模型靠的不是一次做多精细而是有了一套可重复、可更新、可对照数据变化的流程。单次测量结果会过期但一套标准化流程不会。6.3 最终判断把模型当作你的“决策前试验场”回到开头的问题为什么值得从第一性原理建模因为 LLM 在应用层的性能问题绝大多数都不是某个单独环节的简单故障而是多个变量相互作用的结果。只靠基准测试和面板截图你很难快速回答“如果我把 7B 换成 13B并发从 4 调到 8输入从 512 扩展到 2048最终会给用户带来怎样的延迟变化”。这类问题要等实际部署之后测量才知道代价很高。而第一性原理建模给出的是一个可以在部署前做沙盘推演的框架。你可以在 Excel、脚本或者脑内先把这些变量按资源维度换算成数量级。它不会给出精确数字但能帮你排除明显不可能的选项定位最值得优化的方向并在小样本验证后逐步逼近真实值。用一句话来总结这篇文章的核心观点别把第一性原理建模当成一个精确预测工具而要把它当成一种压缩问题的方式。它把“LLM 性能为什么是这样”压缩成几条资源约束和几个可以计算的公式让你在做选型、调优、容量规划时不再依赖反复跑测试去碰运气。这不是最炫酷的技术但大概率是长期最省力的那一种。