小さなローカルLLMで答えが物足りないとき、大きなモデルへ交換する以外の方法はあるのでしょうか。NVIDIAのDory 1.0 4Bは、同じ重みの一部を繰り返し適用し、推論時の計算量を調整するモデルです。この記事では仕組みと導入条件を整理し、自分の仕事で比較するための試験セットを用意します。
2026年10月17日の確認時点で、モデルカードの対応言語はEnglishです。日本語入力が必ず失敗するという意味ではありませんが、日本語業務向けの品質保証はありません。またvLLM・llama.cppの対応は未マージのPR段階です。本記事は公開仕様と評価手順の解説で、Doryを実行したレビューではありません。
Doryの新しさは、重みを替えずに計算量を調整すること
正式名はNVIDIA-Nemotron-Labs-Dory1.0-4B。公式モデルカードはリリース日とGAの版を2026年10月16日と記載し、4B規模、テキスト入出力、最大256Kトークンの文脈長を案内しています。公開された重みと導入資料を確認しましたが、一般公開が始まった正確な時刻は不明です。確認したモデルカードの版
「考える回数」という表現は、同じ質問をチャットで何度も聞き直す意味ではありません。内部の層のまとまりを繰り返す回数です。通常の再質問や、複数の回答を作って多数決する方法とは、処理する場所が違います。
| 方法 | 何を繰り返すか | 比べるときの注意 |
|---|---|---|
| Doryのループ | モデル内部の共有ブロック | 同じ重みでも1トークンを処理する計算量が変わる |
| 長い文章での推論 | 中間の推論内容をトークンとして生成 | 出力トークン数や上限も結果に影響する |
| 再質問・複数回答 | モデルへの呼び出しそのもの | 入力の再処理、選別方法、合計待ち時間を含める |
公式の構成説明では、入力側8層、共有する再帰ブロック20層、出力側8層に分かれ、再帰ブロックを繰り返します。2回ループなら共有する重みを2回使うので、別の8Bモデルへ交換することにはなりません。アーキテクチャとHighlights
トークンが減っても、処理時間や費用が減るとは限らない
NVIDIAは、ループを増やすことで出力トークンを減らせると説明しています。一方で、1トークンあたりには追加の計算が必要です。公式も、実際の仕事で開始から完了までの遅延とコストを評価するよう求めています。「出力が短い＝速い」「4回＝必ず正確」と読み替えないことが大切です。ループ回数の選び方
たとえば文章の抽出処理では、モデルの出力時間が短くても、担当者の抜けを人が直す時間が増えれば業務全体は遅くなります。設定を選ぶときは、正答件数・完了までの秒数・人の修正時間を同じ表に残します。これは本記事の評価案で、Doryで改善を確認した結果ではありません。
| 設定 | 公式の案内 | 最初に確かめること |
|---|---|---|
| 1ループ | 1トークンあたりの計算を抑える選択肢 | 最低限の合格条件を満たすか |
| 2ループ | 精度と計算量のバランスを取る出発点 | 1ループの誤りが直るか、待ち時間は許容範囲か |
| 4ループ | 追加の精度を重視する場合の候補 | 2ループを上回る価値が自分の課題にあるか |
公開ベンチマークはNVIDIA側の測定です。公式表には2回から4回へ増やして向上する項目だけでなく、GPQA DiamondやHLEのように値が下がる項目もあります。またAAスコアの図は内部推定と明記されています。自社の日本語作業の合格率や、独立した第三者ランキングとは分けて読みます。ベンチマークと脚注
ローカルLLMでは、重みとKVキャッシュを分けて考える
モデルの重みは、学習で得たパラメーターです。KVキャッシュは、処理中の文脈を扱うために保持するデータです。重みを共有しても、ループごとにキャッシュを保持すればメモリは増えます。Doryはこのキャッシュの持ち方も選べる設計です。
| モード | 再帰部分のキャッシュ | 見落としやすい点 |
|---|---|---|
| per_loop | ループごとに別々に保持 | ループを増やすと、この部分の必要量が増える |
| last_loop | 各再帰Attention層で1つを使い、最後のループの値を残す | PC全体のメモリが一定になるという意味ではない |
last_loopについて、NVIDIAはキャッシュの大きさを1ループ相当に保ち、実験ではper_loopに近い精度だったと報告しています。これはメーカーの評価であり、すべての文脈長・量子化・言語で同じ結果になる保証ではありません。文脈を長くしたり同時処理を増やしたりすれば、別途メモリが必要です。KVキャッシュの説明
配布形式にはBF16、MXFP8、NVFP4、llama.cpp用Q5_K_M GGUFがあります。公式が案内するGGUFファイルは3,673,288,864バイト、約3.67GBです。これはダウンロードするファイルの大きさで、実行に必要なRAM容量ではありません。またBF16のベンチマーク値を、そのままGGUF版の実測値として扱うことはできません。GGUF配布先
ハードウェアの容量の読み方は、RTX Sparkと128GBメモリの記事でも整理しています。Doryの公式速度比較に登場するDGX Sparkと、同記事のRTX Spark搭載ノートPCは別の製品です。名前が似ていても測定結果を移し替えないでください。
今すぐ誰でも導入できる段階か：MacとLinuxの条件
10月17日のGitHub確認では、llama.cppの対応PR #30306とvLLMの対応PR #60149はどちらもOpenで、未マージでした。通常の最新版を入れるだけで動くとは案内できません。モデルのGAという表記と、使いたい実行エンジンのリリース対応は別です。
| 環境 | 公式資料にある経路 | 必要になる確認 |
|---|---|---|
| Apple SiliconのMac | Dory対応ソースからllama.cppをビルドし、GGUFを使う | ARM64ネイティブ、開発ツール、Metal、指定ソースの版 |
| Linux・NVIDIA GPU | Dory対応PRからvLLMを導入する例 | GPUとCUDA等の依存関係、対応PRの状態 |
| Intel Mac・一般的なGUIアプリ等 | 本記事では動作確認していない | GGUFを選べることだけでは、Dory対応の証拠にならない |
Mac向けQuick Startは、動くPRの先端ではなく、コミット98a74c97ea09ac72f6ceda1559808fc0a2f447ceを指定しています。CMake、OpenSSL、AppleのCommand Line Toolsが前提です。掲載コマンドには特定のSDKパスも含まれるため、自分のインストール先と一致するかを先に確かめます。Apple Silicon向け公式手順
- 1まず対応言語と用途を確認する。日本語が必須なら、Doryだけに置き換える計画を立てず、既存の手段を残して評価する。
- 2公式モデルカードから使用エンジンの手順を選び、対応PRと指定コミットを確認する。既存の実行環境と別の作業ディレクトリを使う。
- 3MacではGGUFを取得し、公式記載のファイルサイズとSHA-256を照合する。BF16のファイルをそのままllama.cppへ渡さない。
- 4まず公式Mac例の小さな文脈上限4,096・同時処理1・2ループ・per_loopを基準にする。最大256K対応という仕様を、最初から確保する理由にしない。
- 5サーバーが起動したら、同じMacの127.0.0.1:8080で短い課題を試す。外部公開せず、版・量子化・設定・結果を保存してから条件を1つずつ変える。
公式Mac例ではdory.num_loopsが回数、dory.recurrent_kv_cache_modeがキャッシュ方式です。vLLMの例ではn_recurrent_loopsとrecurrent_kv_cache_modeを使います。名前を混ぜず、再起動後のログも確認します。本記事のMacにはDory対応ランタイムが用意されておらず、CMakeも確認できなかったため、今回は実行を行っていません。両エンジンの設定例
利用条件はOpenMDW 1.1です。モデルカードは商用・非商用での利用が可能と説明し、ライセンス本文へ案内しています。セルフホストでは端末・電力・構築保守の負担があり、外部のGPUを借りればその費用も別に発生します。配布モデルの存在を、無料のホスト型APIが提供されている意味と解釈しないようにします。配布元の利用条件
日本語で試すなら、まず英語と同じ課題を並べる
日本語が返っただけでは、対応言語に日本語を追加してよいことにはなりません。まず同じ意味の英語と日本語を並べ、言語の違いによる失敗と、ループ数による変化を分けて観察します。次はふくふくが作成した架空の検収教材です。Doryの出力例ではありません。
次のメモから担当者・作業・期限を取り出してください。名前はAとBをそのまま使い、期限が未定ならnullにします。本文にない期限や担当者を補ってはいけません。
Aは見積書を確認します。期限は2026年10月20日です。Bは請求先を確認します。期限は未定です。合格条件は、AとBの2人を残すこと、作業がそれぞれ見積書確認・請求先確認に対応すること、Aの期限が2026年10月20日でBの期限がnullになることです。言い換えは意味で判定します。JSONの形だけ合っていても、人や未定の扱いが誤っていれば不合格です。
ダウンロードできる日英の試験セットJSONには同内容の英語版と、「資料にない締切を質問する」課題も入れました。正解の条件を先に固定し、実際の出力と照合します。教材ファイルの構造と期待値は確認済みですが、モデルが正しく答えたことを示すものではありません。
- 1同じ機械・モデルファイル・文脈長・生成上限・サンプリング設定で、英語と日本語をそれぞれ実行する。公式推奨のTemperature 1.0・Top_P 0.95等から変更したら記録する。
- 2最初はper_loopを固定して1・2・4ループを比較する。各課題は複数回試し、都合のよい1回だけを採らない。
- 3欠落と追加情報、開始から回答完了までの秒数、利用者が修正する秒数を残す。出力上限で打ち切られた実行は成功として数えない。
- 4次にループ回数を固定してlast_loopへ変更する。メモリ・時間・正答の変化を同じ条件で測り、キャッシュ方式の効果を切り分ける。
記録には空の比較表CSVを使えます。初回のモデル読み込みとウォームアップは本番の測定と分け、未測定は空欄にしてください。入力・生成トークン、設定、結果、修正時間を残すことで、「短い回答だから得」といった早合点を防げます。
導入する価値は「小さいのに賢い」だけでは決まらない
Doryは、モデルの大きさだけでなく推論時の計算にも調整の余地があると示す、興味深い選択肢です。英語の短い業務処理や開発支援で、モデルを固定したまま精度と待ち時間を比較したい人に、試す目的を持ちやすい設計といえます。
一方、日本語の会議メモや問い合わせ対応をすぐ任せたい人には、現時点では言語品質と実行環境の確認が先です。小型モデルが応答しても情報が抜ける例は、Bonsai 2の日本語検証でも経験しました。Doryでも、動いたことと仕事を任せられることを分けて評価します。