Retell AI接入开源模型：90行代码自建LLM桥接

Retell AI 的语音智能体默认按分钟计费大模型调用：frontier 模型的价格在每分钟 0.045 到 0.16 美元之间，且叠加在语音引擎费用之上。但 Retell 留了一个 Custom LLM 接口，允许你绕开这条计费线——通话期间它向你的服务器打开一个 WebSocket，推送实时转写文本，并朗读你流式返回的任何内容。把开源模型接进这个插槽，只需要一个约 90 行的桥接服务。

据官方博客介绍，这个桥接器接收 Retell 的事件，再用 llama-3.1-8b-instruct 的流式补全作答，token 成本折合每分钟远低于一美分。下面拆解协议、桥接代码、无需真实电话的本地测试，以及一份诚实的成本账。

Retell AI自定义LLM桥接方案示意

你需要把哪些部件接起来

Retell 并不直接调用一个 chat completions URL。通话开始时，它向你的服务器打开 WebSocket，双方交换 JSON 事件。整个链路的组成如下：

Retell 插槽：Custom LLM，WebSocket 协议，每次通话由 Retell 主动连接你的服务器
协议：Retell 发送转写事件，你流式返回响应事件
桥接器：位于 ecohash-examples 的 integrations/retell 目录，约 90 行
默认模型：llama-3.1-8b-instruct，输入/输出均为 $0.10 / 1M tokens
实测数据：205 ms TTFT（p95），单流约 143 tokens/秒
仍留在 Retell 侧：语音引擎、STT、TTS、电话线路（使用其内置服务商）
API base URL：https://api.ecohash.com/v1

WebSocket 与普通 HTTP 请求的区别在于连接的持久性与双向性。普通 chat completions 调用是「一问一答」：客户端发起一次 HTTP 请求，服务器返回完整响应后连接即关闭。而 WebSocket 在初次握手后保持长连接，双方可以随时互发消息，无需反复建连。这正是实时语音场景需要的：一通电话可能持续数分钟、包含多次轮次，Retell 可以在同一连接上不断推送转写结果，桥接器也能在主模型还在流式生成时就把 token 增量吐回去。此外，WebSocket 天然适合处理打断——服务器不必等待当前请求完全响应，就能接收并处理 Retell 发来的更高优先级事件。

各部件如何协作

事件流遵循一套清晰的握手与轮次机制：

你的服务器发送一个 config 事件和第一句要朗读的话。
当通话方结束一轮发言，Retell 发送 response_required，附带实时转写文本和 response_id。
桥接器把转写文本转发给 EcoHash 的 /v1/chat/completions，设置 stream: true。
每个 token 增量作为 response 事件回到 Retell，最终的 content_complete 关闭该轮。如果通话方中途打断，携带更大 response_id 的新请求会到达，过期的回复被丢弃。

response_id 与打断机制是这套协议中最容易被忽视的细节。每次 Retell 要求模型回应时，都会分配一个单调递增的 response_id。当通话方在模型还没说完时突然插话，Retell 会立刻发送一个携带更大 response_id 的 response_required 事件。桥接器需要维护一个「当前最新 id」的状态：一旦收到新 id，就停止把旧回复的 token 继续推给 Retell，因为那些内容已经过期。如果缺少这层检查，用户会听到模型继续念上一轮的台词，打断体验彻底失效。这也是流式场景与普通请求-响应式调用在工程上最大的差异之一。

桥接器实现

完整服务在 integrations/retell/server.py。核心逻辑用 FastAPI 的 WebSocket 路由实现：接受连接后先发送 config 与首句，然后异步迭代 Retell 发来的 JSON 事件。一旦收到 response_required 或 reminder_required，就把 transcript 映射成 messages，调用流式补全，逐块把 delta 作为 response 事件推回，最后补一个 content_complete: True 的终结事件。

运行方式很直接：安装 fastapi uvicorn openai，导出一个从 console.ecohash.com 创建的 eco_ 开头的 API Key，然后 uvicorn server:app --host 0.0.0.0 --port 8000。首次测试用 ngrok 暴露公网即可。

在 Retell 后台指向桥接器

在 Retell 仪表盘点击 Create an Agent，打开 Other options，选择 Custom LLM，然后把 Custom LLM URL 设为你的桥接地址，例如 wss://your-host.example.com/llm-websocket。Retell 会在通话开始时追加 call id 并建立连接。

此时智能体头部的费用估算只覆盖语音和电话，不再包含 LLM 那一行——这正是本方案的意义。智能体的其他配置（音色、转写器、电话号码）保持不变。Retell 官方的自定义 LLM 设置指南覆盖了仪表盘操作细节，而桥接器正是那份指南留作练习的部分。

