亚马逊云科技 2026 年 9 月 28 日发布两篇 vLLM-Omni 教程：一个镜像在 SageMaker AI 上起三个端点，并给出实测耗时。 这一段落在企业级 AI 与数据系统在真实客户环境里的落地交付：前置部署 Forward Deployed Engineer（FDE）在客户现场最常做的一步，不是训练模型，而是把一个开源多模态模型按客户云账号能接受的形态交付出去——端点怎么建、端口走哪个、请求怎么路由、跑完怎么删干净。这两篇教程的价值就在这里：三类端点的创建、调用与清理全部写成了可复制的命令，并附上了官方自己标注的单次运行读数。 一、先说清这两篇教程是什么，以及它们属于哪条产品线 亚马逊云科技 2026 年 9 月 28 日同一天发布两篇 Technical How-to，Part 1 讲实时语音，Part 2 讲图像与视频，两篇都被标成 Advanced (300) 难度。两篇的发布时间戳都是 2026-09-28T08:15:46-08:00，也就是 2026-09-28 16:15 UTC。四名署名作者是 Yadan Wei、Dmitry Soldatkin、Mona Mona 与 Daniel Wirjo；其中 Yadan Wei 来自亚马逊云科技的 Deep Learning Containers 团队，Dmitry Soldatkin 是 SageMaker Inference 的全球 Specialist Solutions Architecture 负责人。 这套教程的公共底座是 AWS vLLM-Omni 深度学习容器（Deep Learning Container，简称 DLC）。官方对 vLLM-Omni 的定位是：vLLM 只做文本自回归生成，vLLM-Omni 用一套异构流水线抽象把多阶段模型工作流编排起来，其中既包含自回归阶段也包含扩散（diffusion）阶段，对外提供流式输出与 OpenAI 兼容接口。AWS 的 vLLM-Omni DLC 做两件事：把上游 vLLM-Omni 的版本打包进 AWS 镜像，并补上一层给 SageMaker AI 用的路由中间件。 这属于一个更大的 DLC 系列：除了 vLLM-Omni，同系列还包含 WhisperX 与 llama.cpp。系列的前置文章用 Voxtral-Mini-4B Realtime 做语音识别（ASR），解决的是声音进模型的那一段；Part 1 接上输出侧，用 Qwen3-TTS 做「语音合成」（text-to-speech，TTS），把文本变成声音。 前置部署 Forward Deployed Engineer（FDE）在这条线上要看到的是：同一个交付模式可以在语音、图像、视频三类负载上复用，而不是每接一个多模态模型就重建一套推理栈。这也是 FDE 在客户现场最缺的东西——不是又一个模型清单，而是一份能直接跑的命令清单。 二、Part 1 的传输层：一个镜像加一条持久双向连接 实时语音端点的关键不在模型，在传输。官方把这条链路叫「双向流式」（bidirectional streaming），对外是一条跑在 HTTP/2 之上的全双工（full-duplex）WebSocket，客户端连的是 SageMaker Runtime 端点上的 8443 端口。连接进来以后，SageMaker 的推理 sidecar 负责把它转发到容器内 vLLM-Omni 的原生 WebSocket 路由。这套能力是 vLLM-Omni v1.5 的 DLC 才带上的，它补了双向流式所需的 capability 标签与路由中间件。 样例选用的路由是 v1/audio/speech/stream。输出的音频不是等整段生成完再返回，而是一边生成一边以 24 kHz 的 PCM 分片推回来，所以浏览器里听到的第一段声音早于模型生成完整段。这也是官方在开头给出的需求背景：语音智能体、互动教学、无障碍工具与客服助手都受不了长长的静默。 会话协议只有三条消息，写在前端就是三次 send。第一条 session.config，依次给 voice、language、response_format 设为 pcm、stream_audio 设为 true；第二条 input.text 带上要念的文本；第三条 input.done 表示输入结束。样例的 Gradio 界面每收到一个分片就播一次，状态栏显示分片数量与音频总字节数。对 FDE 来说，这三条消息加上 8443 端口，就是自研前端要对接的全部契约。 三、实例池：这是本轮最容易被报价搞错的一处 端点配置用了 SageMaker 的实例池（instance pool）。实例池是给一个生产变体定义的一串按优先级排序的兼容实例类型。样例的顺序是先 ml.g6.xlarge，取不到容量就依次退到 ml.g6e.xlarge、ml.g5.xlarge、ml.g4dn.xlarge。关键点是它最终只开一台实例，不是每个池条目各开一台。 但报价上的坑就埋在这里，原文给了两条明确提示。第一条：SageMaker 在创建端点时会为池里的每一个条目校验配额，所以这四个类型你都得有可用配额，缺一个就创建失败。第二条：如果 SageMaker 最终选中的不是你预期的那个类型，小时成本会跟着变。官方的规避办法是用 --instance-types 把池子收窄到你真正有配额、价格与性能都接受的类型上。前置部署 Forward Deployed Engineer（FDE）在客户现场最容易在这里翻车：客户账号里只有一个类型有配额，却照抄了四类型池，端点一直起不来。FDE 报价前先确认客户账号的配额分布，再决定池子放几个条目。 四、Part 1 的完整命令链，七步可跑通 第一步，拉代码：git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git。第二步，进目录：cd sagemaker-genai-hosting-examples/03-features/bidirectional-streaming-vLLM-Omni。第三步，建环境：python3.12 -m venv .venv，然后 source .venv/bin/activate，再 python -m pip install -r requirements.txt。第四步，给执行角色：export SAGEMAKER_EXECUTION_ROLE_ARN 指向你的 SageMaker AI 执行角色 ARN。样例默认区域是 us-east-1，换区域要显式传 --region。 第五步，建并保留端点：python deploy_bidi_stream.py --endpoint-name vllm-omni-bidi --region us-east-1 --keep-endpoint。这个脚本会用 DLC 建 SageMaker model、建端点配置、建实时端点，容器加载哪个模型由环境变量 SM_VLLM_MODEL 决定；脚本还会自动跑一次流式冒烟测试，把结果存成 validation-output.wav。第六步，跑前端：python sagemaker_bidi_tts_client.py --endpoint-name vllm-omni-bidi --region us-east-1，然后浏览器打开 http://127.0.0.1:6006。第七步，删干净：把同一条部署命令加 --delete-endpoint 再跑一次。 前置条件官方列了七条，其中四条容易漏：Python 需要 3.12 或更新版本；boto3 需要 1.40.0 或更新版本；还需要 SageMaker Runtime HTTP/2 Python 客户端 0.4.0；以及至少一种池内实例类型的端点配额。另外三项是 AWS 账号与 CLI 凭据、Git、SageMaker AI 执行角色。 五、Part 1 正文里点名的三个坑，加上一条成本坑 第一个坑是路径。模型调用路径必须省略前导斜杠，因为 SageMaker 在转发前会自己补一个，带斜杠上去会拼成两个斜杠。这是配置里最容易被忽略、又最难从报错里看出原因的一条。 第二个坑是推理 AMI 这一项必须设置。处理 HTTP/2 WebSocket 的 SageMaker sidecar 依赖它，不设就没有可用的 sidecar 转发链路，双向流式根本建立不起来。 第三个坑在前端侧：Gradio 的 --share 参数会额外开一个公网链接，官方明确说不需要就别开。在一个客户环境里做演示时，这一条直接关系到端点有没有被暴露到公网。 第四个坑是成本，官方写在清理段里：如果清理流程没有跑完，运行中的 GPU 端点会持续计费。判断标准是清理命令必须报告它删掉了三样东西——端点、端点配置与模型；没跑干净就去控制台或 API 手工删。FDE 在交付清单里应当把「确认三样都删掉」写成一条验收项，而不是一句口头提醒。 六、Part 2：同一个镜像再起第二个与第三个端点 Part 2 用同一个 pinned 的 vLLM-Omni DLC 镜像标签 omni-sagemaker-cuda-v1.6，建两个端点：一个实时端点跑 FLUX.2-klein-4B 做「图像生成」（image generation），一个异步端点跑 Wan2.1-VACE-1.3B 做「视频生成」（video generation）。两个端点共用同一个容器镜像，靠环境变量 SM_VLLM_MODEL 切换要加载的模型；官方给的理由是共镜像可以压住服务栈的差异，而分开建端点则让每个模型按自己的负载挑实例类型与推理方式。样例把资源名写进 .vllm_omni_media_state.json，凭据中途过期就刷新后加 --resume 续跑，脚本会复用已保存的资源。 路由机制值得单独记住：SageMaker 把推理流量统一发到 /invocations，DLC 读请求里的 CustomAttributes 头，再按它把请求转发到选定的 vLLM-Omni 路由。视频请求的上传路由是 route=/v1/videos/sync。样例在把视频请求上传到 S3 之前会先拼好 multipart 请求体，这样做是为了让真正发给 Videos API 的请求保持显式、可逐字段核对。 为什么图像走实时、视频走异步，官方给的是一句负载判断而不是规则。图像用实时是因为应用必须拿到图才能拼出下一个请求；视频耗时长、又带图条件化的 multipart 载荷，所以放到「异步推理」（asynchronous inference）上，由 SageMaker 用 S3 收输入、出输出，客户端去轮询结果位置。官方原话是这属于负载选择，不是所有视频模型都必须异步；选哪种推理方式应该按模型的延迟、载荷与客户交互方式来定。 链路里还有一步预处理容易漏。FLUX.2-klein 返回的是 OpenAI 兼容的 JSON，图片以 base64 形式嵌在里面；样例把这个 PNG 缩放到目标视频尺寸，再编码成 JPEG data URL 塞进 Wan VACE 的请求。官方给的原因是这一步转换让 JSON 里的图引用低于 Videos API 分段解析器的单段大小上限。另外，视频端点打开了变分自编码器（VAE）的分块处理（tiling），目的是压低视频解码时的峰值显存。 七、Part 2 里两个必须记住的数字与参数 第一个数字是 128000 字节。SageMaker 的 InvokeEndpointAsync 支持把请求内联在 Body 里，上限是 128000 字节；Body 与 InputLocation 只能二选一，不能同时给。这条教程用的是 InputLocation，原因是它那种带图条件化的 multipart 请求比 128000 字节的内联上限大。换句话讲，只要你的请求带图，基本就该走 S3 加 InputLocation，而不是内联。 第二个是视频的默认参数：17 帧、30 个扩散步。官方只建议在端点的快速冒烟测试里用 4 步，并明确说明 4 步在他们的复看里保不住原始构图。这是一条很少见的、直接写出来的质量取舍，照抄参数时不要只看数字小就觉得更省。FDE 给客户定默认参数时，把 30 步写成默认值、把 4 步写成仅用于冒烟测试。 八、官方给出的实测数字，以及它对这批数字的自我限定 在 us-east-1 的一次验证运行里，ml.g6.xlarge 上的图像端点从创建到 InService 用了 9 分 30 秒；ml.g6e.xlarge 上的视频端点用了 8 分 40 秒。热态下的默认调用出图用了 4.7 秒；Wan VACE 自报的模型耗时是 8.9 秒，命令行取回 MP4 一共用了 11.8 秒。前置部署 Forward Deployed Engineer（FDE）拿这几个数做交付排期时要注意，第一次部署还要额外算镜像与模型产物的下载时间，官方在 Part 1 里专门提示了这一点。 官方对这组数字的限定写得很直白：这些是单次运行的复现检查点（reproduction checkpoints），不是性能基准。也就是说 4.7 秒、8.9 秒、11.8 秒都只是一次观测，不能拿来当容量规划或者 SLA 依据。 九、局限：官方自陈的四条与我方补充的七条 官方自陈的第一条是上面那句话，这批读数是单次运行的复现检查点，不是性能基准。 官方自陈的第二条是异步只是负载选择，不是所有视频模型都要走异步推理。 官方自陈的第三条是 4 个扩散步在他们的复看里保不住原始构图，所以只能用于冒烟测试。 官方自陈的第四条是范围收窄：Part 1 只演示 TTS 的输出侧，语音识别端点与 TTS 端点之间的编排被明确排除在这次走查之外。 我方补充的第一条是成本完全没有数字。两篇教程都没有给每小时单价、也没有给这次验证的总花费，只有一句「选到不同实例小时成本会变」。要做客户报价必须回自己的区域价格页实算。 我方补充的第二条是资源口径缺失：没有给每个模型的显存要求、没有给并发上限、也没有给吞吐曲线，只有首次上线耗时与单次调用耗时。 我方补充的第三条是实例池的成本不确定性被轻描淡写：官方只说小时成本可能变化，没有给四个候选类型之间的价差区间。 我方补充的第四条是区域覆盖单一，走查全程只在 us-east-1 验证，其他区域要自己重跑。 我方补充的第五条是质量没有量化：语音与视频都只给了延迟数字，没有主观质量评分，也没有人工评测的通过率或样本量。 我方补充的第六条是企业安全配置未覆盖：VPC、私有链接、KMS 加密这些交付时必答的问题没有涉及。 我方补充的第七条是部署前提被略过：模型许可以及拉取镜像与模型产物是否需要公网都没有交代，物理隔离环境要自己改造这段下载链路；DLC 镜像标签是 pinned 的，但官方没有给镜像升级与回退策略。FDE 引用这套教程时，要把官方的单次运行限定一起引，不要只引 4.7 秒这一个数。 十、实用结论：谁该行动、怎么做、什么时候别照抄、怎么回滚 前置部署 Forward Deployed Engineer（FDE）可以把这两篇当作一份「在客户云账号里验证多模态交付」的最小配方。该行动的是三类人：需要在客户账号里给出可用多模态端点的交付团队；被「一个模型一套推理栈」拖住运维面的平台组；以及要给客户承诺「多久能出第一个可用端点」的人。 可以照着做的步骤。第一步，先只跑 Part 1，用七条命令拿到一个能出音频的端点，确认 8443 端口、侧车转发与 24 kHz PCM 这三段链路在客户网络里通。第二步，把 --instance-types 收窄到客户账号真正有配额的类型，别留四类型池。第三步，用 Part 2 的脚本以同一个镜像标签起图像与视频端点，图像走实时、视频走异步，并在 S3 上把成功输出与调用失败放到不同前缀下。第四步，把视频默认参数定成 17 帧、30 步，4 步只留给冒烟测试。第五步，上线前故意验一次清理链路，确认它能报出端点、端点配置与模型三者的删除结果。 适用条件要写清楚：能接受先从 us-east-1 起步；客户账号里至少一种池内 GPU 实例有配额；业务能接受异步视频的轮询延迟而不是同步等待；镜像与模型产物可以走公网拉取。这四条里有一条不成立，配方就要先改造再用，尤其是最后一条在金融与政企客户上基本必改。 回滚与退出方式分三层。第一层是端点：用样例自带的 --delete-endpoint 删除，它会连同端点、端点配置与模型一起删，比在控制台逐个点更不容易漏。第二层是部署中断：如果凭据在端点启动过程中过期，刷新凭据后用 --resume 复用已经建好的资源，不要从头重建，否则会出现孤儿端点。第三层是成本失控：优先删异步视频端点，它是长耗时、带大载荷的那一个；图像端点与语音端点可以留到定位完问题再删。 最后一条判断规则：把 4.7 秒当作「这个方向能跑通」的证据，但不要把它当成能写进 SOW 的延迟指标。官方自己把它们叫做复现检查点，你要拿来报价，就必须在自己的区域、自己的实例类型上重跑一遍。 原始来源： - https://aws.amazon.com/blogs/machine-learning/build-real-time-voice-applications-with-vllm-omni-on-sagemaker-ai-part-1/ - https://aws.amazon.com/blogs/machine-learning/generate-images-and-video-with-vllm-omni-on-sagemaker-ai-part-2/ - https://github.com/aws-samples/sagemaker-genai-hosting-examples