16GBのRAM・VRAMで動くローカルLLM｜おすすめモデルと選び方

16GBのRAMまたはVRAMを搭載している場合に、ローカルで実行できるおすすめのAIモデルをまとめました。

12GBのグラフィックスカードについては、12GB VRAM向けのおすすめローカルLLMをご覧ください。具体的なGGUFファイル、メモリ使用量、ビジュアルコーディングのテストを紹介しています。

選定基準

目安として、16GBのVRAMがあれば20B〜35Bのモデルを、合計16GBのRAMまたは統合メモリがあれば8B〜12Bのモデルを実行できます。この基準に基づいて、次のモデルを選びました。

16GB VRAM向けのおすすめローカルLLM

Qwen 3.8 27B

Qwen 3.8 27Bは、Qwenチームが開発した27Bパラメータのデンス型マルチモーダルモデルです。言語モデルは64層で構成され、ネイティブのコンテキスト長は262,144トークン、任意で1Mトークンまで拡張でき、テキスト、画像、動画に対応しています。思考はデフォルトで有効になっており、推論時に無効にできます。

16GB GPUには、AtomicChat/Qwen3.8-27B-GGUFで提供している当社の13.8GBのAD-IQ3_Sビルドをおすすめします。

Qwen 3.8のKVキャッシュは比較的大きめです。llama.cppでは1トークンあたり約256KBを使用し、コンテキスト長が8Kの場合は約2GB、32Kの場合は約8GBになります。そのため、AD-IQ3_Sを使うと、16GB GPUでは全体をGPUにオフロードした状態で約8Kのコンテキスト長を確保できます。

AD-IQ3_SにはAtomic Dynamicレイアウトを使用しています。これは、測定した感度に応じてテンソルごとに異なる精度で量子化する、当社独自のレイアウトです。

このレイアウトを構築するため、まず3,004文書に含まれる4,967,044トークンから重要度行列を生成しました。キャリブレーション用データセットには、コード、推論、ツール利用、多言語テキスト、長いコンテキストのサンプル、構造化データ、グラフィックス、語彙を網羅するデータが含まれています。

次に、モデルのどの部分が精度の低下に最も敏感かをテストしました。最初と最後の層、および複数のアテンション関連テンソルは、高い精度を維持しました。52〜62層で最も大きな活性化のピークが見られました。アテンションゲートと状態出力のテンソルの精度を上げると、サイズは約0.16GB増えましたが、当社のテストでは残存するダイバージェンスが11%減少しました。

完成した量子化モデルは、キャリブレーションに使用していないホールドアウトデータを使い、元のBF16モデルと比較して評価しました。Top-1一致率とトークンごとのKLダイバージェンスの両方を報告しています。

リリースに合わせて、キャリブレーションデータ、量子化ルール、評価手順、生の測定値を公開しています。評価にはコンテキスト長4Kのホールドアウトチャンク87個を使用し、すべての量子化モデルをBF16と直接比較しています。参考として、Q8_0のTop-1一致率は98.92%、KLダイバージェンスは0.00064であり、損失のない基準として扱うのではなく、Q8_0も測定対象にしています。

Qwen 3.8 27Bのベンチマーク

Qwen 3.8 27Bの長所

• 汎用的な推論、コーディング、リサーチ、エージェント機能に優れる
• 画像と動画の理解にネイティブ対応
• 思考の有効化、無効化、推論強度による調整が可能
• Atomic Dynamic量子化には忠実度の実測データがある
• AD-IQ3_Sなら16GB VRAMに全体が収まる

Qwen 3.8 27Bの短所

• 推奨する3ビットビルドは、約7.6%の割合で元モデルとは異なる最上位トークンを選ぶ
• 16GBカードでの実用的なコンテキスト長は約8K
• デンスモデルのため、CPUオフロードの負担が大きい

