企业官网建设流程全解析

1. 先别急着调优，先搞清楚瓶颈到底卡在哪

做了三年多模型推理优化，我最深的体会是：大多数人所谓的"优化"，其实是在瞎猜。模型慢了，第一反应就是换更小的模型、上量化、开TensorRT，一套组合拳打下来，速度可能只提升了一点点，反而精度掉得莫名其妙。

这里有个很反直觉的事实：同样是跑在GPU上，两个模型看起来都是"GPU利用率98%",实际性能却可能差出两三倍。因为利用率这个数字太宏观了，它根本不告诉你卡在算力上还是卡在数据搬运上。

所以每次接到"帮我看下这个模型为什么慢"的需求，我都先按一套固定流程做体检。这套流程花不了半小时，但能直接筛掉八成以上的无效优化。

第一步是确定基准。跑一次纯CPU推理，再跑一次纯GPU推理，做对比；然后再测不同batch size下的吞吐和延迟曲线。很多模型在batch=1时慢得离谱，把batch稍微加到4，吞吐直接翻了几番，这说明瓶颈在启动开销或算子初始化上，跟模型大小关系不大。

第二步是上个profiler，把时间分布扒出来。软件层面也好、硬件厂商提供的工具也好，至少要看三件事：算子耗时占比、数据搬运（host到device）耗时、以及GPU kernel的空闲时间。这里有一个大家很容易忽略的点：GPU内核的空闲时间高，不代表GPU垃圾，反而说明CPU端来不及喂数据，也就是常说的"CPU bound"。这种情况下你优化一百遍model结构都没用，问题在数据加载和预处理流水线上。

第三步才是看模型本身的结构。把计算图导出来，数一下里面的小算子有多少个、有没有反反复复的reshape和transpose、有没有频繁的同步点。这一步能直接暴露很多结构化的问题。

做完这三步，才能基本回答那句经典问题：我的模型到底卡在算力上、访存上、还是在CPU端？

这里我顺手整理了一张表，算是这些年做推理优化的"定位地图"：

2. 算力利用率：为什么那块显卡总在"半工半休"

说起算力瓶颈，得先把两个特别容易混淆的概念拆开：FLOPS和FLOPs。

第一个FLOPS是每秒浮点运算次数，用来衡量硬件算力上限的；第二个FLOPs是浮点运算总量，用来衡量一次推理实际要算多少下。这两个名词长得几乎一样，却一个是"每秒能算多少"，一个是"总共要算多少"，做性能分析的时候如果弄混了，整个排查方向都会跑偏。

假设一张卡理论算力是100 TFLOPs，模型推理需要200 GFLOPs，看起来只需要千分之二秒就能算完。但实际测出来却要2毫秒，差了整整十倍。多出来的时间去哪了？一部分落在访存等待上，一部分落在kernel启动和同步上，还有一部分被低效的算子实现白白浪费了。

要搞明白算力到底吃没吃满，得看一个更细的指标：SM（流式多处理器）的实际占用率以及计算指令在流水线里等待访存的比例。工具打出来的内核详情里通常能看到一行"stall原因分布"，底下一般会列着等待显存返回、等待依存指令、等待取指等等。如果waiting for memory占了一大半，说明这根本不是算力瓶颈，是访存瓶颈，后面优化方向直接就变了。

那什么情况下是真算力瓶颈？简单粗暴的判断方法：当你把精度从FP32降到FP16或者给batch翻倍后，耗时几乎等比例下降，而访存等待比例并不高——这时候就算力不够，得靠减少FLOPs或者换更大算力的卡来解决。

算力不够的场景里我最常遇到的其实是注意力机制。比如做长文本相关的模型推理，没优化过的注意力计算量跟序列长度呈平方关系，序列从1K涨到2K，计算量直接变四倍。如果内核实现还是朴素的逐元素乘加，SM里全是等待中间结果的依赖停顿，利用率能跌破20%。

这种算力瓶颈的解法思路很明确：要么从算法层面降FLOPs，要么让算子实现更贴近硬件的计算风格。像FlashAttention那类思路之所以有效，本质就是既降低了访存量，又让SM的流水线少空转。

在实战中，我还总结了一个"算力瓶颈时别急着换卡"的原则。很多团队第一反应是买更贵的卡，但如果现在利用率连30%都不到，换卡提升也就两三倍，而先把内核和访存优化好，十倍的都能见到。换卡永远是最后面那一步。

2.1 访存瓶颈：带宽才是那个真正的隐形天花板

其实很多号称"算力瓶颈"的推理性能问题，扒开profile一看，全是访存瓶颈。

