ScaleDownの日常的なアプリ内業務向け小型モデル：分類、抽出、要約

2026年10月13日、ScaleDownは、単一のアイデアとして売り出している3つの小型タスク特化モデルの全貌を明らかにした。Classify、Extract、Summarizeで、いずれも会話用ではなく、本番のLLM呼び出しを取り巻く反復作業向けに作られている。3つとも100万トークンの入力を受け付け、3つともテキストまたは画像を受け付け、3つともScaleDown独自のAPI経由で利用できる——ここが価格の話が面白くなるところだ。3つはコスト構造がまったく異なるからである。このファミリーの4番目のモデルであるScaleDown Compressは、ベンダーのドキュメントでは、新しい3つのうちの1つではなく、コンテキストをトリミングするツールとして記載されている。以下はベンダーがドキュメント化している内容であり、まだ誰も再現していないものとは分けて扱う。

10月13日に実際に出荷されたもの

ScaleDown はしばらくの間、Decisions エンドポイントを運用してきた — 状態オブジェクトと型付きの質問のマップを受け取り、較正済みの確率を返す、構造化スコアリング用インターフェースである。10月13日の発表は、同社が基盤となるモデルを単一のエンドポイントとしてではなく、それ自体が独立した製品として販売し始め、アプリ内作業向けの汎用コンポーネントとして説明し始めた時点である。

ベンダーが文書化しているとおりの、3つのモデルとそれらの契約:

• ScaleDown Classify — 呼び出し元が指定するラベルセットにテキストを割り当てます。各ラベルは名前とルーブリックを持ち、ドキュメントではこれを「モデルがそのラベルをスコアリングするために使用する yes/no の問い」と呼び、リクエストの中で最も重要な部分であると説明しています。シングルラベルモードでは、合計が 1.0 になるソフトマックス分布と、最上位のラベルを返します。マルチラベルモードでは、呼び出し元が設定したしきい値に対して各ラベルを個別にスコアリングします。

• ScaleDown Extract — 非構造化テキストから構造化フィールドを抽出します。このファミリーのドキュメントでは、文書をコードがインデックス化できるレコードに変換するモデルとされています。

• ScaleDown Summarize — 長文入力の短い抽象的要約であり、100万トークンのウィンドウが最も明確に狙っている用途です。

三つすべてに共通する契約が、書き留めておく価値のある部分だ。リクエストあたり100万トークンの入力は、主流の中規模APIが受け取る量をおよそ一桁上回っており、チャンク化レイヤーなしで文書全体を扱う上でSummarizeとExtractを現実的にする数字だ。テキストか画像かの入力は、特にExtractにとって重要だ。スキャンした請求書やフォームのスクリーンショットを入れるとフィールドが出てきて、その間にOCRステップは存在しない。三つともScaleDown自身のAPIから提供されており、そのドキュメントではベースURLがspan>api.scaledown.xyz/span>と示され、span>api.scaledown.ai/span>はAPIホストではないと明記されている。

他のものとは違う唯一の数字

価格設定は、これら3つが互換的でなくなる点です。Classifyは入力トークン100万個あたり$0.05、出力トークン100万個あたり$0で掲載されており、サードパーティのカタログにおけるこのモデルの掲載でも同じ料率が示されていますが、時折プロモーション割引が適用されます。その割引はScaleDownによるコミットメントではなく、それを前提に計画すべきではありません。出力価格がゼロであるのはマーケティング上の仕掛けではありません — ルーブリックで採点される分類器は生成テキストではなくラベルと確率を出力するため、請求すべきものが何もありません。ExtractとSummarizeは実際に出力を生成するため、これらのコスト構造はClassifyのものとは比較できず、分類器の料率から推測するのではなく、ベンダーから直接価格を確認すべきです。

Classifyの課金明細は、見出しの料金よりもずっと推論が難しい。単一ラベルモードでは、すべてのラベルとそのルーブリックが1回のモデル呼び出しに入るため、ラベルを追加するごとに課金対象の入力トークンが増える。選択理由を一文で説明させるよう求めると、それらが2倍の料金で再送信される。しかもドキュメントには、説明は最上位ラベルが確定した後に生成されると明記されているので、その説明は答えを正当化するものであり、答えを疑い直すものではない。マルチラベルモードでは、各ラベルが個別のモデル呼び出しとなり、各チャンクは別々に採点される。したがって、推論を有効にした60ラベルのタクソノミーは、読者が想定する意味での100万トークンあたり0.05ドルの処理ではない。それはその料金にラベルセットを掛けたものであり、推論が有効ならさらに2倍になる。ドキュメントに記載されている上限——リクエストあたり20ラベル、マルチラベルモードでは16、バッチあたり50チャンク——が、設計時に考慮すべき実際の制約である。

こうした上限のどれよりも重要な、文書化された挙動がもう一つあります。分類器は「常に何らかの勝者を返す」のであり、どのラベルにも当てはまらない場合でもそうです。信頼度によるフィルタリングは完全に呼び出し側に委ねられています。10ラベルのリクエストでは、スコアは絶対値ではなくラベルセット内での相対値であるため、最高スコアが0.4でも正解であり得ます。このモデルを本番で使うあらゆる場面に、独自のしきい値ポリシーと、すべてを受け止めるキャッチオールラベルが必要です。ドキュメントでは、それに span>other/span

分類器における100万トークンのウィンドウがなぜ興味深い部分なのか

