ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

让麦克风直接对话 AI:litellm 实时语音交互快速上手

让麦克风直接对话 AI:litellm 实时语音交互快速上手 让麦克风直接对话 AIlitellm 实时语音交互快速上手【免费下载链接】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明天要给客户演示语音客服原型今天却被各家 API 卡住了OpenAI Realtime 是一套 WebSocket 协议Bedrock 的 Nova Sonic 是另一套xAI 还是第三套。你只是想对着麦克风说句话、让 AI 用声音答回来却得先学会三种方言。litellm 的思路是把所有实时语音模型收进一个/v1/realtime端点后面客户端只写一次。能力速览litellm 是一个跑在本地的 AI 网关gateway可以理解成各家模型前面的统一转发站100 多家模型商的 API 都按 OpenAI 格式统一调用顺带做成本核算、限流和日志。和语音相关的部分它暴露/v1/realtimeWebSocket 端点把麦克风音频流转发给 OpenAI、Azure OpenAI、Bedrock、Vertex AI、xAI 的实时模型音频进、音频加文字转写出一条链路全通。密钥、负载均衡这些杂活归代理管你的应用代码可以写得非常薄。一套配置路由所有模型的网关概览 三步跑通本地实时语音代理配置任务目标让localhost:4000上多出一个能收发音频流的端点。先装依赖pip install litellm pyaudio websockets。pyaudio 负责读写声卡websockets 负责客户端长连接。然后在仓库根目录建一个config.yaml把要用的语音模型列进去。关键字段是model_info.mode: realtime代理靠它识别出这是个实时音频模型要走 WebSocket 而不是 HTTPmodel_list: - model_name: openai-voice-agent litellm_params: model: gpt-4o-realtime-preview api_key: os.environ/OPENAI_API_KEY model_info: mode: realtime - model_name: grok-voice-agent litellm_params: model: xai/grok-2-vision-1212 api_key: os.environ/XAI_API_KEY model_info: mode: realtime general_settings: master_key: sk-1234写好环境变量后启动litellm --config config.yaml --port 4000。master_key是访问代理的钥匙示例脚本里带着它连进来想验证是否起来了浏览器打开localhost:4000/health看一眼即可。仓库里有一份可直接参考的 配置示例端点细节见 realtime 说明。 接上麦克风实时转写与语音回复代理起来后跑官方示例python cookbook/nova_sonic_realtime.py脚本见 nova_sonic_realtime.py。它连的是ws://localhost:4000/v1/realtime?modelbedrock-sonic用 pyaudio 以 16kHz 采麦克风把音频分片 base64 编码后不断推给代理。连上后第一件事是发session.update定规矩这段配置决定了整个交互的手感session { instructions: You are a friendly assistant. Keep responses short., 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, }, }其中server_vad是服务端语音活动检测判断你说完了没有的机制你停 500 毫秒模型就认为这一轮结束开始回答。之后代理会流式吐回两类事件response.text.delta是转写文本打在屏幕上response.audio.delta是 24kHz 的音频块示例脚本把它塞进队列交给扬声器。你只管说话转写和回复同时出现。 让 AI 开口文本到语音的合成链路如果只想验证文字进、声音出这半条链路看 livekit 语音代理示例配套 requirements.txt。流程很朴素先发一条conversation.item.create把用户消息塞进会话再发response.create并在modalities里声明要text加audio代理就开始流式回传合成音频。这个示例最省事的地方在于换模型不用改代码——把 URL 里的model参数从grok-voice-agent换成openai-voice-agent上游就从 xAI 切到 OpenAI协议格式由 litellm 兜底对齐。跑法就一条命令python cookbook/livekit_agent_sdk/main.py。串起来一次完整的语音对话麦克风以 16kHz 采集 PCM 分片base64 编码后经 WebSocket 持续推给代理代理按 URL 里的 model 名匹配到上游实时模型如 Bedrock Nova Sonic音频流直达厂商服务端 VAD 判定你说完转写文本以 delta 事件流回客户端LLM 生成回答TTS 同步产出 24kHz 语音块客户端把音频块写入播放队列扬声器出声——用户听到 AI 开口。⚡ 调优与排坑延迟、音质和断连响应迟钝多半是silence_duration_ms给大了800 毫秒以上会明显感觉AI 在装没听清500 毫秒是体验与误触的平衡点。模型本身偏重也会拖慢首字演示场景挑轻量的。音质发闷或有杂音先查采样率是否和模型要求对齐输入 16kHz、输出 24kHz别随手改成 44.1kHz真要改善优先调大分片尺寸而不是采样率。长对话掉线WebSocket 长时间静默容易被中间层掐断。示例脚本用有界队列加is_active标志防止音频堆积重连后记得重发一次session.update会话状态才能恢复。线上跑起来之后建议在代理里接上追踪tracing把每次请求的耗时、token、成本记成可查的链路首字延迟多少、这一轮花了多少钱一查便知。每次语音请求的耗时与成本都可追溯适合语音客服、IVR 和语音助手这类要能听会说的场景。想抄作业的话从 nova_sonic 实时示例 起步就对了。【免费下载链接】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),仅供参考
返回列表