这里得再引入一组容易混淆的概念：显存带宽和显存容量。容量是能装多少数据，带宽是单位时间能读取多少数据。模型推理的很多算子，属于"装得下但搬不动"，显存容量绰绰有余，但带宽被榨干到极限，SM被卡在等待数据返回的状态里，几乎整个GPU都在"排队等取货"。

以我优化过的一个大规模视觉模型为例，模型结构不复杂，单张图前向计算的理论FLOPs也不高，但实测下来延迟接近1秒。查profile，发现一个归一化算子占了26%的耗时。那个算子的运算量极小，就是读取足够大的中间特征、做减法、做除法、再写回去。DRAM带宽要吞吐的数据量好几个GB，不管GPU算得多快，搬运就那个速度，根本跑不动。

这类算子的核心特征就是"算术强度"低。算术强度就是每次从内存里取一个数据时能做的计算量，单位是FLOP/byte。低了就必然访存受限。

那怎么打破这个瓶颈？我在团队里最常强调三板斧：

第一板斧是算子融合。把两次甚至三次访存压缩成一次。比如对卷积加归一化再加激活，如果用朴素实现，每过一个算子就读写一遍完整的中间特征。三个算子就是六次全量读写。融合后整个计算就是一次读写。对于动辄几十兆的中间特征来说，这几倍的带宽消耗省下来，速度提升非常直接。

第二板斧是降低精度来减小搬运量。FP32改FP16，数据量立刻减半，带宽压力直接降一半。这比优化算子实现还要见效快。注意力这类访存密集计算在FP16下的带宽需求下降非常可观。

第三板斧是调整数据排布。

这里要展开讲一个很多人根本没想到的点：数据到底放在哪个物理位置，影响的不是一星半点。

GPU内部有L1、L2缓存和显存三级结构。如果我们让某个中间结果保持在小尺寸的L1里，后续多个算子都在L1里读取，带宽就不是问题。但问题是PyTorch的默认行为往往不会给管理这个——它经常把中间结果直接allocate在全局显存里，甚至在多个算子之间多次往返。

所以能做的就是靠算子融合和kernel改写去尽量让数据在片上缓存停留。像卷积、矩阵乘法这类算子大多有现成的融合实现，问题不大；真正麻烦的是那些带数据相关性的复杂算子，比如各种条件分支、动态索引，这类算子想融合就得自己写自定义内核。

2.2 一张表看懂如何初步判断计算瓶颈类型

做了这么多优化项目，我习惯先给瓶颈粗分类再动手。下面这个分类表是基于模型结构的，跟工具层面的定位表刚好形成补充：

看到这张表，很多人会问：那混合型的怎么办？比如注意力既算力高又访存高。

我的经验是：优先解决访存部分，因为访存优化通常同时能改善算力利用率。让数据待在缓存里，SM的等待时间降了，流水线自然跑得更满。所以大部分时候，融合算子带来的收益远大于单纯改一个GEMM的实现。

3. 算子与图结构层面：做加法之前先做减法

很多人一说优化，就习惯性地往模型里加东西——加知识蒸馏模块、加注意力增强、加多尺度结构。但推理优化往往反着来，要做减法，而且是处处做减法。

3.1 把计算图"捋直"

把一个训练好的模型导出成推理格式时，计算图往往包含大量冗余。这不是模型设计者的问题，是训练框架为了能求梯度，自动塞了很多中间节点。这些中间节点在推理时根本用不上，却被一股脑导入到推理引擎里。

我拿一个语义分割模型举例。训练导出的ONNX图里有七百多个节点，但实际上很多节点是堆叠的reshape、transpose、split等操作。它们在训练里有用，在推理里纯粹就是耗时间和占带宽。

处理办法是走一遍图优化，把能合并的合并、能消除的消除、能把常量折叠掉的折叠掉。这类优化在各家推理引擎里基本都是启动前默认做的，但很多人不知道的是：格式转换工具的版本不一样，优化结果也差别很大。

我踩过最典型的一个坑：用某个转换工具，转出来的图里反复出现了针对同一维度的置换操作，数值完全一样，转换工具却没有折叠掉。手动把图形化后加了消除节点，延迟直接降了接近三成。所以对这些优化规则，建议统一用导出的图检查一遍再上生产。

3.2 算子融合的正确姿势和禁忌

算子融合这事，看起来是把多个算子拼成一个内核，但实际操作起来比想象中容易出错。

正确姿势分三层：

第一层是标准融合。卷积加批归一化加激活，这类有固定模式，直接交给推理引擎自动处理就行。

