ScaleDown 用於應用程式內日常任務的小型模型：分類、擷取、摘要

2026 年 10 月 13 日，ScaleDown 揭開了三款小型、任務專用模型的面紗，並將它們包裝成單一概念來銷售：Classify、Extract 與 Summarize，這三者都是為了圍繞正式環境 LLM 呼叫的重複性工作而打造，而非為了對話。三者都接受 100 萬 token 的輸入，都能接受文字或圖像，也都可以透過 ScaleDown 自家的 API 存取——而這正是定價問題變得有趣的地方，因為這三者的成本結構截然不同。這個家族中的第四款模型 ScaleDown Compress，在供應商文件中被列為情境修剪工具，而非這三款新模型的其中之一。以下內容是供應商文件所記載的，並與至今尚無人重現的部分分開呈現。

10月13日實際上線了什麼

ScaleDown 經營一個 Decisions 端點已有一段時間——這是一種結構化評分介面，會接收一個狀態物件以及一份具型別問題的映射，並回傳經過校準的機率。10 月 13 日的公告，是該公司開始將底層模型本身當作獨立產品來販售、而非僅作為單一端點販售的時點，也是它開始將這些模型描述為可供應用程式內工作使用的通用元件的時點。

這三個模型及其合約，正如供應商文件所述：

• ScaleDown Classify — 將文字指派到呼叫端提供的標籤集。每個標籤都帶有名稱與評分準則（rubric），文件稱之為「模型用來為該標籤評分的是/否問題」，並將其描述為請求中最重要的部分。單標籤模式會傳回總和為 1.0 的 softmax 分佈，外加一個最高標籤；多標籤模式則會根據呼叫端設定的閾值，獨立為每個標籤評分。

• ScaleDown Extract — 從非結構化文字中擷取結構化欄位。在此系列的說明文件中，這是能把文件轉換成你的程式碼可建立索引之紀錄的模型。

• ScaleDown Summarize — 為長輸入提供簡短的抽象式摘要，而這正是 100 萬 token 視窗最明顯鎖定的任務。

三者共用的契約才是值得寫下來的部分。每個請求一百萬個 token 的輸入，大約比主流中型 API 所能接受的量高出一個數量級，而正是這個數字讓 Summarize 與 Extract 在無須分塊層的情況下，對整份文件進行處理變得可行。文字或影像輸入對 Extract 尤其重要：掃描的發票或表單的螢幕截圖送進去，欄位跑出來，中間沒有任何 OCR 步驟。三者都由 ScaleDown 自家的 API 提供服務，其文件給出的基底網址是 span>api.scaledown.xyz/span>，並且明確表示 span>api.scaledown.ai/span> 不是 API 主機。

那個與眾不同的數字

定價是這三者不再能互換的地方。Classify 的標價為每百萬輸入 token 0.05 美元、每百萬輸出 token 0 美元，而該模型在第三方目錄上的列表顯示，同樣的費率有時會套用促銷折扣；該折扣並非 ScaleDown 的承諾，不應以此為規劃依據。輸出價格為零並非行銷手法——以評分標準評分之分類器會輸出標籤和機率，而非生成的文字，因此沒有可計費的內容。Extract 和 Summarize 確實會生成輸出，因此它們的成本結構與 Classify 的不可相比，應直接向供應商詢價，而非從分類器的費率推斷。

Classify 的計費細節比表面費率更難推斷。在單標籤模式下，每個標籤及其評分標準都會進入一次模型呼叫，因此你新增的每個標籤都會增加計費的輸入 token 數；要求提供一句話的選擇說明會以 2 倍重新傳送它們，而文件明確表示，說明是在最高標籤確定之後才生成的，因此它是在為答案辯護，而不是對其提出質疑。在多標籤模式下，每個標籤都是一次獨立的模型呼叫，而每個區塊則分別評分。因此，一個啟用推理的六十標籤分類體系，並不是讀者所假設的那種每百萬 token $0.05 的操作；而是該費率乘以標籤集，若啟用推理則再翻倍。文件記載的上限——每次請求 20 個標籤、多標籤模式下 16 個、每批次 50 個區塊——是設計時必須應對的實際限制。

還有一個有文件記載的行為，比上述任何上限都更重要。分類器「永遠會回傳一個贏家」，即使沒有任何標籤合適也一樣。信心篩選完全交由呼叫端決定。在一個要求 10 個標籤的請求中，最高分數為 0.4 仍可能是正確答案，因為這些分數是標籤集合內的相對值，而非絕對值。此模型在正式環境中的每一次使用，都需要有各自的閾值政策，而一個萬用標籤——文件建議命名為 span>其他/span>——在實務上並非可有可無。

為什麼分類器上的 1M-token 視窗才是有趣的部分

