一、部署框架解决的不是“能不能跑”，而是“能不能扛流量”

直接调用 Transformers 的 generate()，很适合验证模型是否能工作，却不等于具备生产服务能力。在线请求的长度、到达时间和生成长度都不一样，朴素实现很容易出现 KV Cache 浪费、静态批处理等待和相同前缀重复计算。

真正的部署框架要把固定硬件转化为稳定服务能力：显存用得更紧、GPU 尽量不空转、相同计算能够复用，同时提供流式输出、并发控制、分布式执行和可观测性。

先看请求分布，而不是只看模型参数量。

先定义 TTFT、TPOT、P99 和成本目标，再比较框架。

任何公开排行榜都不能替代自己的同口径压测。

二、推理引擎只是整套系统中的“发动机”

大模型部署通常分成五层：业务应用、AI 网关、推理服务、模型与缓存、计算资源。vLLM、SGLang 等框架主要覆盖推理服务层，并向上下延伸部分能力。

企业项目常见的误区，是把“启动一个 OpenAI 兼容接口”当成上线完成。实际上，限流、超时、熔断、审计、灰度、弹性伸缩和故障切换，往往比单次 benchmark 更决定用户体验。

三、vLLM：通用 GPU 在线服务的优先候选

vLLM 的代表性设计是 PagedAttention：把 KV Cache 切成固定大小的 Block，通过映射关系组合成每个请求的逻辑序列。请求实际用了多少 token，就占用相应数量的 Block，减少连续大块预留带来的浪费。

当前官方文档还列出了连续批处理、Chunked Prefill、Prefix Caching、量化、推测解码、多种并行方式、结构化输出和 OpenAI 兼容接口。它已经不是只有 PagedAttention 的单点优化，而是一套通用推理平台。

vllm serve Qwen/Qwen3-8B \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 32768 \
  --enable-prefix-caching

四、连续批处理：吞吐量提升的关键不只是“凑大 Batch”

传统静态 Batch 要等一组请求全部结束，短请求完成后仍然占着位置。连续批处理则允许请求在 token 生成步骤之间动态加入和退出，让 GPU 计算槽位持续被新请求补上。

它的收益与请求长度分布、并发量、调度参数高度相关。并发很低时，吞吐优势不一定明显；并发很高时，如果只追求吞吐，也可能牺牲首 token 延迟。因此生产环境必须同时观察吞吐和尾延迟。

五、Prefix Cache：长文档、固定 System Prompt 和 RAG 的重要优化

当多个请求共享相同前缀时，前缀对应的 KV Cache 可以复用，新请求只计算不同的后缀。vLLM 的 Automatic Prefix Caching 已明确支持这种工作负载。

但缓存不会加速后续新 token 的 Decode 阶段，它主要节省共享前缀的 Prefill 计算。提示词只要在前面发生细小变化，缓存块边界和命中率就可能改变，所以固定内容应尽量放前面，用户变量放后面。

典型场景：同一长文档被反复提问。

典型场景：所有请求都带相同系统规则和 Few-shot 示例。

重点指标：Prefix Cache 命中率、节省的 Prefill token、TTFT 变化。

六、SGLang：对 Agent 和共享前缀工作负载更有针对性

SGLang 官方定位是面向生产的高性能大模型与多模态服务框架，核心能力包括 RadixAttention、Prefix Caching 和多 GPU 并行，并兼容 Hugging Face 与 OpenAI API。

RadixAttention 可以把不同请求的公共 token 前缀组织成树。Agent 往往会重复携带工具说明、系统约束和对话历史，这类请求的共享前缀非常明显，因此 SGLang 值得重点压测。

需要注意，vLLM 现在也支持 Automatic Prefix Caching。不能简单地说“有共享前缀就一定只有 SGLang”，更合理的方法是用真实 Agent 轨迹比较缓存命中、TTFT、TPOT 和显存占用。

python -m sglang.launch_server \
  --model-path Qwen/Qwen3-8B \
  --host 0.0.0.0 \
  --port 30000

七、TGI：存量系统仍可维护，新项目不再是默认推荐

TGI 曾经提供了 HF Hub 模型快速部署、连续批处理、张量并行、流式输出、Prometheus 指标、OpenTelemetry 和多种量化方案。

但截至 2026 年 3 月 21 日，Hugging Face 已将 TGI 仓库归档并转入维护模式，只接受小型修复、文档改进和轻量维护。官方同时表示，后续推荐使用 vLLM、SGLang，以及 llama.cpp、MLX 等本地引擎。