Qwen 3.8 27Bを選ぶ場面：16GB GPUを搭載し、汎用作業向けに、このガイドで最も総合力の高いモデルを求める場合に選んでください。AD-IQ3_Sとコンテキスト長8Kから始めてください。それでも実行環境でVRAMが不足する場合は、13.0GBのAD-IQ3_S-IQ3_XXSビルドを使用してください。

Ornith 1.5 35B-A3B

Ornith 1.5 35B-A3Bは、コーディングとエージェント型ワークフロー向けに開発された35BのMixture-of-Experts推論モデルです。トークンごとに約3Bのパラメータを有効化し、ネイティブで262Kのコンテキストウィンドウに対応しています。

Atomic ChatのGGUFビルドには、16GBの境界に近いファイルが2つあります。AD-IQ3_XXS-IQ2_Sは13.7GBで、限られてはいるものの、コンテキスト用に使用できる余裕が残ります。AD-IQ3_S-IQ3_XXSは15.5GBで、公称容量には収まる可能性がありますが、KVキャッシュとバッファを確保すると余裕が足りません。

低ビットのファイルでは用途に対する品質低下が大きすぎる場合、OrnithのMoEアーキテクチャなら別の選択肢があります。エキスパートをシステムRAMに置いて、22.1GBのAD-Q5_K-Q4_Kビルドを実行する方法です。llama.cppでは、--cpu-moeによってルーティング対象のエキスパートをCPUに配置し、アテンション、ルーティング、共有層はGPUに残します。全体をGPUに常駐させる場合より遅くなりますが、通常のデンス層をオフロードするより実用的です。

Ornith 1.5 35B-A3Bのベンチマーク

Ornith 1.5 35B-A3Bの長所

• コーディング、ターミナル操作、エージェント型タスクに特化して開発
• トークンごとに有効になるパラメータは約3Bのみ
• 思考モードをオフにできる
• MoEエキスパートのオフロードにより、極端な量子化より高品質な選択肢が得られる
• MITライセンス

Ornith 1.5 35B-A3Bの短所

• 16GB GPUに全体を常駐させて使うには低ビット量子化が必要
• 15.5GBのビルドでは、通常のコンテキスト利用に必要な余裕が不足
• エキスパートのオフロードにはファイル全体を収められるシステムRAMが必要で、速度も低下する
• モデルの推論出力によって遅延とトークン使用量が増える

Ornith 1.5 35B-A3Bを選ぶ場面：エージェント型コーディングが主な用途の場合に選んでください。16GB GPUに全体を常駐させるにはAD-IQ3_XXS-IQ2_Sを使用してください。GPUに加えて24GB以上のシステムRAMがある場合は、より高品質なAD-Q5_K-Q4_Kビルドをエキスパートのオフロードと組み合わせて使用できます。

gpt-oss-20b

gpt-oss-20bは、OpenAIの小型オープンウェイト推論モデルです。合計20.9Bのパラメータを持ちますが、トークンごとに有効になるのは3.6Bパラメータのみです。これにより、大型モデルの容量を維持しながら、20Bのデンスモデルより大幅に低いコストで実行できます。

このモデルは32個のエキスパートを持つMixture-of-Experts（MoE）アーキテクチャを採用し、トークンごとに4個を選択します。24層で構成され、密なアテンションと、局所的な帯状範囲に限定したスパースアテンションを交互に使用します。KVキャッシュのコストを抑えるためにGrouped Multi-Query Attentionを採用しており、ネイティブのコンテキストウィンドウは128Kトークンです。

MoEの重みはMXFP4形式で直接公開されています。重みの占有容量は約12.8GiBで、モデルを16GBのメモリ内に収められます。

gpt-oss-20bは推論モデルで、低・中・高の推論強度に対応しています。

エージェント型の処理向けにも学習されています。推論環境から提供される場合、関数呼び出し、構造化出力、Webブラウジング、Pythonツールに対応します。

