LLM 推理引擎怎么选——2026 年从本地单机到 PD 分离的全景选型地图
阿里云 CAP 有一篇讲推理引擎选型的文章，把候选收敛到四个：Ollama、vLLM、SGLang、Hugging Face Pipeline。这个划分在 2024 年是够用的。
但到 2026 年，它至少漏掉了半张地图——NVIDIA 的 TensorRT-LLM 完成了「PyTorch 化」转身、SGLang 因为首个开源复现 DeepSeek 大规模部署而封神、Hugging Face 自己给 TGI 挂上了「维护模式」横幅并劝你改用 vLLM，而整个 2025 年推理引擎领域真正的主线，其实是一个字：拆。
这篇文章把这张地图更新到 2026 年年中。它不替你拍板选哪个产品——它给你一套分层框架、一张决策矩阵和一棵决策树，让你自己把候选收敛到 1–2 个。
为什么 2026 年「选推理引擎」才是个真问题 # 三年前不需要纠结这个。那时候能把一个 7B 模型在 GPU 上跑起来、返回还算流畅的 token 流，就已经过关。
现在情况变了，原因有三个：
模型能力在趋同，部署形态在分化。 开源侧从 Llama、Qwen 到 DeepSeek-V3/R1、Kimi K2，能力差距在缩小；真正拉开差距的，变成了「你能不能把它高效、低成本、稳定地跑起来」。同一个 DeepSeek-R1，有人一张 4090 勉强跑起来做原型，有人用 96 张 H100 做到接近官方吞吐、成本压到官方 API 的五分之一——差的就是推理引擎和部署架构。 大规模 MoE 把推理从「单卡工程」推成了「分布式系统工程」。 DeepSeek-V3 是 671B 总参 / 37B 激活，Kimi K2 更是 1T 总参。这类模型单机放不下，必须跨节点做专家并行（EP），推理引擎的选择直接决定了你要不要碰 all-to-all 通信、专家负载均衡这些硬骨头。 同一个模型，引擎之间的吞吐/成本差异可以到数倍。 这不是「快一点点」的差别，是「同样的卡，能不能多服务几倍用户」的差别，直接写进云账单。 所以选型不再是「随便挑一个能跑的」，而是先想清楚你在地图的哪一层。