尧图网站建设 
用 litellm 打造语音交互系统从实时转写、语音合成到全链路落地【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm被各家语音 SDK 的差异搞得焦头烂额litellm 语音交互给出统一答案以 OpenAI 格式调用 100 模型一个网关同时搞定实时转写与语音合成。本文用可复跑的示例带你完整走一遍从麦克风到扬声器的全链路搭建。一、动手之前先拆解一次语音对话会经过哪四站需求拆解把能听会说翻译成四个技术环节想象你正对着电脑说帮我查一下明天的天气。这短短一句话背后其实要走四个环节麦克风把声波变成数字音频流采集→ 语音模型把音频流转成文字转写→ 大模型理解问题并生成回答推理→ 语音模型再把回答读出来合成。前两个环节属于语音识别后两个属于语音合成中间夹着的就是 LLM 本身。任何一个环节接错了供应商、写错了消息格式整条链路都会当场卡壳。选型对比为什么所有环节都交给 litellm 网关新手最容易踩的坑是每家一个 SDKBedrock 的转写接口长这样OpenAI 的实时接口又长那样光是鉴权和流式格式的适配代码就能写出几百行。litellm 的定位就是把这些差异全部吞掉——对外暴露统一的 OpenAI 格式对内把请求翻译成各家原生的调用。这么做有四个直接收益换模型不改业务代码把配置里的模型从xai/grok-2-vision-1212换成gpt-4o-realtime-preview脚本一行都不用动成本、限流、负载均衡开箱即用网关层自动记账语音会话同样计入用量一份配置管所有环节转写、推理、合成全部挂在同一个代理端口日志与审计集中化不用去每个供应商后台翻记录结论与其自己拼装多个 SDK不如让 litellm 做那个翻译官把精力留给业务本身。二、一条命令启动统一语音代理环境准备三条命令装齐运行依赖先把项目拉到本地再安装两个语音相关的库。下面这段在做的事克隆仓库、安装 litellm 本体以及装上麦克风采集库 pyaudio 和 WebSocket 通信库 websockets——后者是实时音频流的传输通道。git clone https://gitcode.com/GitHub_Trending/li/litellm cd litellm pip install -r requirements.txt pip install pyaudio websockets配置文件把多家实时语音模型挂到同一个端口litellm 的核心是一个代理服务器proxy所有请求先打到它身上再由它转发给真实供应商。在proxy_server_config.yaml里把想用的实时语音模型列进model_list即可。下面这段在做的事声明两个语音代理——一个指向 xAI 的 Grok 实时模型一个指向 OpenAI 的实时预览模型并给代理设置访问密钥master_key。model_list: - model_name: grok-voice-agent litellm_params: model: xai/grok-2-vision-1212 api_key: os.environ/XAI_API_KEY model_info: mode: realtime - model_name: openai-voice-agent litellm_params: model: gpt-4o-realtime-preview api_key: os.environ/OPENAI_API_KEY model_info: mode: realtime general_settings: master_key: sk-1234配置写好后一行命令启动代理litellm --config proxy_server_config.yaml --port 4000。记住端口号 4000后面所有示例脚本默认都连它。如果你要用 Bedrock 的 Nova Sonic 实时语音模型只需再追加一条model_name: bedrock-sonic的条目并填入 AWS 凭证后续转写示例就靠它。三、从麦克风到文本litellm 实时语音转写这样落地采样率选型先读懂这张参数对比表转写质量好不好一半取决于音频参数。实时语音模型对采样率有硬性要求参数对不上就会报错或声音变调。下表是cookbook/nova_sonic_realtime.py里验证过的默认值建议照抄参数取值作用备注INPUT_SAMPLE_RATE16000麦克风采集频率Nova Sonic 期望 16kHz 输入OUTPUT_SAMPLE_RATE24000扬声器播放频率24kHz 输出音质更饱满CHANNELS1单声道语音场景够用别开双声道CHUNK_SIZE1024每次读取的音频块大小越小延迟越低越大越稳关键结论输入 16k / 输出 24k 是示例验证过的黄金组合新手不要凭感觉乱改。跑通示例一个脚本体验边说边转项目 cookbook 目录下的nova_sonic_realtime.py是完整客户端它把采集 → 发送 → 接收 → 播放四个任务用 asyncio 并行跑起来。连接代理的 WebSocket 实时端点后客户端会先发送一段会话配置。下面这段在做的事告诉服务器用 matthew 的音色、以文本加音频两种方式回复并开启服务端语音活动检测VAD——由服务器判断你何时开口、何时停顿结束从而自动切分对话轮次。session_update { type: session.update, session: { instructions: 你是一个友好的助手保持回答简短。, voice: matthew, modalities: [text, audio], input_audio_format: pcm16, output_audio_format: pcm16, turn_detection: {type: server_vad, threshold: 0.5, silence_duration_ms: 500}, }, }运行python cookbook/nova_sonic_realtime.py对着麦克风说话终端会实时打印转写文字并在你停顿时自动收尾——这一步验证了 litellm 实时语音转写链路已经打通。四、让回复开口说话语音合成与全链路闭环消息收发一条指令换来音频流回复转写打通之后语音合成其实发生在同一条 WebSocket 连接上。以cookbook/livekit_agent_sdk/main.py这个 litellm 语音合成示例为例客户端先发送conversation.item.create把用户消息写入会话再发一条response.create并声明modalities: [text, audio]服务器就会把回答同时以文字增量response.output_audio_transcript.delta和音频增量两种形式推回来。你收到的文字和声音来自同一次响应天然对齐不需要自己拼接。全链路串联四站齐备的语音助手工作流把前面三节串起来一个完整的语音助手长这样麦克风采集 16kHz 音频 → 通过 WebSocket 推给代理代理转发给实时语音模型边说边出转写文本LLM 生成回复文本同时按配置合成语音扬声器以 24kHz 播放音频一轮对话完成全程只有代理 一个脚本没有为任何供应商单独写适配代码。这就是 litellm 语音交互方案最核心的体验环节多但代码少。五、上线之后三个指标盯住语音体验看板监控延迟、token 与成本一目了然语音应用最怕听起来卡。litellm 会把每次调用记录成一条 trace接入 Langfuse 等观测平台后你能看到从用户提问到首个 token 的延迟、整轮对话的 token 消耗与花费——例如下图里一次 gpt-4o 调用延迟 2.39 秒、13 个 prompt token 加 120 个 completion token、成本约 0.0012 美元还附带了完整的问答内容。上图litellm 语音交互的 Langfuse 追踪视图一次请求的延迟、token 与成本全部可视化请求与审计谁在调用、改了什么都有据可查代理后台还内置了 Request Logs 与 Audit Logs 两个标签页前者看实时请求流后者记录密钥、用户等对象的每一次创建与删除。当你想排查是不是某个测试密钥把预算打爆了这里就是第一现场。上图litellm 的审计日志视图每次密钥与用户操作都带时间戳和变更前后对比六、踩坑实录与下一步行动清单三个高频坑先帮你排掉采样率不匹配报错或声音变调时先核对第二节的参数表尤其是输入必须是 16kHzWebSocket 连接中断多半是代理没启动或端口不对确认litellm进程在 4000 端口活着首轮无声音VAD 阈值 0.5 对安静环境偏敏感可调到 0.6避免把环境音误判成说话下一步行动清单跑通第一个示例执行python cookbook/nova_sonic_realtime.py用一句话验证全链路深入事件流重点读litellm/realtime_api目录和livekit_agent_sdk里的说明理解 WebSocket 各事件类型的含义扩展多语言与音色把配置里的voice换成其他音色或替换模型为多语言模型实现中英文混说接上成本看板把 Langfuse 接入代理让每次语音对话都有账单可查最后提醒一句语音交互的瓶颈往往不在模型而在音频参数和网络延迟。先把参数按文中表格固定下来再逐步调优你的语音助手就能从能跑走到好用。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 litellm 打造语音交互系统：从实时转写、语音合成到全链路落地
用 litellm 打造语音交互系统从实时转写、语音合成到全链路落地【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm被各家语音 SDK 的差异搞得焦头烂额litellm 语音交互给出统一答案以 OpenAI 格式调用 100 模型一个网关同时搞定实时转写与语音合成。本文用可复跑的示例带你完整走一遍从麦克风到扬声器的全链路搭建。一、动手之前先拆解一次语音对话会经过哪四站需求拆解把能听会说翻译成四个技术环节想象你正对着电脑说帮我查一下明天的天气。这短短一句话背后其实要走四个环节麦克风把声波变成数字音频流采集→ 语音模型把音频流转成文字转写→ 大模型理解问题并生成回答推理→ 语音模型再把回答读出来合成。前两个环节属于语音识别后两个属于语音合成中间夹着的就是 LLM 本身。任何一个环节接错了供应商、写错了消息格式整条链路都会当场卡壳。选型对比为什么所有环节都交给 litellm 网关新手最容易踩的坑是每家一个 SDKBedrock 的转写接口长这样OpenAI 的实时接口又长那样光是鉴权和流式格式的适配代码就能写出几百行。litellm 的定位就是把这些差异全部吞掉——对外暴露统一的 OpenAI 格式对内把请求翻译成各家原生的调用。这么做有四个直接收益换模型不改业务代码把配置里的模型从xai/grok-2-vision-1212换成gpt-4o-realtime-preview脚本一行都不用动成本、限流、负载均衡开箱即用网关层自动记账语音会话同样计入用量一份配置管所有环节转写、推理、合成全部挂在同一个代理端口日志与审计集中化不用去每个供应商后台翻记录结论与其自己拼装多个 SDK不如让 litellm 做那个翻译官把精力留给业务本身。二、一条命令启动统一语音代理环境准备三条命令装齐运行依赖先把项目拉到本地再安装两个语音相关的库。下面这段在做的事克隆仓库、安装 litellm 本体以及装上麦克风采集库 pyaudio 和 WebSocket 通信库 websockets——后者是实时音频流的传输通道。git clone https://gitcode.com/GitHub_Trending/li/litellm cd litellm pip install -r requirements.txt pip install pyaudio websockets配置文件把多家实时语音模型挂到同一个端口litellm 的核心是一个代理服务器proxy所有请求先打到它身上再由它转发给真实供应商。在proxy_server_config.yaml里把想用的实时语音模型列进model_list即可。下面这段在做的事声明两个语音代理——一个指向 xAI 的 Grok 实时模型一个指向 OpenAI 的实时预览模型并给代理设置访问密钥master_key。model_list: - model_name: grok-voice-agent litellm_params: model: xai/grok-2-vision-1212 api_key: os.environ/XAI_API_KEY model_info: mode: realtime - model_name: openai-voice-agent litellm_params: model: gpt-4o-realtime-preview api_key: os.environ/OPENAI_API_KEY model_info: mode: realtime general_settings: master_key: sk-1234配置写好后一行命令启动代理litellm --config proxy_server_config.yaml --port 4000。记住端口号 4000后面所有示例脚本默认都连它。如果你要用 Bedrock 的 Nova Sonic 实时语音模型只需再追加一条model_name: bedrock-sonic的条目并填入 AWS 凭证后续转写示例就靠它。三、从麦克风到文本litellm 实时语音转写这样落地采样率选型先读懂这张参数对比表转写质量好不好一半取决于音频参数。实时语音模型对采样率有硬性要求参数对不上就会报错或声音变调。下表是cookbook/nova_sonic_realtime.py里验证过的默认值建议照抄参数取值作用备注INPUT_SAMPLE_RATE16000麦克风采集频率Nova Sonic 期望 16kHz 输入OUTPUT_SAMPLE_RATE24000扬声器播放频率24kHz 输出音质更饱满CHANNELS1单声道语音场景够用别开双声道CHUNK_SIZE1024每次读取的音频块大小越小延迟越低越大越稳关键结论输入 16k / 输出 24k 是示例验证过的黄金组合新手不要凭感觉乱改。跑通示例一个脚本体验边说边转项目 cookbook 目录下的nova_sonic_realtime.py是完整客户端它把采集 → 发送 → 接收 → 播放四个任务用 asyncio 并行跑起来。连接代理的 WebSocket 实时端点后客户端会先发送一段会话配置。下面这段在做的事告诉服务器用 matthew 的音色、以文本加音频两种方式回复并开启服务端语音活动检测VAD——由服务器判断你何时开口、何时停顿结束从而自动切分对话轮次。session_update { type: session.update, session: { instructions: 你是一个友好的助手保持回答简短。, voice: matthew, modalities: [text, audio], input_audio_format: pcm16, output_audio_format: pcm16, turn_detection: {type: server_vad, threshold: 0.5, silence_duration_ms: 500}, }, }运行python cookbook/nova_sonic_realtime.py对着麦克风说话终端会实时打印转写文字并在你停顿时自动收尾——这一步验证了 litellm 实时语音转写链路已经打通。四、让回复开口说话语音合成与全链路闭环消息收发一条指令换来音频流回复转写打通之后语音合成其实发生在同一条 WebSocket 连接上。以cookbook/livekit_agent_sdk/main.py这个 litellm 语音合成示例为例客户端先发送conversation.item.create把用户消息写入会话再发一条response.create并声明modalities: [text, audio]服务器就会把回答同时以文字增量response.output_audio_transcript.delta和音频增量两种形式推回来。你收到的文字和声音来自同一次响应天然对齐不需要自己拼接。全链路串联四站齐备的语音助手工作流把前面三节串起来一个完整的语音助手长这样麦克风采集 16kHz 音频 → 通过 WebSocket 推给代理代理转发给实时语音模型边说边出转写文本LLM 生成回复文本同时按配置合成语音扬声器以 24kHz 播放音频一轮对话完成全程只有代理 一个脚本没有为任何供应商单独写适配代码。这就是 litellm 语音交互方案最核心的体验环节多但代码少。五、上线之后三个指标盯住语音体验看板监控延迟、token 与成本一目了然语音应用最怕听起来卡。litellm 会把每次调用记录成一条 trace接入 Langfuse 等观测平台后你能看到从用户提问到首个 token 的延迟、整轮对话的 token 消耗与花费——例如下图里一次 gpt-4o 调用延迟 2.39 秒、13 个 prompt token 加 120 个 completion token、成本约 0.0012 美元还附带了完整的问答内容。上图litellm 语音交互的 Langfuse 追踪视图一次请求的延迟、token 与成本全部可视化请求与审计谁在调用、改了什么都有据可查代理后台还内置了 Request Logs 与 Audit Logs 两个标签页前者看实时请求流后者记录密钥、用户等对象的每一次创建与删除。当你想排查是不是某个测试密钥把预算打爆了这里就是第一现场。上图litellm 的审计日志视图每次密钥与用户操作都带时间戳和变更前后对比六、踩坑实录与下一步行动清单三个高频坑先帮你排掉采样率不匹配报错或声音变调时先核对第二节的参数表尤其是输入必须是 16kHzWebSocket 连接中断多半是代理没启动或端口不对确认litellm进程在 4000 端口活着首轮无声音VAD 阈值 0.5 对安静环境偏敏感可调到 0.6避免把环境音误判成说话下一步行动清单跑通第一个示例执行python cookbook/nova_sonic_realtime.py用一句话验证全链路深入事件流重点读litellm/realtime_api目录和livekit_agent_sdk里的说明理解 WebSocket 各事件类型的含义扩展多语言与音色把配置里的voice换成其他音色或替换模型为多语言模型实现中英文混说接上成本看板把 Langfuse 接入代理让每次语音对话都有账单可查最后提醒一句语音交互的瓶颈往往不在模型而在音频参数和网络延迟。先把参数按文中表格固定下来再逐步调优你的语音助手就能从能跑走到好用。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考