OpenAIは、STEM、コーディング、一般知識に重点を置き、主に英語のテキストでこのモデルを学習させました。テキスト専用で、画像や音声の入力には対応していません。

gpt-oss-20bのベンチマーク

gpt-oss-20bの長所

• 公式に16GBデバイス向けとして設計
• 推論、コーディング、関数呼び出し、構造化出力に優れる
• 推論強度を設定できる
• ネイティブのMXFP4重みにより、非公式の極端な量子化に頼らずに済む
• llama.cpp、Ollama、LM Studio、Metalなど、幅広い実行環境に対応

gpt-oss-20bの短所

• テキスト専用
• 16GB RAMシステムではメモリの余裕がごくわずか
• 正しく動作させるにはHarmonyプロンプト形式が必要
• 長い推論過程の出力によって遅延が増える
• 最低要件の16GBでは、128Kのコンテキスト全体を使うのは実用的ではない

gpt-oss-20bを選ぶ場面：ローカルでの推論、コーディング、関数呼び出し、構造化出力のワークフローに選んでください。コミュニティによる3ビット変換版ではなく、公式の省メモリチェックポイントを求める場合に、特に扱いやすい選択肢です。

Gemma 4 26B-A4B

Gemma 4 26B-A4Bは、Google DeepMindの25.2BパラメータのMixture-of-Expertsモデルです。トークンごとに有効になるパラメータは3.8Bのみです。ルーティング対象のエキスパートを128個持ち、トークンごとに8個を選択します。これにより、順伝播のたびに25Bの全パラメータを有効化する計算コストをかけずに、はるかに大型のモデルに相当する容量を実現します。

このモデルは30層で構成され、1024トークンのスライディングウィンドウアテンションとグローバルアテンションを混在させたハイブリッドなアテンション構成を使用します。ネイティブで256Kトークンのコンテキスト長に対応します。ベースモデルはマルチモーダルで、テキストと画像を受け付けます。

16GB GPUには、当社の13.9GBのIQ4_XSビルドをおすすめします。

これらのGGUFは、当社がGoogleの元の重みから直接量子化したものです。まずモデルをF16 GGUFに変換し、次に当社のキャリブレーション用コーパスで重要度行列を構築して、量子化の全ラインアップを生成する際に使用しました。この行列は、リポジトリ内でimatrix-coding.ggufとして公開しています。

重要度行列は、キャリブレーション中にモデルの活性化に最も大きな影響を与える重みを記録します。llama.cppは低ビットのIQ量子化やK量子化を生成する際にこの情報を利用し、モデルの最も重要な部分に、利用可能な精度をより多く割り当てることができます。

生成したラインアップは、10.6GBのQ2_Kから26.9GBのQ8_0までにわたります。16GBの上限付近で有用な選択肢は、12.4GBのIQ3_M、13.8GBのQ3_K_L、13.9GBのIQ4_XSです。16GBハードウェアでの実行にはIQ4_XSをおすすめします。このビルドはQ3_K_Lとほぼ同じファイルサイズでありながら、品質低下が4ビットビルドと同程度にごく小さいためです。

元のGemma 4モデルは画像入力に対応していますが、このAtomic Chatリポジトリに現在含まれているのはテキスト専用のGGUFで、ビジョンプロジェクターは含まれていません。画像入力が必要な場合は、元のモデルまたは別のマルチモーダルビルドを使用してください。また、これらのファイルをllama.cppで実行する際は、Gemma 4のチャットテンプレートを有効にする必要があります。

Gemma 4 26B-A4Bのベンチマーク

Gemma 4 26B-A4Bの長所

• MoEの計算コストは、総パラメータ数から想定されるより低い
• 重要度行列を使った量子化モデルを元の重みから直接作成
• IQ4_XSでは実行環境とコンテキスト用に約2GBが残る
• アーキテクチャ上のコンテキストウィンドウは256K
• Apache 2.0ライセンス

