AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS官方博客指出TorchServe已不再积极维护，官方项目声明不再有计划更新、缺陷修复、新功能或安全补丁，漏洞可能不会被处理。对仍在其上跑推理的团队来说，这意味着安全补丁与PyTorch、CUDA兼容更新同时停止，工程师要自行承担整条依赖链。AWS给出的替代方案是Ray Serve深度学习容器：预构建、经测试与打补丁的镜像，把框架、依赖与GPU栈打包在一起，并支持在EKS、EC2与SageMaker上以不同入口点部署。
业务背景：一个被忽略的底层安全债
很多企业的推理服务是在几年前选型时定下的，之后很少再动。AWS官方博客指出，TorchServe已不再积极维护，官方项目声明明确表示不再有计划更新、缺陷修复、新功能或安全补丁，漏洞可能不会被处理。
对仍在其上跑模型推理的团队来说，这意味着两件事同时停止：安全补丁不再发布，与新版PyTorch和CUDA的兼容更新也不再跟进。工程师被迫自己承担整条依赖链——在GPU栈各层之间挑选兼容版本、逐层修补漏洞、在组件漂移时排查难以定位的故障。
问题：无差异的维护工作拖慢模型交付
官方文章把这部分工作定义为“无差异工作”：它不增加最终产品的价值，却持续占用工程资源并拖慢模型交付节奏。
这类问题的根源在于，推理栈由框架、CUDA运行时、服务层与系统库共同组成，任何一层停更都会让整条链失去受支持的基线。
AI怎么落地：用受支持的容器接管推理栈
AWS深度学习容器长期用于训练场景，提供预构建、性能优化的Docker镜像，把框架、依赖与GPU栈打包成经过测试与打补丁的组合。随着Ray Serve DLC发布，这一思路延伸到推理场景。
Ray Serve DLC的CPU版本基于Amazon Linux 2023，GPU版本基于官方NVIDIA Amazon Linux 2023镜像，包含操作系统层与CUDA运行时库；在此之上加入PyTorch、带FastAPI与Uvicorn的Ray Serve服务层，以及面向视觉、音频与多模态的常用工具，其中包括用NVIDIA硬件加速编译的FFmpeg。所有组件在每次发布前一起验证与测试，避免CUDA运行时、框架与服务层之间的版本漂移，安全补丁在构建时应用。
该镜像分别面向EKS与EC2、以及SageMaker发布，各自带有适配该环境服务契约的入口点，但共享同一套底层栈与依赖。
实施步骤：从单节点验证到多节点扩展
官方示例用GPU版Ray Serve DLC在单台g5.xlarge（一张A10G、24GB显存）上部署Qwen3-VL-2B视觉语言模型。服务代码通过ConfigMap注入容器，这样修改服务逻辑不需要重建镜像。
用Ray Serve写端点只需一个带@serve.deployment装饰器的Python类，实现__call__处理HTTP请求并调用.bind()注册，不再需要TorchServe的模型归档器、handler类层级与config.properties配置文件。
部署脚本分三步：deploy_cluster.sh用eksctl创建EKS集群并配置VPC网络、OIDC提供者与核心插件；deploy_node_group.sh添加带role=gpu-worker标签的托管GPU节点组；deploy_ray_cluster.sh应用ConfigMap、部署Kubernetes Deployment并在8000端口启动Ray Serve。验证时可用kubectl describe确认GPU已分配，再用port-forward发请求测试。
官方提醒，Pod报告Ready后会比Ray Serve真正开始应答早一到两分钟，因为模型仍在加载；若首次请求被拒，等待一分钟重试即可。
结果证据与边界
官方文章称，迁移后团队无需自行维护CUDA兼容、无需编写TorchServe handler样板、也无需拼装多阶段Dockerfile；DLC消除了版本漂移，升级简化为更换标签，并提供由AWS管理的定期安全补丁。
边界方面，该示例是单节点单GPU部署；若需要跨机器模型并行或多副本水平扩展，需要在KubeRay之上继续构建。来源未披露迁移耗时、成本节省或性能对比数据。
可复制动作
第一，盘点仍在TorchServe上运行的推理服务，按业务重要性与暴露面排定迁移优先级。第二，用Ray Serve DLC替换自建镜像，服务代码走ConfigMap注入以保持迭代灵活。第三，先在单GPU节点验证端点可用，再评估是否需要KubeRay做多节点扩展。第四，把镜像标签纳入常规升级流程，让安全补丁随镜像更新自动进入生产。
证据与边界
- 来源为AWS官方机器学习博客，正文含官方项目声明引用与完整部署步骤。
- TorchServe停止维护、不再提供安全补丁为原文明确引述的官方项目声明。
- Ray Serve DLC的构建基础、测试方式与发布形态均为原文描述。
- 来源未披露迁移耗时、成本节省或性能对比数据，相关表述已标注。
企业今天可以做什么
先盘点仍在TorchServe上运行的推理服务及其依赖版本，评估迁移优先级；用Ray Serve DLC替换自建镜像，把服务代码通过ConfigMap注入以保持灵活性；在单GPU节点上验证端点可用后再考虑用KubeRay扩展到多节点；把镜像标签纳入常规升级流程，确保安全补丁随镜像更新。