• 时间:
  • 分类:

最近，推理引擎领域出现了两件具有标志意义的事件：vLLM 和 SGLang 相继走向公司化。vLLM 核心团队成立 Inferact，完成 1.5 亿美元融资，估值达 8 亿美元：

Inferact 团队

图源：Inferact

SGLang 团队也成立了 RadixArk，同样获得融资，估值达到 4 亿美元：

image-20260128212509136

图源：RadixArk

这并不是两起孤立的创业故事，而是在同一个时间点，对同一件事情给出了市场层面的确认：推理已经正式进入 AI 基础设施的核心层，而不再是模型之后的附属环节。

如果把过去几年 AI 的发展理解为模型能力竞赛，那么现在正在发生的，是一场系统工程能力竞赛。模型决定上限，推理系统决定规模化能力。一个模型是否有商业价值，越来越取决于它是否能被低成本、稳定、可持续地运行。

vLLM 和 SGLang 的融资，本质上是在为推理层重新定价。

一、推理引擎已经从工具升级为基础设施内核

早期的推理引擎更像是工具链的一部分，目标很简单：把模型跑起来，并尽量提升吞吐和降低延迟。它们解决的是局部性能问题，而不是系统性问题。

但今天的 vLLM 已经完全不同。它必须同时面对两条不断加速的演化曲线：

一条来自模型侧：Dense、MoE、多模态、Agent、超长上下文不断出现；

一条来自硬件侧：GPU、NPU、定制加速器、不同 CUDA/驱动/编译链并存。

在工程上，这意味着推理引擎被迫承担一个新的角色：

成为模型与硬件之间的通用适配层。

当一个系统需要同时满足：

  • 支持大量模型架构
  • 覆盖多种异构硬件
  • 承载从科研验证到大规模生产负载

它的属性就已经不再是“工具”，而是基础设施内核。

SGLang 从另一个方向推动了同一件事。它把推理从“函数调用”扩展为“可编程执行流程”，特别适合 Agent、强化学习和复杂工作流场景。这说明推理系统正在同时向两个方向演进：

一方面更像操作系统内核，负责资源与性能；

另一方面更像运行时与编程模型，负责表达能力。

这两种属性叠加，正是基础设施系统的典型特征。

二、推理成本已经成为 AI 商业化的决定性因素

在真实工程中，一个简单的事实越来越清晰：

训练决定模型能不能出现，

推理决定模型能不能活下去。

对绝大多数公司来说：

  • 训练是阶段性成本
  • 推理是长期、持续、不可回避的成本

随着模型规模扩大、调用频率上升，推理成本已经从“次要支出”变成“核心账单项”。很多场景里，推理成本远高于训练成本。

这使推理系统具备了极强的经济敏感性：

  • 5% 的吞吐提升
  • 10% 的显存利用率优化
  • 一点点调度效率提升

都会直接反映为真实的资金节省。

因此，推理引擎的价值不再只是“技术好不好”，而是“能不能直接影响 AI 服务的成本结构”。

这也是资本真正愿意为其高估值买单的原因。

三、推理系统的复杂性已经不可逆转

推理问题越来越难，并不是因为模型“更大”，而是因为系统维度在急剧膨胀：

  • 模型形态更加复杂：Dense、MoE、多模态、Agent
  • 推理形态更加复杂：长上下文、推理时计算、RL 循环
  • 硬件环境更加碎片化：多 GPU、多 NPU、多编译链

工程上已经出现一个明显现象：

很多模型在理论上“可以跑”，

但系统在现实中“跑不动、跑不稳、跑不起”。

Inferact 提出的愿景非常关键：

部署前沿模型应该像创建一个 Serverless 数据库一样简单。

这句话的真实含义是：

推理系统必须吞掉所有复杂性，而不是把复杂性留给使用者。

四、推理系统治理问题会持续放大

当 vLLM、SGLang 进入快速演进之后，一个确定会发生的变化是：

新模型适配、新硬件支持、新优化策略都会更频繁进入主线版本。这对行业是好事，但对使用者来说，复杂度反而会上升。

在真实工程中很快会遇到这些问题：

  • 同一模型在不同引擎版本下表现差异明显
  • 不同硬件对引擎版本的支持程度不一致
  • 升级引擎可能带来性能提升，也可能带来稳定性风险

推理引擎不再是“选一次就结束”的组件，而是进入持续治理阶段。

五、多引擎并存是工程必然，而不是选择题

现实生产环境中几乎不可能存在万能引擎：

  • 有的模型适合 vLLM
  • 有的模型适合 SGLang
  • 有的场景适合 TRT-LLM
  • 有的设备只能跑 llama.cpp

多引擎并存不是过渡状态，而是长期结构。

如果没有统一治理层，系统最终一定会退化为：

  • 脚本堆叠
  • 手工配置
  • 版本失控
  • 故障不可回溯

这是大型系统必然的退化路径。

六、GPUStack 的本质：推理系统的控制平面

GPUStack 并不是另一个推理引擎，它解决的是“引擎治理问题”。

在 GPUStack 的视角里：

  • 引擎是可插拔资源
  • 引擎版本是可调度对象
  • 模型实例是可编排单元

推理引擎从“写死在系统里的依赖”，变成了“运行时可切换的能力”。

这在工程上的意义非常大：

  • 可以并行运行多个引擎与版本
  • 可以灰度升级
  • 可以快速回滚
  • 可以做真实可控的性能对比

支持自定义使用任意推理引擎：

image-20260128214023530

自由切换任意推理引擎：

image-20260128214143994

自由切换推理引擎版本：

image-20260128212811154

推理系统开始具备云原生系统应有的治理能力。

七、引擎与版本切换，本质是 AI 推理世界的运行时治理

当推理引擎成为基础设施之后：

“要不要升级”不再是问题，

“如何安全升级、如何可控回退”才是问题。

这在工程上与：

  • 数据库内核升级
  • 容器运行时升级
  • Kubernetes 升级

是完全同一类问题。

GPUStack 做的事情，本质是把这种“运行时治理”能力引入推理系统。

八、真正的信号不是融资，而是系统层级的改变

vLLM 与 SGLang 的融资，不是某两个项目的成功，而是行业完成了一次角色确认：

推理层已经从“模型附属组件”，升级为 AI Infra 核心层。

而 GPUStack 的出现，也不是产品机会，而是工程必然：

当底层能力高速进化、多引擎并存成为常态，没有控制平面的系统一定会失控。

从工程视角看，GPUStack 把推理系统从“项目级资产”升级为“平台级资产”；

从组织视角看，它让推理能力不再依赖少数专家，而成为团队可复用的基础能力。

这正是推理基础设施真正成熟的标志。

标签: none

添加新评论