使用Amazon SageMaker AI和vLLM构建实时语音应用

使用 Amazon SageMaker AI 和 vLLM 构建实时语音应用程序 | Amazon Web Services

URL 来源: https://aws.amazon.com/blogs/machine-learning/build-real-time-voice-applications-with-amazon-sagemaker-ai-and-vllm/

发布时间: 2026-05-20T09:10:17-08:00

Markdown 内容: 语音助手、实时字幕、呼叫中心分析和无障碍工具都依赖于实时语音转文本技术，在这种技术中，您的应用程序通过单个持久连接流式传输音频并同时接收转录结果。传统的请求-响应推理在这方面存在不足，因为只有在接收到完整的音频录制后才能开始转录，这增加了延迟，破坏了这些工作负载所需的实时体验。

从2025年11月开始，您可以使用 Amazon SageMaker AI 实时推理的双向流式传输，在客户端和模型容器之间连续双向流式传输数据。vLLM 现在可以通过其 Realtime API 让您实时转录音频，在该 API 中，您使用 WebSockets 实现客户端和服务器之间的双向流式传输。

在本文中，我们将这两种功能结合在一起。我们将展示如何使用具有双向流式传输功能的 vLLM 容器，将 Mistral AI 的紧凑型实时语音模型 Voxtral-Mini-4B-Realtime-2602 部署到 SageMaker AI 端点。结果是一个完全托管的语音转文本服务，音频流入，转录结果实时流出。您可以在 GitHub 仓库 中跟随完整的示例进行操作。

运行语音 AI 应用程序所需的关键功能

构建生产语音 AI 应用程序，无论是语音助手、实时字幕服务还是呼叫中心分析管道，都需要多个基础设施组件协同工作，并且具有严格的延迟预算。Amazon SageMaker AI 和 vLLM 分别解决了这个堆栈的不同部分，它们共同提供了一个端到端的解决方案，消除了无差别的繁重工作。以下是这些应用程序的需求以及每个组件如何实现：

• 具有高效 GPU 服务能力的实时语音模型。 任何语音 AI 应用程序的核心都是一个语音转文本（ASR）模型，它增量处理音频，在音频到达时生成转录标记，而不是等待完整录音。vLLM 通过其 Realtime API 提供这些模型服务，这是一个位于 /v1/realtime 的原生 WebSocket 端点，支持多种语音模型，并采用分段 CUDA 图执行来减少 GPU 内核启动开销，直接转化为流式转录过程中的每标记延迟降低。由于 vLLM 是开源的，您可以在服务层完全控制模型配置、量化和编译设置，不存在供应商锁定问题。
• 双向流式传输基础设施。 传统的请求-响应 API 强制要求客户端在上传整个音频文件后服务器才开始处理。语音 AI 应用程序需要持久的全双工连接，客户端流式传输音频，服务器同时流式返回转录结果。SageMaker AI 通过端口 8443 上的原生 HTTP/2 双向流式传输解决了这个问题，自动在客户端的 HTTP/2 事件流协议和容器端的 WebSocket 之间建立桥接。您无需构建或管理此协议转换层。SageMaker AI 透明地处理这一切。
• 音频处理和编码。 来自麦克风或电话系统的原始音频以各种格式和采样率到达。在到达模型之前，必须对其进行重新采样（通常为 16 kHz 单声道 PCM16），分割成适当大小的片段，并进行 base64 编码以便传输。客户端管道处理此转换，而 vLLM 的 Realtime API 定义了协议：base64 编码的 PCM16 块通过 WebSocket 流入，转录标记流回，SageMaker AI 的双向流同时携带两个方向的数据。
• 连接管理和弹性。 SageMaker AI 使用 ping/pong 保持活动帧维护 WebSocket 连接，对您的容器进行健康检查，并通过 Amazon CloudWatch 提供端点级别的监控。这为您提供了生产可观察性和连接弹性，无需自定义工具。

总之，vLLM 为您提供高性能、开源的模型服务，具有原生 WebSocket 流式传输功能，而 SageMaker AI 将其包装在具有协议桥接、健康监控和运维工具的托管基础设施中。两者结合，让您无需构建自定义流式传输基础设施或管理 GPU 服务器，就能从 Hugging Face 上的语音模型转变为生产就绪的实时转录服务。

解决方案概述

在本教程结束时，您将拥有：

• 一个基于 SageMaker AI vLLM 深度学习容器 构建的自定义 Docker 容器，启用了双向流式传输。
• 一个运行 Voxtral-Mini-4B-Realtime-2602 的 SageMaker AI 端点。
• 一个 Python 客户端，使用 SageMaker AI 双向流式传输 SDK 将音频文件流式传输到端点并实时接收转录结果。
• 一个基于 Gradio 的实时麦克风演示，可在您说话时转录语音。

该解决方案连接了三层：

