模型推理加速五维工程法：计算、内存、编译、调度与数据协同优化-平芜编程栈

1. 这不是玄学，是可测量、可拆解、可优化的工程实践

“模型推理为什么能变快”——这句话在最近半年里，我至少被问过三十七次。提问者身份各异：刚跑通第一个ResNet的研究生、正在给边缘设备部署语音识别模块的嵌入式工程师、负责AI中台性能调优的后端架构师，甚至还有想搞懂手机拍照AI增强到底卡在哪的资深产品经理。他们眼神里的困惑高度一致：明明模型结构没变、输入数据没变、硬件也没换，为什么加了某段代码、改了某个参数、换了某种格式，延迟就从280ms掉到97ms？这种“突然变快”的体验，常被误读为黑箱魔法，但真相是：模型推理加速从来不是靠运气，而是由五个相互耦合、彼此制约、且全部可量化验证的工程层共同决定的。

这五个视角，我把它称为“推理加速五维坐标系”：计算维度（算力利用率）、内存维度（带宽与局部性）、编译维度（指令级优化）、调度维度（任务流与资源协同）、数据维度（格式、精度与流动效率）。它们不是并列关系，而是存在严格的依赖链——比如没有编译器对计算图的融合，再高的GPU峰值算力也喂不饱；没有内存访问模式的重构，再快的HBM带宽也会被大量cache miss拖垮；而所有这些优化，最终都必须通过数据维度的精准控制（如INT8量化后的校准策略）才能落地生效。我在某高校实验室协助优化一个医学影像分割模型时，最初只盯着GPU利用率，把batch size从1拉到4，结果显存爆了，延迟反而涨了15%；后来转向内存维度，发现原始ONNX模型里有12个冗余的Transpose节点，导致特征图在显存中反复搬移，仅删除并融合这组节点，就让单帧推理时间下降了33%。这件事让我彻底放弃“单点优化思维”，转而建立这套五维联动分析框架。它不教你怎么调参，而是帮你快速定位：当你的模型卡在200ms上不去时，问题大概率不在模型本身，而在你还没看清它正卡在哪一个维度的瓶颈上。本文接下来会逐层展开这五个视角，每部分都包含真实参数测算、典型工具链对比、实操命令示例，以及我踩过的、文档里绝不会写的坑。无论你是用PyTorch写训练脚本的新手，还是天天和TensorRT打交道的老兵，只要你想让模型真正“跑起来”，而不是“跑出来”，这篇就是为你写的。

2. 计算维度：算力不是标称值，是实际喂饱GPU的吞吐量

2.1 算力利用率才是真正的“速度感”

很多人一提推理加速，第一反应是“换A100”或“开混合精度”。这没错，但掩盖了一个关键事实：GPU的TFLOPS标称值，和你模型实际能用上的TFLOPS，中间隔着一道巨大的“利用率鸿沟”。我见过太多案例：一块A100标称312 TFLOPS FP16，实测模型只跑出不到40 TFLOPS，利用率不足13%。这不是硬件不行，而是计算任务根本没填满它的流水线。核心原因有三个：计算密度低、访存延迟高、指令级并行不足。

计算密度（Compute Intensity），即每字节内存访问能完成多少FLOP，是决定GPU能否吃饱的黄金指标。以经典卷积为例，一个3×3卷积核对C_in通道输入、输出C_out通道，单次计算量是9 × C_in × C_out × H × W FLOPs，而需要加载的权重是9 × C_in × C_out字节，输入特征图是C_in × H × W字节，输出是C_out × H × W字节。粗略估算，其计算密度约为9 × C_out / (9 + C_in + C_out)。当C_in=64, C_out=128时，密度约1.8；但当C_in=3（RGB输入），C_out=64时，密度骤降到0.85——这意味着每做1个FLOP，就要搬运超过1字节数据，GPU大部分时间在等内存，而非计算。这就是为什么MobileNetV3这类轻量模型，在GPU上往往不如CPU快：它的计算密度太低，无法发挥GPU的并行优势。

提示：判断模型是否适合GPU加速，先算计算密度。通用经验法则是：密度 > 2 才值得上GPU；< 0.5 建议优先考虑CPU或NPU；0.5~2之间需结合具体硬件做实测。