Gemma 4 26B-A4Bの短所

• Q4_K_Mは16GB VRAMに収まらない
• 推奨ビルドはビット数を抑えたIQ4量子化
• Atomic Chatの現在のGGUFはテキスト専用
• 16GBで256Kのコンテキスト全体を使うのは現実的ではない

Gemma 4 26B-A4Bを選ぶ場面：新しい汎用MoEモデルを求める場合に選んでください。

16GB RAM・統合メモリ向けのおすすめローカルLLM

16GBのRAMまたは統合メモリを搭載したコンピューターは、16GBのグラフィックスカードよりモデルに割り当てられる容量が少ないため、ファイルサイズが7〜9GBのモデルを選びました。

Qwen 3.5 9B

Qwen 3.5 9Bは、Qwenチームの9.7Bパラメータのデンスモデルです。32層で構成され、Gated DeltaNetとフルアテンションを中心としたハイブリッドアーキテクチャを使用します。4層ごとのグループは、3層のDeltaNetと、それに続く1層のアテンションで構成されます。ネイティブのコンテキスト長は262,144トークンです。

16GBの統合メモリを搭載したシステムには、当社の7.4GBのQ6_Kビルドをおすすめします。これらのGGUFは、当社のキャリブレーション用コーパスから構築した重要度行列を使用し、元のQwenの重みから当社が量子化しました。この行列は量子化中に使用され、モデルの活性化に大きく影響する重みの精度をより高く保ちます。

6.4GBのUD-Q4_K_XLビルドも提供しています。トークン埋め込みと出力テンソルはQ8_0に保ち、モデルの残りの部分はより強く量子化しています。サイズはQ5_K_Mに近く、Q6_Kに必要な7.4GBを確保できないほどメモリに余裕がない場合に役立ちます。

注意：このAtomic Chatリポジトリにはテキスト専用モデルが含まれており、ビジョンプロジェクターは同梱されていないため、これらのGGUFはテキスト専用ビルドです。

Qwen 3.5 9Bのベンチマーク

Qwen 3.5 9Bの長所

• サイズに対して汎用的な推論とコーディングに優れる
• Q6_Kではシステムメモリに実用的な余裕が残る
• 思考モードと非思考モードに対応
• ハイブリッドアテンションにより、従来のフルアテンションモデルよりKVキャッシュの増加を抑えられる
• 幅広い言語に対応

Qwen 3.5 9Bの短所

• Atomic Chatの現在のGGUFは画像に対応していない
• Q8_0では、負荷の高い16GBコンピューターでスワップが発生する可能性がある
• アーキテクチャ上の262Kのコンテキスト長は、16GBシステムで利用できる範囲を大幅に超える
• 専用の16GB GPUに収まる20B〜35Bモデルより能力の上限が低い

Qwen 3.5 9Bを選ぶ場面：合計16GBのRAMまたは統合メモリを搭載し、文章作成、分析、コーディング、多言語チャットを1つのモデルでこなしたい場合は、これを第一候補にしてください。Q6_Kを使用し、長いプロンプトでシステムにスワップが発生する場合はQ5_K_Mに下げてください。

Ornith 1.5 9B

Ornith 1.5 9Bは、Ornith 1.5ファミリーで最も小型のモデルです。8.95Bの言語モデルと0.46Bのビジョンエンコーダーを搭載し、ネイティブのコンテキストウィンドウは262,144トークンです。Ornithは、コーディング、ターミナルでの作業、ツール利用など、推論とエージェント型の処理を対象としています。

32層に2種類のアテンション機構を混在させており、24層が線形アテンション、8層がフルアテンションを使用します。KVキャッシュを保持するのはフルアテンション層のみで、それ以外の層は固定サイズの再帰状態を使用します。そのため、このサイズのモデルとしては長いコンテキストを比較的低コストで扱えます。llama.cppでは、キャッシュは1トークンあたり約32KBを使用し、コンテキスト長64Kで約2GBになります。

