TorchServe 没维护了，用 Ray Serve DLC 部署模型省心多了

TorchServe 已经基本处于停更状态，不管是 Bug 修复还是 CUDA 兼容性更新都指望不上了。如果你还在用它，现在得自己扛所有依赖链，稍微升个版本可能就导致整个 GPU 栈崩溃。换成 Ray Serve DLC（Deep Learning Containers）的逻辑很简单：直接用 AWS 预构建、测试好且打过补丁的镜像，省去自己配环境的折腾时间。

怎么用 Ray Serve DLC 跑起模型

如果你想在 Amazon EKS 上部署一个视觉语言模型（比如 Qwen3-VL），不需要从零写 Dockerfile。这个 DLC 镜像已经把 PyTorch、FastAPI、Uvicorn 以及 NVIDIA 硬件加速的 FFmpeg 全打包好了。

准备工作：
你需要一个 AWS 账号，确保 Region 里的 g5.xlarge 实例配额足够，并且本地装好 eksctl 和 kubectl。

具体部署逻辑：
1. 选择镜像： 在 ECR 公共库里找 Ray Serve DLC 的标签。注意它分 EC2、EKS 和 SageMaker 三个版本，虽然底层依赖一样，但入口点（entrypoint）不同，部署到 EKS 必须选 EKS 专用镜像，否则启动会报错。
2. 编写部署脚本： 使用 Ray Serve 的 Python API 定义部署逻辑。

from ray import serve
from vllm import LLM, SamplingParams

@serve.deployment(ray_actor_options={"num_gpus": 1})
class VLMDeployment:
    def __init__(self):
        # 直接加载模型，无需担心 CUDA 版本冲突
        self.model = LLM(model="Qwen/Qwen2-VL-2B-Instruct")

    async def __call__(self, request):
        json_data = await request.json()
        prompt = json_data["prompt"]
        outputs = self.model.generate([prompt], SamplingParams(temperature=0.2))
        return {"text": outputs[0].outputs[0].text}

serve.run(VLMDeployment.bind())

3. 启动集群： 用 eksctl 快速起一个单节点 GPU 集群，然后把镜像拉进去跑。

避坑指南与实操感受

我试过自己用 Ubuntu 镜像配 CUDA 12.x + PyTorch + Ray，最头疼的是 FFmpeg 的硬件加速配置，经常出现库文件找不到或者版本不匹配导致视频预处理慢得像蜗牛。Ray Serve DLC 把这些细节给抹平了，直接拉镜像就能用，省掉了至少半天排查依赖的时间。

• 关于镜像选择： 别在这个环节偷懒。如果你在 EKS 上跑，千万别随手抓个 EC2 镜像用，虽然里面 PyTorch 版本一样，但 entrypoint 没对上会导致 Pod 启动后直接 CrashLoopBackOff。
• 性能表现： 在 g5.xlarge 上跑 2B 规模的 VLM，响应速度在可接受范围内，但如果并发高了，建议通过 ray_actor_options 调整副本数，而不是死磕单卡性能。
• 成本预警： g5.xlarge 的费用大概在每小时 1.2-1.6 美金左右（按区域不同有波动），这是按需计费的案例，实际成本取决于你的运行时间，记得不用时赶紧关掉，否则账单会让你惊喜。

选这个方案还是自己写 Dockerfile

如果你追求极致的镜像体积，或者有非常特殊的 C++ 依赖，自己写 Dockerfile 还是得做。但对于 90% 的 PyTorch 模型推理，用 DLC 的收益更高。

对比判断：

• 自建镜像： 启动快（如果精简得好），但维护成本极高。每次 CUDA 更新都要重新测试一遍所有依赖。
• Ray Serve DLC： 镜像体积较大，但稳定性极强。因为它是 AWS 官方针对 GPU 栈做过验证的，不用担心 PyTorch 和驱动版本打架。

总的来说，TorchServe 的掉队给很多开发者留下了坑，转向 Ray Serve 这种更现代、且有托管镜像支持的方案，能让工程师把精力从「配环境」转移到「调模型」上。