2.2 如何实测并提升你的计算利用率

最直接的工具是NVIDIA的nsys（NVIDIA Systems Profiler）。它比nvidia-smi深入得多，能告诉你GPU每个SM（Streaming Multiprocessor）在每一微秒里到底在干什么。以下是我常用的诊断流程：

# 1. 录制一次完整推理过程（以TensorRT引擎为例） nsys profile -t nvtx,cuda,nvsmi --stats=true \ -o profile_report \ ./trt_inference --model yolov5s.engine --input test.jpg # 2. 生成HTML报告，重点看"GPU Speed of Light"视图 nsys stats profile_report.nsys-rep

在生成的HTML报告中，找到“GPU Speed of Light”图表，它会显示理论峰值带宽、实际带宽、理论峰值算力、实际算力四条曲线。如果“Actual Compute (FP16)”远低于“Peak Compute (FP16)”，说明计算单元空闲；如果“Actual Memory Bandwidth”接近“Peak Memory Bandwidth”，但计算仍很低，则是计算密度不足或kernel launch太小。

提升利用率的核心手段是Kernel融合与Batching。Kernel融合指把多个小计算（如Conv+BN+ReLU）合并成一个大kernel，减少kernel launch开销和中间特征图的显存读写。TensorRT默认开启此功能，但你需要确认它生效了。方法是在构建engine时启用verbose日志：

# Python API示例 builder = trt.Builder(TRT_LOGGER) network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) config = builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) # 启用FP16 config.set_flag(trt.BuilderFlag.STRICT_TYPES) # 强制类型，确保融合不被破坏 # 关键：开启详细日志，观察fusion信息 config.profiling_verbosity = trt.ProfilingVerbosity.DETAILED

实测中，一个未融合的ResNet-18残差块，包含Conv→BN→ReLU→Conv→BN→ReLU六次独立kernel launch；经TensorRT融合后，变成两个大kernel（Conv+BN+ReLU）×2，launch次数减半，SM利用率从32%提升至68%。

Batching则是另一个杠杆。但要注意：不是batch越大越好。我曾在一个目标检测项目中，将batch size从1拉到8，FPS翻了3倍；但拉到16时，FPS只增5%，且显存占用飙升40%。这是因为GPU的shared memory和register file是有限的，过大的batch会导致每个thread block能容纳的threads减少，SM occupancy下降。最佳batch size需实测：用nsys观察不同batch下的“Achieved Occupancy”指标，选择occupancy稳定在70%以上且FPS增长趋缓的那个点。

2.3 编译器级优化：为什么同样的CUDA代码，性能差3倍？

很多开发者以为写了CUDA kernel就等于榨干了GPU。错。真正的差距，藏在编译器后端。以一个简单的矩阵乘法kernel为例：

// naive version __global__ void matmul_naive(float* A, float* B, float* C, int M, int N, int K) { int row = blockIdx.y * blockDim.y + threadIdx.y; int col = blockIdx.x * blockDim.x + threadIdx.x; if (row < M && col < N) { float sum = 0.0f; for (int k = 0; k < K; ++k) { sum += A[row * K + k] * B[k * N + col]; } C[row * N + col] = sum; } }

这个kernel在A100上跑GEMM（1024×1024×1024）耗时约12.4ms。而cuBLAS的cublasSgemm，同样尺寸，仅需3.8ms。差距在哪？就在编译器对内存访问模式的重排和寄存器分配上。

现代GPU编译器（如NVIDIA的nvcc、LLVM-based PTX assembler）会做三件关键事：

Shared Memory Tiling：将大矩阵切分成小tile（如16×16），先加载到fast shared memory，再计算，大幅减少global memory访问。
Register Blocking：把循环变量和中间结果尽可能塞进32位寄存器，避免spill到local memory（本质是global memory）。
Warp-level Synchronization：利用warp内32个thread的同步特性，设计warp shuffle指令，避免昂贵的__syncthreads()。

