深度学习推理框架选型指南：从压测方法到决策框架

在模型部署的工程实践中，推理框架的选型往往决定了线上服务的延迟表现、吞吐上限与硬件成本。然而，许多团队在选型阶段就被厂商宣传或非标准化压测数据误导，上线后才发现实际表现与预期相去甚远。本文试图从测量方法论出发，建立一套可复现、可对比的框架评估体系，帮助开发者在真实业务负载下做出理性决策。

一、为什么压测方法比压测数字更重要

在讨论任何框架的性能之前，必须先回答一个问题：你测的是什么？

一个常见的误区是直接用短输入短输出的合成请求做压测，得到极高的吞吐数字，却与真实场景毫无关系。真实问答场景中，输入往往包含较长的上下文（系统提示、历史对话、检索文档），输出长度也不固定，请求到达呈泊松分布而非均匀分布。压测设计如果不还原这些特征，得到的结论就无法迁移到生产环境。

因此，选型评估的第一步不是跑分，而是定义负载模型。建议从以下几个维度刻画你的业务负载：

• 输入长度分布：固定长度只能反映理想情况，应同时测试短输入（如几十Token）与长输入（如数千Token）下的表现，因为Prefill阶段的耗时随输入长度近似线性增长。
• 输出长度分布：输出长度直接影响Decode阶段的总步数，是吞吐量的关键变量。
• 并发模式：是少量长连接持续生成，还是大量短请求高频到达？前者考验持续解码能力，后者考验调度与批处理效率。
• 流式与否：面向终端用户的交互式应用几乎必然采用流式输出，非流式压测会掩盖首Token延迟的真实表现。

只有负载模型确定后，后续所有测量才有意义。

二、标准化测试环境的搭建原则

框架对比的前提是控制变量。不同框架对硬件、驱动、算子库版本的敏感度不同，环境不一致会直接污染结论。以下是一套可参考的标准化环境配置思路（具体型号可按自有资源替换）：

硬件层：单卡测试用于隔离多卡通信带来的干扰，便于观察单机内的调度与显存管理能力。选择显存充裕的加速卡（如80GB级别），是为了在测试较大模型时给KV Cache预留足够空间，避免因显存不足触发换出或降级，从而掩盖框架本身的调度差异。

软件层：统一操作系统版本、CUDA版本与深度学习基础库版本。特别注意，不同框架对CUDA与基础库的版本兼容区间不同，应选择各框架均支持的公共版本区间，而非各自的最新版。

模型与精度：选择一个中等规模的开源指令微调模型（如80亿参数级别），以FP16精度加载。这个规模既能体现真实的内存压力，又不至于让测试周期过长。模型权重本身占用的显存（约16GB）应被记录，以便后续区分“权重占用”与“缓存占用”。

版本锁定：记录每个框架的具体版本号。推理框架迭代极快，调度策略、批处理算法、量化支持都可能在版本间发生显著变化，脱离版本谈性能没有意义。

三、核心指标的测量方法

3.1 首Token延迟（TTFT）：体感等待的真实度量

首Token延迟指从客户端发出请求到收到第一个有效输出Token的时间间隔。它决定了用户按下回车后的“空白等待”时长，是交互式应用最敏感的指标。

正确的测量方式必须基于流式接口。具体做法是：客户端发起流式请求，记录请求发出时刻；服务端以数据块（Chunk）形式逐段返回，客户端在解析到第一个包含有效Token的块时记录时刻，两者之差即为TTFT。

这里有几个容易踩的坑：

• 不要用非流式接口测TTFT。非流式接口的返回时间等于完整生成时间，完全无法反映首Token体验。
• 不要把“收到响应头”当作“收到首Token”。HTTP响应头可能先于实际计算完成返回，必须以解析出第一个Token为准。
• 注意客户端解析开销。流式响应的分块解析、JSON反序列化都会引入毫秒级开销，在高性能框架对比中不可忽略，建议在客户端侧做多次采样取分位数。

TTFT的构成可以拆解为：请求排队时间 + 网络传输开销 + Prefill计算时间 + 首步Decode时间。流式测量能够真实覆盖这四部分，而非流式测量会把Decode的总时间混入其中，导致数据失真。

3.2 吞吐量（TPS）：解码能力的极限刻画

吞吐量的定义是：在测试窗口内，所有请求生成的总输出Token数除以测试总耗时（从第一个请求发出到最后一个请求结束）。

$\text{TPS} = \frac{\sum<em>{i=1}^{N} \text{OutputTokens}_i}{T</em>{\text{end}} - T_{\text{start}}}$

这个指标反映的是框架在Decode阶段的持续生成能力与算力利用效率。测量时需要注意：