第二层是跨层融合。比如把残差结构的合并点融合到前面的卷积里，或者对transformer做偏置融合、权重融合。这一层需要权和偏置的离线重参数化处理，得在模型加载阶段做。

第三层才是真正有价值的自定义融合。把模型里自研的、没有对应融合kernel的特殊算子抠出来，针对性地写CUDA内核。这一层的收益往往最大，代价也最高，不是必要时刻先不动它。

再说禁忌。有三个坑我直到现在还会见到团队在踩：

第一禁忌是在融合前先做精度验证。很多融合算法在数学上是等价的，但浮点数舍入顺序变了，结果就有细微抖动。对某些对数值敏感的网络，这种抖动会被层层放大，最后输出的置信度偏移会超出可接受范围。所以每次融合后一定要做端到端的精度对比，不能只看单层输出。

第二禁忌是为融合而融合。不是所有算子拼在一起都是好事。有些算子融合后会让寄存器和片上缓存的使用量暴增，反而伤害别的算子。

第三禁忌是忽视动态形状。模型的输入尺寸可能变化、某些分支条件可能随数据变化。如果一个融合内核写死在静态形状上，动态情况下动辄重编译，性能直接回退一个代际。

3.3 从训练到推理的模型结构调整

推理优化其实不只在部署阶段做，模型架构层面有些"先天特性"就已经决定了优化的空间。训练时就得有意识。

比如尽量去掉不必要的动态控制流。训练框架里用Python写个if，每层走不同分支，在训练时无所谓，但导出推理图后就是一个条件片段，推理引擎要准备两套方案，调度开销和显存开销都会上涨。一个大的动态分支，可能让整体性能掉20%~30%。能静态化的尽量静态化。

再比如尽量让张量的维度对齐。虽然大多数推理引擎内部会自动做padding和转置优化，但如果在模型设计时就把feature map的通道数设置成对齐友好的数字（比如32或64的倍数），那么很多底层kernel可以直接走向量化路径，减少数据重排的额外开销。

还有一点是关于归一化层的取舍。BatchNorm在训练中好使，但在推理时它带来的额外开销对访存来说很吃亏。现在很多部署方案会直接把BN吸收到前面的卷积层里，这只是深度优化里面很小的一步。好在各家框架都支持自动吸收，能省掉不少手工重参数化的功夫。

4. 模型瘦身三板斧：量化、剪枝与蒸馏

结构级优化完了，就该轮到模型本身了。量化、剪枝、蒸馏这三板斧，是推理提速最立竿见影的手段，但里面全是细节，一旦用量化方式把精度降没了，整个项目前功尽弃。

4.1 量化：不只是把INT8打开那么简单

量化的直觉很简单：把32位浮点权重压到8位整数甚至4位，模型体积小四倍，计算量也降四倍，访存量跟着降，延迟也就下来了。理论上是这样。但实操里"为什么同样开INT8，我的模型要么精度崩了要么速度没变化"，是后台问得最多的问题。

先说精度为什么崩。直接跑INT8推理，相当于给每个张量做一次有损压缩。如果模型本身数值分布很均匀，那问题不大；但很多模型的权重、中间激活数值都表现出明显的长尾分布，简单的线性映射会丢失大量尾部信息。

正确地做法是先做校准：选一批有代表性的输入，跑一遍浮点推理，统计每一层的数值范围（min/max或百分位数），然后基于统计结果确定量化的scale和zero point。这里有个关键经验：校准集的质量比数量重要得多。与其疯狂堆几千张风格相似的图，不如精心挑几十张覆盖所有边界情况的样本，出来的量化效果反而更好。

校准策略上，主流的方案有MinMax、百分位、以及相对熵校准（KL散度校准）。我的经验是，对大多数视觉模型，百分位方法性价比最高——鲁棒又能快速收敛。对语言模型，KL校准和百分位差距不大，反而MinMax可能导致尾部信息丢失。

再说速度为什么没变化。很多人在PyTorch里用一键转换的API，发现精度没掉太多就以为完事了。但这类API只是把权重转成了INT8并模拟了推理过程，底层很多算子执行的还是浮点运算。真正想要硬件加速，必须用能提供INT8内核的推理引擎，把算子和执行图都转换成整型指令。

下面是三种常见量化粒度的性能表现:

这里还得强调一下，量化后的精度验证不只是在测试集上跑个平均值就完了。要分场景看：如果模型输出直接喂给下游做决策，还必须验证边界案例和低置信度样本的输出偏差。反正我在部署前一定亲自看几组bad case的量化前后对比，确认关键特征还在。

4.2 剪枝：别剪掉模型真正的"骨架"

