TorchServe 支持终止后，AWS Ray Serve Deep Learning Containers 接棒
随着 TorchServe 进入无限期维护冻结状态，AWS 发布了一条使用 AWS Ray Serve Deep Learning Containers 的单 GPU 迁移路径。这一变化之所以重要，是因为 TorchServe 用户的生产级 PyTorch 模型已不再运行在一个积极维护的服务框架之上。AWS 提供的是一套经过测试的容器栈，但团队仍需重写服务应用，并负责运行周边基础设施。
新的迁移指南在 Amazon Elastic Kubernetes Service（即 Amazon EKS）上部署 Qwen3-VL-2B 视觉语言模型。它在一个 pod 中运行于一台 g5.xlarge 实例上，使用一块 NVIDIA A10G GPU 和 24 GB GPU 显存。该示例通过 8000 端口的 HTTP 端点暴露模型服务。
这一规模不大的部署揭示了更大的变化。TorchServe 曾通过以 PyTorch 为中心的工作流，将模型归档、处理器、配置和服务封装在一起。AWS Ray Serve Deep Learning Containers 则以受维护的镜像、Ray Serve 应用代码和标准 Kubernetes 资源取代了这一框架。运维责任只是改变了形态，而非就此消失。
AWS 将 TorchServe 的支持缺口转化为容器迁移路径
AWS 针对 TorchServe 的维护冻结提供了一套经过测试的推理栈，而非可直接替换的方案。
TorchServe 官方文档现已显示有限维护通知。通知称，该项目已不再积极维护。现有版本仍可使用，但未来没有更新、错误修复、新功能或安全补丁计划。
这一警告改变了生产用户的风险评估。稳定的应用仍可继续运行在现有 TorchServe 版本上。然而，每一项新的框架、操作系统、CUDA 或安全要求，都会让应用所有者面临新的兼容性决策。
安全问题最难以延后处理。TorchServe 通知明确警告，漏洞可能不会得到修复。组织可以隔离部署并修补周边层级，但无法依赖未来上游对服务框架本身的修正。
AWS 将其 Ray Serve Deep Learning Container（通常称为 DLC）定位为这些工作负载的受支持基础。DLC 是一种容器镜像，其中安装并共同测试了选定框架及其相关依赖项。AWS 分别为 Amazon EC2、EKS 和 Amazon SageMaker 发布 Ray Serve 镜像。
GPU 镜像以 NVIDIA Amazon Linux 2023 基础镜像为起点。该基础包含操作系统和 CUDA 运行时库。随后，AWS 添加了 PyTorch、Ray Serve、FastAPI、Uvicorn、Hugging Face Transformers，以及用于视觉、音频和多模态处理的工具。
该镜像还包含支持 NVIDIA 硬件加速的视频预处理 FFmpeg 构建版本。对于服务同时处理视频帧、图像、音频和文本的模型团队而言，这一细节很重要。这类工作负载通常不只需要模型框架和 HTTP 服务器。
AWS 表示，会在每次镜像发布前共同验证所包含的组件。安全补丁会在构建镜像时应用。这种方式可减少 CUDA 运行时、PyTorch、Ray Serve 和 Web 服务层之间的版本漂移。
这一承诺有明确边界。AWS 支持并测试容器组合，而用户仍需负责模型代码、集群配置、网络控制、扩缩容策略和升级流程。受维护的镜像缩小了团队必须自行组装的范围。
该示例也没有将 Ray Serve 描述为透明的 TorchServe 兼容模式。工程师需要编写新的 Python 服务类，并通过 Ray Serve 部署。他们不会导入 TorchServe 归档文件，也不会复用其完整管理接口。
这一差异让公告保持务实。AWS Ray Serve Deep Learning Containers 为受影响的工作负载提供了一个受支持的去处。它们不会让生产迁移自动完成，也不会免除部署测试的需要。
为什么 TorchServe 团队如今要负责更多 GPU 栈
TorchServe 主动维护的结束，将上游不确定性直接转移给平台和机器学习工程团队。
GPU 推理服务依赖多个独立演进的层级，包括操作系统、NVIDIA 运行时、CUDA 库、PyTorch、模型依赖项、请求服务器和编排环境。即使模型代码没有变化，也可能出现兼容性故障。
TorchServe 此前为 PyTorch 团队提供了易于识别的打包和服务路径。开发者可以使用 torch-model-archiver 创建模型归档，提供自定义处理器，并通过 config.properties 控制行为。该工作流本身也有复杂性，但它同时提供了一套共享的运维惯例。
维护冻结削弱了这一惯例能否跟上相邻软件演进的信心。团队可以固定所有依赖版本，但固定版本只会推迟下一次决策。操作系统补丁、GPU 变更或框架升级最终都会迫使团队对整个栈进行验证。
继续运行 TorchServe 仍然可行。该项目并未消失，现有版本在许多部署中依然可用。问题在于，继续使用它将成为刻意选择由内部承担所有权，而不再是受支持的默认方案。
选择这一路径的组织需要明确的安全流程。他们必须监控相关依赖项、评估暴露的接口、重建镜像并测试修复，而不能期待新的 TorchServe 版本。他们还需要制定应对 TorchServe 自身漏洞的计划。
另一种选择是迁移，而这会立即带来工程工作。TorchServe 的处理器和模型归档不会自动变成 Ray Serve 部署。请求解析、健康检查行为、指标、模型加载、批处理和错误处理都需要逐项比较。
Ray Serve 改变了主要的编程模型。开发者使用 @serve.deployment 标记 Python 类，在该类中初始化模型，并通过 __call__ 处理传入的 HTTP 请求。调用 .bind() 会为 Ray Serve 注册应用。
这种模型可能比 TorchServe 的归档和处理器结构更简单。它也让开发者能够使用常规 Python 组合方式，并直接访问 Ray 的资源声明。例如，AWS 部署通过 ray_actor_options={"num_gpus": 1} 请求一块 GPU。
然而，更简单的应用代码并不意味着更简单的生产运维。团队仍然需要就绪检查、身份验证、流量管理、遥测、部署控制和回滚流程。他们必须决定模型权重如何进入环境，以及副本在更新期间如何运行。
AWS 容器将多项兼容性选择上移。AWS 选择并测试基础操作系统、CUDA 运行时、框架和服务依赖项。这可以减少内部自建镜像所需的重复集成工作。
同时，这也带来了对 AWS 镜像发布的新依赖。平台团队必须跟踪镜像标签、审查变更、扫描其添加的层，并在自身环境中验证新版本。经过测试的基础镜像是有用的证据，但并非应用级认证。
有合规要求的团队需要进行更多验证。他们必须确认镜像内容符合内部政策，并确保更新在规定时间内到达。他们还需要为完整镜像准备软件物料清单和漏洞管理记录。
因此，压力主要落在拥有成熟 TorchServe 体系的团队身上。他们围绕一种框架积累了处理器、打包步骤、仪表板和运维知识。迁移到 Ray Serve 意味着要投入这些专业经验，而旧系统表面上可能依然稳定。
较小规模的部署面临不同的考量。如果一项服务只有一个模型且流量可预测，完整的 Ray 和 Kubernetes 栈可能会引入不必要的复杂性。其价值取决于组织是否已在运行 EKS，以及是否预期有更广泛的扩缩容需求。
AWS Ray Serve Deep Learning Containers 如何改变服务模型
其核心机制是预集成：AWS 固定基础栈，而 Ray Serve 则取代 TorchServe 的打包和请求生命周期。
AWS 示例服务的是 Qwen/Qwen3-VL-2B-Instruct，这是一款处理图像和文本的视觉语言模型。它接收图像 URL 和提示词，然后返回生成的描述或回答。该模型适合作为示例，因为它同时涉及 GPU 推理和多模态预处理。
AWS 通过 Hugging Face Transformers 加载模型。AutoProcessor 准备多模态输入，AutoModelForImageTextToText 则以半精度权重加载模型。随后，应用将这些权重移至 CUDA 设备。
服务类直接接收 HTTP 请求。它从 JSON 中提取图像 URL 和提示词，准备模型输入，运行生成过程并返回结果。FastAPI 和 Uvicorn 提供了 DLC 中包含的 Web 服务基础。
这一设计移除了三种常见 TorchServe 构件：没有 TorchServe 模型归档、没有 TorchServe 处理器层级结构，也没有 config.properties 文件。服务契约存在于 Ray Serve 应用及其部署配置中。
AWS 通过 Kubernetes ConfigMap 注入该 Python 应用。ConfigMap 存储可由 pod 在运行时挂载的非机密配置或文件。这使工程师无需重建容器镜像，即可修改演示代码。
这种灵活性在评估期间很有用。它将服务逻辑与经过测试的基础镜像分离，并缩短编辑、部署和测试循环。不过，生产团队应决定可变配置是否符合其发布和审计要求。
一些组织会选择将应用构建进派生镜像。该方法会创建一个不可变构件，同时包含 AWS 基础镜像和经批准的服务代码。它可以提高可复现性，但每次应用变更都需要重新构建。
该部署通过 Kubernetes nvidia.com/gpu 资源预留一块 GPU，并使用 role=gpu-worker 标签选择 GPU 节点。这些设置有助于 Kubernetes 将推理 pod 放置到目标实例上。
Ray 通过容器环境和应用声明获得 GPU 分配。模型类请求一块 GPU，与 pod 暴露的单块 GPU 相匹配。在更大规模的配置中，Ray 可以在声明资源池中调度部署。
AWS 围绕该示例提供了三个脚本。第一个使用 eksctl 创建 EKS 集群、网络配置、OpenID Connect 提供程序和核心附加组件。第二个脚本添加托管 GPU 节点组。
第三个脚本应用 ConfigMap 和 Kubernetes 部署。它将 Ray Serve pod 调度到 GPU 节点，并在 8000 端口启动服务。配套的示例仓库提供了这些部署构件，供用户查阅。
部署完成后，用户可以检查 pod 并验证其 GPU 分配情况。随后，他们可以将本地端口 8000 转发到正在运行的部署，并发送包含图像 URL 和提示词的 HTTP 请求。在 pod 内运行 nvidia-smi 可确认 GPU 正在被使用。
启动流程揭示了一项生产环境设计必须处理的运维细节。AWS 指出，Kubernetes 可能会在 Ray Serve 能够响应请求之前就将 pod 报告为就绪。pod 达到该状态后，模型仍可能处于加载过程中。
在演示中，首次请求被拒绝尚可接受，但在生产流量之后则存在风险。团队应将就绪状态与应用可用性关联，而非仅依赖容器状态。在模型和端点能够处理真实请求之前，探针应始终保持未成功状态。
模型下载则增加了另一个变量。该演示会在应用初始化时拉取模型，这取决于外部服务可用性和网络吞吐量。生产团队可以使用本地存储、对象存储或镜像层来控制启动行为。
密钥同样需要单独处理。ConfigMap 不应包含访问令牌或私有凭据。任何所需认证都应通过 Kubernetes Secrets、EKS Pod Identity 或其他获批准的密钥系统提供。
这些决策表明 DLC 实际简化了什么。它标准化了软件基础，并提供经过测试的执行环境；但它并不决定组织应如何处理模型、密钥、发布产物或服务暴露。
单 GPU 演示是起点，而非生产结论
一个 pod 使用一张 GPU 可以证明部署路径可行，但并不能证明其具备生产级可靠性、效率或扩展能力。
AWS 有意将参考架构保持在较小规模。EKS 集群只有一个基于 g5.xlarge 实例的托管 GPU 节点。一个 pod 占用该节点的 NVIDIA A10G GPU，单个 Ray Serve 进程则暴露模型端点。
这种安排适用于迁移测试。团队无需先设计分布式集群，便可转换处理器、检查响应行为、对比输出并确认 GPU 访问权限。这也让故障更易于隔离。
同样的简洁性也限制了读者应得出的结论。该示例并未展示冗余副本、多节点模型并行、由流量驱动的自动扩缩容，或跨可用区的故障恢复；它也没有公布延迟或吞吐量的对比结果。
缺少这些测量数据，该文章无法证明 Ray Serve 会优于某个特定的 TorchServe 部署。性能取决于模型、输入形状、并发量、批处理、GPU、预处理路径和生成设置。迁移团队需要自行进行具有代表性的测试。
该架构还包含单一服务故障点。如果 pod 重启或 GPU 节点不可用，端点将停止响应，直到 Kubernetes 将其恢复。生产服务通常需要额外副本，或明确的恢复目标。
扩展这一设计会引入 KubeRay——用于管理 Ray 集群的 Kubernetes 推荐 Operator。Ray 的 Kubernetes 部署指南 描述了一种 RayService 自定义资源，可将 Ray 集群配置与 Serve 应用结合起来。
KubeRay 可以管理 head 和 worker pod、应用更新及集群生命周期，也支持异构计算资源和自动扩缩容。这些能力使 Ray Serve 更适合多模型流水线，或必须跨节点扩展的服务。
但它们也会增加运维概念。团队需要理解 Ray head、worker、Serve controller、资源声明、Kubernetes 自定义资源以及多层日志。排障可能同时涉及 Kubernetes 和 Ray 两个控制平面。
在比较替代方案时，这种取舍十分重要。为单个 Transformer 模型提供服务的团队，可能会评估独立的 vLLM 端点；拥有多种模型格式的组织，则可能考虑 NVIDIA Triton Inference Server。以 Kubernetes 为中心的团队，或许会评估 KServe，以获得标准化的推理资源。
这些选项解决的问题有所重叠，但侧重点并不相同。Ray Serve 强调 Python 应用组合、分布式执行、副本、路由和扩展能力；TorchServe 则主要围绕 PyTorch 模型的打包与服务化构建其使用体验。
AWS 本身也记录了其他服务路径。其当前的 EKS 推理指南 使用 vLLM Deep Learning Container 部署 LLM。这表明 Ray Serve DLC 是一种受支持的模式，而不是通用替代方案。
正确选择取决于工作负载。带有自定义预处理的视觉语言服务可受益于 Ray Serve 的 Python 原生组合能力；标准化的文本生成端点则可能更适合专为大语言模型优化的引擎。
迁移评估应从接口一致性开始。团队需要比较请求模式、错误响应、健康检查端点、认证方式和客户端超时设置，然后再针对受控测试集验证模型输出。
接下来必须进行负载测试。工程师应测量冷启动时间、首次响应时间、稳态延迟、吞吐量、GPU 内存，以及突发流量下的行为。测试应采用与生产环境相同的预处理和生成配置。
故障测试同样重要。团队应终止 pod、排空节点、中断模型访问，并部署无效的应用版本。这些测试能够揭示替代方案是否符合恢复和回滚预期。
可观测性需要直接映射。现有的 TorchServe 指标和仪表盘不会原样迁移。运维人员必须确定哪些 Ray、应用、Kubernetes 和 GPU 指标定义了健康状态、饱和度和面向用户的服务降级。
最后，团队还需要进行一次升级实验。他们应在预发布环境中切换两个 DLC 版本，并记录所需的代码、配置和模型变更。如果日常升级仍然风险过高，支持的价值就会受限。
TorchServe 用户接下来应关注什么
下一个考验是 AWS 能否将清晰的迁移示例转化为可靠的发布与扩展路径。
第一个信号是 Ray Serve DLC 的发布节奏。团队应关注是否有文档化的镜像标签、框架版本、CUDA 组合、安全更新和弃用政策。可预测的发布将强化 AWS 的论点：该镜像能够降低长期维护工作量。
发布说明与发布频率同样重要。运维人员需要知道哪些依赖项发生了变化，以及更新是否包含破坏性行为。他们还需要在受支持标签之间拥有足够的重叠期，以便在采用新镜像前进行测试。
第二个信号是关于就绪状态、模型加载和故障恢复的生产环境指南。当前示例承认，pod 可能在 Ray Serve 响应前就显示为就绪。更完善的参考实现应使 Kubernetes 的就绪状态与已加载的模型和可响应的端点保持一致。
该指南还应涵盖模型存储和启动行为。在初始化期间下载权重适合小型演示；较大规模的部署需要可重复的加载过程、受控凭据、合适的存储，以及针对真实模型预热时间设置的启动探针。
第三个信号是从一张 GPU 扩展到多个副本或节点的受支持路径。AWS 引导读者使用 KubeRay 进行分布式服务和水平扩展。未来示例应展示 DLC 在 RayService 部署中的表现。
多副本参考实现应记录流量路由、滚动更新、自动扩缩容信号，以及 GPU worker 消失时的恢复方式。它还应将 Ray head 工作负载与 GPU 推理 worker 分离，为模型保留昂贵的加速器容量。
团队无需等待所有参考实现就可以开始评估。他们现在即可盘点 TorchServe 服务，并按暴露程度、业务重要性和迁移难度排序。面向互联网的端点应比隔离的批处理系统更早获得关注。
针对每项服务，工程师可以列出当前使用的 TorchServe 功能，包括模型归档、自定义处理器、工作流、批处理、指标、管理 API 和配置文件。这份清单将成为具体的 Ray Serve 迁移检查表。
小规模概念验证应保留既有的请求和响应契约。保持客户端不变，可以将服务层迁移与更广泛的应用重写隔离开来，也能让旧、新端点之间的流量对比保持可控。
评估应使用相同的模型权重和具有代表性的输入。团队可以比较输出一致性、延迟、吞吐量、GPU 利用率和错误行为，也应记录每项服务在重启后恢复所需的时间。
安全团队应将最终镜像作为完整制品进行审查。AWS 基础镜像可能会获得经过测试的依赖项和构建时补丁，但本地新增的软件包可能重新引入漏洞。自定义后仍必须继续进行扫描。
平台负责人也应在迁移前明确所有权。AWS 维护 DLC，Ray 维护 Ray Serve，而组织自身负责其应用和 EKS 部署。清晰的边界可避免将受支持的组件误认为受支持的端到端服务。
更广泛的教训并非每位 TorchServe 用户都必须采用 Ray Serve，而是未维护的服务层如今需要作出明确决策。继续维持现状、迁移至 Ray Serve，或选择另一种服务器，都会形成不同的支持模式。
AWS Ray Serve Deep Learning Containers 让其中一种选择变得更加具体。新示例提供了经过测试的基础、直接的编程模型和可运行的单 GPU EKS 部署，同时也让剩余责任变得清晰可见。
从一项具有代表性的 TorchServe 服务开始，并在真实流量模式下测试迁移。如果 DLC 能在不削弱可用性的前提下降低依赖维护工作，它就值得更广泛地推广；如果 Ray 的运维层负担超过这一收益，测试也会及早揭示这一点。
