モデルルーティングをTypeSafe(Jev)に置き換えたら、どれくらい速く・安くなるか試してみた

クラスメソッドマレーシアの森永です。

以前の記事「NeMo Switchyardをファーストタッチで検証してみた」で、NVIDIAのLLMルーティング基盤 NeMo Switchyard の llm-routing 方式を検証した際、classifier（どのモデルに振り分けるかを判定する役)に何を使うかで「速いけど高い」「安いけど遅い」というトレードオフに悩まされたという結果が報告されていました。

この記事では、「そのclassifier部分を、テキスト生成をしない構造化判定特化モデル TypeSafe の Choice プリミティブに置き換えたら、このトレードオフごと解消できるのでは」という仮説を、実際にTypeSafeのAPIを叩いて確かめてみました。

元記事のモデル選択が抱えていた問題

元記事によると、NeMo Switchyard の llm-routing は、直近4ターンの会話を要約し、classifierモデルで simple / medium / complex / reasoning の4段階に分類してから、対応するティア（弱いモデル〜強いモデル）にリクエストを振り分ける仕組みです。分類に失敗した場合はデフォルトのティアに自動的にフォールバックする、fail-open設計になっています。

このclassifierに何を使うかで、次のような結果になったと報告されていました。

つまり、reasoningを許すLLMを使えば速いがコストが跳ね上がり、reasoningを止められるLLMに変えるとコストは下がるがレイテンシが大きく悪化する、という「同じLLMの中での二択」から抜け出せていませんでした。classifierはあくまで「4択のどれかを当てる」だけの軽いタスクのはずなのに、LLM本来のテキスト生成・reasoningの仕組みに引きずられてしまっているのが根本原因です。

TypeSafeとは何か

TypeSafe は、構造化された意思決定に特化したAIプラットフォームです。旗艦モデルの「Jev」は「最初のSystem One Model」と位置づけられており、公式ドキュメントでは "unstructured state in, typed probabilistic decisions out"（構造化されていない状態を入力すると、型付きの確率的な判定が出力される）と説明されています。

通常のLLMのように文章を生成してからパースするのではなく、サンプリング層から直接、型付きの値と確率分布を返すのがポイントです。用意されているプリミティブは3種類です。

• Choice: 選択肢のリストから1つを選ぶ（確率・信頼度つき）
• Score: ルーブリックに基づいてスペクトラム上にスコア化する
• Noul: ある文が真か偽かを0〜1の値で判定する

この Choice は、「入力を受け取って、あらかじめ決めた選択肢の中から1つ選ぶ」というタスクそのものなので、NeMo Switchyardの「simple/medium/complex/reasoningのどれかに分類する」というclassifierの仕事と、設計上ほぼそのまま置き換えられる形をしています。

料金は入力トークン $0.042 / 100万トークンで、出力トークンは無料です。公式ブログでは、エンドツーエンドのレイテンシを70〜500ms、比較対象LLMに対して20〜200倍高速と謳っています。

ウェイトリストに申し込んだらすぐに使えるようになったので検証してみます！

実際にやってみた

検証の範囲

今回やったのは、TypeSafeのAPIを直接叩いて Choice による4ティア分類のレイテンシ・コスト・分類結果を単体で計測するところまでです。NeMo Switchyardのclassifierとして実際にJevを差し込んで動かす（Switchyardに組み込む）ところまではこの記事では行っていません。

軽く調べたところ、SwitchyardのclassifierはOpenAI Chat Completions等、決まった形式を話すtargetとして構成する設計になっており、TypeSafeの/v1/systemoneをそのままbase_urlに指定して繋ぐことはできませんでした。間にアダプタを挟むか、Switchyardをライブラリとして組み込んでルーティングロジックの中から直接呼び出す必要があり、思ったより骨が折れそうだったため、Switchyardへの組み込みは次回の記事に回すことにしました。そのため、以下のレイテンシ・コストの数値はTypeSafe単体を直接叩いた場合の実測値であり、実際にSwitchyard経由で使った場合のレイテンシとは異なります（ルーティング層やアダプタのオーバーヘッドが上乗せされるはずです）。この点を踏まえてお読みください。

検証方針

NeMo Switchyardの llm-routing を模して、「直近の会話を要約したテキスト」を渡し、Choice で simple / medium / complex / reasoning の4ティアに分類させるリクエストを、TypeSafeの実際のAPI（POST https://api.typesafe.ai/v1/systemone）に対して送りました。

各ティアについて、典型的な会話サマリを1件ずつ用意し、criteria は次のようにNeMo Switchyardの4分類にそのまま対応させました。

