推理引擎的选择将直接决定系统的吞吐量、长尾延迟（P99）、显存利用率、多租户并发表现、结构化输出的稳定性，以及——负责运维的工程师在轮班时会不会痛苦得睡不着觉。
以下是针对11款主流Serving Engine的实战化点评，旨在帮助技术团队在选型时避坑，做出最符合生产需求的选择。
1. vLLM
定位：GPU 推理的“万金油”首选
如果在 NVIDIA 或 AMD 的显卡上部署开源权重的 LLM，并且不想被锁定在某一家特定厂商的软件栈里，vLLM 通常是绝大多数团队的第一站。
它之所以能成为标配，核心在于其均衡且强大的特性：PagedAttention（分页注意力）极大优化了显存管理，配合连续批处理（Continuous Batching）、自动前缀缓存（Automatic Prefix Caching）、分块预填充（Chunked Prefill）以及投机解码技术，使其性能非常能打。更重要的是，它的生态集成度极高，社区活跃，几乎成了开源界的标准答案。
🔗GitHub:https://github.com/vllm-project/vllm
2. SGLang
定位：激进的缓存策略 + 前沿推理研究
SGLang 在业内建立声誉，靠的是围绕Radix Attention（基数/前缀缓存）以及现代推理理念（如预填充/解码分离、高级调度策略）的深度优化。
对于那些Prompt结构高度重复的场景——比如固定的系统提示词（System Prompts）、复杂的工具调用脚手架（Tool Scaffolding）或者多轮对话中历史记录大量重叠的情况，SGLang 的表现往往会非常亮眼，甚至能与 vLLM 拉开差距。
🔗GitHub:https://github.com/sgl-project/sglang
3. TensorRT-LLM
定位：NVIDIA 硬件的性能天花板
如果技术栈完全绑定在 NVIDIA 生态上，并且目标是榨干硬件的每一滴推理性能，TensorRT-LLM 是一个必须严肃考虑的竞争者。它拥有高度定制的内核（Custom Kernels）、In-flight Batching、分页 KV 缓存，以及对 FP8/FP4/INT4 量化和投机解码的极致支持。
当然，选择它的代价也很明显：这意味选择了深度绑定 NVIDIA 的工具链。这把双刃剑既带来了极致的性能，也可能在模型移植性和灵活性上带来一些“痛苦”的维护成本。
🔗GitHub:https://github.com/NVIDIA/TensorRT-LLM
4. NVIDIA Triton Inference Server
定位：通常是 TRT-LLM 的最佳拍档
Triton 更像是一个“自带后端”的推理服务器框架，许多平台团队将其作为标准化的基础设施。在 LLM 领域，它通常作为生产环境的外壳，内部包裹着像 TensorRT-LLM 这样经过深度优化的后端引擎。
当需要进行集群级标准化管理、同时服务多个模型，或者追求一致的部署模式时，Triton 是企业级架构的常见选择。
🔗GitHub:https://github.com/triton-inference-server/server
5. Hugging Face TGI (Text Generation Inference)
定位：曾经的王者，现已进入“维护模式”
TGI 曾经是 Hugging Face 部署方案的标准配置。但需要特别注意的是，Hugging Face 官方文档已指出，截至 2025 年 12 月 11 日，TGI 已进入维护模式。官方甚至在 Inference Endpoints 中推荐用户转向 vLLM 或 SGLang 等替代方案。
所以在 2026 年的时间点上看：
对于存量系统：如果运行稳定，暂时保持现状没问题。 对于新构建系统：除非有非常特殊的理由，否则不建议以此为起点。
🔗GitHub:https://github.com/huggingface/text-generation-inference
6. Ollama
定位：从本地开发到团队协作的最简路径
Ollama 的杀手锏在于极致的开发者体验（DX）。它拥有极速的本地环境搭建流程、简单的模型管理命令，以及越来越完善的服务能力。值得一提的是，它通过新引擎对多模态模型（Vision Models）的支持也相当丝滑。
它非常适合原型开发、内部工具搭建，或者那种“我就想立刻在我的笔记本或小型服务器上跑起来看看效果”的场景。
🔗GitHub:https://github.com/ollama/ollama
7. llama.cpp
定位：可移植性之王（CPU 优先，无处不在）
如果需要在CPU、边缘计算设备或者一些奇奇怪怪的硬件组合上运行大模型，llama.cpp 绝对是主力军。它通过llama-cpp-python等封装器提供了兼容 OpenAI 格式的接口，生态覆盖极广。
这是一个典型的“用吞吐量换通用性”的方案。与顶级的 GPU 软件栈相比，使用者通常需要牺牲原始的推理速度，换取在任何设备上运行的可能性。
🔗GitHub:https://github.com/ggml-org/llama.cpp
8. LMDeploy (TurboMind)
定位：C++ 驱动的高效能派
LMDeploy 将 TurboMind 定位为一个高效的推理引擎，并提供了通往OpenAI 兼容服务器的路径。
如果你倾向于使用更“系统化”的运行时环境，并且看重其模型支持覆盖率和配套工具链，这是一个非常有力的竞争者，尤其是在追求 C++ 级别的高效实现时。
🔗GitHub:https://github.com/InternLM/lmdeploy
9. MLC-LLM (MLCEngine)
定位：一次编译，到处运行
MLC-LLM 走的是跨环境编译器驱动的路线。它暴露了OpenAI 兼容的 API，并支持多平台目标构建（Python / JavaScript / 移动端）。
对于那些需要在桌面端、移动端和嵌入式设备上提供一致模型体验的产品团队来说，MLC-LLM 是解决跨平台碎片化问题的利器。
🔗GitHub:https://github.com/mlc-ai/mlc-llm
10. OpenVINO Model Server
定位：Intel 硬件的御用管家
如果基础设施主要由Intel 的 CPU、GPU 或 NPU组成，OpenVINO 的服务栈就是为了应对这种现实而设计的。OpenVINO Model Server 支持生成式管道，并特别针对 LLM 的连续批处理和状态服务模式进行了优化。
当基础设施受限于成本必须使用 CPU，或者本身就是 Intel 重度用户时，这通常是那个“正确”的选择。
🔗GitHub:https://github.com/openvinotoolkit/model_server
11. DeepSpeed-MII
定位：DeepSpeed 生态的推理拼图
DeepSpeed-MII 专注于高吞吐量和低延迟的推理表现，并且与庞大的 DeepSpeed 推理生态系统紧密集成。
如果所在的组织已经在训练或微调阶段深度使用了 DeepSpeed，那么为了保持生态的一致性和技术栈的复用，MII 会是一个极具吸引力的选项。