模型部署上线，只是 AI 服务交付的起点。
大模型应用进入规模化落地之后，AI 基础设施正在经历一次必然的成熟周期——从"能跑"到"可运营"。
这个转变，不是功能的简单叠加，而是平台定位的升级：从稳定地提供推理服务，演进为可以真正承载企业 AI 服务交付的基础设施底座。
这个阶段的核心命题，是两个方向的同步推进：模型服务需要具备运营级的可靠性与可见性，算力管理需要从"为推理服务"扩展为"统一分配 AI 所需的各类资源"。
GPUStack v2.2 沿着这两个方向继续深入：模型服务从"可用"走向"可运营"，算力管理从"统一调度"向"按需服务"延伸。
深化模型推理场景支持与生命周期管理
模型服务的稳定性，不只是部署阶段的事。实例启动之后，长时间运行中的 OOM、推理挂起、进程静默崩溃，才是生产环境里更常见的麻烦。
此前，GPUStack 的健康检查主要覆盖启动阶段——实例一旦启动成功，后续如果出了问题，平台无从感知，故障实例会留在服务池里持续接收流量，造成静默失败，直到有人发现才手动处理。
v2.2 将健康探测延伸到整个运行阶段：平台持续探测每个实例的真实推理能力，检测到异常立即从服务池下线并自动重启，恢复后自动重新纳入。服务可用性由平台主动保障，不再依赖人工巡检或用户反馈。
排障能力也做了系统性的补齐。生产环境里遇到问题，最需要的往往是完整的现场记录，而这在之前意味着要进终端手动查看日志。v2.2 新增三类日志访问：
重启前历史日志，让你能看到实例崩溃前的完整输出，而不是重启后无法追溯历史故障日志；
分布式子实例日志，多节点部署时可以单独查看每个节点的输出，快速定位哪个节点出了问题；
Ray 容器日志，直接在 UI 里查看 Ray 容器日志，不用再在终端命令行排查。
绝大多数生产排障场景，现在可以在 GPUStack 界面内完成闭环。
分布式推理方面，v2.2 新增了 vLLM MP 自动分布式模式。
此前 GPUStack 仅支持基于 Ray 的 vLLM 自动分布式，MP 分布式需要手动配置，无法自动化拉起所有分布式实例。
随着 vLLM 的快速迭代，相比 Ray 自动分布式，新的 MP 分布式模式在运维成本和推理性能上有明显优势。
现在用户可以根据需求自行选择 vLLM 自动分布式的部署策略。
另一个值得关注的变化是对 Multi-LoRA 的支持。
企业里给不同业务场景做微调是常见需求，之前的做法是每个 LoRA Adapter 单独跑一个模型实例，显存开销随任务数量线性增长，资源浪费明显。
v2.2 支持多个 LoRA Adapter 挂载到同一个基础模型实例上动态切换，同等硬件可以承载更多微调任务，显存利用率大幅提升。
模型 Token 运营治理体系
模型在跑，但 Token 消耗在哪里——这个问题，在早期规模小的时候不明显，一旦多个团队、多个应用共用同一个平台，立刻就会变成运营上的痛点。
GPUStack 此前已支持按模型维度和用户维度查看用量数据，能了解整体消耗趋势。
但在精确归因上，这两个维度还不足以满足需求。
不同应用、不同业务线共用同一个用户账号下的多个 Key，消耗拆不开，成本核算无从下手。
v2.2 新增 API Key 维度的用量统计。每个 Key 的 Token 消耗独立计量，管理员可以清楚看到每个调用方在消耗什么、消耗多少，为跨团队的成本归因和配额管理提供了直接依据。
另一个变化是把查看权限还给了用户。此前用户想了解自己的消耗情况，只能找管理员拉数据。
v2.2 开放了用户侧的个人用量自助查询，模型维度和时间维度的消耗历史可以直接在 UI 里看，不需要走申请流程。
计量能力到位之后，Token 消耗才真正从黑盒变成可以运营的数据——配额分配、内部结算、成本分析，都有了基础。
生产部署能力增强
平台能力的落地，离不开部署侧的配合。v2.2 在三个方向上补齐了企业生产部署的短板。
Kubernetes 是企业基础设施的主流选型，但此前在 K8s 环境里部署 GPUStack 缺乏标准化的云原生路径。
v2.2 提供官方 Helm Chart，支持通过 Helm 一键完成安装与配置，可以直接融入现有的 GitOps 工作流与 CI/CD 体系，部署和升级的运维成本大幅降低。
在数据库支持上，v2.2 新增了对 OceanBase 和 openGauss 的适配，覆盖对国产数据库有合规要求或明确技术选型的企业场景，信创环境下的部署路径更加完整。
网络拓扑方面，v2.2 支持 Worker 单向访问 Server 模式。
在跨地域或跨网络边界的部署场景中，很多环境里难以实现 Server 与 Worker 的双向连接。
单向网络模式下，Worker 节点只需能访问 Server，Server 不需要反向连接，多地域集群统一纳管的网络障碍就此打通。
从算力池化到 GPU 服务
GPUStack 的异构算力统一调度一直是核心能力之一——不同厂商、不同型号的 GPU 纳入同一个算力池，统一调度、统一监控。但这个算力池，此前只服务于一种场景：推理。
数据科学家需要一个交互式开发环境，算法工程师需要实验调试用的独占 GPU，这些需求在很多团队里是绕开 GPUStack 单独走另一套系统解决的，算力的分配和计量也因此割裂。
v2.2 引入 GPU 实例服务，把"分配一个隔离的 GPU 环境"这件事纳入了平台统一管理。
用户可以在平台上按需申请隔离的 GPU 实例，指定 GPU 厂商、型号和数量，选择包含存储挂载、端口配置的运行模板，实例就绪后通过 SSH 或 Web 接入。
使用情况由平台统一计量，和推理服务共用同一套调度与用量体系。
这是算力服务模式的一次扩展：同一算力资源池，既可以作为推理服务的底座，也可以作为按需分配的 GPU 实例对外提供。
统一调度、统一计量，不再因使用场景不同而产生管理割裂。后续的训练/微调资源调度、更细粒度的虚拟化算力切分，都将在这个基础上自然延伸。
AI 基础设施平台的下一阶段
AI 基础设施的演进，有一条清晰的路径：从能跑模型，到稳定运营模型服务，再到统一管理和分配 AI 所需的算力。
v2.2 在这两个维度上都往前走了一步。模型服务侧，推理场景深化、实例生命周期管理完善、Token 运营体系建立与生产部署能力增强，让平台具备了规模化交付的基础条件；
算力侧，GPU 实例服务的引入，让算力的分配和计量不再局限于推理场景。
两条线指向同一个目标：让 GPUStack 成为企业 AI 服务真正可以依赖的基础设施底座。
立即体验：
GPUStack v2.2 企业版：即将发布
v2.2 开源版奠定了平台运营能力的基础。
在更复杂的企业场景中，还有一层能力是开源版本身无法覆盖的——当平台需要服务多个相互隔离的租户，当算力消耗需要精细管控到每个 API Key、每条模型路由，当平台的全链路高可用和 Token/GPU 计费管理成为刚需，这些就是 GPUStack 企业版要解决的问题。
GPUStack v2.2 企业版面向需要组织级治理与商业化运营能力的企业场景，支持多租户隔离、精细配额限流与访问管控、生产级高可用、资源拓扑图与计费管理，敬请期待。
如果你对企业版感兴趣，欢迎提前联系我们，了解详情与抢先体验计划。
399
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