TIER_CRITERIA = {
    "simple": "単純な質問への一問一答、または短い確認応答で完結する。ツール実行や複数手順の計画は不要。",
    "medium": "説明や軽いアドバイスが必要だが、複数ステップの調査やツール連携は伴わない。",
    "complex": "複数のファイル・ログ・ツール実行結果を突き合わせるなど、複数ステップの調査や実行を要する。",
    "reasoning": "トレードオフの比較や設計判断など、深い論理展開・多制約の同時考慮が必要。",
}

リクエスト自体は非常にシンプルです。

payload = {
    "state": state_text,  # 直近の会話を要約したテキスト
    "model": "jev-latest",
    "questions": {
        "tier": {
            "type": "choice",
            "instructions": "この会話の直近のやり取りを踏まえて、次に必要な対応の難易度ティアを判定してください。",
            "criteria": TIER_CRITERIA,
        }
    },
}

4パターン（simple/medium/complex/reasoningそれぞれを期待する会話サンプル）に対して、各10回ずつ、合計40回APIを呼び出し、レイテンシ・分類結果・信頼度・コストを記録しました。

結果

40コールすべてが成功し、分類結果は4パターンとも10/10回、期待したティアと完全に一致しました。

元記事のclassifier実測値と並べると、次のようになります。

レイテンシ（中央値ベースで0.643〜0.674秒、平均値まで含めると0.652〜0.690秒）は、reasoningを許すGemini 3.5 Flash classifier比で約3倍、reasoningを止めたDeepSeek V4 Flash classifier比で約10〜11倍高速という結果になりました。コストについては、NeMo Switchyard側が「セッション単位」、今回の実測が「1コールあたり」と単位が異なるため単純な比較はできませんが、1回の判定にかかるコストとしては桁が違うことは確認できました。

注意したいポイント

今回の検証結果についていくつか注意したほうがよいポイントがあります。

• medium ティアだけconfidenceが低め: simple/complex/reasoning はconfidence 1.0で迷いなく分類された一方、medium は0.57〜0.67とやや低めの値が返ってきました。境界線上のケースで判定が揺れやすいことが確率分布として素直に表れており、これはLLMのテキスト分類にはあまりない利点だと感じました。confidenceに閾値を切って「低ければ安全側のティアにフォールバックする」といった運用がしやすそうです。
• Switchyardには組み込んでいない: 繰り返しになりますが、今回の数値はTypeSafe単体を直接叩いた場合の実測です。実際にNeMo Switchyardのclassifierとして動かした場合のレイテンシではないので、本番導入時の数値としてそのまま使わないようにしてください。
• 今回の検証は分類精度の網羅的なベンチマークではない: 4ティアそれぞれに1パターンずつ、わかりやすい会話サンプルを用意したものなので、境界線上のケースを大量に用意した精度検証ではありません。また、そもそもTypeSafeの売りは精度そのものではなく速度・コストである点にも注意が必要です。ベンダー自身が公表しているワークフローベンチマークでも、Jev 76.0%に対しGPT-5.6 Luna 76.1%・DeepSeek V4 Flash 76.8%と、精度面で他モデルを明確に上回っているわけではありません。さらに第三者による独立検証（Every社）では、Jev 67.8%に対し最良の比較対象は74.1%と、その差はもう少し開いています。「速度・コストは圧倒的だが、精度は横並びかやや劣る」というのが実態に近く、精度がボトルネックになりうる用途では別途しっかり検証したほうがよさそうです。

まとめ

元記事の llm-routing が抱えていた「classifierを軽くすればレイテンシが悪化し、reasoningを許せばコストが跳ね上がる」というトレードオフに対して、テキスト生成をしない構造化判定特化モデル TypeSafe(Jev) の Choice プリミティブに置き換えることで、実測ベースで元記事のどちらの構成よりも速く、かつコストも大幅に低いという結果が得られました。

仮説通り、Jevのような「reasoningトークンを生成しないアーキテクチャ」は、LLMベースのclassifierが抱える速度とコストのトレードオフを、そもそもの土俵の外から解決するアプローチだと言えそうです。一方で、TypeSafe自体がまだアーリーアクセス段階であること、今回の検証がTypeSafe単体のベンチマークであり実際にSwitchyardに組み込んだ数値ではないこと、精度面の網羅的なベンチマークでもないことは踏まえておく必要があります。

複数モデルのルーティング基盤を運用していて、classifierの速度・コストに悩んでいる方は、選択肢の一つとして押さえておいて損はなさそうです。次回は、実際にNeMo Switchyardへライブラリとして組み込み、classifierとしてJevを動かしたところまで踏み込んでみようと思います。