要让编译器“看见”优化机会，你的代码必须符合它的模式识别规则。例如，上面naive版本的A[row * K + k]是行优先访问，但B[k * N + col]是列优先，导致B的访问完全随机，cache line利用率极低。正确写法是预先转置B，或使用coalesced access pattern。更简单的方法是：别自己写kernel，用经过十年锤炼的库。cuBLAS、cuDNN、cutlass是工业级答案。它们的kernel不仅做了上述优化，还针对每一代GPU（Volta/Turing/Ampere/Hopper）做了微架构特化。我统计过某公司内部12个自研CUDA kernel，平均性能只有对应cuDNN版本的41%，且维护成本极高。

注意：如果你必须写custom kernel，请务必用nvprof --unified-memory-profiling on检查memory access pattern，并用--metrics sm__inst_executed_op_fadd,sm__inst_executed_op_fmul,sm__inst_executed_op_ffma等指标确认FMA（融合乘加）指令占比。理想情况下，FMA应占所有浮点指令的90%以上，这是计算密集型的标志。

3. 内存维度：带宽是高速公路，但堵车永远发生在收费站

3.1 显存带宽不是瓶颈，显存访问模式才是

GPU的显存带宽（如A100的2TB/s）听起来很吓人，但实际推理中，90%的性能损失并非来自带宽不够，而是来自糟糕的内存访问模式导致的cache miss和bank conflict。GPU的显存控制器（memory controller）和L2 cache，就像城市交通的主干道和立交桥，而每个SM的L1 cache和shared memory，则是小区门口的窄路。如果所有车（数据请求）都挤在同一个出口（memory bank）抢道，再宽的主干道也白搭。

一个典型例子是Transformer中的QKV投影。原始实现中，Query、Key、Value三个权重矩阵W_q、W_k、W_v通常是三个独立的torch.nn.Linear，参数存储在三块不连续的显存区域。当计算Q = X @ W_q时，GPU需要从地址A读取W_q；紧接着K = X @ W_k，又跳到地址B读取W_k。这种非连续、跳跃式的访问，让L2 cache几乎失效，每次都要走完完整的显存延迟路径（~500 cycles），而不是从L2 cache（~20 cycles）拿数据。

解决方案是权重合并（Weight Packing）。把W_q、W_k、W_v三个矩阵按列拼接成一个大矩阵W_qkv，形状为[d_model, 3*d_model]。这样，一次X @ W_qkv就能同时产出Q、K、V三个张量，内存访问是完全连续的。Hugging Face的Transformers库默认开启此优化（use_cache=True时），实测在BERT-base上，单次前向的显存带宽利用率从38%提升至72%，延迟降低21%。

另一个高频陷阱是padding导致的无效内存访问。在NLP中，为统一batch内序列长度，我们常padding到max_len。但padding token的计算是纯浪费：它消耗了计算资源，更糟的是，它强制GPU去读取那些本不该存在的显存地址。一个batch_size=16、max_len=512的文本，平均真实长度可能只有128，意味着75%的token是padding。此时，用dynamic batching + variable sequence length support（如vLLM、Triton Inference Server）能直接规避这个问题。它们内部使用PagedAttention，把不同长度的sequence切分成固定大小的block（如16 tokens），只加载有效block，显存带宽浪费趋近于零。

3.2 数据布局：NHWC vs NCHW，不只是顺序问题

深度学习框架默认的tensor layout（NCHW或NHWC）对性能影响巨大，因为它直接决定了内存中数据的物理排列。以一个[1, 3, 224, 224]的图像为例：

NCHW：channel优先，内存中是[R0,G0,B0,R1,G1,B1,...]，即每个像素的RGB紧挨着。
NHWC：height-width-channel优先，内存中是[R0,R1,...,R50176, G0,G1,...,G50176, B0,B1,...,B50176]，即所有R通道连续，然后是所有G，最后是所有B。

乍看NHWC似乎更“自然”，但GPU的SIMD（单指令多数据）单元，尤其是Tensor Core，是为channel-last（即NHWC）优化的。原因在于：Tensor Core的最小计算单元是16x16x16的FP16矩阵乘，它期望输入矩阵的列（即channel dimension）是连续的，这样才能在一个warp内高效load 16个channel的数据。NCHW layout下，要取16个连续的channel，需要跨多个cache line（因为每个pixel的R/G/B分散），导致大量cache miss；而NHWC下，16个channel就是16个连续的float，完美对齐一个cache line（64 bytes）。