不打电话也能测试

桥接器说的是文档化协议，所以可以用任意 WebSocket 客户端在终端里伪造 Retell。测试脚本连接 ws://localhost:8000/llm-websocket/test-1，先读取 config 和首句，然后发送一个带 response_id 和 transcript 的 response_required 事件，循环拼接返回的 content 直到 content_complete 为真。

据原文描述，写作期间实际跑过这个循环：桥接器完成了 config 握手、说出第一句，并从 llama-3.1-8b-instruct 流式返回了连贯的 18 个 chunk，ping 与打断处理均按文档工作。这说明除了电话网络本身，协议层的正确性完全可以离线验证。

成本测算

用 Retell 内置模型时，LLM 按分钟计费；换用 Custom LLM 后，这一行从 Retell 账单上消失，改由你按 token 向自己的服务商付费。原文列出的价目（标注日期为 2026-07-23）如下：

GPT 5.5（经 Retell）：$0.16/分钟
GPT 5.4 或 Claude 4.6 Sonnet（经 Retell）：$0.08/分钟
GPT 4.1（经 Retell）：$0.045/分钟
llama-3.1-8b-instruct（EcoHash 经桥接）：约 $0.0003 token 成本/分钟

这个 EcoHash 数字基于典型客服通话每分钟约 2000 输入 token、250 输出 token、单价 $0.10/1M 的假设；即便上下文重十倍的智能体，token 成本仍低于一美分。Retell 其他计费项——语音引擎 $0.055/分钟，加上 TTS 和电话——没有变化，节省只发生在 LLM 这一行。代价是你需要托管一台小服务器。

TTFT（Time To First Token） 是评估语音智能体延迟的关键指标，指从发出请求到收到模型第一个输出 token 的时间。对语音交互而言，TTFT 直接决定用户感知的「反应速度」：人耳对对话间隙的容忍度大约在 300 毫秒以内，超过就会觉得对方「在发呆」。文中提到的 205 ms（p95）意味着 95% 的请求首 token 在 205 毫秒内返回，这是可以接受的。除模型 TTFT 外，桥接器所在服务器的网络往返也会叠加进来，所以把服务器部署在离 Retell 机房更近的区域、并选用支持流式输出的快速模型，是控制端到端延迟的两个主要手段。

权衡与限制

Custom LLM 插槽只覆盖“大脑”。Retell 的 STT 和 TTS 仍走其内置服务商，无法在此接入第三方的开源 TTS。原文提到 Vapi 提供开放的 TTS 插槽，走的是另一条路径。
你在通话关键路径上托管 WebSocket 服务器。服务器要尽量靠近 Retell 的区域，并快速返回首 token；llama-3.1-8b-instruct 在 EcoHash 上的 TTFT 为 205 ms（p95），你的托管会额外增加延迟，给出承诺前先实测。
语音回复应当简短。系统提示词要严格要求一句话作答，否则智能体会滔滔不绝。
成本表用的是特定日期的标价和既定 token 假设，做商业测算前需重新核对。

常见问题

Retell 支持直接填 OpenAI 兼容 base URL 吗？ 不支持。Custom LLM 插槽是 WebSocket 协议，不是一个 base URL 字段，这也是需要跑桥接器的原因。

桥接器能用哪些模型？ EcoHash 上任意 chat 模型。llama-3.1-8b-instruct 是语音场景的合理默认；gpt-oss-20b 以 $0.05 输入 / $0.18 输出每 1M tokens 提供更强能力。

通话方打断时发生什么？ Retell 发送带更高 response_id 的新 response_required，桥接器跟踪最新 id，丢弃仍在流式输出的旧回复。

能加工具调用或 RAG 吗？ 可以，这正是自持桥接器的意义：在转写文本和模型之间插入检索、工具调用或护栏。同一个 key 也能用于 /v1/embeddings 和 reranker。

会影响 Retell 的音质或延迟预算吗？ 语音仍在 Retell 引擎上。你对延迟的贡献是桥接托管加模型 TTFT，所以要把服务器托管在靠近 Retell 的位置并选快模型。

事后如何转写或分析通话？ 用 whisper-large-v3-turbo 处理录音，再用 chat 模型做摘要，同一个 API Key 即可。

上手路径

整体看，这套方案的价值不在“省下几分钱”，而在于把语音智能体的推理层从封闭计费中解耦出来：你可以自由换模型、加检索、插工具、做护栏，而语音与电话基础设施继续交给 Retell。对需要控制成本或要深度定制对话逻辑的团队，这 90 行桥接是一个低门槛的切入点。