剪枝的原理是强干弱枝，把不重要的连接或者通道直接砍掉。但什么样的权重"不重要"？标准做法是看权重绝对值大小。越小越不重要，这个直觉很符合认知，但在实战中我吃过亏。

有一个模型，我用全局幅值剪枝的策略，一下子给通道砍了30%，模型速度提升明显，但精度掉得不能忍。一查原因，发现被剪掉的那些通道里，有一些虽然权重绝对值小，但它们的下游层却非常依赖这些通道的分布特征。剪完之后，下游层的输入分布完全变了，模型直接瘫痪。

后来换成了基于激活重要性的剪枝策略：跑一批校准样本，统计每个通道对后续层输出的贡献度，再去剪那些贡献度低的通道，这才稳住了精度。所以剪枝不该只盯权重绝对值，要结合激活值和损失函数的变化来评估。

剪枝后的第二个大坑是剪完必须重新微调。不多说，微调是必须的，而且微调时要注意学习率。剪完网络容量变小了，学习率还沿用原来的容易震荡。

4.3 蒸馏：用大模型教小模型，但别指望零损耗

蒸馏这条路适合那种想大幅压缩模型、又舍不得太多精度的场景。做法是用一个大模型（教师网络）的软输出，去监督一个小模型（学生网络）的学习，小模型不光学真实的标签，还学大模型给出的平滑概率分布。这样小模型相当于继承了大模型的知识冗余部分。

我参与过一个小型检测模型的蒸馏项目，教师是参数量巨大的高精度模型，学生模型参数量只有前者的十分之一。做法还是有讲究的：不仅要对齐最后的分类输出，还要对齐中间的特征图。我们在特征图的多个层级上加了额外的对齐损失。最后学生模型的精度只比教师低了不到两个百分点，但推理延迟却只有原来的四分之一。

蒸馏不是说做就能做的，最大的坑是教师模型本身要够好。如果教师模型本身就带系统偏差，那学生会把偏差照单全收，这叫"偏置继承"。所以拿来做蒸馏的教师模型得先在测试集上验证过足够强，再让它当老师。

另外，蒸馏结束后，学生模型其实经常会塌缩到某几个局部模式里，泛化能力没想象中好。稳妥的做法是在蒸馏完成后用真实标签再做少量轮次的微调作为"校准"。

5. 部署工程里的隐藏开销：系统层面那笔账

改完模型结构和算子，性能已经提升不少了。但真正决定线上服务吞吐和响应时间的，往往不在模型内部，而在模型周围的整个工程系统。这部分常被叫"推理服务化优化"。我的经验是：很多模型的性能在离线下已经跑到很好了，一上线就原形毕露，基本都是工程问题。

5.1 数据搬移是最容易被忽视的隐形杀手

最常见的一种情况：单个GPU上模型推理本身只花了5毫秒，但整体延迟却要20毫秒。那多出来的15毫秒，基本都耗在了数据从CPU传到GPU、再从GPU传回CPU的路上。

对于图像、视频这类大输入来说，单次传输就是几十MB级别的数据，再加上必经的预处理（解码、缩放、归一化），这部分工作一多，GPU就跑得断断续续，每跑一下都得等数据。

我遇到过一个真实案例：一个视频理解类服务，瓶颈根本不在模型，而在视频解码上。GPU利用率极低，CPU却满负荷转。后来把视频解码改成硬件解码并且跟推理重叠起来流水线处理，整体延迟立刻下降了60%多。

解决这类问题有个固定套路：

• 预处理尽量放到GPU上做，比如利用GPU专用解码器，把解码的输出直接留在显存里，不走"GPU->CPU->GPU"的往返；
• 用异步传输和流机制，让数据边传边算，而不是传完再算；
• 把数据管线完全并行化，CPU侧解帧、GPU侧推理同时进行，不要互相等。

很多框架提供异步推理模式，能直接在代码层面实现这种流水线。需要说明的是，流水线化不是凭空把总计算量变小了，而是把等待时间填满了。

5.2 Batch机制：吞吐的倍增器，也是时延的放大器

推理服务里最猛的一个性能杠杆是动态批处理（dynamic batching）。单个请求进来时，模型对每个请求都做一遍完整的kernel启动和数据搬运。但如果把多个请求攒在一起变成一个大的batch，kernel启动变成一次，数据搬运的摊销成本也小得多。吞吐量往上翻几倍都有可能。

但动态批处理是有代价的：为了等待攒批，每个请求都会多等一会儿，在线延迟直接上升。