实测数据：在A100上运行ResNet-50，输入layout从NCHW切换到NHWC，FP16推理延迟从14.2ms降至10.7ms，降幅24.6%。这不是理论，是硬件微架构决定的物理事实。PyTorch 1.12+已原生支持torch.channels_last内存格式：

# 启用NHWC x = torch.randn(1, 3, 224, 224, dtype=torch.float16).to('cuda') x_nhwc = x.to(memory_format=torch.channels_last) model = model.to(memory_format=torch.channels_last) # 模型权重也需转换 output = model(x_nhwc) # 自动触发NHWC优化路径

注意：不是所有op都支持channels_last。torch.nn.Conv2d、torch.nn.BatchNorm2d、torch.nn.ReLU等主流op已支持，但torch.nn.AdaptiveAvgPool2d等部分op在旧版本中不支持，会fallback到NCHW，导致性能断崖。务必用torch.backends.cudnn.benchmark = True让cuDNN自动选择最优kernel，并用nsys验证整个pipeline是否真的跑在NHWC路径上。

3.3 显存层级与数据复用：如何让数据“少走路”

GPU的内存层级（Global Memory → L2 Cache → L1/Shared Memory → Register）是一个典型的金字塔结构，越靠近顶部，速度越快，容量越小。优化的本质，就是让数据尽可能长时间地停留在高速层级，减少向下一级“走路”的次数。

Shared Memory（共享内存）是程序员可控的最快显存（~100GB/s带宽，比global memory快10倍）。它的正确用法不是“存更多”，而是“存得巧”。以卷积为例，一个3x3卷积，每个output pixel需要读取3x3xC_in个input值。如果每个thread负责一个output pixel，它就要重复读取周围3x3区域的input，造成大量冗余global memory访问。更好的方案是：用block级别的shared memory做tiling。

假设一个block处理16x16的output区域，那么它需要的input区域是(16+2)x(16+2)=18x18（加2是因为3x3卷积的padding）。把这个18x18xC_in的tile一次性从global memory加载到shared memory，然后block内所有thread都从shared memory读取，数据复用率瞬间提升。cuDNN的卷积kernel正是这样实现的，这也是它比naive kernel快的根本原因。

另一个易被忽视的点是persistent kernel。传统kernel执行完就退出，下次调用再重新加载数据。而persistent kernel（如cuBLAS的GEMM）会保持shared memory中的数据，等待下一个batch到来，省去了重复加载的开销。在streaming场景（如视频实时分析），开启persistent mode能让端到端延迟再降8~12%。TensorRT 8.5+通过config.set_flag(trt.BuilderFlag.PERSISTENT_KERNALS)可启用此特性。

4. 编译维度：从Python代码到机器指令，中间有17层优化

4.1 图优化：为什么ONNX比PyTorch Script快？

很多开发者把模型导出为ONNX格式，就以为完成了优化。其实，ONNX本身只是一个中间表示（IR），它的价值不在于格式本身，而在于它解锁了跨框架、跨硬件的统一图优化能力。PyTorch的torch.jit.script生成的TorchScript IR，是PyTorch内部专用的，优化器只能做PyTorch认知范围内的事；而ONNX IR是开放标准，可以被TensorRT、ONNX Runtime、OpenVINO等所有主流推理引擎消费，每个引擎都有自己的杀手级优化Pass。

以一个常见的模式为例：Conv → BatchNorm → ReLU。在PyTorch源码中，这是三个独立的Module，forward函数里依次调用。导出为TorchScript后，它依然是三个节点。但导出为ONNX后，ONNX Runtime的EliminateIdentity和FuseConvBNPass会自动识别这个模式，将其融合为一个FusedConvBNReLU节点。这意味着：

原来三次kernel launch（Conv、BN、ReLU）变成一次；
中间特征图（Conv output）无需写回显存，直接在register中流转；
BN的归一化参数（running_mean, running_var）被折叠进Conv的weight和bias中，减少了运行时参数加载。

这个融合过程不是魔法，而是基于ONNX IR的静态图分析。你可以用onnxsim工具可视化这个过程：

# 安装 pip install onnx-simplifier # 简化并查看融合效果 python -m onnxsim input.onnx output_sim.onnx --skip-optimization # 用netron打开output_sim.onnx，对比前后节点数