客户端到 SageMaker AI：您的应用程序使用 HTTP/2 连接到 SageMaker AI 运行时端点（端口 8443），该协议支持多路复用的双向流式传输。vLLM 实时协议中的每个 JSON 消息（如 input_audio_buffer.append 或 transcription.delta）都包含在一个 RequestPayloadPart 中，DataType 设置为 "UTF8"。这告诉 SageMaker AI 将数据作为 WebSocket 文本帧转发。响应消息以 ResponsePayloadPart 事件的形式到达。

SageMaker AI 到 Docker 容器：SageMaker AI 自动桥接 HTTP/2 事件流和 WebSocket 协议。它在 ws://localhost:8080/invocations-bidirectional-stream 处建立到容器的 WebSocket 连接，这是 SageMaker AI 期望双向流式传输的路径，并在两个方向上转发数据帧。当您在客户端中设置 DataType="UTF8" 时，桥接器会向容器发送 WebSocket 文本帧。

Docker 容器：在容器内部，一个轻量级的 FastAPI 桥接器（app.py）在端口 8080 的 /invocations-bidirectional-stream 路径上监听。当它从 SageMaker AI 接收到 WebSocket 连接时，它会打开第二个到 vLLM 实时 API 的 WebSocket 连接（位于 ws://localhost:8081/v1/realtime），并双向转发消息。桥接器处理 SageMaker AI 期望路径与 vLLM 原生端点之间的路由转换，同时文本帧保持不变地通过。vLLM 服务器在端口 8081 上运行，并在默认的 /v1/realtime WebSocket 端点上提供其实时 API，无需您修补源代码。桥接器还将 /ping 健康检查代理到 vLLM 的健康端点，满足 SageMaker AI 托管合约。

实时 API 协议

实时 API 提供基于 WebSocket 的流式音频转录，允许在录制音频时进行实时语音转文本。发送前，您必须将音频编码为 16 kHz 采样率、单声道的 base64 PCM16。协议中的消息流程如下：

1. 客户端连接到 ws://host/v1/realtime。
2. 服务器发送 session.created 事件。
3. 客户端可选地发送带有模型/参数的 session.update。
4. 准备发送音频时，客户端发送 input_audio_buffer.commit。
5. 客户端发送带有 base64 PCM16 数据块的 input_audio_buffer.append 事件。
6. 服务器发送带有增量文本的 transcription.delta 事件。
7. 服务器发送带有最终转录和使用统计信息的 transcription.done。
8. 对于下一个语音片段，从步骤 5 重复。

模型一旦拥有足够的音频上下文就开始转录，同时客户端继续发送音频块，将 transcription.delta 令牌流式传输回客户端。您无需在接收结果前等待发送完整个音频。可选地，客户端可以发送带有 final=True 的 input_audio_buffer.commit 来表示音频输入已完成，这在流式传输音频文件时很有用。

先决条件

• 具备 SageMaker AI 权限 的 AWS 账户（包括用于双向流式传输的 sagemaker:InvokeEndpoint*）。
• Docker 环境（启用 Docker 的 SageMaker AI Studio，或 本地机器）。
• Python 3.12+。
• 访问 Hugging Face 上的 Voxtral-Mini-4B-Realtime-2602 模型。
• 用于调用双向流式 API 的 aws-sdk-sagemaker-runtime-http2 Python 包。

构建自定义 vLLM 容器

我们从 SageMaker AI vLLM 深度学习容器开始，添加三样东西：双向流式传输 Docker 标签、一个在 SageMaker AI 期望路由和 vLLM 原生 API 路径之间进行转换的 WebSocket 桥接器，以及一个运行这两个进程的入口点。

Dockerfile

FROM public.ecr.aws/deep-learning-containers/vllm:0.17.1-gpu-py312-cu129-ubuntu22.04-sagemaker-v1.0-soci

# 告诉 SageMaker AI 此容器支持双向流式传输
LABEL com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true

WORKDIR /opt/ml/code

# 安装桥接器依赖项
COPY requirements.txt .
RUN pip install --upgrade --no-cache-dir -r requirements.txt

# WebSocket 桥接器：路由 /invocations-bidirectional-stream → /v1/realtime
COPY app.py .
COPY sagemaker-entrypoint.sh entrypoint.sh
RUN chmod +x entrypoint.sh

ENTRYPOINT ["./entrypoint.sh"]

HEALTHCHECK --interval=30s --timeout=10s --start-period=120s --retries=3 \
  CMD curl -f http://localhost:8080/ping || exit 1

代码

Docker 标签 com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true 向 SageMaker AI 表示此容器支持双向流式传输。没有此标签，SageMaker AI 将不会建立到容器的 WebSocket 连接。

