litellm实时语音交互完整指南：30分钟搭建语音转写与语音合成全链路系统

litellm实时语音交互完整指南30分钟搭建语音转写与语音合成全链路系统【免费下载链接】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/litellmlitellm 是一个以 Rust 内核驱动的高性能开源 AI 网关让你用统一的 OpenAI 格式调用 100 多家 LLM 服务同时它也把各厂商的实时语音能力实时语音转写与语音合成收敛到一套 WebSocket 协议下。本文从一个真实的客服质检场景切入带你从零配置 litellm 代理逐步搭出「录音 → 转写 → 智能问答 → 语音播报」的完整语音链路全程约 30 分钟即可跑通。从一个让人头大的需求说起想象一下这个场景你的团队负责一个呼叫中心的质检系统每天有几千通客服电话录音要处理。业务方提了三个需求——把录音自动转成文字方便事后检索和评分用大模型对通话内容做总结判断客服是否解决了用户问题把质检结论用语音播报出来让坐席在忙着手头工作时也能听到结果。如果你挨个对接云厂商的语音 API很快就会被折磨疯A 家的实时转写走 WebSocket、B 家走 HTTP 轮询、C 家的采样率要求和别家完全不同……每一家都要写一套适配代码换模型等于重写一遍。而 litellm 恰恰就是为这种多供应商混用的痛点设计的它在中间加了一层代理对外只暴露一套标准协议对内帮你把路由、鉴权、限流、日志、成本统计全部接管。语音这块也不例外/v1/realtime端点就是那把万能钥匙。一张表看懂 litellm 能帮你省掉什么对比维度传统多供应商直连方案使用 litellm 网关方案对接方式每家厂商一套 SDK、一套协议统一 WebSocket 实时接口/v1/realtime模型切换改代码、改配置、重新联调改一行 YAML 配置即可热切换鉴权管理密钥散落在各业务代码里集中在代理层统一管理成本与用量各厂商后台分开看网关侧统一记录 token 与费用日志追踪需要自己拼装链路内置回调可对接 Langfuse 等观测平台容灾与限流基本靠手写内置负载均衡、重试与预算控制换句话说litellm 把语音转写 语音合成 LLM 推理这三件事统一收敛成了一个网关背后的多个模型入口。litellm 官网概览一个网关即可覆盖模型访问、成本追踪、日志与预算管理等能力三分钟完成代理环境配置动手前先理清分工litellm 代理负责连接各家模型并提供统一接口你的业务代码只负责捕获麦克风音频、推送数据流、接收并播放返回的音频。第一步拉取代码并安装依赖git clone https://gitcode.com/GitHub_Trending/li/litellm cd litellm pip install -r requirements.txt pip install pyaudio websockets这里pyaudio负责本地音频采集与播放websockets负责与代理建立实时通道。如果本机没装音频库Linux 下可能需要先执行apt install portaudio19-dev之类的系统依赖。第二步编写代理配置文件新建一个voice_config.yaml把语音模型注册进网关。这里以 AWS Bedrock 上的 Nova Sonic 模型为例它的输入采样率为 16kHz、输出为 24kHz是实时语音场景的常用选择model_list: - model_name: sonic-voice litellm_params: model: bedrock/anthropic.claude-3-sonnet-20240229-v1:0 aws_access_key_id: os.environ/AWS_ACCESS_KEY_ID aws_secret_access_key: os.environ/AWS_SECRET_ACCESS_KEY region_name: us-east-1 model_info: mode: realtime # 声明该模型走实时语音协议 general_settings: master_key: sk-1234 # 代理访问密钥生产环境请替换注意model_info.mode: realtime这一行它告诉代理该模型应使用实时语音的协议栈去路由而不是普通的对话补全接口。第三步启动代理并验证litellm --config voice_config.yaml --port 4000看到日志中出现Uvicorn running on http://0.0.0.0:4000即启动成功。再开一个终端确认健康状态curl http://localhost:4000/health/liveliness返回ok就说明网关已就绪可以进入下一步了。核心功能拆解一段语音从麦克风到扬声器的旅程实时语音交互的本质是一条双向数据流你的声音以二进制音频块的形式流进网关模型的回答又以音频块的形式流回来。下面按「输入 → 处理 → 输出」三段拆开讲。输入侧捕获 16kHz 音频并持续推流客户端先用 PyAudio 打开麦克风按 Nova Sonic 要求的参数读取 PCM 数据然后通过 WebSocket 把每个音频块编码为 base64 发送出去import asyncio, base64, json, pyaudio, websockets SAMPLE_RATE 16000 # 输入采样率匹配模型要求 CHANNELS 1 CHUNK 1024 # 每次读取的帧数 async def pump_audio(ws, mic): 从麦克风持续读取音频并推送进实时通道 while True: raw mic.read(CHUNK, exception_on_overflowFalse) payload { type: input_audio_buffer.append, audio: base64.b64encode(raw).decode(utf-8), } await ws.send(json.dumps(payload)) await asyncio.sleep(0.01) # 留出呼吸避免推流过快input_audio_buffer.append是 OpenAI 实时协议的标准事件litellm 代理会原样转发给后端模型因此这套推流代码对 Bedrock、Azure、xAI 等厂商都通用。会话控制用一条指令配置 VAD 与音色连接建立后客户端可以发送session.update事件一次性下发助手人设、音色、回声抑制策略、转写与音频的返回格式等参数。这里的turn_detection就是服务端语音活动检测VAD模型自己判断用户什么时候说完话省去客户端写静音检测的麻烦。session_cfg { type: session.update, session: { instructions: 你是客服质检助手回答尽量简短先给结论再给依据。, voice: matthew, temperature: 0.6, max_response_output_tokens: 1024, modalities: [text, audio], input_audio_format: pcm16, output_audio_format: pcm16, turn_detection: { type: server_vad, threshold: 0.6, prefix_padding_ms: 400, silence_duration_ms: 600, }, }, } await ws.send(json.dumps(session_cfg))参数含义值得展开说明threshold是 VAD 触发灵敏度值越高越不容易误触发prefix_padding_ms是检测到说话后向前补录的时长避免吞掉句首辅音silence_duration_ms是判定一句话结束所需的静音时长直接影响对话节奏。事件流转读懂实时通道里的消息类型通道里来来往往的都是 JSON 事件记住下面这五类就足够入门事件类型方向含义session.created/session.update双向会话建立确认 / 修改会话参数input_audio_buffer.append上行推送音频块input_audio_buffer.commit上行告诉服务端这一段说完了开始处理response.text.delta下行模型的文字转写增量response.audio.delta下行模型的音频增量base64输出侧把音频流实时播放出来服务端返回的response.audio.delta携带 base64 编码的 PCM 数据客户端解码后直接写入扬声器。因为音频是流式到达的所以听到第一个字的延迟可以压得很低。完整的事件分发逻辑可参考仓库中的cookbook/nova_sonic_realtime.py它把连接、推流、接收、播放拆成了四个独立协程思路非常清晰。实战串联跑一个「语音质检问答」迷你闭环现在把上面的片段拼成一个能实际运行的闭环对着麦克风说一句话模型转写出来、给出文字回答并把回答念给你听。import asyncio, json, base64, pyaudio, websockets WS_URL ws://localhost:4000/v1/realtime?modelsonic-voice AUTH {Authorization: Bearer sk-1234} async def demo(): async with websockets.connect(WS_URL, additional_headersAUTH, max_size10 * 1024 * 1024) as ws: # 1. 建立会话 await ws.send(json.dumps({ type: session.update, session: { instructions: 你是一个耐心的语音助手回答不超过三句话。, voice: matthew, modalities: [text, audio], input_audio_format: pcm16, output_audio_format: pcm16, turn_detection: {type: server_vad, silence_duration_ms: 500}, }, })) pa pyaudio.PyAudio() mic pa.open(formatpyaudio.paInt16, channels1, rate16000, inputTrue, frames_per_buffer1024) speaker pa.open(formatpyaudio.paInt16, channels1, rate24000, outputTrue, frames_per_buffer1024) # 2. 后台推流 前台收消息 async def push(): while True: raw mic.read(1024, exception_on_overflowFalse) await ws.send(json.dumps({ type: input_audio_buffer.append, audio: base64.b64encode(raw).decode(), })) await asyncio.sleep(0.01) async def consume(): async for msg in ws: evt json.loads(msg) t evt.get(type) if t response.audio.delta: speaker.write(base64.b64decode(evt[delta])) elif t response.text.delta: print(evt.get(delta, ), end, flushTrue) elif t error: print(\n出错, evt) await asyncio.gather(push(), consume()) asyncio.run(demo())运行前确保代理已启动且环境变量AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY已配置。执行python demo_voice_qa.py对着麦克风说一句帮我总结一下今天的待办你会在终端看到转写文本同时听到合成语音的实时播放——到此语音转写与语音合成的闭环就打通了。如果你还想体验只做语音合成、不接麦克风的更简路径可以看cookbook/livekit_agent_sdk/main.py它演示了通过conversation.item.create提交纯文本消息、再用response.create请求音频返回的写法适合把 LLM 文本回答直接翻译成语音播报的场景。常见报错排查与延迟优化三方案排错清单遇到问题先对号入座现象可能原因解决办法连接被拒 /Connection refused代理未启动或端口不对确认litellm --config voice_config.yaml --port 4000在运行返回 401 鉴权失败master_key与客户端不一致核对Authorization头里的密钥一直收不到session.createdmodel_info.mode未声明为 realtime在配置中补上mode: realtime音频断断续续 / 爆音麦克风采样率与模型要求不符把输入采样率固定为 16000输出固定为 24000模型不开口说话VAD 静音阈值过长调小silence_duration_ms或手动发送input_audio_buffer.commit强制触发延迟优化的三种方案调 VAD 参数压缩感知延迟silence_duration_ms从 600ms 降到 400ms 左右句子结束的判定更快但要注意别太激进否则会截断停顿较长的话就近部署网关把 litellm 代理部署到离模型区域近的节点网络 RTT 是实时语音延迟的大头这一步往往比调参更立竿见影权衡模型与采样配置在音质与速度之间取舍——提高采样率和块大小能改善音质但会加大每次传输的数据量与编码开销测试环境里可以逐档对比再定值。用日志定位问题语音交互是毫秒级的双向流出问题时肉眼很难盯住现场。litellm 内置了丰富的回调能力可以在配置里打开 Langfuse 等观测平台的接入随后在平台上查看每一次实时会话的完整轨迹——包括请求耗时、token 消耗与费用明细。上图为 Langfuse 中 litellm 的一次请求跟踪可以看到模型、首响应耗时与单次费用方便你对比不同语音模型的性能差异总结下一步可以做什么到这里你已经掌握了用 litellm 搭建实时语音链路的全部关键动作配置代理网关、用 WebSocket 推流与收流、用session.update控制对话行为以及用观测平台做性能与成本分析。这个基础能力可以继续延伸出不少玩法会议纪要助手把server_vad换成固定时长的音频分段会议录音流式转写并自动生成待办清单多语言客服同一个网关里注册多个厂商的语音模型按区域或价格自动路由无障碍播报把文本回答接上conversation.item.create路径为视障用户提供即时的语音播报服务。下一步建议直接动手跑一遍上面的示例脚本然后打开cookbook/目录看看更多配套样例在网关侧/health接口和审计日志页面可以帮你持续观察代理的稳定性与调用记录把语音系统打磨得更可靠。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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考