serve

Serve（推理服务）指将训练好的模型部署为可调用的在线服务的技术环节，是 AI 应用从原型走向生产的关键一层。随着大模型推理成本成为主要开销，围绕 Serve 的工具生态正快速分化与整合：既有 Ray Serve、vLLM、TorchServe 这类通用框架，也有面向特定硬件的原生方案，云厂商则通过托管容器进一步降低部署门槛。

Serve 生态近期进展

AWS推出Ray Serve深度学习容器支持TorchServe：AWS 在官方博客中宣布推出基于 Ray Serve 的深度学习容器，用于承接 TorchServe 工作负载。由于 TorchServe 已进入维护模式，这条迁移路径为存量 PyTorch 用户提供了平滑的过渡选项，也反映出 Ray Serve 在通用推理编排层的位置正在巩固。

Ray Serve LLM 在 GKE 上实现预填负载 4.4 倍、解码负载 24 倍吞吐量提升：vLLM 官方公布的测试数据显示，Ray Serve LLM 在 Google Kubernetes Engine 上针对预填（prefill）负载获得 4.4 倍、解码（decode）负载获得 24 倍的吞吐提升。预填与解码分离部署是当前大模型服务的主流优化方向，这一结果对生产环境选型有直接参考价值。

MLX-Serve：用 Zig 写的 Apple Silicon 原生 LLM 推理服务器：社区推出了基于 Zig 编写的 MLX-Serve，将 Apple Silicon 的统一内存优势用于本地 LLM 推理服务。与此同时，Anyscale 网络研讨会：用 Ray Serve 构建可扩展的分布式推理系统则聚焦云端大规模场景，本地与云端两条 Serve 路线的分工愈发清晰。

GLM-5.2 NVFP4格式在vLLM上线，内存减半精度不变：vLLM 宣布支持 GLM-5.2 的 NVFP4 量化格式，在精度不变的前提下将显存占用减半。模型侧的量化进展与推理服务框架的适配速度，正成为衡量 Serve 工具链成熟度的重要指标。

当前焦点与观察点

综合近期动态，Serve 领域呈现三个值得关注的方向。其一是框架整合：TorchServe 式微后，Ray Serve 与 vLLM 的组合正在成为 Python 生态的事实标准，云厂商的容器化支持加速了这一收敛。其二是性能优化向系统层深入：预填/解码分离、FP4 量化、分布式调度等手段叠加，使得相同硬件上的服务吞吐量出现数倍甚至数十倍的差异，选型时不能只看单点数字。其三是评测体系的补齐：SWE-Serve：评测智能体生产级推理工程能力的新基准尝试把"生产级推理工程能力"量化为可测指标，弥补了以往只评模型质量、不评部署工程的空白。对工程团队而言，接下来需要观察的是这些框架在智能体（agentic）长时任务、多模态负载下的稳定性表现，以及各云平台托管方案之间的可迁移性。

Overview

Serve 生态近期进展

当前焦点与观察点

Coverage