分類器模型通常接受短輸入。原因很機械：以評分規準計分的分類器，必須將整份輸入與每個標籤的是／否問題相互權衡，而用二十條評分規準來為一份十萬字符的文件計分，成本就是對該文件完整掃描二十遍。ScaleDown 的解答是 1M 視窗加上批次處理層——在單一請求中，最多可將 50 個區塊對照同一份共用設定檔進行評分——而廠商的主張是：不論你送出一個還是五十個區塊，每個區塊的校準結果都相同，唯一的差別在於共用設定檔是每次請求計費一次。

那個主張就是你在據此建構之前必須先驗證的那一項。它同時也是讓這個模型變得有趣的那個主張：之所以要在應用程式內部而非在邊緣進行分類，整個理由在於這項決策能看到完整脈絡——整條支援討論串、整份合約、整份檢索到的文件——而不是一個被截斷的視窗。如果 1M 視窗在你的輸入大小下站得住腳，那麼架構問題（「我需要一套分塊與投票機制嗎？」）大致上就會消失。如果它站不住腳，你就有了一個非常便宜的短輸入分類器，以及第二個待解決的問題。

需要第二意見的主張

ScaleDown 的行銷主張認為，針對特定任務的小型語言模型在大量重複性工作的成本、速度和準確度上，都優於前沿模型，並引用了一些數據，包括一個約五億參數的模型在一項簡單分類任務上達到 91.7%，而一個 720 億參數的模型則是 88.6%。這些是供應商自家的數字，尚未經過獨立重現：ScaleDown Classify 目前在公開排行榜上尚未獲得評分，也沒有公布任何第三方基準測試列。應將這項準確度論點視為一個具有合理機制的假設——一個專用訓練的小型模型與一個通用大型模型在狹窄分類體系上的樣本效率差距，確實存在且已有充分文獻記載——而非已確立的結果。

100 萬 token 的輸入數字同樣是廠商自行宣稱的。第三方為該模型列出的目錄資料將上下文長度標示為「不適用」，而非沿用那個百萬 token 的數字；這屬於目錄本身的限制，而非相互矛盾，但這確實意味著該上下文視窗並未在 ScaleDown 的文件之外獲得佐證。

如果您已經在執行管線，這適合放在哪裡

這三個模型所瞄準的模式是一個迴圈，而非單次呼叫：檢索文件、將其分類、擷取欄位、加以摘要，接著把摘要交給生成式模型來撰寫回覆。第四步以每個 token 計算是最昂貴的一步，而這正是 OrcaRouter 所涵蓋的步驟——以一組相容於 OpenAI 的金鑰取得超過 200 個模型，收費方式為供應商定價原封不動轉嫁、零加成，並在服務路徑效能下降時自動容錯移轉。我們不代管 ScaleDown Classify、Extract 或 Summarize；它們不在我們的目錄中，也不是 chat-completions 的目標，而這裡的路由層是此模式的生成那一半，而非評分那一半。

那個區分值得明白說清楚，因為人們會拿來做的成本比較其實會誤導人。以每百萬輸入 token 只要幾分錢計價的評分標準分類器，和每百萬要價幾美元的生成式模型，並不是競爭對手；它們是不同的費用項目，而在分類步驟放一個小模型的原因，是這樣一來你就能負擔得起在真正負責寫出內容的那個步驟使用更好的模型。

什麼會改變這項評估？

三件事，按它們能多大程度改變整體判斷的順序排列。對這項以評分標準計分的分類任務，在公開基準上做獨立評估，將能把準確率的論據從供應商的說法變成一筆實測資料。一個公開的延遲數字——供應商記錄了成本驅動因素，卻沒有服務延遲——將能釐清 1M 視窗是在吞吐量下可用，還是僅能在批次處理時使用。而由第三方重現「逐區塊校準」這項主張，將能判定五十區塊的批次究竟是一種成本最佳化，還是其實是不同的模型。在上述至少一項落實之前，最誠實的總結是：ScaleDown 已推出三個模型，其合約異常清楚、輸入上限異常大，價格則讓以閾值為基礎的分類階段便宜到值得考慮，而支撐這些數字的，是供應商自己的數據。

簡短版本

如果你有大批量分類或擷取階段，且具備穩定的分類法與文字或圖像輸入，那麼本週值得用你自己的資料對 ScaleDown 的三個模型做一次基準測試，因為合約很單純，輸入上限也很寬鬆。在確定採用某套分類法之前，請先為標籤倍增和 2 倍推理附加費編列預算，並預期你得自行撰寫信心門檻。如果你的任務是開放式生成，這些都不是針對你。

模型選擇也關乎過去曾出過哪些問題：此類模型背後有紀錄的 AI 事故與代理失敗，都收錄在OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心評級與爭議標記。