16GBの統合メモリを搭載したシステムには、当社の8.55GBのAD-Q8_0-Q6_Kビルドをおすすめします。元のBF16モデルとのTop-1一致率は97.46%に達し、9.53GBのQ8_0ビルドと比べて約1GBを節約できます。コンテキスト、実行環境、ほかのアプリケーションが同じ16GBのメモリプールを共有するマシンでは、この余裕をそれらに使うほうが有益です。

AD-Q8_0-Q6_Kは、Ornithに対する当社のAtomic Dynamic量子化の取り組みから生まれました。同じサイズ帯で8種類のテンソルレイアウトをテストし、それぞれをBF16の基準モデルと比較して測定しました。実験では、アテンションゲートと状態出力のテンソルが、その割合に比して大きな影響を持つことが分かりました。両者を合わせても重みの約9%ですが、これらの精度を上げることで、テストしたレイアウトの中で最大の改善が得られました。

9,686チャンクにわたる496万のキャリブレーション用トークンを使用し、BF16の重みから重要度行列を生成しました。コーパスには、エージェントによるツール利用のトレース、コード、推論、多言語テキスト、長いコンテキスト、構造化データ、グラフィックス、トークナイザー固有の語彙を網羅するデータが含まれています。Ornithの語彙の99.5%をカバーしています。

その結果、当社の5.93GBのAD-Q5_K-Q4_Kは、標準の6.47GBのQ5_K_Mより小さく、かつ高精度です。標準のQ4_K_Mとほぼ同じサイズで、AD-Q4_K-IQ4_XSはKLダイバージェンスを約31%削減します。精度が高くなるほど改善幅は小さくなるため、すべてのサイズ帯にADレイアウトを強制するのではなく、ラインアップには標準のQ6_KとQ8_0も含めています。

リポジトリには0.92GBのビジョンプロジェクターも含まれており、GGUFでもモデルの画像対応を維持できます。テキスト専用で使用する場合は、プロジェクターを省いてメモリを節約できます。

Ornith 1.5 9Bのベンチマーク

Ornith 1.5 9Bの長所

• 9Bモデルとしてはエージェント型コーディングの性能が高い
• 2026年8月にリリースされた新しいモデル
• Atomic Dynamicビルドは共有メモリに収まりながら、元モデルに近い品質を実現
• ハイブリッドアテンションにより、KVキャッシュの増加を比較的低く抑えられる
• 画像入力に対応し、MITライセンスを採用

Ornith 1.5 9Bの短所

• 汎用アシスタントというより、コーディングとエージェント型の作業に特化
• 思考がデフォルトで有効になっており、応答の遅延が増える
• 画像処理には別途プロジェクターファイルが必要
• モデルとチャットテンプレートを正しくサポートするには新しい実行環境が必要

Ornith 1.5 9Bを選ぶ場面：16GBのコーディング用ノートPCやMacに選んでください。ほかの処理によるマシンの負荷が軽い場合はAD-Q8_0-Q6_Kを、IDEやブラウザー用により多くのメモリが必要な場合はAD-Q5_K-Q4_Kを使用してください。

Gemma 4 12B

Gemma 4 12Bは、Googleの11.95Bパラメータのデンスモデルで、48層を持ち、1024トークンのスライディングウィンドウアテンションとグローバルアテンションを混在させています。最大256Kのコンテキスト長に対応し、ベースモデルはテキスト、画像、音声を受け付けます。

当社の7.4GBのQ4_K_Mビルドなら、より低ビットの量子化に下げることなく、共有メモリプールにOS、KVキャッシュ、実行環境のための十分な余裕を残せます。システムのメモリにより余裕がある場合は、8.5GBのQ5_K_Mも適した選択肢です。

Gemma 4 12Bのベンチマーク

Gemma 4 12Bの長所