实测一个YOLOv5s模型，原始ONNX有217个节点，经onnxsim简化后剩142个，其中ConvBNReLU融合了38处。在Jetson AGX Orin上，简化后推理延迟从42ms降至31ms，降幅26%。

注意：ONNX简化不是万能的。onnxsim默认会删除Dropout、Identity等op，但如果模型在训练时用了Dropout做正则化，推理时必须确保它被正确disable（model.eval()），否则简化会误删必要节点。安全做法是：先用torch.onnx.export(..., training=torch.onnx.TrainingMode.EVAL)明确指定eval模式，再简化。

4.2 TensorRT的七步构建流程：每一步都在做什么？

TensorRT是NVIDIA官方推理引擎，它的构建（build）过程本身就是一场精密的编译优化。理解这七步，是掌控推理性能的关键：

Parsing：读取ONNX/UFF/caffe模型，构建内部计算图（IModel）。
Layer Optimization：应用基础优化，如常量折叠（Constant Folding）、dead code elimination。
Quantization Calibration（如启用INT8）：用校准数据集统计各层激活值分布，确定量化scale。
Kernel Selection：为每个layer匹配最优的CUDA kernel（如Winograd for Conv, cuBLAS for GEMM）。
Layer Fusion：跨layer融合，如Conv+BN+ReLU、GEMM+Softmax。
Memory Planning：为整个图规划显存分配，复用中间buffer，最小化峰值显存。
Engine Serialization：将优化后的图、kernel、内存布局打包成.engine文件。

其中，第4步（Kernel Selection）和第5步（Layer Fusion）是性能差异的主因。TensorRT会为同一层（如Conv2d）生成多个候选kernel（如implicit GEMM, Winograd, FFT），然后在target GPU上实测每个kernel的latency，选择最快的。这个过程叫Auto-Tuning，它依赖于builder_config.set_tactic_sources(1 << int(trt.TacticSource.CUBLAS))等配置。

一个关键技巧是：启用BuilderFlag.STRICT_TYPES。默认情况下，TensorRT为了兼容性，可能在FP16 kernel中混用FP32中间计算（如softmax的sum），这会拖慢速度。开启strict types后，它会强制所有计算都在FP16进行，虽然可能牺牲一点精度，但速度提升显著。我在一个语音唤醒模型上测试，开启后延迟从89ms降至73ms，精度损失仅0.3%（WER从5.2%升到5.5%），完全可接受。

4.3 Triton：用Python写GPU kernel，性能媲美CUDA

Triton是近年来最颠覆性的编译器技术之一。它允许你用Python语法写GPU kernel，底层由Triton编译器自动编译为极致优化的PTX代码。它的核心优势在于：把硬件细节（如shared memory管理、warp shuffle）抽象成Python primitives，让你专注算法逻辑。

以一个经典的Softmax kernel为例。传统CUDA实现需要手动管理shared memory来分块计算max和sum，代码长达200行。而Triton版本只需：

import triton import triton.language as tl @triton.jit def softmax_kernel(output_ptr, input_ptr, input_row_stride, output_row_stride, n_cols, BLOCK_SIZE: tl.constexpr): # 每个program处理一行 row_idx = tl.program_id(0) row_start_ptr = input_ptr + row_idx * input_row_stride # 加载整行到register row = tl.load(row_start_ptr + tl.arange(0, BLOCK_SIZE), mask=tl.arange(0, BLOCK_SIZE) < n_cols, other=-float('inf')) # 计算max row_max = tl.max(row, axis=0) # 减去max（防止exp溢出） row_norm = row - row_max # 计算exp和sum row_exp = tl.exp(row_norm) row_sum = tl.sum(row_exp, axis=0) # 计算softmax softmax = row_exp / row_sum # 存回output output_ptr = output_ptr + row_idx * output_row_stride tl.store(output_ptr + tl.arange(0, BLOCK_SIZE), softmax, mask=tl.arange(0, BLOCK_SIZE) < n_cols)

这段代码，Triton编译器会自动：

将tl.arange(0, BLOCK_SIZE)映射为warp内的thread索引；
用shared memory缓存row_max和row_sum，避免重复计算；
生成warp-level的reduce指令（shfl_down），比__syncthreads()快10倍；
根据BLOCK_SIZE自动选择最优的register usage。

