1. AI模型推理工具的概念边界与选型维度
我做AI模型推理工具选型咨询时，最怕听到一句话：“你们这个工具能推理吗？”能推理和能上线，中间隔着一条河。我把这条河拆成三段看：训练框架管模型怎么长出来，推理工具管模型怎么跑起来，模型服务化平台管模型怎么稳定、安全、可计费地交给业务用。三个东西经常被打包成一个词卖，选型的人一不留神就买错层。
从产品同学视角看，模型服务化平台最像“成品”，有部署按钮、API、监控面板、鉴权、限流和账单。工程同学更关心推理工具本身：它吃什么模型格式，跑在什么卡上，并发上来会不会崩，流式输出稳不稳。训练框架呢，更多出现在算法团队的工作流里，负责训练、微调、实验管理。把训练框架当推理工具用，短 Demo 能跑，长业务会疼。
我的判断很简单：训练框架是生产线，推理工具是发动机，模型服务化平台是整车和售后体系。你买发动机之前，得先确认自己是要造车，还是要直接打车。概念边界不清，后面比吞吐、比延迟、比价格都会比歪。
1.1 推理工具与训练框架、模型服务化平台的边界
我见过一个团队拿训练脚本直接包一层 Flask 就上线，前两周很顺，第三周并发一上来，显存碎片、排队、超时全冒出来。训练框架关心的是梯度、优化器、分布式训练通信，推理工具关心的是加载权重、KV Cache、批处理、量化、流式返回。两者优化目标不一样，硬凑在一起，工程债会滚得很快。
模型服务化平台站在更上层。它通常会把推理工具封在下面，再补上模型版本管理、灰度发布、API 网关、监控告警、计量计费和多租户隔离。运维同学看平台，先问扩缩容和故障自愈；财务同学看平台，先问按什么口径计费；法务同学看平台，先问数据落在哪里、许可协议干不干净。推理工具只是平台里的一颗核心零件，不是全部。
我习惯用一个问题切开边界：“模型上线后，谁负责请求排队、显存回收、版本回滚和账单？”答案落在推理工具，说明你在选发动机；答案落在平台，说明你在选整车。这个问题问完，很多选型会从“哪个工具最强”变成“我这一层到底缺什么”。
1.2 核心能力矩阵：模型格式、硬件后端、批处理、量化与流式输出
能力矩阵不能只看官网打勾。模型格式决定你能不能把训练出来的权重顺滑接进来，SafeTensors、ONNX、GGUF、TensorRT-LLM 自有格式，各有各的舒适区。硬件后端决定它跑在 CPU、GPU、NPU 还是异构集群上。批处理决定高并发时吞吐能不能抬起来，量化决定显存和成本能不能压下去，流式输出决定终端用户等答案时会不会觉得卡死。
工程同学看这张矩阵，先盯格式和硬件匹配度，免得模型转换转出一堆精度问题。产品同学看流式输出和首字延迟，用户等三秒和等三百毫秒，体感差很多。运维同学看批处理和量化，连续批处理能不能开、量化后精度掉多少、显存峰值稳不稳，这些直接决定夜里能不能睡踏实。
我常用一张简表做初筛，表格背后还要补实测：
| 能力项 | 我重点问什么 | 容易踩的坑 |
|---|---|---|
| 模型格式 | 原生支持哪些格式，转换链路长不长 | 转换后精度漂移，回滚困难 |
| 硬件后端 | GPU 型号、驱动、CUDA 版本匹配度 | Demo 卡能跑，生产卡跑不动 |
| 批处理 | 静态批处理还是连续批处理 | 高并发下排队时间飙高 |
| 量化 | INT8、INT4、FP8 的支持范围 | 量化后效果下降，缺少评估集 |
| 流式输出 | SSE、WebSocket、断线重连 | 首包慢，中途断流 |
这张表不是用来打分的，是用来逼出真实约束的。谁家的矩阵都好看，能不能在你的模型、你的卡、你的流量形态下稳住，才是分水岭。
1.3 选型关键指标：吞吐、延迟、成本、易用性、生态与许可协议
吞吐和延迟经常被混着说。吞吐看单位时间能处理多少请求或多少 token，延迟看用户等多久，首 token 时间、每 token 输出时间、P99 尾延迟，关注点完全不同。一个工具吞吐很漂亮，P99 抖得厉害，实时对话业务照样难受。另一个工具单请求很快，批处理能力弱，离线大批量任务成本会上去。
成本要拆开看。卡时成本、显存占用、量化后的精度损失、运维人力、扩容弹性，都算钱。财务同学喜欢问“单千 token 成本”，工程同学会补一句“峰值预留多少卡”。易用性也不是虚词，部署要几小时还是几天，文档能不能照着跑通，SDK 和 OpenAI 兼容接口顺不顺手，都会影响落地速度。
生态和许可协议是选型里最容易被低估的两项。生态看社区活跃度、框架适配、云市场镜像、问题响应速度。许可看 Apache、MIT、商业授权、AGPL 这类条款会不会卡住你的分发方式。法务同学一句“这个许可证我们能商用吗”，经常能把技术选型拉回现实。我的习惯是给指标加角色权重：产品重延迟和体验，工程重吞吐和稳定，财务重成本，法务重许可，运维重可观测性。权重不统一，评审会就会变成各说各话。
1.4 关键词需求映射：性能对比与开源推荐前需明确的评估前提
用户搜“AI模型推理工具性能对比”，背后往往藏着一个没说完的场景。有人要做实时客服，有人要做离线文档摘要，有人要在边缘盒子上跑小模型。场景不同，性能对比的结论会反过来。我写对比或做推荐前，会先把评估前提钉住：任务类型、模型家族和参数量、输入输出长度、并发量、硬件环境、精度要求、预算边界、合规要求、团队运维能力。
开源AI模型推理框架推荐也一样。开源不等于免费上线，社区活跃不等于生产可用，Star 多不等于你的模型跑得顺。我会问三个问题：这个框架最近半年有没有稳定发版，有没有真实生产案例，许可协议能不能覆盖我的部署方式。再把团队能力放进去看，没人懂 CUDA 和编译优化，选一个高度依赖手工调优的框架，落地成本会翻倍。
我常用一份评估前提清单做开场，避免后面比了个寂寞：
| 评估前提 | 我要确认的内容 |
|---|---|
| 任务类型 | 实时对话、RAG、摘要、分类、离线批处理 |
| 模型规模 | 参数量、上下文长度、是否多模态 |
| 流量形态 | 平均 QPS、峰值 QPS、并发会话数 |
| 硬件环境 | GPU 型号、卡数、CPU、边缘设备 |
| 精度与量化 | FP16、INT8、INT4 的可接受范围 |
| 成本边界 | 单请求预算、卡时预算、人力预算 |
| 合规与许可 | 数据驻留、商用许可、分发限制 |
| 团队能力 | 是否具备推理调优和运维经验 |
这份清单不花哨，能省很多返工。性能对比前先对齐前提，开源推荐前先对齐生产约束，后面的工具全景和横向评测才有意义。边界和维度梳理清楚，再看参数表就不容易被带跑。
2. 主流AI模型推理工具全景与适用场景
我在给团队做工具选型的时候，习惯先摊开一张全景图。不是那种官网功能清单拼出来的图，是我自己用过的、踩过坑的、或者看别人在生产里跑稳了的工具。这一章我想按部署形态来分：云端托管、本地与边缘、大模型专用服务加网关编排。三种形态对应三种完全不同的决策逻辑，混着比容易把自己绕进去。
有个做电商的朋友问我，说他们想上AI客服，问我推荐哪个推理工具。我没直接答，先问他数据能不能出公司。他说不能。那云端托管就直接排除了，哪怕它再省事。工具选型不是选最强，是选最不拧巴的那条路。
2.1 云端托管推理服务与商业推理平台的能力特征
云端托管推理服务是我见过上线最快的路径。AWS SageMaker、Azure Machine Learning、Google Vertex AI 这些平台，把模型部署、自动扩缩容、监控、鉴权都打包好了，你点几下就能出一个 endpoint。对没有专职推理运维团队的公司来说，这条路省掉了很多脏活。我自己在几个项目里用过 SageMaker 的实时推理端点，从模型上传到 API 可用，半天能搞定。
商业推理平台是另一类。OpenAI API、Anthropic API、Together AI、Fireworks AI、Replicate 这些，连模型权重都不用你管，按 token 或按调用次数付费。产品团队最喜欢这种，一个 API key 就能接进应用，不用跟 CUDA 版本和显卡驱动较劲。我见过一个初创团队用 Together AI 跑开源模型，两周出 MVP，融资路演都够用了。
这些平台的能力特征很集中：弹性好、上手快、运维外包、按量计费。隐性成本也集中：数据要出域、长期单价不低、模型版本和参数受平台约束、迁移时会有锁定感。财务同学算月度账单的时候会皱眉，法务同学看数据驻留条款的时候会皱眉，工程同学在需要自定义采样逻辑或者特殊量化的时候也会皱眉。
我自己的判断标准是：如果你的场景是标准任务、流量波动大、团队没有推理调优能力，云端托管很合适。如果数据敏感、成本敏感、或者需要深度定制推理链路，这条路会越走越窄。别被“开箱即用”四个字冲昏头，开箱之后能不能改箱，是另一回事。
2.2 本地与边缘推理运行时、通用推理引擎的适用边界
本地推理运行时这两年热闹得很。Ollama 我几乎逢人就提，安装简单、模型拉取方便、自带 API，做原型和内部工具特别顺手。llama.cpp 更底层一些，量化支持好，CPU 和 Apple Silicon 上都能跑，很多边缘盒子和小主机上的方案都是它撑起来的。LM Studio 偏桌面体验，产品经理和设计师也能自己玩起来。
通用推理引擎是另一条线。ONNX Runtime 跨平台、跨框架，模型转换一次能在多种硬件上跑，Windows、Linux、移动端都有覆盖。TensorRT 在 NVIDIA 卡上性能很猛，但转换和调优有门槛。OpenVINO 在 Intel 的 CPU、集成显卡和 VPU 上表现不错，工业边缘场景里常见。这几个工具的共同点是：它们不绑死大模型，图像、语音、传统 NLP 模型都能推。
适用边界我觉得要看三件事。数据能不能出设备，延迟能不能容忍网络往返，运维有没有人盯着。工厂质检、医疗设备、车载语音这类场景，数据不出本地是硬约束，边缘推理运行时几乎是唯一选择。反过来，如果模型很大、更新频繁、流量忽高忽低，本地部署的运维成本会吃掉所有省下来的推理费用。
边缘部署还有一个容易被低估的点：硬件碎片化。你在开发机上跑得好好的量化模型，换到客户现场的某款 ARM 盒子或者老款 Jetson 上，可能直接跑不起来。我一般会建议先在目标硬件上做一轮最小验证，再谈优化。别在 x86 服务器上把性能调优做完了，才发现落地硬件是另一套指令集。
2.3 大模型专用推理服务、推理网关与API编排工具
大模型专用推理服务是我这两年花时间最多的一块。vLLM 靠 PagedAttention 和连续批处理打出了名气，吞吐表现很亮眼，OpenAI 兼容接口也让它接起来省事。Text Generation Inference 是 Hugging Face 那一套，跟 Transformers 生态贴得近，部署体验顺。SGLang 在结构化生成和多轮对话场景里有自己的优化思路。TensorRT-LLM 在 NVIDIA 卡上把性能压得很紧，代价是编译和调优要花功夫。
推理网关和 API 编排工具站在更前面一层。LiteLLM 能把多家模型的接口统一成 OpenAI 格式，做模型路由、成本追踪、限流都方便。Kong AI Gateway、Portkey 这类产品在鉴权、缓存、可观测性上补了不少企业能力。我见过一个团队用 LiteLLM 做多模型 fallback，主模型限流的时候自动切备用模型，业务侧几乎无感。
这三类工具经常被混着问“哪个好”。我的回答是看你在哪一层。你要的是把模型跑起来，看专用推理服务。你要的是把多个模型、多个供应商管起来，看网关和编排。你要的是端到端的应用逻辑，那可能还要往上走到 LangChain 或者 LlamaIndex 那一层。层次分不清，就会拿网关跟推理引擎比吞吐，比出来的结论没有意义。
我自己的组合习惯是：底层用 vLLM 或 TGI 跑开源模型，前面挂一层 LiteLLM 做统一接口和路由，再往上才是业务应用。这个组合不算新鲜，胜在每一层职责清楚，出问题的时候知道该去哪一层查。
2.4 主流工具能力对照与典型业务场景匹配
我把常用工具按部署形态和核心能力拉了一张对照表，不是打分表，是给自己做初筛用的：
| 工具/平台 | 形态 | 强项 | 我什么时候会选它 |
|---|---|---|---|
| SageMaker / Vertex AI | 云端托管 | 全托管、弹性、生态完整 | 团队无推理运维，流量波动大 |
| OpenAI / Together AI | 商业API | 零运维、模型即用 | 快速验证、标准任务、数据可出域 |
| Ollama | 本地运行时 | 安装简单、模型管理方便 | 原型、内部工具、个人开发 |
| llama.cpp | 本地运行时 | 量化好、CPU/边缘友好 | 边缘盒子、离线环境、低配硬件 |
| ONNX Runtime | 通用引擎 | 跨平台、多框架、多硬件 | 非LLM模型、跨端部署 |
| TensorRT-LLM | 专用推理 | NVIDIA卡上性能强 | 有GPU调优能力、追求极致吞吐 |
| vLLM | 专用推理 | 高吞吐、连续批处理、兼容接口 | 自建LLM服务、开源模型托管 |
| TGI | 专用推理 | HF生态、部署顺滑 | Hugging Face模型为主的技术栈 |
| LiteLLM | 推理网关 | 多模型统一接口、路由、成本追踪 | 多供应商、需要fallback和配额管理 |
典型场景匹配我一般这么分。实时对话和客服，首token延迟和P99稳定性优先，云端API或者自建vLLM加网关都行，看数据约束。RAG和知识库问答，吞吐和上下文长度更关键，vLLM、TGI这类专用服务比较合适，检索层另算。离线批处理，成本优先，能排队、能降精度、能用spot实例的方案更划算。
边缘和离线场景，Ollama、llama.cpp、ONNX Runtime各有所长，先看硬件再看模型。多模型路由和成本治理，LiteLLM这类网关能省不少事。我常跟团队说，先把自己的场景写成一句话：谁在用、等多久、数据能不能出去、预算多少。这句话写清楚，上面这张表才有参考价值。写不清楚，表看得再多也是别人的答案。
3. 开源AI模型推理框架推荐与评估
我自己的经验是，开源推理框架这一块最容易被“榜单思维”带偏。看到某个框架吞吐高就冲上去用，结果在自家机器上跑不起来，或者量化之后精度掉得没法看。这一章我想把框架分成三类来讲，再把那些真正影响生产落地的关键特性和评估维度摊开。最后给一份我自己在用的选型清单，外加几个踩过的坑。
3.1 开源推理框架分类：通用引擎、LLM服务框架与编译优化框架
我一般把开源推理框架分成三条线。通用引擎是第一条，ONNX Runtime、OpenVINO、llama.cpp 都属于这一类，它们不绑死大模型，图像、语音、传统 NLP 模型都能推，跨平台能力是核心卖点。ONNX Runtime 我用的最多的是在 Windows 和移动端做模型分发，一次转换多端跑，省了很多重复适配的活。llama.cpp 这两年在大模型上也很能打，但骨子里它还是通用推理的思路，量化格式丰富，CPU 和 Apple Silicon 上跑得稳。
第二条线是 LLM 服务框架。vLLM、Text Generation Inference、SGLang、LMDeploy 这几个，专门为自回归生成做优化，调度策略、KV Cache 管理、批处理都是围绕大模型设计的。我在生产环境里用得最多的是 vLLM，PagedAttention 带来的显存利用率提升很直接，连续批处理让吞吐曲线比朴素批处理好看不少。TGI 跟 Hugging Face 生态贴得紧，部署体验顺滑，模型更新快。SGLang 在结构化输出和多轮对话上有自己的巧思，我做 JSON 约束生成的时候会优先试它。
第三条线是编译优化框架。TensorRT-LLM、TVM、MLC-LLM、OpenXLA 这些，走的是“先把模型编译成目标硬件上的高效算子图”的路子。TensorRT-LLM 在 NVIDIA 卡上性能压得很紧，代价是编译时间和调优门槛。MLC-LLM 走的是跨平台编译路线，手机、浏览器、嵌入式设备都能跑。我自己的判断是，编译优化框架适合对性能和部署体积有极致要求的场景，团队里得有人愿意跟编译报错和算子融合较劲。普通业务团队上来就用编译优化框架，很容易在第一个模型上卡三天。
这三条线的边界不是死的。vLLM 也在接量化、接 speculative decoding，llama.cpp 也在往服务化方向走。分类的意义在于帮你判断“这个框架的主战场在哪”，而不是给每个框架贴死标签。
3.2 推荐框架关键特性：并发调度、KV Cache、量化与分布式推理
我最看重的一个特性是并发调度。朴素批处理是等一整批请求凑齐再一起推，短请求被长请求拖住，GPU 利用率上不去。连续批处理是来一个请求就塞进当前批次，跑完一个补一个，vLLM、TGI、SGLang 都支持。我在一个客服场景里做过对比，同样一张 A100，连续批处理把吞吐拉高了接近三倍，P99 延迟反而更稳。这个特性对在线服务几乎是必选项，离线批处理可以放宽。
KV Cache 管理是第二个分水岭。传统做法是给每个请求预分配一大块连续显存，长度估不准就浪费，估少了就 OOM。PagedAttention 把 KV Cache 切成固定大小的块，按需分配，显存碎片问题缓解了很多。vLLM 靠这个打出了名声，TGI 后面也跟进了类似的分页思路。我在做长上下文场景的时候会特别关注框架有没有 prefix caching，多轮对话和 RAG 里相同的前缀能复用缓存，首 token 延迟能降一截。
量化支持是第三个硬指标。GPTQ、AWQ、GGUF、FP8 这几个格式，不同框架的支持程度差别很大。llama.cpp 在 GGUF 上最成熟，CPU 和低配 GPU 上跑量化模型很实用。vLLM 对 AWQ 和 GPTQ 的支持比较完整，FP8 在 Hopper 卡上也能开。我一般会先确认目标框架支持哪几种量化格式，再倒推模型转换流程。量化不是免费的午餐，4bit 量化在数学推理和代码生成上掉点的情况我见过不少，上线前得用自己的评测集跑一轮。
分布式推理这块，单卡放不下的模型就得靠张量并行或者流水线并行。vLLM 的张量并行配置比较直接，TGI 也支持多卡分片。我自己的经验是，张量并行在单机多卡上通信开销可控，跨机就要看网络了。小团队没有高速互联的时候，跨机张量并行的收益经常被通信吃掉。分布式推理的调优复杂度比单卡高一个量级，选框架的时候要看清它的并行策略文档写没写清楚。
3.3 社区活跃度、许可协议、文档完备性与生产可用性评估
社区活跃度我一般看三个地方。GitHub 的 issue 响应速度、版本发布频率、以及有没有稳定的维护团队。vLLM 和 TGI 这两个在这三项上表现都不错，issue 里能看到 maintainer 经常回，release 节奏也稳。llama.cpp 的社区更偏草根，PR 多、迭代快，但有些边角问题的修复要看运气。我会特别翻一下最近三个月的 commit 记录，如果一个大框架三个月没什么动静，生产选型的时候我会打个问号。
许可协议这一块容易被忽略，踩坑的人不少。Apache 2.0 和 MIT 是最省心的，商用、修改、分发都没什么额外约束。AGPL 就要小心，网络服务场景下可能触发开源义务。BSL 这类商业源码许可有时间和用途限制，法务同事得提前看。我见过一个团队把 AGPL 协议的推理框架嵌进闭源产品，后来被要求整改，返工成本很高。选型清单里我永远会给许可协议留一栏，不填完不往下走。
文档完备性和生产可用性我放在一起看。文档不光看有没有 quickstart，要看有没有部署拓扑示例、显存估算指南、监控指标说明、故障排查章节。vLLM 的文档这两年补得比较全，TGI 的部署文档也清楚。生产可用性还包括多租户隔离、鉴权、限流、可观测性这些工程能力，很多开源框架在这块是空白，得靠外面的网关和监控系统补。我自己的做法是，框架负责推理，网关负责治理，监控负责兜底，三层各干各的活。
还有一个隐性指标是升级成本。开源框架版本迭代快，API 和行为都可能变。我会看它的 changelog 写得细不细，breaking change 有没有迁移指南。一个框架如果每次升级都要重写部署脚本，生产环境里没人敢跟。
3.4 开源AI模型推理框架选型清单与常见避坑要点
我自己的选型清单大概长这样。模型格式支持要覆盖团队在用的格式，GGUF、AWQ、GPTQ、FP8 至少中一个。硬件后端要覆盖目标部署环境，NVIDIA、AMD、Intel、ARM 得对得上。并发调度要看有没有连续批处理，KV Cache 要看有没有分页或前缀缓存。量化支持要看格式和精度损失情况。分布式推理要看并行策略和通信要求。许可协议要能过法务。社区活跃度要看最近三个月的 commit 和 issue 响应。文档要看部署、调优、监控、排障四块齐不齐。生产可用性要看多租户、鉴权、可观测性有没有现成方案。
避坑要点我列几个自己踩过的。第一个坑是拿 Ollama 当生产服务用。Ollama 做原型和内部工具很舒服，并发调度和显存管理不是它的强项，流量一上来延迟曲线就很难看。第二个坑是量化之后不重新评测。4bit 量化在通用对话上看着还行，在代码生成和数学推理上掉点很明显，得用自己的测试集验。第三个坑是 KV Cache 显存估算拍脑袋。长上下文加高并发的时候，KV Cache 占的显存可能比模型权重还大，框架文档里的估算公式要认真套一遍。
第四个坑是多卡张量并行不看网络。单机 NVLink 和跨机以太网的通信带宽差一个数量级，跨机张量并行的加速比经常让人失望。第五个坑是忽视框架的 breaking change。生产环境锁版本，升级前在 staging 环境跑一轮压测，这个习惯能省很多半夜排障的时间。第六个坑是许可协议没提前看，AGPL 和 BSL 混进闭源产品，后面整改很麻烦。
我常跟团队说，开源推理框架没有“最好”，只有“当前场景下最不拧巴”。把模型格式、硬件、并发量、延迟要求、团队调优能力这五件事写清楚，清单上的选项会自己收敛。写不清楚，看再多推荐文也是别人的答案。
4. AI模型推理工具性能对比方法与指标体系
性能对比这件事，我自己吃过不少亏。早些年看厂商发的 benchmark 图，绿色柱子比蓝色柱子高一截，脑子一热就选了，部署到线上才发现那个测试用的是理想输入长度、单请求、预热充分的环境，跟我这边真实流量完全不搭。这一章我想把做性能对比的整套方法掰开讲，从测试怎么设计到指标怎么看，再到哪些坑我亲自踩过。不是说看完就能变成评测专家，至少能让你在选型会上少被几张漂亮图表忽悠。
4.1 基准测试设计：数据集、输入输出长度、并发模型与硬件环境
测试数据集这块，我现在的原则是“别拿别人的考卷答自己的题”。公开的 benchmark 像 ShareGPT、Alpaca 这些数据集能用，它们只能告诉你框架在通用对话上的大致水平。真要做选型决策，我会从自己业务日志里抽几百条真实请求，把输入长度分布、输出长度分布、多轮比例都保留下来。有个做法律问答的团队找我帮忙看推理工具，他们一开始用通用数据集测，vLLM 和 TGI 差距不大，换成自家合同问答数据之后，长输入短输出的场景下差距一下子拉开了。数据集不对，后面所有对比都是空中楼阁。
输入输出长度的处理比很多人想的要细。平均值是最坑人的统计量。我自己做测试的时候会把输入长度切成几个桶：短输入（128 token 以内）、中输入（128 到 1024）、长输入（1024 到 8192）、超长输入（8192 以上），每个桶单独看指标。输出长度也一样，生成 50 token 和生成 2000 token 对框架的调度压力完全不同。还有输入输出比例，RAG 场景是长进短出，创作场景是短进长出，代码补全是中进中出，这几种模式混在一起测，出来的数字没法解释。我一般会让测试集里每种模式都有足够样本，报告里分模式列指标，别揉成一个总数。
并发模型是设计里最容易被简化的一环。我见过太多测试就用固定并发数跑，比如固定 32 并发压五分钟，得出一个吞吐数字。这种测试对容量规划有点用，对真实服务模拟很差。真实流量是泊松到达的，请求之间有间隔，批处理框架的连续批处理能力在这种到达模式下才能体现出来。我现在会准备两套并发模型：一套是固定并发，用来测框架的性能上限和稳定性；一套是开放环模型，按目标 QPS 打请求，看延迟分布和排队情况。固定并发测出来吞吐高，开放环一压 P99 就爆的框架，在线服务里我不敢用。压力测试工具用 Locust 或者 k6 都行，关键是请求到达时间要能控制，别用那种一口气发完的脚本。
硬件环境这块，我的要求是“写清楚、控变量、看隔离”。写清楚是指报告里要标明 GPU 型号、显存大小、CPU 核数、内存、驱动版本、CUDA 版本、框架版本，少一项这个测试就没法复现。控变量是指对比两个框架的时候，除了框架本身，其他条件尽量拉齐，量化格式、batch size 上限、并发数、模型版本都得一致。看隔离是指多卡机器上要确认测试进程独占资源，别跟别的任务抢 GPU。我有一次在共享机器上做对比，A 框架跑的时候隔壁在训练，数据偏了一大截，白折腾两天。温度功耗我也会顺手看一眼，长时间压测降频的情况真实存在，短时间跑分看不出来。
4.2 核心性能指标：TTFT、TPOT、吞吐、P99延迟与显存占用
TTFT 是我现在看在线服务的第一指标，全称是 Time To First Token，从请求发出去到收到第一个输出 token 的时间。聊天、搜索摘要、实时翻译这些场景，用户对首字延迟极其敏感，首字不出来用户就觉得卡。TTFT 受输入长度影响很大，prefill 阶段要把整个 prompt 过一遍，输入越长 TTFT 越高。我做对比的时候会分输入长度桶看 TTFT，长输入场景下不同框架的差距能到两三倍。prefix caching 对这种场景帮助明显，相同前缀的请求能跳过重复 prefill，TTFT 能降一大截。
TPOT 是 Time Per Output Token，每个输出 token 的平均生成时间，有时候也叫 inter-token latency。这个指标决定用户看到的“打字速度”。人眼对流畅输出的感知大概在每秒 20 到 30 个 token 以上就比较舒服了，低于每秒 10 个 token 会有明显的卡顿感。TPOT 跟批大小关系很大，批越大单请求的 TPOT 越高，因为 GPU 要同时伺候更多请求。我一般会看不同并发下的 TPOT 曲线，找一个吞吐和单请求速度的平衡点。有些框架在低并发下 TPOT 很好看，并发一上来就崩，这种曲线比单个数字有信息量得多。
吞吐要拆成两个口径看：tokens per second 和 requests per second。前者反映 GPU 的计算利用率，后者反映服务的请求处理能力。两个口径在不同场景下的重要性不一样，离线批处理看重 tokens/s，API 服务看重 requests/s。我见过报告里只写 tokens/s 不写请求特征的，短输出场景下 tokens/s 很高但 requests/s 很低，拿来对比长输出场景就是关公战秦琼。吞吐还分总吞吐和单请求吞吐，总吞吐高可能是靠堆批大小换来的，单请求体验未必好。报告里这两个数我都会要。
P99 延迟是我判定一个框架能不能上生产的关键。平均延迟和 P50 延迟都会骗人，用户投诉的永远是那 1% 的慢请求。P99 延迟反映的是排队、调度、显存碎片、GC 这些长尾因素的综合结果。我做过一个对比，两个框架平均延迟只差 15%，P99 差了将近一倍，原因是一个框架的调度队列在高负载下会出现请求饥饿。看 P99 的时候我会连着 P95、P999 一起看，画延迟分布曲线，比看单个分位数直观。压测时间也要够长，短时间压测抓不到长尾，我一般至少压 15 到 30 分钟，让排队和内存回收的效应充分暴露。
显存占用这个指标经常被低估。模型权重只是显存的一部分，KV Cache、激活值、框架自身的开销都要算进去。我会记录三个数：空载显存、稳定压测时的峰值显存、以及 KV Cache 占的总比例。峰值显存决定了你能开多大并发、能支持多长上下文。有些框架显存管理激进，利用率高但峰值波动大，OOM 风险高；有些框架保守，留的余量大，能开的并发就少。这两个取向没有绝对好坏，得结合你的 SLA 和运维能力选。我还会看显存随并发增长的曲线斜率，斜率陡的框架在扩并发的时候要更小心。
4.3 不同模型规模与硬件平台下的横向对比方法
模型规模这个维度，我的经验是“别拿小模型的结论套大模型”。7B 模型上 vLLM 和 TGI 的差距可能只有 10%，到 70B 模型上差距可能变成 50%，因为大模型对 KV Cache 管理和张量并行的依赖高得多。我一般会按参数量分档：小模型（7B 以下）、中模型（7B 到 30B）、大模型（30B 以上），每档挑一两个代表模型做测试。同一个框架在不同档位上的表现可能反转，小模型上调度开销占比高，大模型上显存和通信是瓶颈，优化重点完全不一样。MoE 模型又是另一套逻辑，激活参数少但显存占用大，测试的时候要单独拉出来看。
量化格式必须作为对比的固定变量。我见过有人拿 A 框架的 FP16 跟 B 框架的 4bit 量化比吞吐，得出 B 快三倍的结论，这种对比没有意义。正确做法是同一量化精度下比框架，或者同一框架下比量化精度的影响。我自己的测试矩阵一般是：每个框架跑 FP16、AWQ 4bit、GPTQ 4bit 三档（框架支持的格式），记录吞吐、延迟、显存、以及在自己的评测集上的精度损失。精度这一项很多人省了，我觉得不能省，4bit 量化在代码生成和数学推理上掉 5 到 10 个点的情况我见过不止一次。
硬件平台的横向对比，核心是控制网络和互联条件。单卡对比最干净，同型号卡、同驱动、同 CUDA 版本，结论最可信。多卡对比就复杂了，单机 NVLink、单机 PCIe、跨机以太网、跨机 InfiniBand，这几种互联条件下张量并行的效率差好几倍。我做多卡对比的时候会把互联拓扑写进报告，跨机测试会标注网络带宽和延迟。有个客户拿跨机以太网环境问我为什么张量并行加速比只有 1.3，我一看他的网络是 10Gbps 以太网，换成 NVLink 单机立刻到 2.8。硬件条件不同，框架的并行策略优劣也会变，没有一个放之四海的结论。
CPU 和边缘设备这块，对比方法要换一套。桌面 CPU 上 llama.cpp 的 GGUF 量化跑得很稳，ONNX Runtime 在 ARM 上优化不错，这些结论跟 GPU 服务器上的排名完全是两个世界。我做边缘对比的时候会额外看内存带宽占用、功耗、冷启动时间。冷启动对边缘部署很关键，模型加载加预热可能要几十秒，这个时间用户等不起。浏览器端跑 MLC-LLM 这类方案，还要看 WebGPU 兼容性和首次加载体积。这些指标在 GPU 服务器的 benchmark 里根本不会出现，得单独建一套评测方法。
4.4 性能对比报告解读、复现实验与常见评测误区
看别人的性能报告，我第一件事是找“测试条件”那一节。找不到输入输出长度分布、并发模型、硬件配置、量化格式的报告，我基本只当参考，不当决策依据。厂商发的 benchmark 有个常见套路：挑对自己有利的配置，比如固定批大小、超长预热、理想输入长度。这些配置不一定是假的，只是离真实场景远。我会特别留意报告里有没有说明“为什么选这个配置”，说不清楚的，数字再漂亮也打个折扣。还有一类报告只给柱状图不给原始数据，这种没法复现，也没法算置信区间，参考价值有限。
复现实验是我现在做选型的必做环节。看中两三个候选框架之后，我会在自己的机器上搭一套最小可复现的测试环境：固定模型版本、固定量化文件、固定测试集、固定压测脚本，跑三轮取中位数。复现的时候最容易出问题的地方是版本漂移，框架版本、CUDA 版本、驱动版本、甚至 Python 依赖版本都可能影响结果。我一般会用容器把环境锁死，测试脚本和配置文件一起存档，过一个月再跑还能对得上。复现不出来的报告，我不会拿来支撑采购决策，哪怕它是顶会论文。
评测误区我列几个自己踩过或者见别人踩过的。第一个是忽略预热，框架第一次跑要编译算子、加载权重、初始化显存池，头几十个请求的延迟完全不能代表稳态。我的做法是压测前先跑足够多的预热请求，确认指标曲线走平了再开始记录。第二个是只看吞吐不看延迟分布，吞吐高但 P99 爆炸的框架，在线服务里是灾难。第三个是拿单请求延迟当服务延迟，单请求测试环境干净，线上有排队有竞争，两者能差一个数量级。
第四个误区是忽略输出质量的变化。量化、蒸馏、编译优化都可能改变模型输出，评测的时候只看速度不看质量，上线之后胡言乱语率上升才发现。我一般会在压测的同时跑一个小规模的质量评测集，对比输出的一致性和准确率。第五个误区是测试集和业务数据分布不一致，前面说过了，这里再强调一次，公开数据集的结论只能当起点。第六个误区是不记录测试环境的“噪声源”，共享 GPU、后台任务、网络抖动这些因素会让结果不可复现。我的习惯是测试期间用 nvidia-smi 定期采样，记录利用率和温度，出异常波动的时候能回溯。
最后说一句报告怎么写。我自己的性能对比报告会分三块：测试条件（硬件、软件、数据、并发模型全部写清）、分场景指标（按输入输出长度和并发档位分列）、结论与限制（明确说清这套结论适用于什么场景、不适用于什么场景）。限制那一节我写得比结论还认真，因为我知道下一个看报告的人很可能拿着结论去套一个完全不同的场景。性能对比的价值不在于给出一个排名，在于让人理解“在什么条件下谁更好”，条件写不清楚，排名就是误导。
5. 推理工具部署优化与工程实践
部署优化这件事，跟前面聊的选型和评测完全不是一个画风。评测阶段可以关起门来跑分，部署上线之后每一点优化都得对真实流量负责。我自己带团队做推理服务这几年，踩过的坑比踩过的油门多，这一章就把量化、编译、批处理、扩缩容这些工程实践里的门道摊开讲。有些经验是花钱买的，有些是凌晨三点被报警叫起来学会的，都挺贵的，写出来希望你能少付点学费。
5.1 量化、蒸馏与编译优化对推理性能的实际影响
量化是第一把刀，也是最容易上手的一把。我最早接触量化是在一个显存吃紧的项目上，70B 模型 FP16 要 140G 显存，两张 A100 80G 都紧张，换成 GPTQ 4bit 之后一张卡就能跑，显存直接砍到 40G 左右。速度上的提升没有数字看起来那么线性，我的实测经验是 4bit 量化在低并发下 TTFT 能快 1.5 到 2 倍，吞吐提升大概 1.3 到 1.8 倍，具体多少跟模型结构、batch size、框架实现都有关系。AWQ 和 GPTQ 我都在生产里用过，AWQ 对激活值分布的处理更细一些，在指令跟随类任务上精度保持好一点，GPTQ 生态更成熟，工具链兼容性好。选哪个别光看论文里的 perplexity 数字，拿自己的评测集跑一轮再定。
精度损失这件事必须认真对待。我在一个代码补全项目上做过对比，4bit 量化之后 HumanEval 通过率掉了 6 个点，这个数字在 demo 里看不出来，上线之后用户抱怨补全质量下降才发现。后来我们的做法是分场景定精度底线，代码生成和数学推理这类任务只允许 8bit 量化或者 AWQ 4bit 加更严格的校准集，闲聊和摘要类任务 4bit 可以放宽。GGUF 格式在 llama.cpp 生态里用得很多，Q4_K_M 这种混合量化在 CPU 和边缘设备上表现不错，部署到 Mac 或者 ARM 服务器上我经常选它。量化不是免费的午餐，省下来的显存和算力，多多少少要从输出质量里扣，关键是搞清楚你的业务能承受多少扣减。
蒸馏这条路我走得更谨慎。用大模型教小模型，理论上能在保持大部分能力的前提下把参数量降一个数量级，部署成本降得非常可观。实际操作里蒸馏出来的模型在垂直任务上效果可以，通用能力会有明显短板。我见过一个团队用 70B 蒸馏出 7B 做客服问答，垂直场景准确率能到原模型的九成，换成开放式闲聊就露馅了。蒸馏适合场景收敛、任务明确的业务，比如意图分类、信息抽取、固定模板生成。你要是做一个通用助手，蒸馏模型撑不起场面，别在这上面省 GPU 钱。
编译优化是第三把刀，也是门槛最高的一把。TensorRT-LLM 在 NVIDIA 卡上的性能确实能打，我做过一个对比，同样 13B 模型、同样 A10 卡，TensorRT-LLM 比原生 PyTorch 推理吞吐高了将近一倍，TTFT 也明显低。代价是编译时间长、模型转换麻烦、动态 shape 支持有限，改一次模型或者换一个输入长度范围就要重新构建 engine。ONNX Runtime 的图优化和算子融合对中小模型效果不错，跨平台兼容性好，部署到 CPU 和边缘设备上我经常用它。torch.compile 这两年在 PyTorch 生态里进步很快，一行代码就能开，适合快速验证，生产环境里稳定性还要看具体版本。编译优化有个共同问题：冷启动。TensorRT engine 加载要几十秒，ONNX 首次推理要编译算子，这些时间对弹性扩缩容是硬伤，后面讲扩缩容的时候还得提。
这三项技术经常要组合用。我现在的典型配置是：模型先做 AWQ 4bit 量化，再用 TensorRT-LLM 编译，部署在 A10 或者 L20 上。量化降显存，编译提算子效率，两个叠加的收益不是简单相加，有时候编译优化在低精度下的收益会打折扣，得实测。有个做视频内容审核的客户，输入是长视频字幕，输出是短标签，他们的场景里编译优化的收益比量化还大，因为瓶颈在 prefill 阶段的算子效率。场景不同，哪把刀更锋利也不一样，别照搬别人的方案。
5.2 批处理、连续批处理与KV Cache调优策略
批处理这件事，静态和动态要分开说。静态批处理是把一批请求攒齐了一起送进 GPU，等整批跑完再返回。做法简单，吞吐也还行，缺点是短请求要等长请求，尾延迟很难看。我早期做离线批量摘要任务就用静态批处理，反正不着急，攒够 64 条跑一轮，GPU 利用率能到八成以上。在线服务不能用这套逻辑，用户不会等你的批攒满。连续批处理（continuous batching）或者叫 in-flight batching，是现在主流推理框架的标配，vLLM、TGI、TensorRT-LLM 都支持。它的思路是每生成一个 token 就检查一次，有请求完成就立刻把排队的请求塞进来，GPU 几乎不停转。TTFT 和 P99 延迟在这种模式下能压得很低。
批大小的调优是个精细活。批开大，吞吐上去，单请求的 TPOT 下来，P99 延迟上去。批开小，延迟好看，GPU 利用率上不去，单位成本下不来。我一般的做法是画一条曲线：横轴是并发请求数，纵轴是吞吐和 P99 延迟两个值，找一个 P99 还在 SLA 以内、吞吐接近拐点的位置作为目标批大小。这个拐点跟模型大小、显存、请求长度分布都有关，换个模型或者换个场景就得重测。还有一个坑是批大小上限设得太死，流量突发的时候请求全堆在队列里，P99 直接爆表；设得太松，显存 OOM 一次能搞挂整个服务。我的经验是给显存留 15% 到 20% 的余量，批大小上限按峰值流量的 1.5 倍配，同时开好排队超时和降级策略。
KV Cache 的调优是被低估的一块。PagedAttention 出来之后，KV Cache 的显存碎片问题缓解了很多，vLLM 靠这个在长上下文场景里比早期方案省了三四成显存。我现在的调优清单里有几项必看：block size 设多大，prefix caching 开不开，KV Cache 量化用不用。block size 默认 16 在多数场景够用，遇到超长上下文（32K 以上）我会试试 32 或者 64，减少块表管理的开销。prefix caching 对系统提示词很长的场景收益巨大，比如 RAG 或者带固定人设的客服机器人，相同前缀的 prefill 结果直接复用，TTFT 能降一半以上。KV Cache 量化到 FP8 或者 INT8 能再省一半显存，精度影响比对模型权重量化小很多，我现在的项目里基本默认开。
有个细节很多人忽略：KV Cache 的回收和抢占策略。高并发下显存不够用的时候，框架要么拒绝新请求，要么把已有请求的 KV Cache 换出到 CPU 内存，要么直接抢占丢弃。不同框架的处理方式不一样，vLLM 有 swap 和 recompute 两种模式，TGI 有自己的调度逻辑。这个策略直接影响高负载下的延迟分布，swap 模式能保住请求但延迟会抖，recompute 模式延迟可控但浪费算力。我会在压测的时候专门看高负载下的请求成功率和不成功率的原因分布，调度策略不合适的框架，流量一冲就现原形。
连续批处理和 KV Cache 是搭配着调的。批越大，KV Cache 占用越高，显存越紧张，能开的并发反而受限。我遇到过一个配置陷阱：把 max_num_seqs 开到 256，结果 KV Cache 把显存吃满，新请求进不来，吞吐反而比 128 的时候低。调参的时候要盯着两个数一起看：GPU 利用率和 KV Cache 占用率。利用率上去了但 KV Cache 占用长期在九成以上，说明瓶颈在显存不在算力，这时候加卡或者降精度比调批大小更管用。
5.3 多模型服务、弹性扩缩容、监控告警与可观测性建设
多模型服务这块，组织方式的选择比技术选型还重要。我见过两种典型做法：一种是一个模型一个独立服务，每个服务有自己的进程、端口、扩缩容策略；另一种是一个推理服务里挂多个模型，按请求路由。前者隔离性好，一个模型出问题不拖累别的，资源浪费也明显，每个服务都要留冗余。后者资源利用率高，但模型之间抢显存、抢算力，调度复杂度上一个台阶。我现在的倾向是核心大模型独立部署，小模型和辅助模型（embedding、rerank、分类）共享一个服务池，用推理网关做路由。vLLM 的多 LoRA 支持在这种场景下很实用，一个基座模型挂多个 LoRA 适配器，既省显存又保持隔离。
弹性扩缩容的难点在冷启动。GPU 推理服务的冷启动时间跟模型大小、量化格式、编译方式强相关。7B 模型从容器拉起、加载权重、预热到能接流量，快的话三十秒，慢的话两三分钟。TensorRT 编译过的模型加载更慢，因为要反序列化 engine。这个时间窗口里流量怎么办，得有预案：预热池保底，缩容的时候留最小副本数，扩容触发阈值设得激进一点提前量留足。我用 K8s 做推理服务编排的时候，HPA 的指标不只看 CPU 和 GPU 利用率，还会看请求队列深度和 TTFT 的 P95。队列深度先涨、延迟后涨，看队列能提前几十秒触发扩容，这几十秒在流量尖峰里很关键。
缩容比扩容更容易出事。缩容触发太快，副本刚杀掉流量又回来了，反复震荡；缩容太慢，闲时 GPU 空转烧钱。我的做法是扩容用快策略，缩容用慢策略，缩容前先确认队列深度和延迟指标持续一段时间低位，冷却时间设十五分钟以上。还有个细节是优雅退出，副本收到终止信号之后先把新请求摘掉，等在处理的请求跑完再退出，不然用户会收到一批莫名其妙的报错。这个配置在 K8s 里就是 preStop hook 加 terminationGracePeriodSeconds，设短了等于没设。
监控告警和可观测性是运维的地基。我现在的监控体系分三层：基础设施层看 GPU 利用率、显存、温度、功耗、网络；推理服务层看 QPS、TTFT、TPOT、P99 延迟、请求成功率、队列深度、KV Cache 占用率；业务层看端到端响应时间、用户侧错误率、token 消耗量。三层指标要能串起来看，用户投诉慢的时候，先看业务层哪个接口慢，再看推理服务层是队列堆积还是单请求 TPOT 高，最后看基础设施层是不是 GPU 降频或者显存碎片。链路追踪我用 OpenTelemetry 把请求 ID 打穿整个链路，推理框架的指标用 Prometheus 暴露，Grafana 做面板。告警规则别设太多，我见过一个团队配了两百条告警规则，天天响，最后没人看。我会把告警分 P0 和 P1，P0 只留几条：服务不可用、错误率超阈值、P99 延迟超 SLA、GPU 显存超九成。P1 走日报，不半夜叫人。
日志这块我吃过亏。推理服务的日志量很大，每个请求的输入输出都记的话，存储成本和隐私风险都扛不住。我现在的做法是请求级日志只记元数据：请求 ID、模型名、输入输出 token 数、延迟分阶段耗时、状态码。输入输出内容默认不落盘，排查问题的时候按请求 ID 临时开启采样。这个策略既满足可观测性需求，又规避了合规风险，后面讲安全合规还会提到。
5.4 成本、稳定性、安全合规与运维复杂度的工程权衡
成本这件事要算总账，不能只看 GPU 单价。自建 GPU 集群的账本里包括：硬件采购或者租赁、机房电费、网络带宽、运维人力、闲置冗余。云上按需实例单价高，弹性好；预留实例单价低，灵活性差；竞价实例最便宜，随时可能被回收。我做过一个三年期的 TCO 对比，中等规模（峰值 20 张 A10 卡）的场景下，自建加预留混合的成本比纯按需云低四成左右，比纯自建高一层运维复杂度。小规模场景（峰值 4 张卡以内）我一般建议先用云，把流量模型和成本曲线摸清楚再说。省钱的另一个维度是提高利用率，推理服务的 GPU 利用率能到六成以上算健康，长期低于三成就要考虑缩容或者合并服务。
稳定性的投入要跟业务等级挂钩。核心交易链路上的推理服务，我会做多副本跨可用区部署、健康检查自动摘除、降级预案（模型降级到小模型或者规则兜底）、容量预留至少 30%。非核心的离线任务，可以容忍偶尔失败，重试逻辑做好就行。这里有个常见误区是追求百分之百可用，成本会指数级上升，业务收益却很有限。我一般跟业务方一起定 SLA：核心接口 P99 延迟 500ms 以内，可用性 99.9%，非核心接口 99% 就行。SLA 定了之后，容量规划、告警阈值、应急预案都围绕它来配，不搞一刀切。
安全合规在推理服务里是硬约束，尤其是金融、医疗、政务这些行业。几个必须做的点：数据不出域，模型推理的输入输出不能流到境外节点，部署区域的选型要提前确认；访问控制，推理 API 要鉴权、限流、审计，内部调用也不能裸奔；内容安全，输出侧要接敏感词和有害内容过滤，尤其是面向 C 端的生成类应用；模型和数据的许可合规，开源模型的许可证条款要审清楚，商用限制、再分发限制、训练数据来源这些都要过法务。我做金融客户项目的时候，推理日志的保留期限、加密方式、访问审计都有明确要求，这些在架构设计阶段就要排进去，别等上线前再补，补不动。
运维复杂度是隐形成本，容易被低估。推理工具链的组件很多：框架本身、推理网关、模型仓库、监控系统、日志系统、编排系统。每多一个组件，就多一套部署模板、多一套升级流程、多一类故障模式。我见过团队为了追性能上了一个很复杂的方案，结果一年里三分之一的运维时间花在维护这套推理基础设施本身，业务迭代反而慢了。我的取舍原则是：性能收益超过三成、或者成本节省超过四成，才值得引入新组件，否则优先把现有方案调优。易用性也是运维成本的一部分，文档全不全、社区活不活跃、出问题能不能搜到答案，这些软指标在长期运维里的权重比 benchmark 分数高。
这四项权衡经常互相打架。量化降成本但影响质量，影响合规审核；多副本保稳定但增加成本；弹性扩缩容省成本但增加冷启动风险；上编译优化提性能但增加运维复杂度。没有一套通用最优解，得结合业务阶段来定。我自己的决策顺序是：先定合规底线和 SLA，这是硬约束；再算成本预算，确定资源上限；然后在这个框架里选稳定性和复杂度平衡的方案；最后才是抠性能细节。反过来先追性能、再补合规和成本的团队，我见过好几个，返工代价都不小。
部署优化这件事，说到底是工程判断力的问题。工具和参数都在那里，文档也都能查到，真正难的是知道在你的场景里哪个指标优先、哪个妥协可以接受。我现在的习惯是每次上新的优化手段之前，先写清楚预期收益、验证方法、回滚方案，跑一轮 A/B 对比再全量。这套流程看起来慢，实际上省掉了很多拍脑袋决策带来的返工。推理服务的优化没有终点，模型在换、流量在变、硬件在迭代，保持一套可度量、可回滚的迭代机制，比追求某个静态的最优配置重要得多。
6. 场景化选型与AI模型推理工具发展趋势
选型这件事，前五章把该铺的地基都铺得差不多了。工具清单有了，评测方法有了，部署优化的坑也踩过一遍。这一章我想聊点更“前面”的事——你手里拿着这些工具，到底怎么根据业务场景做选择。还有个绕不开的话题，推理工具这个领域半年一小变、一年一大变，今年选的东西明年还合不合适，得有个自己的判断框架。我见过太多团队照着网上的评测文章选型，结果跑自己业务上水土不服，返工成本高得吓人。
6.1 实时交互、离线批处理与边缘推理的场景化选型建议
实时交互场景的选型逻辑跟离线完全是两套思路。实时交互的核心矛盾是延迟，用户在那头盯着屏幕，你的P99延迟多三百毫秒他就能感觉到卡顿。这种场景下我会把TTFT和TPOT放在第一优先级，吞吐和成本反而往后排。框架选型上，vLLM和TGI这类支持连续批处理的LLM服务框架是标配，TensorRT-LLM在NVIDIA卡上能把单请求延迟压得更低，代价是编译流程麻烦。有个做AI写作助手的客户，他们要求首 token 延迟在 400ms 以内，我最后选了TensorRT-LLM加FP8量化，A10卡上跑13B模型，TTFT能稳在350ms左右。vLLM在他们场景下TTFT要五百多毫秒，差了这一百多毫秒用户体感就是流畅和卡顿的区别。
实时交互还有个容易被忽略的点：请求长度分布。聊天类应用的输入输出长度波动很大，短的一二十个token，长的可能几千。这种场景要特别关注框架对变长请求的处理能力，PagedAttention这类机制能不能把显存碎片控制住。我压测过一个客服机器人，平均输入长度800 token，但P95能到3000多，早期没开prefix caching的时候长请求一多KV Cache就爆，延迟曲线惨不忍睹。后来开了prefix caching加上块大小调到32，长请求的TTFT降了将近一半。实时场景选型，光看benchmark里的平均指标没用，得拿自己业务的长度分布去压。
离线批处理是另一个极端。没有用户在那等着，延迟指标可以完全放松，转换成了吞吐和单位成本。这种场景我反而不太在意框架的实时性能，看的是批处理效率、断点续跑能力和大规模任务的调度能力。做视频字幕摘要那类任务，我经常用静态批处理配合大batch size，GPU利用率能拉到八成五以上。框架选型上，HuggingFace的Text Generation Inference在离线批量场景里我就够用了，没必要上TensorRT-LLM那套复杂的编译流程。有时候甚至直接用PyTorch写个循环跑，加上torch.compile，简单直接，运维成本还低。离线场景别追求那些花里胡哨的推理框架，稳定跑完任务、失败能重试、资源能跑满，比什么特性都实在。
边缘推理选型的约束条件最多。算力有限、内存有限、功耗有限，有时候连散热都是问题。这种场景下模型量化和框架的轻量化是生死线。llama.cpp配合GGUF格式是我用得最多的组合，Q4_K_M混合量化下7B模型在ARM设备上能跑到十几token每秒，够很多场景用了。ONNX Runtime在边缘侧也很能打，跨平台支持好，CPU上做算子优化有积累。MNN和TFLite在移动端生态成熟，但大模型支持这两年才跟上，成熟度还差一点。我做过一个工业质检的项目，推理跑在工控机上，没有独立显卡，最后选了ONNX Runtime加INT8量化，单张图片推理延迟控制在80ms以内，产线节拍跟得上。边缘场景选型的第一原则是：先确认硬件能跑起来，再谈性能优化，别选了个框架结果芯片不支持，那就尴尬了。
还有个混合场景值得提一下。很多企业的实际业务不是纯粹的实时或者离线，而是实时交互为主、离线批处理为辅。比如在线客服系统，白天实时问答，晚上跑对话质量分析和摘要归档。这种场景我会做双路部署：实时路径用vLLM或者TensorRT-LLM做低延迟服务，离线路径复用同一套模型权重，用不同的服务配置跑批量任务。模型仓库统一管理，推理网关做路由，资源和运维开销能摊薄。别为两个场景各维护一套完全独立的技术栈，长期看运维成本会吃掉所有省下来的GPU钱。
6.2 企业落地路径：POC验证、压力测试、灰度发布与规模化推广
企业里上一个新的推理工具，流程比个人开发者复杂得多。我参与过的项目里，失败率最高的环节往往不是技术选型本身，而是落地路径没设计好。上来就全量上线的团队我见过几个，结果流量一冲各种问题冒出来，回滚都回不利索。比较稳妥的路径我总结成四步：POC、压测、灰度、推广，每一步的验收标准和退出机制都得提前定好。
POC阶段的核心目标不是跑出最高性能数字，是验证可行性。我一般会挑两到三个候选框架，用真实业务数据各跑一轮最小闭环。数据这块很多人偷懒用公开数据集，效果看起来很好，上线之后发现业务数据分布完全不一样。我做一个法律合同审核的项目，POC阶段用通用问答数据集测出来vLLM和TGI效果差不多，换成真实合同文本之后，长文档截断和特殊符号处理的问题全暴露出来了，TGI的tokenizer实现跟业务侧预处理有冲突，最后POC阶段就把TGI排除了。POC的验收标准我一般定三条：典型业务请求能正常返回、输出质量主观可接受、关键指标（延迟或吞吐）达到业务底线。三条都过才进下一步，缺一条就换候选或者调配置。
压力测试是POC和灰度之间的必经环节，也是最多团队做得敷衍的环节。压测不是拿ab或者wrk跑个QPS数字就完事，得模拟真实流量特征。请求长度分布、并发模式、突发尖峰、长尾请求，这些都要复现。我现在的压测方案一般会录一段生产环境的真实请求做回放，同时叠加阶梯式并发增长，从正常流量的0.5倍一路压到2倍，看各个负载点的TTFT、P99延迟、错误率和显存占用。压测里最容易暴露问题的是尖峰场景，并发从50突然跳到200，冷启动来不及扩容，队列堆满，P99直接飙到几十秒。这种尖峰我在灰度和生产环境里都遇到过，压测阶段提前发现就能提前设计排队超时、降级和预热策略。
灰度发布是控制风险的关键手段。我一般的灰度节奏是1%、5%、20%、50%、100%，每个阶段观察至少半天到一天。灰度流量的切分方式也有讲究，按用户ID哈希切分比按请求随机切分更稳，同一个用户始终走同一个版本，出问题的时候影响面可控、回滚也干净。灰度期间重点看的指标跟平时运维不太一样，除了延迟和错误率，我会特别盯新版本的输出质量。怎么盯，简单的方式是做人工抽检，复杂的上自动评估，用小模型或者规则做输出一致性比对。有个做营销文案生成的团队，灰度阶段发现新推理框架下生成文案的多样性指标掉了两成，原因是采样参数在不同框架里的默认实现不一致，这种问题只看延迟指标根本发现不了。
规模化推广阶段反而容易松懈。前期POC和压测做扎实了，推广阶段出大问题的概率不高，但细节上的坑不少。配置管理是第一个，不同环境、不同集群的推理服务配置要统一管理，靠手工改配置文件迟早会出不一致的事故。我现在的做法是把模型版本、框架版本、推理参数、资源配额全部做进配置中心，通过发布系统统一推送，改配置走审批流。容量规划是第二个，推广阶段流量是逐步涨上来的，扩容节奏要跟上，我一般按周维度做容量回顾，看资源利用率和流量趋势，提前两周做扩容决策。文档和培训是第三个，运维和业务开发团队得知道这个推理服务怎么用、怎么排查问题、出故障找谁。我见过推广到一半停下来的项目，原因不是技术不行，是业务团队不会用、不敢用，培训没跟上。
落地路径里还有个隐性环节：回滚预案。每一步推广之前都要确认回滚能多快完成、回滚之后数据一致性怎么保证。推理服务的回滚比普通微服务复杂一些，模型版本、框架版本、量化格式都可能不同，回滚不是简单切个流量就完事。我的做法是保留上一版本的完整运行环境，回滚时流量切回去、模型加载预热、健康检查通过再放量，整个过程控制在十分钟以内。这个演练在灰度之前至少做一次，别等真出事了才发现回滚脚本跑不通。
6.3 推理工具生态趋势：统一接口、编译优化、异构算力与标准化
推理工具这个领域，过去两年变化快得让人眼花。2023年vLLM刚火起来的时候，身边用的人还不多，2024年已经成了LLM服务框架的事实标准之一。往未来看几年，我觉得有几个趋势对选型决策影响很大，提前看准了能少走弯路。
统一接口的趋势越来越明显。OpenAI兼容的API格式现在基本成了行业默认，vLLM、TGI、TensorRT-LLM、SGLang都支持。这对企业来说是好事，应用层代码不用为每个推理框架写适配层，换框架的成本大幅降低。我现在的项目里，推理网关统一做OpenAI格式的转换和路由，后端接哪个框架对业务侧透明。更深一层的统一在模型格式和推理协议上，ONNX作为中间表示已经比较成熟，MLIR在编译优化层的统一也在推进。不过统一归统一，各框架在特性支持上还是有差异，流式输出、工具调用、多模态这些新能力各家的实现进度不一样，选型的时候还得看框架对业务所需特性的支持程度。
编译优化是另一个大方向。TensorRT-LLM在NVIDIA生态里的统治力还在加强，新卡新特性第一时间支持。AMD的ROCm生态里推理工具这两年追得很快，vLLM对ROCm的支持已经能跑生产负载了，虽然稳定性和性能跟CUDA比还有差距。Intel的Gaudi和GPU产品线也在推自己的推理优化方案。编译优化未来的竞争点我觉得在动态shape支持和编译速度上，现在TensorRT-LLM编译一次要几十分钟，模型迭代频繁的场景根本扛不住。torch.compile和SGLang的RadixAttention这类方案在动态性和编译效率上做得更好，适合快速迭代的场景。选型的时候得看你的模型迭代节奏，一周改一次模型和三个月改一次，编译方案的选择完全不同。
异构算力是绕不开的趋势。GPU供应紧张那两年，很多企业被迫考虑国产卡和各类加速器。昇腾、寒武纪、海光这些国产芯片的推理生态在快速完善，MindSpore和CANN工具链的成熟度每年都在提升。我的建议是核心业务还是优先选生态成熟的方案，GPU加主流框架的稳定性经过大规模验证。国产化有硬性要求的场景，昇腾配合MindIE或者vLLM的昇腾后端是可以落地的，POC阶段一定要用真实模型和真实数据充分验证，性能预期要务实，别拿CUDA的benchmark直接对标。异构算力还有个现实问题是算子覆盖，新模型里用的新算子在某些芯片上可能没有优化实现，跑起来性能断崖式下跌，这个坑我在一个国产卡项目上踩过，模型转换的时候没报错，推理性能只有预期的一成多，排查了两天才定位到是某个attention变体的算子没适配。
标准化这件事进展慢但方向明确。模型格式上GGUF、safetensors、ONNX各有各的地盘，短期内看不到完全统一。推理服务的部署标准倒是有进展，Kubernetes的推理扩展、KServe、Ray Serve这些方案在推动推理服务的标准化部署。监控指标也有标准化趋势，Prometheus的推理指标exporter越来越多。标准化的好处是降低锁定风险，换框架、换硬件、换云厂商的成本降低。我在选型的时候会把标准化程度作为一个隐性指标，一个框架如果只支持自家私有格式、监控指标不兼容标准协议，长期运维的切换成本会很高。
还有个趋势是推理和训练的边界在模糊。SGLang、LMDeploy这些框架开始支持推理和微调的统一调度，一套基础设施两种负载共用。这对资源利用率是好事，模型微调之后直接热加载到推理服务，省掉了模型转换和重新加载的时间。我关注这个方向有一段时间了，生产环境里还没大规模用，稳定性待验证。中小团队可以留意，如果框架能把推理和微调统一管理，运维组件的数量能少一套，长期看是省心的。
6.4 面向未来的选型决策框架与持续评估机制
前面聊了场景化选型、落地路径和生态趋势，最后这一节我想收拢一下，给一个能长期用的决策框架。推理工具选型没有一劳永逸的答案，模型在换、流量在变、工具在迭代，能持续做对决策比某一次选对工具更重要。
我的决策框架分三层。第一层是硬约束，合规要求、数据驻留、硬件可用性、许可协议，这些是一票否决项，不满足的直接排除，别在硬约束上做妥协。第二层是业务匹配度，延迟SLA、吞吐需求、输出质量底线、成本预算，这些是打分项，按业务优先级加权。第三层是长期成本，社区活跃度、文档质量、生态兼容性、团队技术栈匹配度，这些是软指标，影响的是未来两三年的运维效率和切换成本。三层筛完，候选工具一般就剩两三个，这时候再做POC对比。我见过一些团队跳过前两层直接做POC，测了半个月发现候选工具里有个许可协议不允许商用，前面的时间全白费。
持续评估机制是很多团队缺的。选型不是一次性事件，是持续过程。我现在的做法是每季度做一次推理工具回顾，看几个东西：现有工具的性能和稳定性指标趋势、社区有没有重要版本更新、新出现的工具里有没有值得POC的、业务需求有没有变化导致选型前提失效。回顾不用搞得很重，一两个小时过一遍关键信息，有变化就排POC，没变化就继续观察。这个机制能避免两种情况：一种是工具已经明显落后了还在硬撑，另一种是频繁换工具导致技术栈不稳定。
评估指标要跟业务阶段挂钩。业务早期，选型权重放在开发效率和上线速度上，工具易用性、文档质量、社区响应速度比极致性能重要。业务上量之后，性能和成本权重上来，编译优化、量化、分布式推理这些能力变得关键。业务成熟期，稳定性和运维效率权重最高，标准化程度、生态兼容性、长期支持承诺变得重要。我见过团队在业务早期选了套性能很强但运维复杂的方案，结果产品还没验证PMF，运维已经把团队拖垮了。也见过业务上量之后还在用早期图省事的方案，性能瓶颈卡住业务增长。评估指标跟着业务阶段调，这个意识比指标本身重要。
技术雷达是个实用的工具。我会维护一个简单的推理工具雷达，分四类：已经在生产用的、POC验证过的、观察中的、暂时不碰的。每季度更新一次，工具在四类之间流动。观察中的工具定期看社区动态和版本发布，有重大更新或者业务需求匹配度提高，就升级到POC验证。暂时不碰的也留个记录，知道为什么排除，过半年再看排除理由还成不成立。这个雷达我一般用共享文档维护，团队都能看到和更新，知识不会锁在个别人脑子里。
最后说个心态上的事。推理工具选型容易陷入两个极端：一个是追新，每个新框架出来都想试，技术栈换来换去，团队疲于奔命；另一个是守旧，选了一个就一直用，外面变化视而不见，等到不得不换的时候代价巨大。我自己的平衡点是：生产环境的主框架保持稳定，一年最多评估一次是否更换；实验环境保持开放，新工具出来可以快速POC，验证有价值的再往生产迁。这个节奏在保持稳定和拥抱变化之间找了个折中，落地几年下来效果还可以。
推理工具这个领域还会继续快速演进，模型架构在变、硬件在变、应用模式在变，工具跟着变是常态。选型决策的核心不是找到那个“最好”的工具，是建立一套能持续做出合理决策的机制。业务需求清楚、评估维度明确、验证流程扎实、回滚预案到位，有这四样打底，工具怎么变都不慌。我常跟团队说的一句话是：工具是拿来用的，不是拿来供的，能用、好用、换得起，就是好工具。