• 共有メモリ向けのほかの推奨モデルより大型のデンスモデル
• テキスト、画像、音声に対応
• Atomic Chatが必要なビジョンプロジェクターを同梱
• 元の重みから重要度行列を使って作成した量子化モデル
• Q4_K_Mではシステムメモリに実用的な余裕が残る

Gemma 4 12Bの短所

• マルチモーダル入力には追加のメモリが必要
• 9.8GBのQ6_Kでは、OSとコンテキストを含めると余裕がなくなる可能性がある
• 正しいJinjaチャットテンプレートが必要
• 合計16GBのメモリでは、256Kのコンテキスト全体を使うのは実用的ではない

Gemma 4 12Bを選ぶ場面：スクリーンショット、画像、文書、音声がワークフローの中心となる場合に選んでください。Q4_K_Mと控えめなコンテキスト長から始め、実行中のメモリ使用量を確認してからQ5_K_Mに移行してください。

LFM2.5 8B-A1B

LFM2.5 8B-A1Bは、デバイス上で動作するアシスタント向けに開発された、Liquid AIの8.3BパラメータのMoEモデルです。トークンごとに約1.5Bのパラメータを有効化し、18層の二重ゲート畳み込みと6層のGQAを組み合わせています。Liquid AIはLFM2.5を38兆トークンで学習させ、コンテキストウィンドウをLFM2の32Kから128Kに拡張しました。

このモデルはルーティング対象のエキスパートを32個持ち、トークンごとに4個が有効になります。有効なパラメータ数が少ないため推論時の計算量を比較的小さく抑えられ、畳み込みとアテンションのハイブリッドアーキテクチャにより、高速なローカル生成を目指しています。Liquid AIはこのリリースで、指示追従、推論、複数ステップのツール利用に重点を置いて調整しました。

LFM2.5では語彙も65Kから128Kトークンに拡張され、ラテン文字を使わない複数の言語でトークン化が改善しています。Liquid AIは、ヒンディー語、タイ語、ベトナム語、インドネシア語、アラビア語などで、トークン数が特に大きく削減されたと報告しています。

このモデルはテキスト専用で、ChatMLに似たテンプレートを通じて関数呼び出しに対応します。そのため、長い自由形式の応答にすべての時間を費やすのではなく、生成とツール実行を交互に行うローカルアシスタントに特に適しています。

LFM2.5 8B-A1Bのベンチマーク

LFM2.5 8B-A1Bの長所

• 有効なパラメータ数が少なく、高速に生成できる
• デバイス上で動作するアシスタントと、連続するツール呼び出し向けに設計
• Q6_Kではメモリに大きな余裕が残る
• llama.cpp、MLX、vLLM、SGLangに対応
• アーキテクチャ上のコンテキストウィンドウは128K

LFM2.5 8B-A1Bの短所

• テキスト専用
• 難しいタスクでの能力の上限はQwen 3.8 27BやOrnith 1.5 35Bより低い
• Q8_0では、16GBシステムで長いプロンプトを扱うための余裕が少なくなる
• ライセンスはApache 2.0やMITより制約が多い

LFM2.5 8B-A1Bを選ぶ場面：応答の速いローカルアシスタント、ツール呼び出し、CPUを多用する使い方に選んでください。16GBコンピューターで最適なバランスを得るには、Q6_Kを使用してください。

よくある質問

2026年に16GB VRAMで使うなら、どのローカルLLMが最適ですか？

Atomic Chatの13.8GBのAD-IQ3_S量子化を使用したQwen 3.8 27Bが、最もバランスの取れた選択肢です。16GB VRAMに全体が収まり、ベースモデルはテキスト、画像、動画に対応し、推論、コーディング、リサーチ、エージェント型の作業をカバーします。エージェント型コーディングを優先する場合は、その分野に特化したOrnith 1.5 35B-A3Bのほうが優れています。

16GB RAMに最適なローカルLLMは何ですか？