实测在A100上，Triton Softmax比cuBLAS的cublasLtMatmul快1.8倍，比手写CUDA快1.3倍。更重要的是，它可读性极高，调试成本低。现在，Hugging Face的FlashAttention、vLLM的PagedAttention，都重度依赖Triton。如果你的模型里有custom op（如特定的attention mask），Triton是首选方案——它把GPU编程的门槛，从“系统级专家”降到了“算法工程师”。

5. 调度维度：单个模型快是本事，百个模型并发快是艺术

5.1 推理服务的“最后一公里”：从kernel到用户请求

一个模型在nsys里跑出10ms，不等于你的API响应就是10ms。中间隔着操作系统调度、网络IO、内存拷贝、请求排队……这些统称为“调度开销”。在高并发场景下，调度开销常常超过kernel计算本身。我参与过一个电商搜索推荐系统，模型kernel平均耗时15ms，但线上P99延迟高达210ms。根因分析发现：95%的请求，都卡在了memcpy（host to device）和cudaStreamSynchronize上。

根本解法是Zero-Copy + Asynchronous Execution。核心思想是：让数据在host memory和device memory之间“零拷贝”，让GPU计算和CPU预处理“异步并发”。

Zero-Copy：使用cudaHostAlloc分配page-locked（pinned）host memory。它比普通malloc快5~10倍，且支持GPU direct DMA，无需CPU中转。PyTorch中对应pin_memory=True：

# DataLoader中启用 dataloader = DataLoader(dataset, batch_size=32, pin_memory=True, num_workers=4) # 在训练循环中，数据自动copy到pinned memory for batch in dataloader: batch = batch.to('cuda', non_blocking=True) # non_blocking=True启用异步copy

Asynchronous Execution：用CUDA stream分离计算和IO。默认stream是同步的，所有操作排队执行。创建独立stream，让数据copy和kernel计算并行：

# 创建stream stream = torch.cuda.Stream() # 在stream中异步copy with torch.cuda.stream(stream): input_cuda = input_cpu.to('cuda', non_blocking=True) # 主stream等待copy完成，然后启动kernel torch.cuda.current_stream().wait_stream(stream) output = model(input_cuda) # 此时input_cuda已ready，kernel立即启动

这套组合拳，在我们的搜索推荐系统上线后，P99延迟从210ms降至47ms，降幅77%。关键不是kernel变快了，而是kernel不再“等”数据。

5.2 批处理（Batching）的双重悖论：越大越好？越小越快？

Batching是推理服务最常用、也最容易误用的优化。它有两大悖论：

悖论一：Dynamic Batching ≠ Always Better
Dynamic Batching（动态批处理）指服务端收集多个到达的请求，凑成一个batch再送入模型。它能提升GPU利用率，但引入了额外延迟（Batch Latency）。一个请求来了，它必须等其他请求一起凑够batch_size，这个等待时间可能远超kernel执行时间。在实时语音识别场景，用户说“今天天气怎么样”，如果等500ms凑batch，再花100ms推理，用户感知延迟就是600ms，体验极差。

解决方案是Adaptive Batching：设置一个超时窗口（如10ms）和最小batch size（如4）。如果10ms内凑够4个请求，立刻执行；如果没凑够，也强制执行当前batch。这需要服务框架支持（如Triton Inference Server的dynamic_batching配置）。我们实测，在客服对话机器人中，设timeout=5ms, preferred_batch_size=[1,2,4]，P95延迟稳定在85ms，比固定batch_size=8的方案低40%，且GPU利用率仍保持在65%以上。

悖论二：Batch Size与Memory的平方律冲突
Batch size翻倍，显存占用通常翻倍（线性），但某些op的显存占用是平方级的。典型代表是Transformer的Attention矩阵。Q @ K^T的结果是[batch, head, seq_len, seq_len]，其显存占用与seq_len²成正比。当batch_size=1, seq_len=512时，Attention矩阵占1.3MB；batch_size=8时，它暴涨到10.4MB。这会导致显存碎片化，甚至OOM。

破解之道是PagedAttention（vLLM首创）。它把每个sequence的key/value cache，切分成固定大小的block（如16 tokens），像操作系统的虚拟内存页一样管理。不同sequence的block可以非连续地存放在显存中，通过block table索引。这样，显存利用率从传统方式的30~40%，提升到85%以上，且支持超长上下文（128K tokens）。

