LongCat-2.5-Preview 對決 GPT-5.6 Sol：1M Token 視窗在雙方各要付出什麼代價

關於 LongCat-2.5-Preview對上GPT-5.6 Sol，你能說的最有用的一件事，並不是哪一個更聰明，而是兩者都標榜約一百萬個 token 的上下文視窗，卻只有其中一個對整個視窗收取相同費率。Sol 在輸入超過 272,000 個 token 之後，價格就翻倍。而就美團所公布的價目表來看，LongCat-2.5-Preview 完全沒有分級收費。這個單純的結構性差異，在還沒查閱任何基準測試之前，就已經決定了大多數真實的長文件工作負載——而這正是規格表比較永遠不會告訴你的事，因為兩款模型都把「1M」用同樣的字級印出來。

以下是每個人實際上記錄在案的內容，並按值得提出的問題來整理。

百萬 token 視窗在兩邊是同一款產品嗎？

不，差別不在於視窗——而是在於你填入它時會發生什麼事。我們的產品目錄列出 Sol，具備 1,050,000 個 token 的上下文視窗，最大輸出為 128,000 個 token，對於最高 272,000 個 token 的請求，每百萬個輸入 token 為 $4.00 美元，每百萬個輸出 token 為 $20.00 美元；快取輸入為每百萬 $0.40 美元，快取寫入為每百萬 $5.00 美元。超過該門檻後，費率會調升至每百萬 $8.00 和 $30.00 美元。因此，在 Sol 上處理一份 500,000 個 token 的文件時，整筆請求都會以長上下文費率計費，而不是混合費率。

LongCat-2.5-Preview 列出 1,000,000 個符元的上下文，以及 131,072 個符元的最大輸出。其費率表——發布於 Meituan 自家平台，並在該處標示為限時折扣——為每百萬個未快取輸入符元 0.30 美元、每百萬個已快取輸入符元 0.006 美元，以及每百萬個輸出符元 1.20 美元。Meituan 並未公布第二個價格層級。這並不等於說不存在第二個價格層級——而是說該供應商尚未描述任何第二層級，而一個未被描述的價格，不是你能據以編列預算的價格。

給它一個數字。讀取 500,000 個 token、寫回 20,000 個 token，在 Sol 的長上下文層級大約花費 4.60 美元，而在 LongCat-2.5-Preview 上以其公佈的促銷費率大約是 17 美分。這兩個數字都是根據公佈的價目表計算得出的，並非實測值。這個比率大到足以改變在經濟上合理嘗試的範圍：在 Sol 的長上下文費率下，將程式碼庫餵入模型是一個需要抉擇的決定；在 LongCat 的費率下，這更接近預設做法。

哪一個的數字背後有證據？

Sol，以相當大的差距勝出，而這正是讓這項比較不至於淪為單純價格之爭的關鍵。Sol 是 2026 年 7 月發布的版本，在我們的目錄中擁有完整的獨立評測檔案：Coding Index 為 77.4，在 Artificial Analysis 追蹤的模型中排名第三；Intelligence Index 為 47，排名第十三；GPQA Diamond 94.1%；Humanity's Last Exam 49.5%；SciCode 57.1%；Terminal-Bench v2.1 為 88.0；τ²-Bench 為 85.1。以上數據皆出自 Artificial Analysis，而非 OpenAI。

它在這項比較中最相關的數字是長上下文召回率：84。那是我們引進的前沿模型中最高的，而它衡量的是模型是否仍能運用到長輸入深處的資訊——這正是大型上下文視窗理應回答的問題。這項數據同樣是在 Sol 自家的上下文長度下、依 Sol 自家的標準測得的。

