AWS发布vLLM-Omni on SageMaker AI第二部分：文生图接图生视频
同一vLLM-Omni DLC部署FLUX.2-klein实时端点与Wan2.1-VACE异步端点，图片内联返回、视频写入S3，AWS给出实测启动与推理耗时作为复现检查点。
AI解读：AWS这篇教程的核心是用同一个vLLM-Omni深度学习容器（DLC）在SageMaker AI上部署两个端点：一个实时端点跑FLUX.2-klein-4B做文生图，一个异步端点跑Wan2.1-VACE-1.3B做图生视频。流程是先把文字提示词生成静态图，再把图和运动提示词送进视频端点。
之所以分开两种推理模式，是因为两者行为不同：图片模型直接把结果内联返回，应用拿到base64编码的PNG后还要构造下一个请求；视频生成耗时更长、带图条件化的multipart负载，走异步推理后请求排队、输入输出都放在S3，客户端轮询结果位置，不用一直挂着一个同步连接。
对想自建生成媒体管线的团队，实用信息是容器镜像可以共用、端点必须分开，每个模型按自己的显存和延迟选实例类型。但这次公布的是单次复现检查点而非性能基准：图片端点约 9 分 30 秒达到InService，视频端点约 8 分 40 秒，默认视频设置是 17 帧、30 步扩散。
普通用户暂时不需要为此做什么；真正相关的是要跑GPU端点的开发者，注意运行中的端点会持续计费，且教程提醒 4 步扩散只适合快速冒烟测试，AWS在评审中发现低步数没有保住源图构图。
AWS机器学习博客发布“Generate images and video with vLLM-Omni on SageMaker AI – Part 2”，演示用同一个AWS vLLM-Omni Deep Learning Container（DLC）在SageMaker AI上部署两个端点：一个实时端点运行FLUX.2-klein-4B做文生图，一个异步端点运行Wan2.1-VACE-1.3B做图生视频。工作流把文字提示词生成静态图，再把图片和运动提示词传给视频端点，最后从Amazon S3取回MP4，并提供可选的Streamlit界面。
两个端点，两种推理模式
部署脚本通过修改环境变量SM_VLLM_MODEL，把同一个固定版本的AWS vLLM-Omni DLC镜像加载成不同模型：一个端点加载FLUX.2-klein，另一个加载Wan VACE。AWS称，共用容器镜像可以减少服务栈差异，而分开的端点让每个模型使用适合自身工作负载的实例类型和推理选项。
实时端点把请求路由到 /v1/images/generations，异步端点把请求路由到 /v1/videos/sync。SageMaker AI把推理流量发往 /invocations，DLC读取CustomAttributes头，再把请求转发到选定的vLLM-Omni路由。Amazon S3存放视频生成的多段请求和生成的MP4。
应用把图片提示词发给FLUX.2-klein，收到base64编码的PNG；它把图片缩放到视频尺寸、转换成紧凑的JPEG data URL，并把该引用插入Wan VACE请求。异步推理从Amazon S3读取multipart请求，把MP4写入返回的输出位置。示例把成功响应和调用失败分别存放在不同的S3前缀下。
- 图片端点：SageMaker AI实时推理，结果内联返回，应用需要拿到直接响应才能构造下一个请求。
- 视频端点：SageMaker Asynchronous Inference，请求排队、输入输出走Amazon S3，客户端轮询结果位置。
- AWS强调这是工作负载选择，而不是所有视频模型都必须遵守的规则，应按模型延迟、负载和客户端交互方式选择推理选项。
代码与部署参数
示例代码位于GitHub的sagemaker-genai-hosting-examples仓库，目录为 03-features/vllm-omni-image-video。前置条件包括：配置了AWS CLI或AWS SDK凭据的AWS账号、能访问示例S3桶的SageMaker AI执行角色、创建和调用端点权限、所选区域有ml.g6.xlarge和ml.g6e.xlarge端点配额、Git、Python 3.11或更高版本。教程使用美国东部（弗吉尼亚北部）区域。
部署脚本固定使用omni-sagemaker-cuda-v1.6，创建实时图片端点和异步视频端点，并把资源名写入 .vllm_omni_media_state.json。视频端点开启变分自编码器（VAE）分块，以降低视频解码时的峰值内存。如果端点启动过程中本地AWS凭据过期，可刷新后加 --resume重跑，脚本会复用已保存的资源。
示例使用固定的ml.g6.xlarge和ml.g6e.xlarge实例类型。对于实时图片端点，SageMaker容量感知实例池可以按优先级列出兼容实例类型；AWS建议先验证每个候选类型满足图片模型的GPU显存和性能要求，再添加实例池。异步视频端点保持固定实例类型。
生成命令同时接收图片提示词和运动提示词。视频请求默认使用 17 帧和 30 步扩散。示例先把完整的multipart视频请求体构建好再上传到S3，以保持发给vLLM-Omni Videos API的请求明确；这种把图片转成JPEG的做法也让JSON安全的图片引用低于Videos API multipart解析器的单部分大小限制。
- 部署命令：python deploy.py --role-arn "$SAGEMAKER_ROLE_ARN" --region us-east-1
- 端到端命令：python generate.py --image-prompt "..." --video-prompt "..."
- Streamlit应用：两个端点都达到InService后运行streamlit run app.py
- 清理：python cleanup.py删除端点、端点配置和模型；清理脚本会保留S3输出前缀下的生成对象，AWS提醒运行中的GPU端点会持续产生费用。
内联body上限与实测数据
AWS说明，对于较小的请求，InvokeEndpointAsync也可以通过Body接受最多 128,000 字节的内联请求数据，但Body和InputLocation只能选其一。该工作流使用InputLocation，因为带图片条件的multipart请求大于InvokeEndpointAsync文档所写的 128,000 字节内联Body设计参数。
AWS公布了一组在美国东部（弗吉尼亚北部）区域的单次验证数据：ml.g6.xlarge图片端点用 9 分 30 秒达到InService，ml.g6e.xlarge视频端点用 8 分 40 秒达到InService；一次热启动默认调用在 4.7 秒内返回图片；Wan VACE报告 8.9 秒模型延迟，CLI在 11.8 秒内取回MP4。AWS明确称这些单次运行值是复现检查点，不是性能基准。
默认视频设置使用 17 帧和 30 步扩散；AWS提醒，只有在快速端点冒烟测试时才用 4 步，因为在其评审中，较低的步数没有保住源图构图。