3. 推理框架与运行时高频问题

模型 Serving 工程师的面试里，推理框架与运行时是区分“会调 API”和“懂系统”的分水岭。面试官真正想确认的是：你能否根据业务场景选对运行时，能否解释性能数字背后的机制，能否在延迟、吞吐、显存、成本之间做出可辩护的取舍。本章围绕 TensorRT、ONNX Runtime、Triton、vLLM 四个高频对象，给出回答框架、追问路径与公司侧重点。

推理框架回答框架：场景→机制→指标→取舍 先定场景 在线/离线/LLM 再讲机制 图优化/调度/批 量化指标 P99/吞吐/显存 给出取舍 成本/复杂度 追问路径：为什么不用另一个？瓶颈在哪？如何验证？ 加分点：主动给出压测方法与回滚方案

一、核心原理：四个运行时到底在解决什么

TensorRT 是 NVIDIA 的推理编译器与运行时，核心价值在于图层融合、精度校准（FP16/INT8）、kernel 自动调优和显存复用。它把训练框架导出的图编译成针对特定 GPU 架构高度优化的 engine，因此换卡、换 shape 往往需要重新编译。ONNX Runtime 是跨平台推理引擎，强项是图优化、执行提供器（Execution Provider）抽象和算子覆盖，适合多硬件、多框架的统一部署。Triton Inference Server 不是单模型运行时，而是服务化编排层，支持多框架后端、动态批处理、模型仓库版本管理和并发实例，解决的是“如何把多个模型稳定地服务化”。vLLM 面向大语言模型，核心是 PagedAttention 与连续批处理（continuous batching），把 KV Cache 分页管理，显著提升显存利用率和吞吐。

面试表达要点：先一句话定位“它是什么层的东西”，再讲它最关键的机制，最后落到指标。不要一上来就背参数。

二、方法流程：选型与调优的标准动作

  1. 明确场景：在线低延迟、离线高吞吐、还是 LLM 长上下文生成。
  2. 确定硬件与精度：GPU 架构、是否允许 INT8/FP8、精度损失容忍度。
  3. 选择运行时：CV 小模型优先 TensorRT；多硬件统一优先 ONNX Runtime；多模型服务化优先 Triton；LLM 高吞吐优先 vLLM。
  4. 压测与调参：批大小、并发实例、动态批窗口、KV Cache 显存占比。
  5. 验证与回滚：对比 P50/P99、吞吐、显存、错误率，保留可回滚版本。
# Triton 动态批处理配置片段
dynamic_batching {
  preferred_batch_size: [8, 16, 32]
  max_queue_delay_microseconds: 2000
}

# vLLM 启动关键参数
python -m vllm.entrypoints..api_server \
  --model /models/qwen \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 256

三、案例与场景：把机制讲成业务结果

场景一：图像分类服务延迟超标。原方案用 ONNX Runtime CPU 推理，P99 约 120ms。改用 TensorRT FP16 并固定输入 shape 后，P99 降到 25ms，但换模型需重新编译。回答时要说明“收益来自图层融合与 FP16”，并主动补充“编译耗时与版本管理成本”。

场景二：多模型推荐服务。团队有排序、召回、特征处理多个模型，用 Triton 统一托管，开启动态批处理后 GPU 利用率从 35% 提升到 70%。追问常问“动态批处理会不会增加延迟”，应回答“会引入排队延迟，需要根据 SLA 设置 max_queue_delay_microseconds”。

场景三：LLM 对话服务。用 vLLM 替换 HuggingFace 原生推理，开启连续批处理后吞吐提升数倍。要能解释 PagedAttention 减少显存碎片，从而支持更大并发；同时说明长上下文会挤占 KV Cache，需要限制 max_model_len。

框架核心机制适用场景主要代价
TensorRT图融合、INT8/FP16、kernel 调优固定 GPU 的 CV/小模型低延迟编译绑定硬件与 shape
ONNX Runtime图优化、EP 抽象多硬件、多框架统一部署极致性能不如专用编译
Triton动态批、多后端、模型仓库多模型服务化编排配置复杂、排队延迟
vLLMPagedAttention、连续批处理LLM 高吞吐在线服务显存与调度调参门槛

四、误区与复盘：面试官最想听到的反思

常见误区：只背“TensorRT 快、vLLM 吞吐高”，却说不清快在哪里；把 Triton 当成推理引擎而不是服务层；忽略精度损失与回滚；压测只报平均值不报 P99。

复盘模板：先给结论，再给机制，再给数据，最后给边界。例如“我们选 vLLM，因为 PagedAttention 降低了 KV Cache 碎片，实测吞吐提升约 3 倍；代价是长上下文下显存紧张，我们通过限制 max_model_len 和调整 gpu-memory-utilization 控制风险”。这样的回答既有原理又有工程判断，符合大厂对 Serving 工程师的期待。

公司侧重点提示：云厂商与基础设施团队更关注 Triton 编排、多租户隔离与成本；自动驾驶与边缘团队更关注 TensorRT 编译、INT8 校准与确定性延迟；大模型公司更关注 vLLM 的调度、KV Cache 与并行策略；传统 AI 平台则看重 ONNX Runtime 的跨平台一致性。回答时主动对齐目标公司的技术栈，会显著加分。

← 上一章 📖 返回目录 下一章 →