LongCat-2.5-Preview 並沒有對等的同類產品。美團針對 2026 年 9 月 25 日的變更記錄條目宣稱具備圖像理解、程式編寫能力，並相容於「Claude Code 與其他主流開發環境」，還點名了 Hermes、OpenClaw、OpenCode 與 Kilo Code。它並未公布任何基準測試表、模型卡或技術報告。約 1.6 兆總參數、每 token 約 480 億活躍參數的說法，來自美團網站的詮釋資料與中國業界報導，而非官方文件。HuggingFace 上沒有 LongCat-2.5-Preview 的儲存庫，美團的 GitHub 組織中也沒有，而 OpenCode 隨附的目錄詮釋資料則將開放權重記載為 false。

是輸入端相符，還是只有輸出端？

這正是 Sol 的支援範圍更廣，而 LongCat 則備受爭議之處。在我們的型錄中，Sol 接受文字、圖像與檔案作為輸入，並輸出文字。LongCat-2.5-Preview 的更新日誌將圖像理解列為其頭號新增功能——「解析圖像內容以進行跨模態問答、內容摘要與複雜視覺推理」——但美團自家的「Retrieve Model」文件中的範例回應仍顯示 input_modalities 為 ["text"]，並帶有 text->text 的模態字串。該範例可能只是過時了。儘管如此，它仍是廠商公布的合約，而誠實的解讀是：在實際測試之前，圖像輸入只是聲稱支援，而非已獲確認。

一個實際的後果：來自 LongCat-2.5-Preview 的推理軌跡，是以交錯的 reasoning_content 欄位形式送達，而非以取樣參數的形式。若某個工具框架在解析對話補全結果時並未預期會有這個欄位，就會悄然丟棄模型的思考過程——不會報錯，只是得到更差的答案。無論你對這個模型本身作何判斷，請先確認這一點。

哪一條才是你真正能保留的路線？

Sol 是我們自家提供的。我們以 OpenAI 的定價提供，零加價，因此供應商的價格變動會在當天反映到您的帳單，而非等到下一次續約，且自動容錯移轉會把效能劣化的請求轉往健康的供應商，您的應用程式毫無所覺。LongCat-2.5-Preview 並非我們的路由之一——我們不提供它，本文任何內容都不應被解讀為我們聲稱有提供。

這種不對稱性，正是路由層在這項特定比較中之所以有其價值的原因，而非只是一般性的附帶說明。Sol 的分級定價意味著同一項任務可能單憑輸入長度就貴上一倍，而門檻落在 272,000 個 token——這個數字是你的應用程式在送出請求之前就知道的。依請求大小把工作負載拆分到不同供應商，正是路由 DSL 的用途所在，而模型融合更進一步：可以在單一請求中組合兩個模型，這樣一來，長脈絡的處理與高品質的綜合步驟就不必是同一模型、同一費率。這兩點都不是選擇一個沒有公開基準測試的模型的理由。兩者都是不該把模型寫死的理由。

總結來說

如果你的工作負載很短，Sol 是最直截了當的選擇：它在程式編碼指數中排名第三，各方面的數據都有獨立來源，而且它的輸入端有文件記載。如果你的工作負載很長，這筆帳就會急遽翻轉——同樣讀取 500,000 個詞元，Sol 的長上下文層級成本大約是 LongCat-2.5-Preview 促銷費率的 26 倍，而真正能回答長窗口是否管用的是 Sol，它的召回分數是 84。你是在以尖端價格買一個經過實測的長窗口，來對比一個未經實測、以折扣價提供的長窗口，而後者的供應商已經標明那是暫時性的。

要避免的失敗模式，是把它們當成可互相比較的選項。它們不是以不同價格販售的同一款產品；而是一項有明確記載的能力，以及一個承諾。縮小落差的正確做法，是在 LongCat-2.5-Preview 透過 OpenCode 免費、或透過 Meituan 便宜取得時，把它用在你自己的長上下文任務上——並且把 Sol 放在路由器後面，這樣一來，當促銷費率消失，或長上下文方案超出你的預算時，切換就只是一行設定，而不是一次遷移。