Tell 1 与 LFM2.5 2.6B Base：一个你租用的语音模型，和一个由你自行完成的检查点

把Tell 1和LFM2.5 2.6B Base并排放在一起，体量差异看起来就像故事本身：一个是 Retell 在联络中心平台内部自研的推理模型，另一个是来自 Liquid AI 的 26.9 亿参数纯文本检查点，能装进一个 5.4 GB 的文件里。但这不是故事本身。故事本身在于，LFM2.5 2.6B Base 是一个基础模型——它从未经过指令微调，如果你问它一个问题，它会续写你的文本，而不是回答你——而 Tell 1 是一个以接听电话为业的产品中的成品组件。其中一个只是原材料。另一个是你不允许拆开的工作部件。下面所有内容都在说明你的问题实际需要这两者中的哪一个，因为两者都不能相互替代，而看似显而易见的价格比较，是本页最没用的东西。

时机也很重要，而这正是这个组合存在的原因。两者都是近期发布的：Liquid AI 于 2026 年 8 月发布了 LFM2.5 系列，而 Retell 的 Tell 1 于 2026 年 11 月进入公众视野，当时它出现在 Retell 发布的一项基准测试榜首。这两者都不是你读到得太晚的发布。两者的公开文档也都异常稀少，原因却相反——Liquid 交付了一个没有说明的检查点，因为说明从来不是重点；而 Retell 交付了一个没有文档的模型，因为该模型不是可以单独购买的产品。

从 Liquid checkpoint 做不到的事情开始。

LFM2.5 2.6B Base 是 Liquid AI 的 LFM2.5 混合模型家族的预训练检查点：共 30 层，其中 22 层是双门控短卷积块，8 层是分组查询注意力，在 16 种语言、约 34 万亿个 token 上训练而成，上下文窗口为 131,072 个 token，Q4_K_M 量化版本大小约为 1.67 GB。输入文本，输出文本。不支持视觉，不支持音频，没有可依赖的工具调用模板，也没有指令微调——而且 Liquid 自己的模型卡明确表示，它旨在用于大规模微调，而不是用于提示。

那不是缺陷，把它当作缺陷是撰写基础模型说明时最常见的错误。当你有一个形态明确的任务、大量自己的示例，并且不想按 token 向供应商付费来解决它时，基础检查点才是正确的起点。一个 2.69B 模型能在一块消费级 GPU 上微调，然后量化后运行在笔记本或手机上，这与任何托管 API 都是不同的经济对象：每次调用的边际成本大致降到电费，而你实际支付的成本转移到了数据标注、训练运行和评估上。

它做不到的，是被直接丢进一段对话里。没有任何系统提示词能把一个基座检查点变成可靠的工具调用智能体，再多的提示工程也替代不了后训练这一步。如果你的计划是“把它下载下来，套一个 OpenAI 兼容的服务器，再让语音智能体指向它”，那这个计划会在第一次函数调用时就失败——而这种失败看起来会像是模型质量问题，实际上却是缺少了一个训练阶段。

那么，Tell 1 是什么，以及为什么你不能拥有它

Tell 1 是 Retell 语音技术栈中的推理层，在公司主页“Developed by Retell Labs”下列出，旁边是一个将模型、知识和工具组合起来的智能体框架。它并非作为模型出售。Retell 网站上任何地方都没有发布模型卡、代码仓库、上下文窗口数值、参数数量、许可证或每 token 价格。唯一公开的量化证据是 Retell vCX Benchmark 中的一行数据，而该基准是 Retell 自己维护的排行榜：指令遵循 88.6%，在标为“幻觉”的维度上为 97.2%，工具调用 95.4%，口语化 96.6%，平均 94.45%，中位延迟 72.5 毫秒，模型成本为每分钟 3.5 美分。

Tell 1 是对某个公开模型进行微调、从零训练，还是从更大模型蒸馏而来的小模型，目前并未披露。72 毫秒的中位数表明这是一个小而快的模型，而不是前沿通用模型，因为这个数字处在往返第三方推理栈的时间开始占主导的区间内——但这只是根据延迟数字作出的推断，而延迟数字有很多成因。并非推测的是其产品形态：你要通过在 Retell 平台上购买使用时长来获得 Tell 1，价格依配置为每分钟 0.07 到 0.31 美元，而且该模型无法与电话系统、语音栈及其外围框架分开。