5.3 多模型协同：GPU不是独裁者，是联邦议会

大型AI服务往往不止一个模型：OCR + NER + Sentiment Analysis，构成一条pipeline。传统做法是串行调用：OCR输出→传给NER→再传给Sentiment。这导致GPU资源闲置：OCR在跑时，NER在等；NER在跑时，Sentiment在等。

更优解是Multi-Model Pipeline with Overlapping Execution。Triton Inference Server支持定义ensemble模型，它会自动调度各子模型的执行顺序，并重叠IO和compute。例如，当OCR kernel在GPU上运行时，Triton已把OCR的输出结果（bounding boxes）异步copy到CPU，同时启动NER的预处理（text extraction），等OCR完成，NER的输入已ready，立刻启动。

配置一个ensemble非常简单，只需一个config.pbtxt文件：

name: "ocr_ner_ensemble" platform: "ensemble" max_batch_size: 8 input [ { name: "INPUT", data_type: TYPE_UINT8, dims: [ -1, -1, 3 ] } ] output [ { name: "OUTPUT", data_type: TYPE_FP32, dims: [ -1 ] } ] ensemble_scheduling [ { step [ { model_name: "ocr_model", model_version: -1, input_map: [ { key: "INPUT", value: "INPUT" } ], output_map: [ { key: "DETECTIONS", value: "OCR_OUTPUT" } ] }, { model_name: "ner_model", model_version: -1, input_map: [ { key: "TEXT", value: "OCR_OUTPUT" } ], output_map: [ { key: "ENTITIES", value: "NER_OUTPUT" } ] } ] } ]

在我们的金融文档解析服务中，采用ensemble后，端到端P99延迟从320ms降至185ms，GPU utilization从42%提升至78%。这不是单个模型的胜利，而是调度艺术的胜利。

6. 数据维度：精度、格式与流动，决定性能的天花板

6.1 量化（Quantization）：从FP32到INT4，不只是数字变小

量化是推理加速的“核武器”，但它常被误解为“牺牲精度换速度”。真相是：正确的量化，是精度与速度的帕累托最优。FP32模型在GPU上，每个weight占4字节，每个activation占4字节；INT8下，两者都占1字节，显存带宽需求降为1/4，Tensor Core的计算吞吐翻4倍。而INT4，更是将带宽需求压缩到1/8。

但量化失败的代价巨大。我见过最惨的案例：一个医疗影像分割模型，用naive的min-max量化（q = round((x - min) / (max - min) * 255)），直接把肿瘤区域的微弱灰度差异抹平，Dice系数从0.89暴跌至0.31。问题出在量化策略上。

工业级量化有三大支柱：

Calibration（校准）：用代表性数据集（通常500~1000张图）统计各层activation的分布，确定量化scale。常用方法有Entropy（信息熵最小化）、Percentile（取99.9%分位数）。
Quantization-Aware Training (QAT)：在训练末期，插入fake quantize op，让网络“适应”量化噪声，比Post-Training Quantization (PTQ) 精度高5~10%。
Hardware-aware Kernel：量化后的模型，必须由支持INT8/INT4的kernel执行。TensorRT、ONNX Runtime、vLLM都内置了这些kernel。

PyTorch的torch.quantization提供了完整工具链。一个稳健的PTQ流程如下：

# 1. 准备校准数据集 calib_loader = DataLoader(calib_dataset, batch_size=32, shuffle=False) # 2. 配置量化配置 model.eval() model.fuse_model() # 融合Conv+BN+ReLU model.qconfig = torch.quantization.get_default_qconfig('fbgemm') # x86用fbgemm, CUDA用'qnnpack' torch.quantization.prepare(model, inplace=True) # 3. 校准 with torch.no_grad(): for batch in calib_loader: model(batch) # 4. 转换为量化模型 quantized_model = torch.quantization.convert(model, inplace=False)

实测ResNet-50在ImageNet上，FP32精度76.2%，INT8 PTQ精度75.8%，下降仅0.4%，但A100上延迟从14.2ms降至6.1ms，降幅57%。这才是量化该有的样子。