• 区分单请求TPS与聚合TPS。单请求TPS衡量的是单条序列的解码速度，聚合TPS衡量的是批处理调度下的整体产出。选型时应以聚合TPS为主，因为它更接近生产环境的资源利用形态。
• 测试窗口要包含完整的请求生命周期。只统计稳定生成阶段会高估吞吐，应把请求的排队、Prefill、Decode全过程纳入时间窗口。
• 并发梯度而非单点。只测一个并发数没有意义，应在多个并发档位（如1、4、8、16、32）下分别测量，观察吞吐随并发的增长曲线是否饱和、是否出现拐点。拐点位置往往对应框架调度策略的效率边界。

3.3 显存占用：不能只看监控面板

这是选型中最容易被误读的部分。用常规的显存监控工具观察到的占用数字，在不同框架之间不具备直接可比性，因为各框架的显存管理策略存在本质差异。

以预分配策略为例：部分框架在启动时即按配置比例（如90%）一次性申请大块显存作为KV Cache内存池，此后运行全程显存占用恒定。这种设计的好处是避免运行期动态分配带来的碎片与抖动，坏处是监控面板上看到的数字接近硬件上限，但这并不代表框架“更耗显存”——它只是提前占位。

而另一些框架采用按需分配或分页管理策略，运行期显存占用随请求量波动，监控曲线呈现起伏。此时若在低负载时刻采样，会得出“占用很低”的结论，但这同样不代表它在高并发下更节省。

正确的比较方法是：在相同并发、相同输入输出长度下，比较“除模型权重外可用于KV Cache的显存量”，以及在该显存约束下框架能支撑的最大并发请求数或最大上下文总长度。换言之，比较的不是瞬时占用数字，而是显存效率——单位显存能换来的有效吞吐。

此外还需关注：框架是否支持显存碎片整理、是否支持KV Cache的量化压缩、是否支持前缀缓存复用。这些机制在长上下文、多轮对话场景下对显存效率的影响远大于静态占用数字。

四、容易被忽视的评估维度

除了上述三个核心指标，以下维度在实际选型中往往更具决定性：

调度与批处理策略。连续批处理（Continuous Batching）已成为主流框架的标配，但实现质量差异很大。评估时应关注：新请求能否在解码过程中动态插入、已完成序列能否及时移出以释放资源、批处理大小是否自适应。这些行为难以从文档中读出，需要通过阶梯并发压测观察吞吐曲线是否平滑。

量化与低精度支持。INT8、FP8、INT4等量化方案对吞吐和显存的提升显著，但不同框架对量化精度的保持能力、支持的量化粒度（逐层/逐通道/分组）不同。选型时应验证目标框架在你所用模型上的量化效果，而非只看是否“支持量化”。

长上下文处理能力。当输入长度超过数千Token时，Prefill阶段的耗时成为TTFT的主要成分。框架是否支持分块Prefill、是否支持Prefix Caching（相同前缀的请求复用已计算的KV）、是否对注意力算子做了长序列优化，直接决定了长文档问答类场景的可用性。

生态与运维友好度。包括：是否提供标准的OpenAI兼容接口、是否有活跃的社区与文档、是否支持主流的可观测性接入（指标导出、链路追踪）、部署形态是否与现有容器平台契合。这些“非性能”因素在长期运维中的权重往往超过几个百分点的吞吐差异。

稳定性与故障表现。在压测中应刻意制造显存压力边界、超长请求、突发并发等场景，观察框架是否会出现OOM崩溃、请求超时堆积、内存泄漏等问题。一个在极限下优雅降级的框架，比一个峰值跑分高但脆弱易崩的框架更值得选择。

五、从数据到决策：建立选型矩阵

完成测量后，不要试图用单一分数排名。更合理的做法是构建一个加权决策矩阵：

1. 确定业务优先级。交互式应用把TTFT和稳定性放在首位；离线批处理更看重聚合吞吐与显存效率；长文档场景则聚焦长上下文下的Prefill优化。
2. 为每个维度设定权重与及格线。例如TTFT的P99必须低于某阈值，聚合TPS必须达到某水平，否则直接淘汰。
3. 在真实负载回放下做最终验证。用生产流量的采样回放（或贴近真实的合成负载）跑一轮端到端对比，而不是依赖固定Prompt的基准测试。
4. 保留可复现的测试脚本与配置。框架版本升级后应能快速复测，避免“上线即失忆”。

结语

推理框架的选型本质上是一个测量工程问题：先定义清楚你要优化什么，再用可复现的方法测量它，最后在约束条件下做权衡。流式测量TTFT、阶梯并发测吞吐、以显存效率替代显存占用数字，这三条方法论能够过滤掉大部分失真数据。而调度策略、量化效果、长上下文能力、运维生态等维度的定性评估，则需要结合实际业务形态做判断。没有任何一个框架在所有维度上最优，理性的选型永远是在明确的优先级下做出可解释的取舍。