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做语音助手的第三周我数了数手头的适配代码转写一套、合成一套、流式对话又一套每换一家模型厂商就要重写一遍。直到同事甩给我一个开源项目litellm——一个把 100 多家大模型 API 统一成 OpenAI 格式的 AI 网关语音转写、语音合成这些活儿终于能在一套配置里解决了。这篇文章记录我踩过的路以及最终跑通的完整流程。深夜事故当语音 API 碎片化找上门事情的起因很简单我要给内部工具加一个能说话的助手。结果从第一天开始画风就不对劲。第一家厂商的转写接口要 WebSocket 长连接第二家却只提供 REST 轮询第三家的流式协议又完全不同转写、对话、合成是三个互相独立的服务我得分别写三个客户端、三套鉴权、三份错误处理最要命的是换模型这个需求——老板今天说想试试 A 厂的新模型明天又觉得 B 厂便宜而我每次都要跟着改业务代码。那晚我盯着屏幕上三份风格迥异的 SDK 文档突然意识到我需要的不是更多的适配代码而是一个中转站——所有模型都往里接业务代码只跟中转站对话。中转站思维litellm 把 100 多家模型收进同一套接口litellm 干的事情用一句话概括就是用一套 OpenAI 格式的接口替你转发给背后的任何大模型。它自称是最快、最轻的 AI 网关底层用 Rust 核心加速对外提供 Python SDK目前已经覆盖 Bedrock、Azure、OpenAI、Anthropic、VertexAI、vLLM、Nvidia NIM 等 100 多家服务商。把它想成机场的中转柜台就很形象旅客你的请求不管从哪里来只要递上统一格式的登机牌OpenAI 格式柜台就会帮你分流到对应的登机口各家模型 API。你不再需要知道每个登机口长什么样。除了统一格式它顺手还做了几件运营层面的活负载均衡多个模型按策略分发请求某一家挂了自动切走成本追踪每一次调用的花费都有记录方便按团队、按用户对账护栏Guardrails可以在请求前后插入校验规则拦截敏感内容日志与观测请求链路、token 用量、延迟指标都能接出去。这些能力对语音这类实时、高频、烧钱的场景尤其重要后面会讲到怎么用。最小可用配置三分钟把代理服务器跑起来先把它拉下来装好git clone https://gitcode.com/GitHub_Trending/li/litellm cd litellm pip install -r requirements.txt接着写一份最简配置。以仓库里cookbook/livekit_agent_sdk/config.example.yaml的思路为例核心就是在model_list里登记你手头的模型并给每个模型标上用途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这里有两个细节值得注意一是os.environ/前缀表示密钥从环境变量读取避免把密钥写死在文件里二是model_info.mode: realtime专门标记这是实时语音模型代理会据此路由到实时通道。如果要用 AWS Bedrock 上的 Nova Sonic把model换成bedrock/...并补上aws_access_key_id、aws_secret_access_key、region_name即可。启动代理就一条命令litellm --config proxy_server_config.yaml --port 4000从这之后你的所有业务代码只认localhost:4000这一个地址。想换模型改配置不动代码——这正是中转站最大的价值。实时语音转写实操麦克风声音如何变成文字流仓库里cookbook/nova_sonic_realtime.py是一个可以直接跑的实时语音客户端核心思路分五步采集用 PyAudio 从麦克风读音频按 16kHz、单声道、16 位 PCM 的格式分包连接通过 WebSocket 连上代理的实时端点ws://localhost:4000/v1/realtime?modelbedrock-sonic带上 Bearer 密钥下配置发送一个session.update消息告诉模型你是谁、什么音色、怎么判断一句话说完了传音频把麦克风采集到的每个分片做 base64 编码通过input_audio_buffer.append持续上传说完话再发一个input_audio_buffer.commit通知处理收结果服务端推回的response.text.delta就是逐字出现的转写文本直接打印或落库都行。转写质量好不好多半取决于会话配置里几个参数我把它们列成了一张对照表参数作用建议起点输入采样率麦克风采集规格16000 HzNova Sonic 期望值输出采样率合成音频规格24000 HzVAD 阈值多响的声音才算开口0.5静音时长安静多久算说完了500 ms前缀填充开口前多保留一点语音300 msVAD语音活动检测是自动判断你什么时候开始、什么时候结束说话的机制调大了不容易误触发但可能漏听轻声音调小了敏感但容易把环境噪声当人声。新手先用默认值跑通再按实际场景微调。语音合成怎么做让模型开口的两种姿势语音合成在 litellm 里有两条路可以走取决于你的产品形态。姿势一实时语音对话。还是上面那个 Nova Sonic 客户端——它其实是语音进、语音出的实时对话模型在返回转写文本的同时会通过response.audio.delta把合成音频分片推回来客户端解码后直接用扬声器播放。这种方案延迟低、体验自然适合语音助手、客服机器人这类对讲机式产品。姿势二文本型语音 Agent。cookbook/livekit_agent_sdk/main.py展示了另一种玩法通过代理连上 xAI 的实时语音模型先用conversation.item.create把用户消息塞进会话再发response.create请求回复最后从response.output_audio_transcript.delta里逐段接收合成结果。它的妙处在于代码完全不感知后端是哪家——配置里把grok-voice-agent换成openai-voice-agent同一份代码立刻从 xAI 切到 OpenAI 的实时模型。简单说想省事、要最低延迟走姿势一想复用已有的文本对话链路、逐步升级走姿势二。串起完整对话闭环转写、理解、合成三步走把前面几块拼起来一个完整的语音对话闭环其实只有三步像一场传话筒接力你说→ 麦克风采集的音频流实时送进代理模型完成语音转写它想→ 转写出的文字作为上下文进入大模型生成回复内容它说→ 回复文本被转成语音分片回传扬声器播放给你听。值得强调的是第 2 步和第 3 步在实时模型里往往是边生成边合成的所以你听到的不是等全部文本算完才开口而是像真人聊天一样断断续续地回应。这也是为什么这种架构能把说完话到听到回答的等待感压到很低。如果暂时没有真实的 Bedrock 或 xAI 凭证也可以先在配置里挂一个本地 mock 端点把链路整体走通再把模型参数替换成真实服务业务代码一行都不用动。上线后盯这三块延迟、成本与调用日志语音交互系统跑起来之后真正要花心思的是看得见。litellm 的观测能力刚好覆盖我关心的三块。延迟通过success_callback: [prometheus]可以把指标接到 Prometheus配合 Grafana 观察首 token 时间、端到端延迟等关键数字。实时语音场景对延迟极其敏感建议把 P95 延迟单独拎出来盯。成本每次调用的 token 数和费用都会被记录可以按用户、按团队、按模型维度拆账。语音对话往往一次交互就吃掉几千 token没有成本视图的话月底账单会教你做人。调用追踪与审计下面这张 Langfuse 集成的追踪图能直观看到一次语音交互请求的完整链路——用户说了什么、模型回了什么、耗时多少、花了多少钱定位问题比大海捞针高效得多。除了请求追踪代理还自带审计日志密钥的创建、轮换、删除等敏感操作都会留下操作人、时间点和变更前后的完整记录。多人在一个网关下协作时这张表能帮你快速回答这个密钥是谁、什么时候建的。新手最容易踩的四个坑跑通之后回头看最折腾我的其实是下面四个细节提前避开能省下大半天采样率对不上。麦克风用 44.1kHz 采出来的音频直接喂给期望 16kHz 输入的模型结果就是听不清、转不对。先确认输入是 16kHz、输出是 24kHz再做别的优化。VAD 调得太激进。静音判定时间设得太短一句话中间停顿一下就被当成说完了设得太长又显得回应迟钝。建议从 500ms 起步结合实际语速微调。Bedrock 凭证没配齐。用 AWS 系模型时aws_access_key_id、aws_secret_access_key、region_name三者缺一不可而且建议优先用环境变量注入别写死在配置里。密钥管理混乱。master_key一定要换掉默认值WebSocket 消息如果包含较大的音频帧记得确认代理端消息大小上限避免大包被静默丢弃。排错心法先确认代理日志里请求有没有进来再看是模型层报错还是传输层断连。问题基本都出在这两者之间很少是业务代码的锅。最后一步从能跑到能上线回头看这趟语音交互的上手之路其实就三件事把 litellm 代理架起来、把模型登记进配置、让业务代码只认代理这一个地址。实时转写用cookbook/nova_sonic_realtime.py当模板语音合成参考cookbook/livekit_agent_sdk/main.py配上代理自带的负载均衡、成本追踪和日志审计一个小而完整的语音交互系统就具备了上线的底气。接下来你可以沿着两条线继续深入一是把配置里的模型换成你真正要用的那家做一轮延迟与成本的实测对比二是给网关接上护栏和更细的监控告警把它从能跑打磨到能扛。工具已经替你铺好了路剩下的就看你想让这个能听会说的助手先出现在哪个产品里了。【免费下载链接】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做语音助手的第三周我数了数手头的适配代码转写一套、合成一套、流式对话又一套每换一家模型厂商就要重写一遍。直到同事甩给我一个开源项目litellm——一个把 100 多家大模型 API 统一成 OpenAI 格式的 AI 网关语音转写、语音合成这些活儿终于能在一套配置里解决了。这篇文章记录我踩过的路以及最终跑通的完整流程。深夜事故当语音 API 碎片化找上门事情的起因很简单我要给内部工具加一个能说话的助手。结果从第一天开始画风就不对劲。第一家厂商的转写接口要 WebSocket 长连接第二家却只提供 REST 轮询第三家的流式协议又完全不同转写、对话、合成是三个互相独立的服务我得分别写三个客户端、三套鉴权、三份错误处理最要命的是换模型这个需求——老板今天说想试试 A 厂的新模型明天又觉得 B 厂便宜而我每次都要跟着改业务代码。那晚我盯着屏幕上三份风格迥异的 SDK 文档突然意识到我需要的不是更多的适配代码而是一个中转站——所有模型都往里接业务代码只跟中转站对话。中转站思维litellm 把 100 多家模型收进同一套接口litellm 干的事情用一句话概括就是用一套 OpenAI 格式的接口替你转发给背后的任何大模型。它自称是最快、最轻的 AI 网关底层用 Rust 核心加速对外提供 Python SDK目前已经覆盖 Bedrock、Azure、OpenAI、Anthropic、VertexAI、vLLM、Nvidia NIM 等 100 多家服务商。把它想成机场的中转柜台就很形象旅客你的请求不管从哪里来只要递上统一格式的登机牌OpenAI 格式柜台就会帮你分流到对应的登机口各家模型 API。你不再需要知道每个登机口长什么样。除了统一格式它顺手还做了几件运营层面的活负载均衡多个模型按策略分发请求某一家挂了自动切走成本追踪每一次调用的花费都有记录方便按团队、按用户对账护栏Guardrails可以在请求前后插入校验规则拦截敏感内容日志与观测请求链路、token 用量、延迟指标都能接出去。这些能力对语音这类实时、高频、烧钱的场景尤其重要后面会讲到怎么用。最小可用配置三分钟把代理服务器跑起来先把它拉下来装好git clone https://gitcode.com/GitHub_Trending/li/litellm cd litellm pip install -r requirements.txt接着写一份最简配置。以仓库里cookbook/livekit_agent_sdk/config.example.yaml的思路为例核心就是在model_list里登记你手头的模型并给每个模型标上用途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这里有两个细节值得注意一是os.environ/前缀表示密钥从环境变量读取避免把密钥写死在文件里二是model_info.mode: realtime专门标记这是实时语音模型代理会据此路由到实时通道。如果要用 AWS Bedrock 上的 Nova Sonic把model换成bedrock/...并补上aws_access_key_id、aws_secret_access_key、region_name即可。启动代理就一条命令litellm --config proxy_server_config.yaml --port 4000从这之后你的所有业务代码只认localhost:4000这一个地址。想换模型改配置不动代码——这正是中转站最大的价值。实时语音转写实操麦克风声音如何变成文字流仓库里cookbook/nova_sonic_realtime.py是一个可以直接跑的实时语音客户端核心思路分五步采集用 PyAudio 从麦克风读音频按 16kHz、单声道、16 位 PCM 的格式分包连接通过 WebSocket 连上代理的实时端点ws://localhost:4000/v1/realtime?modelbedrock-sonic带上 Bearer 密钥下配置发送一个session.update消息告诉模型你是谁、什么音色、怎么判断一句话说完了传音频把麦克风采集到的每个分片做 base64 编码通过input_audio_buffer.append持续上传说完话再发一个input_audio_buffer.commit通知处理收结果服务端推回的response.text.delta就是逐字出现的转写文本直接打印或落库都行。转写质量好不好多半取决于会话配置里几个参数我把它们列成了一张对照表参数作用建议起点输入采样率麦克风采集规格16000 HzNova Sonic 期望值输出采样率合成音频规格24000 HzVAD 阈值多响的声音才算开口0.5静音时长安静多久算说完了500 ms前缀填充开口前多保留一点语音300 msVAD语音活动检测是自动判断你什么时候开始、什么时候结束说话的机制调大了不容易误触发但可能漏听轻声音调小了敏感但容易把环境噪声当人声。新手先用默认值跑通再按实际场景微调。语音合成怎么做让模型开口的两种姿势语音合成在 litellm 里有两条路可以走取决于你的产品形态。姿势一实时语音对话。还是上面那个 Nova Sonic 客户端——它其实是语音进、语音出的实时对话模型在返回转写文本的同时会通过response.audio.delta把合成音频分片推回来客户端解码后直接用扬声器播放。这种方案延迟低、体验自然适合语音助手、客服机器人这类对讲机式产品。姿势二文本型语音 Agent。cookbook/livekit_agent_sdk/main.py展示了另一种玩法通过代理连上 xAI 的实时语音模型先用conversation.item.create把用户消息塞进会话再发response.create请求回复最后从response.output_audio_transcript.delta里逐段接收合成结果。它的妙处在于代码完全不感知后端是哪家——配置里把grok-voice-agent换成openai-voice-agent同一份代码立刻从 xAI 切到 OpenAI 的实时模型。简单说想省事、要最低延迟走姿势一想复用已有的文本对话链路、逐步升级走姿势二。串起完整对话闭环转写、理解、合成三步走把前面几块拼起来一个完整的语音对话闭环其实只有三步像一场传话筒接力你说→ 麦克风采集的音频流实时送进代理模型完成语音转写它想→ 转写出的文字作为上下文进入大模型生成回复内容它说→ 回复文本被转成语音分片回传扬声器播放给你听。值得强调的是第 2 步和第 3 步在实时模型里往往是边生成边合成的所以你听到的不是等全部文本算完才开口而是像真人聊天一样断断续续地回应。这也是为什么这种架构能把说完话到听到回答的等待感压到很低。如果暂时没有真实的 Bedrock 或 xAI 凭证也可以先在配置里挂一个本地 mock 端点把链路整体走通再把模型参数替换成真实服务业务代码一行都不用动。上线后盯这三块延迟、成本与调用日志语音交互系统跑起来之后真正要花心思的是看得见。litellm 的观测能力刚好覆盖我关心的三块。延迟通过success_callback: [prometheus]可以把指标接到 Prometheus配合 Grafana 观察首 token 时间、端到端延迟等关键数字。实时语音场景对延迟极其敏感建议把 P95 延迟单独拎出来盯。成本每次调用的 token 数和费用都会被记录可以按用户、按团队、按模型维度拆账。语音对话往往一次交互就吃掉几千 token没有成本视图的话月底账单会教你做人。调用追踪与审计下面这张 Langfuse 集成的追踪图能直观看到一次语音交互请求的完整链路——用户说了什么、模型回了什么、耗时多少、花了多少钱定位问题比大海捞针高效得多。除了请求追踪代理还自带审计日志密钥的创建、轮换、删除等敏感操作都会留下操作人、时间点和变更前后的完整记录。多人在一个网关下协作时这张表能帮你快速回答这个密钥是谁、什么时候建的。新手最容易踩的四个坑跑通之后回头看最折腾我的其实是下面四个细节提前避开能省下大半天采样率对不上。麦克风用 44.1kHz 采出来的音频直接喂给期望 16kHz 输入的模型结果就是听不清、转不对。先确认输入是 16kHz、输出是 24kHz再做别的优化。VAD 调得太激进。静音判定时间设得太短一句话中间停顿一下就被当成说完了设得太长又显得回应迟钝。建议从 500ms 起步结合实际语速微调。Bedrock 凭证没配齐。用 AWS 系模型时aws_access_key_id、aws_secret_access_key、region_name三者缺一不可而且建议优先用环境变量注入别写死在配置里。密钥管理混乱。master_key一定要换掉默认值WebSocket 消息如果包含较大的音频帧记得确认代理端消息大小上限避免大包被静默丢弃。排错心法先确认代理日志里请求有没有进来再看是模型层报错还是传输层断连。问题基本都出在这两者之间很少是业务代码的锅。最后一步从能跑到能上线回头看这趟语音交互的上手之路其实就三件事把 litellm 代理架起来、把模型登记进配置、让业务代码只认代理这一个地址。实时转写用cookbook/nova_sonic_realtime.py当模板语音合成参考cookbook/livekit_agent_sdk/main.py配上代理自带的负载均衡、成本追踪和日志审计一个小而完整的语音交互系统就具备了上线的底气。接下来你可以沿着两条线继续深入一是把配置里的模型换成你真正要用的那家做一轮延迟与成本的实测对比二是给网关接上护栏和更细的监控告警把它从能跑打磨到能扛。工具已经替你铺好了路剩下的就看你想让这个能听会说的助手先出现在哪个产品里了。【免费下载链接】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），仅供参考