桥接器（app.py）是一个小型 FastAPI 应用程序，在面向 SageMaker AI 的端口 8080 上监听，并将 WebSocket 连接转发到内部端口 8081 上的 vLLM /v1/realtime 端点。它还将 /ping 健康检查代理到 vLLM 的 /health。

VLLM_WS_URL = "ws://localhost:8081/v1/realtime"

@app.websocket("/invocations-bidirectional-stream")
async def websocket_bridge(sm_ws: WebSocket):
    await sm_ws.accept()
    async with websockets.connect(VLLM_WS_URL) as vllm_ws:

async def sm_to_vllm():
    """Forward SageMaker AI → vLLM."""
    while True:
        message = await sm_ws.receive()
        if "text" in message and message["text"]:
            await vllm_ws.send(message["text"])
        elif "bytes" in message and message["bytes"]:
            # Fallback for non-UTF8 clients
            await vllm_ws.send(message["bytes"].decode("utf-8"))

async def vllm_to_sm():
    """Forward vLLM → SageMaker AI."""
    async for msg in vllm_ws:
        if isinstance(msg, str):
            await sm_ws.send_text(msg)
        elif isinstance(msg, bytes):
            await sm_ws.send_bytes(msg)

await asyncio.gather(sm_to_vllm(), vllm_to_sm())

代码

由于客户端设置了 DataType="UTF8"，SageMaker AI 将文本帧传递给桥接服务，桥接服务直接将这些帧转发到 /v1/realtime 的 vLLM，无需进行帧类型转换。sm_to_vllm 中的二进制到文本解码是针对未设置 DataType 的客户端的备用方案。

部署到 SageMaker AI 端点

我们部署到 SageMaker AI 实时端点，该端点将处理我们的请求。

配置模型环境和部署模型

SM_VLLM_* 环境变量配置 vLLM 的服务器参数：

vllm_env = {
    "SM_VLLM_MAX_MODEL_LEN": "45000",
    "SM_VLLM_COMPILATION_CONFIG": '{"cudagraph_mode": "PIECEWISE"}'
}

代码

Voxtral-Mini-4B 支持高达 262,144 个 token 的上下文。我们在这里设置 MAX_MODEL_LEN=45000，这足以实时记录大约一小时的音频（3600 秒 / 每个 token 0.08 秒）。根据您预期的音频持续时间调整此值。带有 cudagraph_mode: PIECEWISE 的 COMPILATION_CONFIG 提供 CUDA 图优化，以提高推理吞吐量。

以下代码片段创建 SageMaker AI 端点：

# Create model
voxtral_model = Model.create(
    model_name=model_name,
    primary_container=ContainerDefinition(
        image=inference_image,
        model_data_source=ModelDataSource(
            s3_data_source=S3ModelDataSource(
                s3_uri=f"{model_artifact}/",
                s3_data_type="S3Prefix",
                compression_type="None",
            )
        ),
        environment=vllm_env
    ),
    execution_role_arn=role,
)

# Create config
endpoint_config = EndpointConfig.create(
    endpoint_config_name=endpoint_config_name,
    production_variants=[
        ProductionVariant(
            variant_name="AllTraffic",
            model_name=model_name,
            initial_variant_weight=1.0,
            instance_type=instance_type,
            initial_instance_count=1,
            model_data_download_timeout_in_seconds=health_check_timeout,
        )
    ]
)

# Create endpoint
endpoint = Endpoint.create(
    endpoint_name=endpoint_name,
    endpoint_config_name=endpoint_config_name
)

endpoint.wait_for_status("InService")

代码

使用双向流进行测试

端点运行后，我们使用 aws-sdk-sagemaker-runtime-http2 Python SDK 调用它。该 SDK 通过 SageMaker AI 运行时端点端口 8443 上的 HTTP/2 事件流进行通信。

流式传输音频并接收转录

仓库 包含一个完整的客户端 sagemaker_bidi_client.py，它将双向流式 SDK 包装在 SageMakerRealtimeClient 类中。当 transcribe_audio() 运行时，它首先发送一个 session.update 事件来选择模型，然后以 4 KB PCM16 块的形式流式传输音频文件。接收循环作为后台 asyncio.Task 运行，而主协程发送音频块，以便 HTTP/2 流的两个方向同时处于活动状态。

使这种重叠可观察的关键细节是每次发送后的 await asyncio.sleep(chunk_duration)。它控制传输速度以匹配实时播放（在 16 kHz 下，每个 4 KB 块约 128 ms），并将控制权让给事件循环，使接收任务有机会处理 transcription.delta 事件，同时还有更多音频正在传输。如果没有这个让步，块传输速度将比模型生成输出的速度快，即使底层流是双向的，交互看起来也是顺序的。在接收端，循环根据事件类型进行分发：正常的 ResponseStreamEventPayloadPart 事件携带 JSON 消息（session.created、transcription.delta、transcription.done），而 ResponseStreamEventModelStreamError 和 ResponseStreamEventInternalStreamFailure 则单独处理，以便模型级别和平台级别的故障能够通过清晰的诊断信息呈现，而不是在负载路径中丢失。