因此，已有 TGI 系统不必立即推倒重来，但新项目应把迁移能力、模型支持和长期维护风险纳入选型。

八、llama.cpp：本地、Mac、边缘与隐私场景的强项

llama.cpp 以纯 C/C++、较少依赖和广泛硬件支持为特色。官方列出了 Apple Metal、x86 指令集、CUDA、HIP、Vulkan、SYCL、WebGPU 等后端，并支持 CPU 与 GPU 混合推理。

它使用 GGUF 作为主要模型格式，支持多档整数位宽量化，还提供 OpenAI 兼容的 llama-server。它不只适合命令行体验，也可以部署为轻量本地 API、Embedding 服务和 Rerank 服务。

它的优势是离线、隐私、硬件覆盖广和部署门槛低；若目标是大型数据中心的极高并发，应与 GPU 专用推理框架进行实测，而不是只凭“CPU 框架”或“GPU 框架”的标签判断。

# 直接从 Hugging Face 运行 GGUF 模型
llama-server -hf ggml-org/gemma-3-1b-it-GGUF \
  --host 0.0.0.0 --port 8080

九、TensorRT-LLM：NVIDIA 集群上的深度优化选项

TensorRT-LLM 是 NVIDIA 面向 LLM 推理的框架，官方文档覆盖 In-flight Batching、Chunked Prefill、Paged KV Cache、张量/流水线/专家并行以及 FP8、INT4 等量化能力。

它适合硬件型号比较稳定、模型发布节奏可控、团队能够维护 NVIDIA 软件栈的场景。优势来自硬件和 Kernel 的深度协同，代价则是工程链更长、硬件绑定更强。

当前高层 LLM API 和 trtllm-serve 已降低了启动门槛，并提供 OpenAI 兼容接口，但真正做极致性能时仍需要理解量化、并行和调度配置。

trtllm-serve "nvidia/Qwen3-8B-FP8" \
  --host 0.0.0.0 \
  --port 8000

十、五类框架的定位对比

框架之间不存在脱离场景的永久排名。vLLM 和 SGLang 都在快速增加 Prefix Cache、结构化输出、推测解码和分布式能力；llama.cpp 也已提供并行请求和 OpenAI 兼容服务；TensorRT-LLM 的高层接口也在持续简化。

选型时应把“当前版本支持什么”写进技术验收清单，不要只依赖一年以前的博客结论。尤其是 TGI 已归档这一变化，会直接影响新项目的长期维护决策。

十一、选型决策：从硬件与请求形态开始

一个实用的起点是先问三件事：硬件在哪里、请求是否高并发、前缀重复率有多高。

本地和边缘优先评估 llama.cpp；通用 GPU 在线服务优先评估 vLLM；Agent、多轮和共享前缀明显时，把 SGLang 加入同口径压测；NVIDIA 大集群且模型稳定时，再评估 TensorRT-LLM 的深度优化空间。

TGI 更适合作为存量系统维护对象，而不是 2026 年新项目的默认首选。

十二、压测方法：只报一个 tokens/s 没有意义

可靠的压测必须固定模型版本、量化方式、GPU、上下文长度分布、输出长度分布、并发和采样参数。

TTFT 反映用户等待第一字的时间；TPOT 或 ITL 反映流式输出节奏；P95/P99 能暴露排队和抖动；吞吐量反映容量；显存和成本决定商业可行性；质量回归集则确保量化、Kernel 或框架升级没有破坏业务效果。

建议至少准备三套工作负载：短问短答、长文档问答、Agent 多轮调用。不要用单一均匀随机 Prompt 代表全部生产流量。

十三、生产架构：把推理副本放进可治理的系统

生产环境通常在推理框架前增加统一 AI 网关，负责鉴权、限流、模型路由、请求审计和超时；在后端配置多个推理副本、灰度版本和故障备用；同时接入 KV/Prefix 缓存、日志、Prometheus 与 OpenTelemetry。

高峰期可以通过队列和扩容保护 GPU，异常时可以切换到小模型、备用框架或降级回答。比起追求实验室里最高 tokens/s，这种可治理性更接近真实用户体验。

十四、上线前检查清单

上线前至少完成模型兼容性、长上下文 OOM、并发尾延迟、缓存命中、结构化输出、工具调用、可观测性、多卡故障、升级回归和真实成本十项检查。

框架更新非常快。建议锁定版本和容器镜像，为每次升级保留可重复 benchmark，同时准备一小套业务质量回归数据。这样才能知道性能提升来自哪里，也能在出现问题时快速回滚。