Q6_KのQwen 3.5 9Bが、汎用用途の第一候補です。7.4GBのファイルなので、OS、実行環境、実用的なコンテキストウィンドウのために十分なメモリが残ります。コーディングにはOrnith 1.5 9B、マルチモーダル入力にはGemma 4 12Bを選んでください。

16GB VRAMで30Bモデルを実行できますか？

はい。ただし、トレードオフがあります。27Bのデンスモデルには、Qwen 3.8 27B AD-IQ3_Sのような3ビットビルドが必要です。35BのMoEも低ビット量子化なら収まります。すべての重みがメモリを占有するものの、計算時に有効になるエキスパートはごく一部だからです。この規模の一般的なQ4ファイルは、通常、コンテキスト用の余裕を残すには大きすぎます。

16GB RAMで20Bモデルを実行できますか？

gpt-oss-20bは16GB以内で動作するように設計されており、ネイティブのチェックポイントは12.8GiBです。ただし、システムRAMの合計が16GBしかないコンピューターでは、OS、実行環境、KVキャッシュのために残る容量がわずかです。効率的なバックエンドと控えめなコンテキスト長なら可能ですが、日常的な利用では、通常7〜9GBのモデルファイルのほうがスムーズに使えます。

16GB VRAMではどの程度のコンテキスト長を使えますか？

主にモデルのサイズ、アーキテクチャ、KVキャッシュの精度によって異なります。Qwen 3.8 27B AD-IQ3_Sでは、16GB GPUで約8Kのコンテキスト長を確保できます。より小型のハイブリッドモデルでは、重みを読み込んだ後に残る空きメモリが多く、従来型のKVキャッシュを保持する層も一部に限られるため、はるかに長いコンテキストを使えます。KVキャッシュを量子化して保存すると、利用可能なコンテキスト長を大幅に伸ばせます。

16GB VRAMではどの量子化を使うべきですか？

27Bのデンスモデルには、13〜14GB程度のIQ3、または実測評価済みの混合3ビット量子化を使用してください。20BのMoEモデルなら、ネイティブのMXFP4や通常のQ4ビルドが収まる場合があります。9B〜12Bのモデルでは、通常Q6やQ8が余裕を持って収まり、元モデルの品質をより多く保てます。

27Bモデルをllama.cppで実行すると、VRAMをどれくらい使いますか？

Qwen 3.8 27Bの場合、重みだけでもAtomic ChatのAD-IQ3_Sで約13.8GBからAD-Q4_Kで約17.1GBまで幅があります。llama.cppは、このほかにKVキャッシュ、計算バッファ、実行時に必要なその他のメモリも確保します。ディスクに収まるファイルや、VRAMに読み込めるファイルであっても、コンテキストが長くなると動作しなくなる可能性があります。そのため、GGUFのサイズだけでなく、実行中のメモリ使用量で構成を判断してください。

まとめ

• 16GBのVRAMを搭載したグラフィックスカードがあるなら、AD-IQ3_SのQwen 3.8 27Bは、能力とメモリ使用量のバランスが良い選択肢です。
• 16GBのRAMまたは統合メモリを搭載しているなら、Qwen 3.5 9B Q6_K、Ornith 1.5 9B、Gemma 4 12Bなど、7〜9GB程度のモデルファイルを目安にしてください。
• 通常は、CPUオフロードやスワップに大きく依存する大型モデルよりも、高速なメモリに全体が収まるモデルのほうが高いパフォーマンスを得られます。
• GGUFのファイルサイズを、必要なメモリの総量と考えないでください。KVキャッシュ、計算バッファ、実行環境、OSのためのメモリも必要です。
• Atomic Dynamic量子化は、テンソルのグループごとに異なる精度を使うことで、Qwen 3.8 27BとOrnith 1.5 35Bに必要なメモリを削減します。個々のビルドには、忠実度の実測データも含まれています。