Laguna XS 2.1の24問実測——コード60/60と日本語40/60が示す使い分けの線

関連記事としては Bloggemma4 12BはどのGPUで動く？実測3点＋主要18枚の速度早見表【VRAM 8GBは崖の縁】gemma4 12Bを手持ちGPUで動かす判断材料を、VRAM別・実測3点・主要18枚の速度早見表で整理。8GBの限界も明確にします。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

MoE（Mixture of Experts）の33Bパラメータモデルが、12GB VRAMのGPUに載るという話を聞いた時、まず「本当か？」と思いました。33Bモデルを量子化しても20GB前後は必要になるのが普通で、12GBは物理的に足りない気がしたんです。手元に12GBクラスのGPUを持つ開発者なら、この手の話は「また夢物語か」と流しがちです。クラウド代を節約したい気持ちはあっても、実際に手元で使える精度と速さが出るかは、いつも半信半疑でした。

結論から書くと、Laguna XS 2.1は実際に動きました。ただし、公式ドキュメントにさえ明記されていない、ある重要なフラグが必要でした。そして動かしてみた結果、コーディングでは期待以上の60点満点を取る一方、日本語の常識問題では40点という、はっきりとした長所と短所が出ました。この一見矛盾する結果が、このモデルの使いどころを教えてくれます。

Laguna XS 2.1は総パラメータ33Bですが、推論時に動く「アクティブ」部分は3BというMoEアーキテクチャを採用しています。Q4_K_M量子化したファイルサイズは20.3GB。これをそのまま12GB VRAMに載せようとすると、当然Out Of Memory (OOM) エラーで弾かれます。ここで諦めてしまうのが普通です。

しかし、llama.cppの最新masterブランチには、--cpu-moe という実験的なフラグが追加されていました。このフラグを指定すると、MoEの「専門家」部分の重み全てをCPUのRAMに置き、GPU（VRAM）にはアクティブな部分だけをロードします。結果、VRAM使用量は3.4GBまで下がり、8.6GBの空きが生まれました。このフラグがなければ、今回の検証は始まらなかったでしょう。検証時、手元のllama.cppビルドはこの機能が入るコミットより1970コミットも古かったため、最初はOOMに悩まされました。最新化が必須条件でした。

モデルファイルは、空き38GBしかないルートパーティションを避け、/mnt/data/linux_data/ 配下に配置しています。上位版のLaguna S 2.1 (118B/8B) は、この環境（VRAM 12GB + RAM 32GB）では到底収まらず、試すことさえ断念しました。XSとSでは、アクティブパラメータが3Bと8Bで約2.7倍の差があります。速度とメモリ消費のトレードオフを考えると、12GB環境ではXSが現実的な選択肢です。

--cpu-moe フラグを付けて起動した状態での性能を測りました。生成速度は49.4 tok/s、プロンプト処理速度は65.3 tok/sでした。これは、アクティブパラメータが3Bという設計を反映しており、純粋な9Bモデルと同程度の速度です。例えば、同じ環境で動かしたNemotron-9Bモデルの実測値が63 tok/sでしたから、ほぼ同じ水準にあると言えます。つまり、33Bの名前とは裏腹に、実質的には9Bクラスの軽快さで動く、というのが実際の使用感です。VRAMを3.4GBしか消費しないのは、メモリ制約の強い環境では大きなメリットで、他のアプリケーションと並行して動かす余裕が生まれます。

過去の記事と比較可能な、同じ24問のベンチマークテストを実施しました。結果は総合で199点/240点（82.9%）、ランクAでした。これは、日本語特化モデルとして知られるNemotron-Nano-9B-v2-Japaneseの198点とほぼ同じ総合点です。しかし、内訳を見ると話は全く別です。

• Aカテゴリ（意地悪問題）: 47点 / 60点
• Bカテゴリ（論理問題）: 52点 / 60点
• Cカテゴリ（コード問題）: 60点 / 60点（満点）
• Dカテゴリ（日本語問題）: 40点 / 60点

