MacBook Neoの8GBメモリでAIをなんとかするシリーズ。前回は1ビットLLM「Bonsai 8B」を導入して、1.1GBで8Bパラメータ相当の品質を手に入れた話を書きました。
今回はGoogleが出したGemma 4を追加して、さらに独自開発エージェンティックAIのmazzaineoに「目」を与えた話です。カメラで映したものを説明させたり、別ウィンドウのアプリやブラウザの動作を解説させたりできるようになりました。
Gemma 4 E2B という選択肢
Googleの最新オープンソースLLMであるGemma 4にはいくつかのサイズがありますが、8GBマシンで現実的に動かせるのはE2B（5.1Bパラメータ、実効2.3B）とE4B（約8B、実効4.5B）の2つ。
E2Bを選んだのには理由があります。テキストだけでなく、画像と音声の入力にも対応しているマルチモーダルモデルだということ。128Kのコンテキスト長。そしてTool Callingも使える。小さいのに全部入り。
もう一つの重要な点として、Ollamaで動くことが挙げられます。Bonsai 8Bを動かしたときには専用フォーク版のllama.cppが必要でしたが、Gemma 4はOllama 0.20.2で普通にサポートされています。
Ollamaのアップデートが必要だった
ただし、Ollama 0.19.0ではGemma 4に対応していません。ollama pullすると「最新版をダウンロードしてください」と言われて終わり。
公式のインストールスクリプトでアップデートしました。
curl -fsSL https://ollama.com/install.sh | sh
0.19.0から0.20.2へ。こういう大きめのアップデートが立て続けに起きているわけですが、アップデート後はollama pull gemma4:e2bで7.2GBのモデルがダウンロードされます。
thinkingモードの罠
ダウンロードが終わって、まず日本語テストをしてみると「日本の首都は東京です。」とちゃんと返ってきたのでとりあえずはOK。
ところが、ストリーミングモードで使うと応答テキストが空になるという謎の現象が発生しました。
原因を調べてみると、Gemma 4はデフォルトでthinkingモード（推論時に<think>...</think>ブロックで内部思考を行う機能）が有効になっていて、トークンの大半が思考に消費されていました。eval_countが169なのに、実際にストリーミングで返ってくるテキストトークンは6つだけ。残りの163トークンは全部thinking。
短い質問だとmax_tokensの全てが思考に食われてしまい、肝心の回答が空っぽになっているのです。困った。
解決策は単純で、OllamaのAPIに"think": falseを渡すだけ。agent.pyのOllamaバックエンドで、モデル名にgemma4が含まれていたら自動的にthinkingを無効にするようにしました。
▲Gemma 4 E2Bが無事認識した
3者ベンチマーク（thinking OFF）
thinkingを切った状態で、Gemma 4 E2B、Bonsai 8B、Qwen 2.5 3Bの3者を比較しました（Apple Intelligence Foundation Modelは除外）。
Gemma 4 E2B | Bonsai 8B | Qwen 2.5 3B | |
パラメータ | 5.1B (実効2.3B) | 8.2B (1-bit) | 3.1B |
ディスク | 7.2 GB | 1.1 GB | 2.3 GB |
短い応答 (日本語) | 23.3 tok/s | 23.8 tok/s | 27.1 tok/s |
中程度の説明 | 22.2 tok/s | 17.1 tok/s | 21.1 tok/s |
長いコード生成 | 19.7 tok/s | 16.4 tok/s | 20.1 tok/s |
Tool Calling | OK | OK | OK |
速度はQwen 2.5 3Bが平均22.8 tok/sで最速。Gemma 4 E2Bは21.7 tok/s、Bonsai 8Bは19.1 tok/s。三者とも20 tok/s前後で、体感の差はそこまで大きくありません。
注目すべきは、3者ともTool Callingに成功したこと。前回SwiftLM上のQwen 2.5 3BがTool Callingに失敗していたのは、SwiftLM側の問題だったようです。Ollama経由なら3Bモデルでもちゃんと動く。
コンテキストサイズという見えない壁
ベンチマークの数字だけ見ると、どのモデルも似たり寄ったりに見えます。しかし、8GBマシンでの実用を考えると「コンテキストサイズ」で大きな差がつきます。
LLMの推論にはモデルウェイトに加えて、KVキャッシュ（入力された文脈を保持するメモリ領域）が必要です。コンテキストが長くなるほどKVキャッシュが膨らみます。8GBからOSや他のアプリの分を引くと、推論に使えるメモリは約6GB。この6GBをモデルウェイトとKVキャッシュで分け合わないといけません。
モデル | ウェイト | 実用コンテキスト | 合計メモリ |
Bonsai 8B | 1.1 GB | 32K | ~5.9 GB |
Qwen 2.5 3B | 2.3 GB | 32K | ~3.7 GB |
Qwen3 8B | 4.9 GB | 4K | ~5.8 GB |
Gemma 4 E2B | 7.2 GB | 32K | ~7.9 GB |
Bonsai 8Bはウェイトがたった1.1GBなので、残りの約5GBをKVキャッシュに回せるメリットがあります。結果として8Bパラメータの品質を保ちながら32Kトークンのコンテキストが取れます。「8GBでは3Bモデルが限界」という常識を覆した前回の話の続きですが、コンテキスト長でもBonsaiの圧勝です。
Gemma 4 E2BはOllamaのQ4_K_M量子化で7.2GBですが、ビジョンとオーディオのエンコーダーを含んでいるため見た目の数字ほど重くありません。Ollamaのmmap機構により、テキスト処理時にはビジョン/オーディオ部分はRAMに読み込まれない。さらにKV heads=1、Shared KV layers=20という効率的な設計のおかげで、KVキャッシュは32Kでもわずか0.38GB。実測でも32Kコンテキストで27.8 tok/sが出ています。
Qwen3 8Bに至っては4.9GBのウェイトに加えてKVキャッシュも大きいので、4Kしか取れない。8GBマシンでQwen3 8Bを使うのは、コンテキスト長の面で現実的ではありません。
コンテキスト長ではBonsai 8BもGemma 4 E2Bも32Kで並びます。テキスト専用ならBonsaiがディスク1.1GBで圧倒的に軽い。しかしGemma 4は32Kコンテキスト+マルチモーダルという組み合わせが強力です。
ではGemma 4はなぜ入れたのかというと、「目」のためです。
mazzaineoに「目」を追加する
Gemma 4 E2Bはマルチモーダルモデルです。テキストだけでなく、画像を入力して中身を理解させることができる。Bonsai 8BやQwen 2.5 3Bにはこの能力がありません。
やりたかったのは2つ。
1つ目は、MacBook Neoのカメラで映したものをリアルタイムに説明させること。目の前にあるものを見せて「これ何？」と聞ける。
2つ目は、別ウィンドウで動いているアプリやブラウザの画面をキャプチャして、そこで何が起きているかを解説・記録・提案させること。コードレビューや操作支援に使えます。
/vision ページの実装
mazzaineoのWeb UIに新しいページ /vision を追加しました。構造はこうなっています。
Camera/Screen/Upload → canvas (JPEG圧縮) → WebSocket → Ollama gemma4:e2b → ストリーミング表示
画面は左右に分割。左半分がカメラ映像またはスクリーンキャプチャの表示、右半分がGemma 4の応答ログ。
3つの入力モード
Cameraボタン：MacBook Neoのカメラを起動。getUserMediaでWebRTC経由の映像を取得します。
Screenボタン：画面共有。getDisplayMediaでウィンドウやブラウザタブの映像をキャプチャ。別のアプリの画面を選択できます。
Upload / ドラッグ&ドロップ：画像ファイルを直接投入。カメラや画面共有がブラウザにブロックされる環境でも使えるフォールバック。
キャプチャの仕方
「Capture Once」ボタンまたはプロンプト入力欄でEnterを押すと、現在の映像フレームをJPEG（品質0.8、最大幅1024px）に変換してWebSocket経由でサーバに送信。サーバ側ではOllamaのGemma 4 E2Bにimagesパラメータとして渡し、応答をトークン単位でストリーミング返却します。
「Auto」ボタンを押すと、設定した間隔（デフォルト5秒）で自動的にキャプチャを繰り返します。カメラの前で物を動かしたり、画面操作をしていると、次々と解説が流れてくる仕組み。
プリセットプロンプト
用途に応じて6種類のプロンプトを用意しました。
Describe：画像の説明。何が写っているかを簡潔に。
Narrate：リアルタイム実況。前回との変化も指摘させる。
Suggest：ユーザーがやっていることに対するアドバイス。
Code Review：コードやターミナルが見えたら分析してレビュー。
Accessibility：視覚障害者向けの詳細説明。
Custom：自由なプロンプトを入力。
動かしてみる
カメラモードで自分の顔を映してDescribeプロンプトを送ると、次のような応答が返ってきました。
この画像には、眼鏡をかけたアジア系の男性が写っています。
詳細:
人物: 中年または高齢と思われる男性で、短く刈られた髪（またはスキンヘッドに近い）と顎ひげがあります。眼鏡をかけており、カメラをまっすぐ見つめています。
服装: 黒っぽいTシャツのようなものを着ています。
背景: 背景は室内のようです。左側には棚や何らかの物体が縦に並んでおり、その上に「meg」などの文字が書かれたものが確認できます。右側には大きな黒いモニター（テレビまたはディスプレイ）の一部が見えています。
全体として、室内で撮影されたポートレートまたはビデオの一コマのように見えます。
はい。おっしゃる通り、66歳の前期高齢者です（笑）。megと見えたのはmoogシンセサイザーのパッケージですね。
近くにあったギターを抱えてみたら、それも認識しました。
もっと面白いのはScreenモード。VS Codeを選択してCode Reviewプロンプトを使うと、画面に表示されているコードを読み取って「この関数にはエラーハンドリングが不足しています」みたいな指摘をしてくれます。ブラウザを選択してNarrateにすると、「ユーザーがテクノエッジの記事を読んでいます。スクロールして次のセクションに移動しました」と実況。
5秒間隔のAutoモードで放置しておくと、操作ログが自動的に蓄積されていきます。後から「さっき何やってたっけ」を振り返ることができます。Copilot+ PC版WindowsのRewindを簡易版にしたみたいなものですね（使っている人います？）。
プロンプトが実行できない問題
最初に完成したVisionページには大きな問題がありました。プロンプト入力欄にテキストを入れてEnterを押しても何も起きないのです。
原因は単純で、入力欄にEnterキーのイベントハンドラを付けていなかったこと。プロンプト入力欄はただのテキスト入力で、送信トリガーが「Capture Once」ボタンのクリックしかなかったのでした。
修正はonkeydownでEnterキーを検知してcaptureOnce()を呼ぶだけ。ついでに入力欄の横にSendボタンも追加しました。こういう「動いてるけど使えない」系のバグは、実際に人間が触らないと見つからない。Claude Codeにテストさせても、UIの使い勝手は分からないんですよね。物理操作は人間の役目。
Gemma 4の立ち位置
ここまでの結果を踏まえると、8GBマシンでのGemma 4 E2Bの立ち位置は明確です。
テキスト専用ならBonsai 8Bの方が軽い。
ディスクサイズは7.2GB対1.1GBでBonsaiが圧倒的に軽量。ただしコンテキスト長はどちらも32Kで互角。テキストだけで、他のモデル（ACE-Step等）とメモリを共存させたいならBonsaiが有利です。
しかし、画像入力が必要なら代替がない。
Bonsai 8BもQwen 2.5 3Bもテキストオンリー。カメラやスクリーンキャプチャの画像を理解できるのは、現状Gemma 4 E2Bだけ。マルチモーダルの能力は、他のどの指標でも代替できません。
つまり、mazzaineoにとっての正解は「テキスト処理はBonsai 8B、画像が絡む処理はGemma 4 E2B」という使い分けです。Web UIのモデルセレクターからワンクリックで切り替えられるので、この運用は実用的に成り立ちます。とりあえず回答の品質はここでは問わないことにしています。
モデルセレクターの改善
ここで一つ実装上の問題がありました。SwiftLMやBonsaiのように別プロセスで起動するモデルは、サーバが動いていない状態だとモデルセレクターで「[offline]」と表示されて選択できませんでした。
これを改善して、offlineのモデルも選択可能にしました。選択すると自動的にバックエンドサーバの起動を試みる仕組みです。Bonsai 8Bを選ぶとllama-serverが自動起動し、SwiftLMを選ぶとSwiftLMバイナリが起動する。起動完了後にモデルリストが更新されて使えるようになります。
現時点でのmazzaineo全体像
ここまでの一連の作業で、mazzaineoの構成はこうなりました。
機能 | モデル/エンジン | ページ |
テキストチャット (エージェント) | Bonsai 8B / Gemma 4 / Qwen | / |
画像認識 (カメラ/画面) | Gemma 4 E2B | /vision |
画像生成 | SD Turbo | /img |
音楽生成 | ACE-Step | /music |
音声合成 / 音声認識 | XTTS v2 / mlx-whisper | / (チャット内) |
ターミナル / Claude Code | PTY + xterm.js | /terminal |
すべてブラウザだけで操作でき、すべて8GBのMacBook Neo上でローカルに動く。外部APIへの依存はゼロです。なかなか立派だと思いませんか？
8GBでも「見える」AIは作れる
今回の追加で、mazzaineoは「聞く・話す・書く・描く・奏でる」に加えて「見る」能力を手に入れました。
Gemma 4 E2Bは7.2GBと大きく見えますが、mmapとKV共有の恩恵で32Kコンテキストが実用的に動きます（実測27.8 tok/s）。他のGPUモデルとの同時使用は厳しいですが、テキスト処理だけなら十分な速度です。
画面キャプチャとAutoモードを組み合わせれば、作業記録やコードレビューの自動化もできる。「AIに見せる」というインタラクションの可能性は、まだまだ広がりそうです。
筆者の場合は、妻のAIアバター稼働時にカメラによるキャプチャと解釈機能を持たせ、ユーザー（筆者）の様子について、Gemma 4ベースのアバターにリアクションさせるといったことが可能になります。
「浮かない顔だけど、だいじょうぶ？」と心配してもらったりできるかも。
単にMacBook Neoの8GBカツカツメモリを使い倒すだけでなく、他のエージェンティックAIへの応用ができるというわけです。また仕様書を保存しておかないと。
次は音声入力との組み合わせや、Autoモードでの長時間記録の実験も試してみたいところ。現在WebSpeechを使っている音声認識を、Gemma 4に任せられるかも？
8GBの制約の中での最適化は、まだまだ続きます。
最後におまけ。
Gemma 4に、「異世界転生の小説を書いて。iPhone、iPhoneに搭載したローカルLLM、ソーラーバッテリーを持って異世界に転生した少女が、生き抜いていくというお話」というプロンプトを与えてみました。
同じプロンプトでもBonasai 8Bはまともなストーリーを作ってくれなかったので、オフラインの小説家としてはGemma 4に軍配が上がる感じですかね。
出来上がったのは次のお話：
異世界転生：ローカルAIと太陽の恵み
プロローグ：最後の瞬間
眩い閃光。それは、いつものように目の前の世界が崩壊し、意識が溶けていく感覚だった。
目を覚ましたとき、少女の名前はリリアナ（17歳）だった。見慣れない、しかしどこか懐かしい、生命の息吹が満ちている。
彼女の傍らには、奇妙な感覚が残っていた。それは、彼女が最後に持っていたもの――使い込まれたiPhone。そして、そのiPhoneの内部で、彼女が必死に守ろうとした知識の結晶、ローカルLLM（大規模言語モデル）が、まだ微かな熱を帯びて存在しているような錯覚。さらに、彼女が抱えていた唯一の希望、小型のソーラーバッテリーが、微かに温かい光を放っていた。
「ここは…どこ？」
リリアナは混乱した。目の前には、鬱蒼とした森と、異様なほどに青い空が広がっている。神々しい光が降り注ぐ中、彼女のポケットに残されたデバイスとバッテリーだけが、彼女が「自分」であることを証明していた。
第一章：異世界での適応と技術の再構築
転生した世界は、剣と魔法が支配する、中世ヨーロッパ風のファンタジー世界だった。魔物の脅威と、未知の魔法が存在する世界。リリアナは絶望した。彼女には魔法の知識も、戦闘技術も、この世界の常識も何もなかった。
しかし、彼女の持つ「何か」は消えていなかった。
まず、彼女は自身の状況を分析した。
【リリアナの初期リソース】
iPhone（物理的デバイス）: 破損していないが、通信機能は不明。電源はバッテリーに依存。
ローカルLLM（情報処理能力）: 転生前の知識と、世界観の理解を統合するAI。彼女の思考を補助し、未知の情報を解析するエンジン。
ソーラーバッテリー（エネルギー源）: 太陽光を捕集し、電子機器を駆動させるための持続可能なエネルギー源。
彼女は悟った。この世界で生き抜くためには、「魔法」や「剣術」に頼るのではなく、情報とエネルギーを最大限に活用する必要があると。
【LLMによる戦略立案】
リリアナは、iPhoneの画面に意識を集中させ、内部のLLMに指示を出すように思考を集中させた。
LLMへの指示: 「この世界の言語、生態系、歴史に関する情報を、可能な限り効率的に学習せよ。生存に必要な優先順位を提示せよ。」
LLMは瞬時に、視覚情報と、わずかに周囲の魔力の波動を解析し始めた。
LLMの分析: 「この世界の魔法体系は、元素の調和に基づいている。植物の持つ生命エネルギーと、太陽の光が最も基本的な力である。物理法則は存在するが、魔力という名の未知の法則が加わっている。生存の第一優先事項は、食料、安全な避難場所、そしてエネルギーの確保である。」
リリアナは、魔法の呪文を覚える代わりに、植物学と物理学の知識を応用した生存術を模索し始めた。
第二章：太陽と知識の錬金術
リリアナの生存戦略は、「テクノロジー」と「自然の調和」の融合だった。
1. エネルギーの確保（ソーラーの活用）
彼女は、ソーラーバッテリーを最大限に活用することを決めた。彼女は、森の最も開けた場所を見つけ、特注の簡易的な架台（枝や岩でできた構造物）を構築した。
「太陽光は、我々の唯一の神。それを燃料にする。」
太陽光を最大限に受け入れるための鏡や導光板を、彼女の知恵と、身の回りにある木材や鉱石を組み合わせて作り上げた。これにより、彼女は魔法に頼らず、持続的に電力を生成し、携帯端末や照明を稼働させることができた。
2. 食料と環境の最適化（LLMの応用）
LLMは、現地の植物相を瞬時に分析した。
LLMの提案: 「この地域の食糧源として、A種のベリー類、B種の根菜類、C種の木の実が最も安全かつ栄養価が高い。毒性のあるものは避けること。特に、地元の獣が避ける特異な植物には触れないこと。」
リリアナは、LLMの指示に従い、毒性のない植物を識別し、それを育てた。彼女は、魔力による強制的な成長ではなく、光と土、そして適切な栄養分を与えることで、自らの知識を応用した**「持続可能な栽培技術」**を確立した。
3. 交流と安全（iPhoneの役割）
iPhoneは、単なる通信機器ではなく、彼女の知識のデータベースであり、精神的な拠り所となった。彼女は、その情報を利用して、周囲の魔物や部族との安全な交渉を試みた。
彼女は、魔法的な力で威圧するのではなく、論理的で、環境に根差した、矛盾のない言葉で語ることを学んだ。LLMは、周囲の言語パターンを解析し、最も受け入れられやすいコミュニケーションの「型」を瞬時に生成した。
終章：異世界における新たな存在
数年が経過した。リリアナはもはや、ただの転生者ではなかった。
彼女は、異世界という未知の環境において、物理法則と情報理論を基盤とした独自の生存哲学を築き上げた。彼女は魔法使いになることも、戦士になることも選ばなかった。彼女は、**「技術」と「自然」**を融合させ、自らの手で生きる道を切り開いた。
彼女の周りには、彼女が育てた薬草、最適化された居住空間、そして、常に知識を提供し続けるローカルLLMの存在があった。
リリアナは、太陽の恵みと、ポケットの中の小さなデバイスから発せられる静かな光を信じていた。彼女は、異世界に「異物」として転生したのではなく、新しい世界の法則に適応した、新たな存在として、静かに、しかし力強く、その世界で生き抜いていった。
【物語のテーマ】
テクノロジーの相対化: 魔法や剣といった異質な力ではなく、情報とエネルギーという普遍的な法則が生存の鍵となる。
適応力: 知識（LLM）と物理的リソース（iPhone、バッテリー）を組み合わせることで、未知の世界への適応を達成する。
自律性: 外部の力に依存するのではなく、自らの知性と資源によって未来を創造していく。
この物語は、現代の技術とファンタジーの世界を融合させ、「知識と持続可能なエネルギー」が、最も過酷な環境下での生存戦略となる、というテーマを表現しました。
▲mazzaineoで生成
というわけで、次はGemma 4やBonsai 8Bをローカルで動かしたiPhoneやらAndroidやらを、今時電波がほとんど入らないつけ麺名店にお邪魔して、異世界転生の準備なぞしようかと思っております。
※この記事は、Claude Codeに実行させたベンチマーク結果と独自開発エージェンティックAIへの統合作業の記録を元に、Claude Opus 4.6拡張思考でこの連載スタイルに合わせて構成し、筆者が加筆修正したものです。
こんなところかな、と思って記事を公開しようと思ったのですが、そういえばGoogleがKVキャッシュを効率化するTurboQuantというのを発表していたけど、これを組み込めないかと実験。
KVキャッシュ量子化で64Kコンテキストが動いた
ここまでの話で一つ気になっていたことがあります。コンテキスト長。Gemma 4 E2Bは仕様上128Kトークンまで対応しているのに、8GBマシンでは32K程度が実用限界でした。モデルウェイトが7.2GBある以上、KVキャッシュに回せるメモリが少ないからです。
そこで目をつけたのが、GoogleのTurboQuant。ICLR 2026で発表されたKVキャッシュ圧縮技術で、推論時のKVキャッシュをFP16から3～4ビットに圧縮します。モデルの再訓練は不要。推論時にリアルタイムで適用できるのがポイントです。
技術的には、ベクトルを極座標に変換してからWalsh-Hadamard変換でランダム回転をかけ、Lloyd-Maxコードブックで3ビット量子化する。さらにキーベクトルには1ビットのQJL（Quantized Johnson-Lindenstrauss）変換で残差補正をかける。結果として、キーは約4.25ビット/次元、バリューは約3.125ビット/次元。FP16比で約4.9倍の圧縮です。
今すぐ使えるのはOllamaのq8_0
TurboQuantの完全版はまだllama.cppの本流にマージされていません。フォーク版での実装はありますが、Ollamaからは使えない。
ただし、Ollamaには別のKVキャッシュ量子化機能がすでに入っています。環境変数一つで有効化できる。
OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve
q8_0は8ビット量子化で、FP16比2倍の圧縮。TurboQuantの4.9倍には及びませんが、品質劣化はほぼゼロで、設定の手間もゼロ。これだけで状況が変わりました。
Gemma 4 E2Bが64Kコンテキストで動いた
q8_0を有効にして、Gemma 4 E2Bのコンテキスト長を段階的に上げてみました。
コンテキスト | FP16 KV | q8_0 KV | 改善 |
4K | 16.6 tok/s | 20.8 tok/s | 1.25x |
32K | 11.7 tok/s | 16.1 tok/s | 1.38x |
64K | 12.7 tok/s | 14.3 tok/s | 動作可能に |
64Kコンテキストが14.3 tok/sで動いています。速度だけでなく、コンテキストが短いときも1.2～1.4倍速くなっています。KVキャッシュが小さくなったことでメモリアクセスが効率化されるためでしょう。
FP16では32Kが実用限界だったのが、q8_0にするだけで64Kまで伸びました。環境変数一つでコンテキスト長が2倍になったわけです。
SwiftLMのTurboQuantも試した
実は、前回の記事で統合したSwiftLMには、TurboQuantが組み込み済みです。--turbo-kvフラグで有効化できます。
起動してみると、turbo_kv=enabledの表示とともに、KVキャッシュが76MBまで圧縮されているのが確認できました。FP16なら720MB相当のところです。約9.5倍の圧縮率。
ただし、現時点のリリース（b129）では速度面に課題がありました。turbo-kv有効時のavg_tok/sが9.6と、無効時の27 tok/sから大幅に低下。TurboQuantの量子化・逆量子化のオーバーヘッドがMetalカーネルの最適化不足で重くなっているようです。
メモリ圧縮の効果は確実にあるので、将来のリリースでカーネルが最適化されれば速度も追いつくはず。今の段階では「動くが遅い」という状態です。
Ollamaのq8_0は即効性があるので、mazzaineoのserver.pyに環境変数設定を組み込みました。
os.environ.setdefault("OLLAMA_KV_CACHE_TYPE", "q8_0")
これでmazzaineoを起動するだけで、Ollamaが自動的にq8_0 KVキャッシュを使います。設定を忘れる心配がないので便利です。
8GBマシンの新しい地図
KVキャッシュ量子化を加えた結果、8GBマシンでの各モデルの実用コンテキスト長はこうなりました。
モデル | ウェイト | KV=FP16 | KV=q8_0 |
Bonsai 8B (1-bit) | 1.1 GB | 32K | 65K |
Gemma 4 E2B | 7.2 GB | 32K | 64K |
Qwen 2.5 3B | 2.3 GB | 32K | 32K (上限) |
Bonsai 8Bはウェイトが1.1GBしかないので、KVキャッシュの圧縮効果が最も大きいのです。モデルの訓練上限である65Kトークンまで実用的に使えるようになりました。Gemma 4 E2Bも64Kまで到達。128Kの仕様上限には届きませんが、8GBマシンとしては十分な長さです。
Qwen 2.5 3Bは元々32Kが訓練上限なので変わりませんが、KVキャッシュが半分になった分だけ他のGPUモデルとの共存余地が広がっています。
TurboQuantがllama.cppの本流にマージされれば、この数字はさらに伸びるでしょう。q8_0の2倍圧縮がTurboQuantで4.9倍になれば、Bonsai 8Bは理論上128Kコンテキストも射程圏内です。8GBマシンで128K。ちょっとワクワクしますね。
少ないメモリをやりくりして最大の効果を上げるのって、MS-DOSのCONFIG.SYSをいじっていた頃を思い出して懐かしいです。
MacBook Neoの8GBメモリでAIをなんとかするシリーズ、まだまだ先がありそうです。