运行客户端

python sagemaker_bidi_client.py  ./audio.wav \
  --region us-east-1

代码

输出会在音频发送时实时流式显示转录文本。Delta token 逐个字符出现，同时音频块在后台继续流式传输。

使用 Gradio 进行实时麦克风演示

基于文件的客户端对于测试很有用，但双向流在实时音频中提供最低延迟。仓库 包含一个基于 Gradio 的麦克风客户端（sagemaker_bidi_microphone_client.py），它从您的麦克风捕获音频并实时流式传输到 SageMaker AI：

python sagemaker_bidi_microphone_client.py \
  --endpoint-name  \
  --region us-east-1

代码

麦克风客户端

麦克风客户端使用与基于文件的客户端相同的 DataType="UTF8" 设置和 vLLM Realtime API 协议。它通过 Gradio 的流式音频输入从浏览器捕获音频，重新采样为 16 kHz PCM16，将每个块编码为 base64，并通过 SageMaker AI 双向流发送。说话者说话时，转录文本会在 UI 中更新，而无需等待其话语结束。

考虑事项

vLLM Realtime API 期望音频为 16 kHz 单声道的 base64 编码 PCM16。如果您的源音频使用不同的格式或采样率，请在流式传输之前进行转换。Voxtral-Mini-4B-Realtime-2602 是一个 4B 参数模型，可以适配单个 GPU，因此 ml.g6.4xlarge（1x NVIDIA L4）实例就足以托管它。

SageMaker AI 每 60 秒使用 ping/pong 帧维护 WebSocket 连接，如果 5 个连续的 ping 未得到响应，连接将关闭。对于长时间运行的会话，请确保您的客户端处理重新连接，而不是假设流将无限期保持打开状态。对于您的用例，块大小和节奏也值得调整。此示例使用 4 KB 音频块，对应于 16 kHz PCM16 下约 128 毫秒的音频。较小的块可减少延迟但增加每条消息的开销，而较大的块可提高吞吐量但会增加延迟。适当的值取决于您应用程序的延迟要求。

清理

为避免持续收费，测试完成后请删除在此演练期间创建的资源。SageMaker AI 端点只要服务中就会为基础实例计费，因此删除它是最重要的步骤。配套的 notebook 包含一个清理单元格，用于删除端点、端点配置和模型。如果您不再需要 Amazon Elastic Container Registry (Amazon ECR) 中的自定义容器镜像或上传到 Amazon Simple Storage Service (Amazon S3) 的模型工件，请单独删除这些资源以停止产生存储费用。

结论

在本文中，我们演示了如何在 Amazon SageMaker AI 上部署 Mistral AI 的 Voxtral-Mini-4B-Realtime-2602 进行实时语音转录，结合了 vLLM 的 Realtime WebSocket API 和 SageMaker AI 双向流功能。

SageMaker AI 双向流基础设施充当 HTTP/2 事件流（面向客户端）和 WebSocket（面向容器）之间的透明桥梁。通过此桥梁，支持基于 WebSocket 的文本帧 API 的模型服务器（如 vLLM 的 Realtime API）可以在 SageMaker AI 管理的基础设施后以最少的适配进行部署。您只需要一个 Docker 标签、一个路由重新映射和标准的 SageMaker AI 托管合同。

这种模式不仅限于语音转文本。需要连续双向通信、语音助手、实时翻译、交互式音频生成或多轮流式对话的用例可以使用相同的架构。我们通过一个用于测试的基于文件的客户端和一个用于交互式使用的基于 Gradio 的实时麦克风客户端演示了这一点。

下一步

使用 vLLM 在 SageMaker AI 双向流端点上部署您自己的 Realtime API 兼容模型。完整的 notebook、基于文件的客户端和实时麦克风演示可在 GitHub 上获取，以帮助您入门。从那里，考虑以下方向来构建您在本文中部署的内容：

将 Gradio 演示扩展为完整的应用程序。使用实时麦克风客户端作为起点，并通过将转录输出链接到文本 LLM 来添加诸如转录导出或下游摘要等功能。

针对您的延迟和成本目标调整端点。尝试实例类型、块大小和 vLLM 编译设置，以找到适合您工作负载的正确平衡。

部署不同的实时模型。通过更新模型工件和传递给 sagemaker_bidi_client.py 和 sagemaker_bidi_microphone_client.py 客户端的模型标识符，将 Voxtral-Mini-4B-Realtime-2602 替换为另一个 vLLM Realtime API 支持的模型。

了解有关 SageMaker AI 双向流的更多信息。查看文档以了解完整的 HTTP/2 事件流合同，并将其应用于语音助手或交互式音频生成等用例。

关于作者