Cカテゴリのコード問題で満点を取ったことは、Poolsideがコーディング特化として設計されていることを如実に示しています。一方、Dカテゴリの日本語問題での40点は、実用レベルでは明らかに不足しています。具体的な誤答例を見ると、その傾向がよく分かります。

俳句「古池や蛙飛びこむ水の音」の季語を「夏」と答えました（正解は「蛙」で春の季語）。「的を得た」という表現について、「的を射る」が正しいと指摘する設問に対し、「的を得た」も広く使われているとして「正しい」と判定しました。ことわざ「情けは人のためならず」の解釈を問う問題では、罠にはまる形で「他人に情けをかけることは、結局その人のためにならない」という誤った解釈を正当化してしまいました。さらにAカテゴリでは、「法的に生きている人が、自分のお墓に自分で入ることは許可されていますか」という問題で0点を喫しました。この設問は「入る＝埋葬される」と思い込ませる罠で、生前墓（寿陵）を購入して参拝する行為は日本でも一般的な合法行為です。ところがLaguna XS 2.1は、実在しない法律名を挙げて根拠のある回答のように組み立ててきました。誤るだけでなく、それらしい出典を作って正当化してくる点が厄介です。

これは、コーディング特化モデルに日本語の自由文生成を任せる危険性を裏付ける結果です。以前、Laguna S 2.1がRyzenプロセッサを「Intel互換」と誤って生成した実例がありましたが、同じ系列のXS版でも、日本語での事実誤認や常識からの逸脱が起こりうることが確認されました。

Laguna XS 2.1は「Reasoningモデル」として設計されており、推論過程を reasoning_content というフィールドに書き出します。これは思考の透明性を高める良い機能なのですが、初期のテストで少しハマりました。max_tokens（生成トークン数の上限）を小さく設定した場合、この reasoning_content が予算の大半を消費してしまい、肝心の最終回答（content）が空になってしまうのです。24問中、5問がこの現象で正しく評価できませんでした。

解決策は単純で、max_tokens を4096から8192に増やすことでした。reasoning_content を含めた全体の出力が長くなることを見越して、十分な予算を確保しておく必要があります。これは運用上の小さな引っかかりですが、知らないと「モデルが答えを返さない」と誤解するポイントです。

ここまでの実測結果を踏まえると、Laguna XS 2.1の使いどころは非常に明確になります。

迷うとしたら、「これ一台で何でもこなそうとするかどうか」という一点です。コード生成、特に実装やリファクタリング、デバッグ補助に関しては、12GB VRAM環境で動くモデルとしては傑出した性能を発揮します。60点満点は伊達ではありません。一方で、日本語での説明文書作成、顧客へのメール応答、事実確認を伴う調査報告などは、40点というスコアが示す通り、誤認や不自然な表現のリスクが高すぎます。

したがって、実際の開発ワークフローでは、Laguna XS 2.1を純粋な「コーディングエンジニア」として位置づけ、その作業に特化させるのが得策です。日本語を必要とするコミュニケーションやドキュメンテーションは、別途、日本語能力の高い小型モデルや、クラウドの高性能モデルに任せるという棲み分けが現実的です。VRAM使用量が3.4GBと軽いので、このようなマルチモデル環境を組むことも技術的に可能です。

Laguna XS 2.1は、33Bというパラメータ規模でありながら、--cpu-moeフラグという現実的な工夫により、12GB VRAM環境への載せ込みに成功しました。速度も実用域の49トークン/秒を確保しています。その代償として、MoEの重みをCPU RAMに置くため、システム全体のRAM容量に余裕が必要になる点には注意が必要です。

最大の特徴は、その能力の極端な偏りにあります。コーディングタスクに対してはほぼ完璧な性能を示す一方、日本語の常識問題では深刻な弱点を露呈します。これは欠点というより、このモデルの本質的な「個性」です。それを理解した上で、コード生成という特定の仕事に特化させて使えば、非常に強力なツールになります。クラウドのコーディング特化AIの利用頻度を減らし、ローカルで高速に反応するアシスタントとして、十二分に役割を果たせるでしょう。

ただし、何でも任せられる万能アシスタントを求めているのであれば、このモデルは不向きです。その期待は裏切られます。用途をコード生成に限定できるなら、12GB VRAM環境において、現時点で最も実用的な選択肢の一つと言えると思います。

