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 層是分組查詢注意力，訓練資料約 34 兆個符元，涵蓋 16 種語言，上下文視窗為 131,072 個符元，Q4_K_M 量化後約為 1.67 GB。文字輸入、文字輸出。不具備視覺、音訊功能，沒有可依賴的工具呼叫範本，也未經指令微調——而 Liquid 自家的模型卡直言，它是要用於大量微調，而非用於提示。

那不是缺陷，把它當成缺陷是撰寫基礎模型評述時最常見的錯誤。當你有一個具備特定形態的任務、大量自己的範例，而且不想按 token 付費給供應商來解決它時，基礎檢查點就是正確的起點。一個能在單張消費級 GPU 上微調、隨後量化後在筆電或手機上運行的 2.69B 模型，與任何託管 API 都是不同的經濟物件：每次呼叫的邊際成本大致只剩電力，而你實際支付的成本則轉移到資料標註、訓練運行與評估上。

它做不到的，是被直接丟進一段對話裡。沒有任何系統提示詞能把一個基礎檢查點變成可靠的工具呼叫代理，再多的提示詞工程也取代不了後訓練這一步。如果你的計畫是「把它下載下來、包進一個 OpenAI 相容的伺服器，然後讓語音代理指向它」，這個計畫會在第一次函式呼叫時就失敗——而那個失敗看起來會像模型品質的問題，實際上卻是少了一個訓練階段。

那麼 Tell 1 究竟是什麼，以及為什麼你不能擁有它

Tell 1 是 Retell 語音技術堆疊中的推理層，在公司首頁的「Developed by Retell Labs」項目下，與一個負責整合模型、知識與工具的 agent harness 並列展示。它並非以模型的形式販售。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 毫秒的預算；一旦超過，這段停頓就會被聽成斷線。這筆預算要依序支付語音辨識、模型回合、工具呼叫和語音合成的時間。

• 模型延遲 — 在 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 個；廠商指出，手機上可達到每秒 30 個 token；2.69B 模型的速度取決於機器，而非服務等級。

那最後一句正是根本的性質差異。Tell 1 的延遲是別人替你兌現的承諾；LFM2.5 的延遲則是你所選硬體的固有屬性。如果你的部署目標是擁有 200 條並行線路的客服中心，你買的就是前者。如果是倉庫裡沒有網路的裝置，後者則是唯一存在的選項。

微調是道路上的岔路口

以下是我的決定，我會盡可能說得直白。若你有一個能精確描述的任務、該任務的範例，以及一個不該把那些範例送給第三方的理由，就選 LFM2.5 2.6B Base：通話流程中的分類步驟、領域專用摘要器、決定某個請求是什麼的裝置端路由器。這個模型小到微調只需一個下午，而不是一季；上下文視窗大到足以處理真實文件；授權允許年營收低於 1,000 萬美元的商業使用，達到或超過此門檻則須另行簽訂協議。這個門檻是採購事實，應納入決策本身，而不是放在註腳。

如果你買的是電話代理，而不是模型，就選擇 Tell 1；尤其是當你無法自行打造的是對話互動層時：插話處理、口語化措辭，以及第一個音節要來得夠快，快到讓來電者察覺不出是機器。Retell 的基準報告指出，這正是 Tell 1 領先的兩個面向——口語排名第 1、延遲排名第 1——也同樣明確指出，它在指令遵循、grounding 或工具呼叫上並未領先，排名分別是第 2、第 2 和第 5。在標準化之前，請用自己的通話測試這三項，因為它們會造成答錯，而不只是答得比較慢。

還有第三種選項，也是多數擁有實際工作負載的團隊最終會採用的做法：把小型微調模型保留給任務中狹窄且重複的部分，並將困難的回合導向更大的託管模型。這正是路由層所為而生的分工，也是 我們自家的模型目錄發揮作用的地方。Tell 1 和 LFM2.5 2.6B Base 都無法透過 OrcaRouter 進行路由——我們並未託管其中任何一個——因此這個架構的實務版本，是把 Liquid 微調模型放在你自己的硬體上，並將升級路徑送到我們確實有提供的模型，使用同一組 API 金鑰，按 供應商定價、不加收任何費用。

什麼會改變答案？

就線索一而言，有三份公開資料能讓它從「平台內部測試」推進到「考慮標準化」：一份載明架構與訓練資料的模型卡、一個按模型計價的價格（讓成本能從每分鐘的套裝方案中拆分出來），以及一場由 Retell 以外的人員執行的評測。目前的紀錄不過是供應商自家排行榜上的一列，而供應商在自己的測試框架上把自己排在第一，那只是假設，不是結果。

對於 LFM2.5 2.6B Base，缺少的不是文件說明，而是你自己的微調。檢查點是完整的，授權條款也清楚可讀，這意味著唯一的未知數是：一個以你的資料訓練的 2.69B 模型，能否在你的任務上達到門檻。這是你能用一張 GPU 在本週回答的問題，再多的閱讀也無法替你回答。這就是一句話總結的取捨：Tell 1 替你省下工程工作並拿走控制權；LFM2.5 2.6B Base 給你控制權，並讓你去做工程工作。