这里得做延迟和吞吐的权衡。要压延迟的服务，batch就该设小一点甚至1；要压吞吐的离线任务，batch可以尽量拉大。最稳妥的办法是让批处理器自适应调节等待时间：流量高的时候直接发当前攒到的batch，流量低的时候多等几毫秒攒个更大的batch。

顺带提一句，动态batch跟动态形状一起出现时，坑更深。如果每个请求的输入宽高不一样，强行一起进模型会让所有计算被padding到最长的那个请求的尺寸上。最夸张的一次，一个团队为了让两张分辨率差异很大的图片共享batch，one batch的耗时直接变成原来两张单独跑的1.8倍，完全得不偿失。

所以现在的做法大多是按尺寸分桶（bucket），只把接近尺寸的请求放进同一个batch，其余的分到别的桶里。这样动态batch的收益能回来一大半。

5.3 推理引擎与运行时选型：技术选型很关键

这套东西很依赖具体实现，但我还是想强调：选引擎不只是选速度，还要选生态、选硬件兼容性、选算子覆盖度。哪怕同一个模型，在通用引擎和专用引擎下面的表现能差出一倍以上，更别说不同的后处理逻辑。

我的避坑建议是：正式上线前做一次覆盖"引擎A vs 引擎B vs 引擎C"的全量benchmark，拿真实业务流量回放来测，别拿公开的benchmark结论直接拍板。另外要留意引擎的"确定性"问题——同一输入两次推理结果是否一致，某些引擎在动态形状下可能有意想不到的漂移。

模型格式转换的坑也很多。ONNX、TorchScript、各引擎自家的格式，来回倒腾时很容易出现算子兼容性问题。一旦遇到不支持的算子，引擎会退化成用通用实现甚至是CPU实现，性能直接崩掉。每次转换完都应该做一个全算子覆盖测试，确保没有暗退化的算子。

5.4 固定输入形状带来的惊人收益

这是一个经常被提及但被严重低估的优化手段。很多人为了通用性，把模型的输入形状设计成动态的，任何尺寸都能跑。但动态形状意味着推理引擎没办法在编译阶段做充分的优化，很多显存布局、kernel选择都得运行时判断，性能损耗非常直接。

如果业务场景的输入尺寸固定（比如图片统一缩放、文本padding到固定长度），强烈建议把模型输入形状固化成静态Shape。我做过一项改造：把一个文本模型从动态长度改成固定最大长度后，重新走一遍编译优化，推理延迟下降了近一半。原因很直接，静态形状让引擎可以做显存内存预分配、算子融合套娃、甚至CUDA Graph，把启动开销压缩到极致。

当然，不是所有场景都能固定输入。如果用户的输入千奇百怪，那就用前面说的分桶策略，每个桶里固定形状，效果也很不错。

6. 可观测性建设：没有度量就没有优化

聊到这，我想强烈建议每个做推理优化的团队，建立自己的性能可观测体系。没有度量体系，优化就永远是"拍脑袋+撞运气"。

至少要有下面几层度量：

第一层是硬件层指标：GPU利用率、显存带宽利用率、显存占用、SM占用率。这些能从硬件工具或者云厂商监控里拿到，用于判断优化方向对不对。

第二层是运行时层面的：kernel耗时分布、启动次数、一次推理的CPU时间/GPU时间/数据传输时间拆分、算子级别的Profile汇总。这些数据是定位具体优化点的关键。

第三层是业务层面：P50/P95/P99延迟、吞吐量、超时率、排队长度。这些直接决定用户体验，也决定你到底该优化延迟还是吞吐。

这三层数据要对齐到同一时间轴上，否则很难定位问题。比如GPU利用率突然下降，你到底要知道同时刻是不是CPU排队变长、P99延迟涨了多少，不然根本没法判断关联性。

工具方面，用图形化的profiler做算子耗时瀑布图，配合PB级别的追踪系统做请求级时序抽样，基本就够应付大多数问题了。我遇到比较难搞的性能问题，往往是通过对比同一条链路在优化前后的完整追踪文件才定位出来的。

我还建议有条件的话，在生产环境里布置一个影子流量开关：小比例地把线上真实请求复制一份发送到新版本服务，跟旧版本做全链路延迟和精度对比。这样能避免很多在测试环境测不出来、一上线就翻车的情况。

整个推理优化不是一锤子买卖，而是持续迭代的过程。每个版本上线前过一遍这套度量体系、跑一遍标准benchmark、对比上一次的数据，长期坚持下来，性能系统才会越来越健康。

最后分享一个小经验：优化这件事，最怕的不是难，而是"方向错了还坚持"。与其在不该优化的地方死磕，不如先花时间把问题定位准。只要方向对，哪怕慢一点，每一步都是实打实的收益。