VRAM 3.4GBという数字だけを見て「軽いモデル」と受け取ると危険です。--cpu-moe はVRAMの負担をCPU RAMへ移し替えているだけで、20.3GBの重みはどこかに載ります。RAM 32GBの環境でようやく現実的というのが実感で、16GB機では別の壁に当たるはずです。

--cpu-moe 自体もllama.cppの新しいフラグで、対応コミットは検証の前日にマージされたばかりでした。今後オプション名や挙動が変わる可能性は十分にあります。速度もGPU・量子化・同時実行数で変わるため、49 tok/sはあくまで12GB級1枚での一例です。

24問という規模は傾向を掴むには足りても、日本語40点という数字の精度を保証するほどの母数ではありません。この記事で断言できるのは「コードと日本語の落差がはっきり出た」ところまでで、40点という値そのものは幅を持って読んでください。

検証日は2026年7月23日、モデル公開の2日後です。環境はVRAM 12GBのGPUとRAM 32GBを積んだ自宅サーバーで、poolside/Laguna-XS-2.1-GGUF のQ4_K_M（20.3GB）を /mnt/data/linux_data/ 配下に置いて動かしました。推論エンジンはllama.cppのmasterビルドで、Laguna対応コミット 1f66c3ce（2026年7月22日マージ）を含んでいることが前提です。起動オプションは -ngl 99 --cpu-moe -c 32768 を使い、--cpu-moe でMoEの重みをCPU RAMへ退避させています。

採点は過去のベンチ記事と同じ24問セットで、意地悪・論理・コード・日本語の4カテゴリ各6問、1問10点の240点満点です。速度はcold起動分を捨てたうえで計測し、生成49.4 tok/s・プロンプト処理65.3 tok/sを得ました。max_tokens は当初4096で走らせましたが、24問中5問で推論過程が予算を食い切って最終回答が空になったため、8192へ引き上げて再実行しています。

RAMは何GB必要ですか？

検証環境はRAM 32GBです。--cpu-moe はMoEの重み20.3GBをCPU側に置くため、OSと他のプロセスの分を足すと32GBでほぼ埋まる感覚でした。16GB機では厳しく、載せるなら --n-cpu-moe N で一部の専門家をGPUへ戻す調整が要ります（今回は未検証）。

VRAM 8GBのGPUでも動きますか？

今回の構成ではVRAM使用量が3.4GBだったので、数字の上では8GBでも収まります。ただし試していないので断言はできません。むしろ効いてくるのはVRAMよりRAMのほうです。

上位版のLaguna S 2.1は使えますか？

118B総パラメータ・8Bアクティブという構成で、VRAM 12GB＋RAM 32GBの環境では収まらず断念しました。アクティブパラメータがXSの約2.7倍あるため、速度もそれなりに落ちるはずです。

コード補助以外に使い道はありますか？

論理問題は52/60で悪くないので、仕様の整理や設計の壁打ちには使えます。避けるべきは日本語の文書作成と事実確認を伴う調査で、実在しない法律名を作ってきた挙動を見る限り、出典が要る仕事は任せないほうが安全です。

• META-MARK: GPU ランキング
• META-MARK: AIモデル別 GPU 選定ガイド

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！

• Bloggemma4 12BはどのGPUで動く？実測3点＋主要18枚の速度早見表【VRAM 8GBは崖の縁】gemma4 12Bを手持ちGPUで動かす判断材料を、VRAM別・実測3点・主要18枚の速度早見表で整理。8GBの限界も明確にします。→
• BlogOllamaでローカルにチャットを住まわせた記録 — インストールからモデル選びまでOllamaを使ってローカルLLMを動かした実録。インストール手順・VRAM別モデル選び・実際に使って感じた正直な評価まで。RTX 4070 Ti（12GB）環境での体験ベース。→

• 実際の構成を探すなら、GPU 比較ページやローカルLLM向け構成記事もあわせて見ると判断しやすいです。
• ハードウェア候補は用途別の AI 構成ガイドからたどると、単体製品より違和感なく検討できます。