分類器モデルは従来、短い入力を取る。理由は機械的である：ルーブリックで採点される分類器は、入力全体を各ラベルのyes/noの質問と比較検討しなければならず、10万トークンの文書を20個のルーブリックに対して採点するコストは、その文書を20回完全に走査することに等しい。ScaleDownの答えは、1Mウィンドウとバッチ処理レイヤーである — 1回のリクエストで最大50チャンクを1つの共有プロファイルに対して採点する — そしてベンダーの主張は、1チャンクを送るか50チャンクを送るかに関わらず、チャンクごとのキャリブレーションは同じであり、唯一の違いは共有プロファイルがリクエストごとに1回課金されることである。

その主張こそ、それに基づいて構築する前に検証すべきものだ。また、それはこのモデルを面白くしている主張でもある。アプリケーション内で分類するのであってエッジで行わない理由は、判断が完全なコンテキスト——サポートスレッド全体、契約書全体、取得した文書全体——を見られるからであり、切り詰められたウィンドウしか見られないからではない。もし1Mウィンドウがあなたの入力サイズで持ちこたえるなら、アーキテクチャ上の問い（「チャンキングと投票の仕組みが必要か？」）はほぼ消える。持ちこたえないなら、あなたには非常に安価な短入力分類器と、解くべき第二の問題があることになる。

セカンドオピニオンが必要な請求

ScaleDownのマーケティングは、タスク特化型の小規模言語モデルが、大量の反復作業においてコスト、速度、精度でフロンティアモデルを上回ると主張しており、約5億パラメータのモデルが単純な分類タスクで91.7%に達し、720億パラメータのモデルでは88.6%だったという数値を含めて引用している。これらはベンダー自身の数値であり、独立に再現されたものではない。ScaleDown Classifyは現在、公開リーダーボードではスコア未評価の状態にあり、第三者によるベンチマークの行も公表されていない。精度に関する主張は、もっともらしいメカニズムを伴う仮説として扱うべきである——狭い分類体系において、目的に特化して訓練された小規模モデルと汎用の大規模モデルとの間のサンプル効率の差は実在し、十分に文書化されている——確立された結果としてではなく。

100万トークンの入力値も同様にベンダー申告です。このモデルに関するサードパーティのカタログ掲載では、100万トークンという数字をそのまま反映するのではなく、コンテキスト長を該当なしとして示しており、これは矛盾ではなくカタログ上の制約ですが、しかしそれによって、このウィンドウがScaleDownのドキュメント以外では裏付けられていないことが意味されます。

すでにパイプラインを運用している場合、これがどこに当てはまるか

これら3つのモデルが想定しているのは、単一の呼び出しではなくループです。文書を取得し、分類し、フィールドを抽出し、要約し、その要約を生成モデルに渡して返信を書かせます。トークン単価で見ると高コストなのは4番目のステップであり、まさにそこをOrcaRouterがカバーします — 200以上のモデルを1つのOpenAI互換キーの背後に、プロバイダーの定価を0%のマークアップでそのまま、提供経路が劣化した際の自動フェイルオーバー付きで。当社はScaleDown Classify、Extract、Summarizeをホストしていません。これらは当社のカタログに含まれておらず、chat-completionsの対象でもありません。また、ここでのルーティング層はパターンの採点側ではなく生成側です。

その区分ははっきり述べておく価値がある。なぜなら、人がすぐに持ち出すコスト比較は誤解を招くからだ。100万入力トークンあたり数セントのルーブリック採点分類器と、100万あたり数ドルの生成モデルは競合相手ではない。それらは別々の費目であり、分類ステップに小さなモデルを置く理由は、実際に何かを書き出すステップにより良いモデルを使う余裕が生まれることにある。

何がこの評価を変えるでしょうか

状況を大きく変えるであろう順に、3つの点がある。公開ベンチマーク上でルーブリック採点による分類タスクを独立評価すれば、精度の論拠はベンダーの主張から1つのデータに変わるだろう。公開されたレイテンシ値——ベンダーはコスト要因は文書化しているが、サービングレイテンシは文書化していない——があれば、1Mウィンドウがスループットで使えるのか、それともバッチでのみ使えるのかが決着するだろう。そして、チャンク単位のキャリブレーション主張の第三者による再現があれば、50チャンクのバッチがコスト最適化なのか、別のモデルなのかが決まるだろう。少なくともそのうちの1つが実現するまでは、正直な要約はこうだ。ScaleDownは、異例に明確な契約と異例に大きな入力上限を備えた3つのモデルを出荷しており、その価格はしきい値ベースの分類段階を検討に値するほど安くし、それらを裏付ける数値はベンダー自身のものである。

短いバージョン

大量処理の分類または抽出ステージがあり、安定的なタクソノミーとテキストまたは画像入力を扱っているなら、ScaleDownの3つのモデルは今週、自社データでベンチマークする価値があります。契約がシンプルで、入力上限も寛大だからです。タクソノミーを確定する前に、ラベルの増殖と2倍の推論サーチャージを見込んで予算を組み、信頼度しきい値は自分で書くことになると思っておいてください。あなたのタスクがオープンエンドの生成なら、これはどれもあなた向けではありません。

モデルの選択は、これまでに何がうまくいかなかったかという問題でもあります。このクラスのモデルの背後にある、文書化されたAIインシデントやエージェントの障害は、OrcaRouter AI Incident Archiveにまとめられており、各エントリには独自の情報源、深刻度、信頼度グレード、係争中フラグが付いています。