这就是买家必须计入成本的不对称之处。LFM2.5 2.6B Base 以任何托管模型都无法做到的方式属于你：你可以读取其权重、对其进行量化、将其打包进应用，并在供应商消失后继续运行它。Tell 1 则以任何可下载模型都无法做到的方式可用：它已经接入电话号码、轮流对话层和语音，而让它在真实通话中听起来像人的工作已经由别人完成。

真正重要的对比：延迟预算都花在了哪里

这两个模型的成败都取决于一块秒表，所以尽管它们承担的任务不同，还是常被相提并论。一通电话留给你的时间预算大约是 800 ms：从主叫方说完一句话，到智能体开始说话，超过这个时间，停顿就会被听成掉线。这笔预算要依次支付语音识别、模型回合、工具调用和语音合成的开销。

• 模型延迟 — 在 Retell 的测试框架中，Tell 1 的中位延迟为 72.5 ms，在该基准的 62 种配置中排名第一；LFM2.5 2.6B Base 未公布该数据，因为基础检查点没有可测量的已上线产品，其量化吞吐量完全取决于你的硬件。

• 800 ms 里还包括什么——对 Tell 1 来说，电话和语音都算在平台给出的数字内，Retell 给出的典型端到端响应约为 600 ms；对于自托管的 LFM2.5 技术栈，ASR、TTS 和服务层都需要你自行添加，而每一项都需要做供应商选型决策。

• 吞吐量——Liquid 针对该检查点进行后训练的同系列模型在 Apple M5 Max 上达到每秒 220 个 token，在 AMD Ryzen CPU 上达到每秒 113 个 token，厂商还指出在手机上可实现每秒 30 个 token；2.69B 模型的速度取决于机器，而非服务等级。

最后一行正是本质区别所在。Tell 1 的延迟是别人替你兑现的承诺；LFM2.5 的延迟则是你所选硬件本身的属性。如果你的部署目标是拥有 200 条并发线路的呼叫中心，那你买的就是前者。如果目标是一台没有网络的仓库设备，那后者就是唯一存在的选择。

微调是岔路口

结论如下，我尽可能直白地说。如果你有一个能够精确描述的任务、有该任务的示例，并且有理由不把这些示例发送给第三方，那就选择 LFM2.5 2.6B Base——比如呼叫流程中的一个分类步骤、领域专用的摘要器、判断请求类型的端侧路由器。这个模型足够小，微调只需一个下午而不是一个季度；上下文窗口足够大，能处理真实文档；许可证允许年收入低于 1000 万美元的商业使用，达到或超过这条线则需另行签订协议。这个门槛是采购事实，应纳入决策本身，而不是放在脚注里。

如果你购买的是电话代理而不是模型，就选择 Tell 1；尤其是当你无法构建的是对话层面时：打断处理、口语化措辞，以及快到让来电者察觉不到机器的第一个音节。Retell 的基准测试称，这正是 Tell 1 领先的两个维度——口语化排名第 1，延迟排名第 1——并且同样明确地表示，它在指令遵循、事实依据或工具调用上并不领先，分别排名第 2、第 2 和第 5。在标准化之前，用你自己的通话测试这三项，因为正是它们会产生错误答案，而不只是让回答更慢。

还有第三种方案，也是大多数有真实工作负载的团队最终会选择的方案：把小型微调模型保留给任务中狭窄且重复的部分，把困难的部分路由到更大的托管模型。这正是路由层所针对的拆分方式，也正是我们自己的目录的用武之地。Tell 1 和 LFM2.5 2.6B Base 都无法通过 OrcaRouter 路由——这两个我们都不托管——因此这种架构的实用版本会把 Liquid 微调模型部署在你自己的硬件上，并通过一个 API key 将升级路径发送到我们确实提供的模型，按供应商标价，无任何加价。

什么会改变答案

对于 Tell 1，三份公开资料就能让它从“在平台内部测试”升级为“考虑标准化”：一份写明架构和训练数据的模型卡、一个按模型定价的价格（以便把成本从按分钟打包的套餐中拆分出来），以及一次由 Retell 以外的一方执行的评测。目前可查的记录只有厂商自家排行榜上的一行，而厂商在自家测试框架上把自己排到第一，这只是一个假设，而不是结果。

对于 LFM2.5 2.6B Base 来说，缺失的一环不是文档——而是你自己的微调。检查点是完整的，许可证也可读，这意味着唯一的未知数是：一个基于你的数据训练出来的 2.69B 模型能否在你的任务上达标。这个问题你可以这周用一块 GPU 回答，读再多资料也不会替你回答。用一句话概括这笔取舍：Tell 1 替你省掉工程工作，但拿走控制权；LFM2.5 2.6B Base 给你控制权，但让你自己做工程工作。