Bonsai 8B(1bit LLM)をGPUなしWindows PCで動かす|Iris Xe・Radeon 680Mで実測ベンチ比較

ここ最近、ローカルLLM周りの話題の流れがいよいよ早くなってきたなと感じています。新しいモデルが発表されたかと思えば、翌週には量子化版が公開され、その次の週には本家llama.cppにマージされて…というペースで、ちょっと目を離すとすぐ置いていかれそうになるんですよね。

そんな中、ふと自分の業務PCを見て「あれ…これでAI開発とかできるんだろうか…」と思う方も多いんじゃないかなと思います。業務用PCって、GPU非搭載のスリムなモデルだったりすることが多くて、SNSで流れてくる「RTX 4090でローカルLLM爆速!」みたいな記事を見ると、正直ちょっと遠い世界の話に感じたりするんですよね。

でも最近、その「遠い世界」の方がどんどんこっち側に近づいてきていて、その象徴みたいなモデルが1ヶ月ほど前に登場しました。PrismML社の「Bonsai」 という1bit LLMです。

  • 8Bパラメータのモデルが たった1.15GB
  • Apache 2.0ライセンスで商用利用OK
  • GPU非搭載の普通のPCでも動く

発表直後はSNSでもかなり話題になっていて、自分も「これはすごい」とすぐ飛びつきそうになったんですが、少し時間を置いてから触るのもアリかなと思ってちょっと寝かせていました。 1ヶ月経つと、初期のお祭り感が落ち着いて、実際にどこまで使えるモデルなのか、どのツールで動くのか、を冷静に見られる タイミングかなと思います。

今回はこの Bonsaiを、手持ちの中でAIにはパワー不足な環境(GPU非搭載PC)から試してみた という実験ログです。Windowsネイティブだけで完結する構成 にしたので、WSLの準備も不要です。業務PCしか持っていない人でも、そのまま真似できるようにしました。

⚠️Bonsaiは2026年3月末に公開されたモデルで、本記事は発表から約1ヶ月経った時点での実験記録です。ツールのサポート状況は日々変わっていくので、最新情報は必ず公式を確認してください。公式情報: prismml.com / HuggingFaceモデルカード


続きを読む

NPUってメモリどうなってるの?GPUとの違いからIntel・AMDのアーキテクチャを調べてみた

最近「AI PC」という言葉を耳にするようになりましたね。Windows PCを買おうとすると「NPU搭載!」「○○TOPS!」みたいな文字が踊っていて、なんだか凄そうな雰囲気は伝わってくるんですが、実際のところNPUって何をしてるの? メモリはどうなってるの?というあたりが意外とよくわからないんですよね。

GPUについては、ゲームや動画編集で使ってる人も多いし、最近はローカルLLMの推論でVRAMが足りない!みたいな話題でだいぶ認知が広がってきた印象があります。 一方でNPUは「なんかCopilot+PCの要件で必要らしい」くらいの認識の人が多いんじゃないかと思います。自分もそうです🫠

というのも、NPUを直接意識して使うアプリケーションがまだ少ないんですよね。 GPUならゲームを起動すれば勝手に使われるし、LLM推論ならOllamaでGPUオフロードすれば「おお、速い!」と実感できる。 でもNPUは「Windows Studioエフェクトの背景ぼかし」とか「Copilotの一部処理」とか、なんとなくバックグラウンドで動いてる感じで、体感しにくい。

そんなわけで、今回はNPUが内部的にどうメモリを使っているのか、GPUとの違いは何なのか、IntelとAMDでアーキテクチャはどう違うのか、というあたりを調べてみました。 自分のレベルでは100%の理解は正直難しい(自分も完全にはわかっていない🤣)ので、「なるほど、だいたいそういうことね」くらいの感覚で読んでいただければと思います。

以前、DELLのPCのモニタをして行く中で、興味がでたのでなんとなく調べてみたという感じの内容になります。

参考

uepon.hatenadiary.com

uepon.hatenadiary.com

uepon.hatenadiary.com

uepon.hatenadiary.com

uepon.hatenadiary.com

uepon.hatenadiary.com

続きを読む

非エンジニアのためのClaude Cowork入門|WEBチャットとの違い・設定手順・活用Tipsまとめ

4月に復帰してからというもの、日中は業務に追われてClaudeをじっくり触る時間がほとんど取れていない。Max 5xプラン($100/月)を契約しているのに、正直もったいない状態が続いている🫠

私は世間的には非エンジニアにカテゴライズされているメモ帳プログラマなので、コードを書くときはWEBチャットで対話しながら進めるほうが性に合っていると思っている。それは引き続きそうするつもり(やりたいことが出てきたらClaude Codeを使用すると思うが🤗)。最近分かったことだが、自分は実はLLMと対話したり議論するがかなり好きらしい。

そんな中、2026年4月9日にClaude Cowork(以降はCoworkとする)がResearch PreviewからGA(一般提供)になったというニュースがあった。タスクを渡して「あとはよろしく」とできるなら、夜間の作業効率が上がるかもしれない。せっかくのMaxプランを活かすためにも、重い腰をあげて移行に手を動かしてみることにした。

続きを読む

RAG4パターン比較 …AIのカンニングペーパーにも組み方がある!?

大学も卒業したので、やっているときにはあまり考えられなかったところを、かじった程度の視点から考えてみました。

RAGってそもそも何?

AI(大規模言語モデル=LLM)は賢いけれど、社内固有情報や新事実に対してはそのままでは弱い。「うちの会社の就業規則は?」と聞いても知らないし、昨日のニュースも知らない(最近のChatサービスでは答えられますが…🫠)。

そこで考えられたのがRAG(Retrieval-Augmented Generation 検索拡張生成)という仕組みです。AIに質問する前に、手元のデータベースから関連情報を「検索」して、それをAIに渡して回答させる。つまり「カンニングペーパー付きのテスト」のようなものです。

最近では、このRAGにはもいくつかのパターンがあり、どれを選ぶかで精度もコストも使い勝手も大きく変わるようです。私も大学で学んでいるときにRAGを使った経験があるので、そのときの実感も交えながら、4つの代表的なRAGパターンを比較してみたいと思います。

素人なりの視点からの考察ですが、RAGをこれから導入しようと考えている人や、RAGの違いがよくわからない人の参考になれば幸いです。


4つのRAGパターン

1. 従来型 RAG

一言で言うと、質問に似た文書を探してきて、AIに読ませる

質問 → ベクトル化 → 似た文書を検索 → AIが回答

文章を多くの実装では「ベクトル」という数値の列に変換し、質問と似ている文書をコサイン類似度距離で探す。シンプルで高速。多くの場合、最初に検討するパターン。

向いている場面 FAQ、社内文書検索、マニュアル参照

良いところ🤗

  • 構築が簡単で、動くものがすぐ作れる
  • 応答が速い
  • 「この質問にはこの文書が関連する」という直感的な仕組み

つらいところ😢

  • 「似ている」と「正しい」は別物。的外れな文書を拾うこともある
  • 文書の切り分け方(チャンキング)の良し悪しで精度が大きく変わる
  • 要素間の関係性(AだからB、AなのにC)は理解できない

私の実感 自分も最初にこのパターンを試した。「料理番組」で検索すると似た料理番組は出てくるが、「料理×お笑い」のような異質な分野の組み合わせは、単純な類似度検索だけでは拾いにくい。似ていないものを探す能力には乏しいかもしれない。


2. エージェント型 RAG

一言で言うと、AIが自分で検索計画を立て、何度も調べ直してから答える

質問 → AIが分析・計画 → 検索 → 足りなければ再検索 → 検証 → 回答

従来型のRAGが「一発検索」なのに対し、エージェント型RAGはAI自身が「この情報だけでは足りない」と判断して、クエリを書き換えたり、追加で検索したりする。人間が調べ物をするときの試行錯誤に近い。

向いている場面 調査レポート、複雑な質問、複数情報源の統合

良いところ🤗

  • 複雑な質問にも対応できる
  • 検索結果の品質をAI自身が検証する
  • 人間の調査プロセスに最も近い

つらいところ😢

  • 遅い。検索を何往復もするので体感的に待たされる
  • API呼び出しが増えるのでコストが嵩む
  • 構築が複雑で、デバッグが大変

私の実感 精度は確かに上がるが、レイテンシの問題は深刻。ユーザーが「待てる」用途でないと使いにくい。ただし、全部をエージェント型にするのではなく、「最初の検索結果が不十分なときだけ追加検索する」という軽量版なら実用的かもしれない。


3. Graph RAG(知識グラフ型RAG)

一言で言うと、情報を「関係性のネットワーク」として持ち、つながりを辿って答える

質問 → 関連する要素を特定 → グラフ上の関係性を探索 → 回答

情報を「AはBと関係がある」「BはCの原因である」というネットワーク(知識グラフ)として構造化する。ベクトル検索が「似た文書」を探すのに対し、Graph RAGは「関係している情報」を芋づる式に辿る。

向いている場面 人物関係、組織構造、因果関係の分析

良いところ🤗

  • 「AとBの関係は?」という問いに強い
  • 複数の情報をまたいだ推論(マルチホップ)ができる
  • 回答の根拠をグラフ上のパスとして示せる(説明可能性)

つらいところ😢 * 知識グラフの構築と維持に手間とコストがかかる * グラフの設計(スキーマ)にドメイン知識が必要 * 大きなグラフでは検索が遅くなりがち

私の実感 自分はNeo4jneosemanticsを使ってRDFを取り込み知識グラフを構築した。情報の関係性をノードとエッジで表現でき、従来型RAGでは不可能だった関係性の探索が可能になった。一方、スキーマ設計は試行錯誤の連続で、「何をノードにし、何をエッジにするか」という判断自体にドメインの専門知識が求められる。実務知識が必要なのが大きなハードルかもしれない。


4. ベクトルレス型 RAG

一言で言うと、ベクトル変換を使わず、キーワードの一致で検索する

質問 → AIがキーワードを生成 → キーワードで文書を検索 → 回答

ベクトル埋め込みを使わず、BM25などのキーワードマッチングアルゴリズムで検索する。ベクトル変換のコストがゼロになるため、最も軽量で安価。

BM25(Best Matching 25)は、全文検索で最も広く使われているキーワードベースのランキングアルゴリズム。

向いている場面 予算制約のあるPoC、固有名詞が重要な検索、ローカル環境

良いところ🤗

  • 埋め込みモデルが不要なのでコストが低い
  • パイプラインがシンプルで理解しやすい
  • 固有名詞や専門用語の完全一致に強い

つらいところ😢

  • 「意味的に近い」検索ができない(同義語や言い換えに弱い)
  • スケールに限界がある
  • 検索の柔軟性が低い

私の実感 実は実用的な場面は多いと考える。特にローカルLLM(Ollama等)と組み合わせれば、外部APIに一切データを送らずにRAGシステムが組める可能性もある。企業の機密情報を扱う場面では、これだけで十分なケースもある。


全体を俯瞰して見えてくること

どう選ぶか ── 4つの判断軸

判断軸 従来型 エージェント型 Graph RAG ベクトルレス型
スピード重視
精度重視
コスト重視
構築の手軽さ ×

⚠️正解は一つではなく、適応する分野や正確性などによって正解は変わる。複雑な業務では単一方式では足りないことが多い。 BM25のキーワード検索、ベクトルの意味検索、Graph RAGの関係性検索を組み合わせた「ハイブリッド型」が現実的な最適解かもしれない。

RAG全体に共通する課題

4つのパターンを見比べてみると、パターン固有の課題とは別に、RAGという仕組み自体が抱える構造的な課題が浮かび上がってくる。

1. データ管理の問題

RAGの精度は、結局のところ「元のデータの質」に依存する。どんなに高度な検索アルゴリズムを使っても、元のデータが雑然としていれば、出力も雑然とする。チャンキングの方法、メタデータの付与、データの鮮度管理である。これらの地味な作業が精度を左右するが、十分に体系化されていないようにも感じる。

2. レイテンシの問題

精度を上げようとすると、処理が重くなる傾向がある。エージェント型RAGの反復検索、Graph RAGのグラフ走査、ハイブリッド型の複数検索統合。精度とスピードはトレードオフの関係にあり、用途に応じた妥協点を見つける必要があると感じる。

3. データ変換時の情報損失

これが本質的な課題だと考えている。体験を言語にし、言語を構造化データにし、構造化データをベクトルにする。変換のたびに元の情報は不可逆的に圧縮される。RDF-Starのようにメタ情報を付与して損失を減らす工夫はできるが、「完全な保存」は原理的に不可能だろう。


おわりに

技術的な進化

  • ハイブリッド検索の成熟 … BM25 + ベクトル + グラフの三層統合が標準になる可能性がある。各手法の弱点を補完し合い、並列実行でレイテンシも抑えられる。
  • データガバナンス層の確立 … 検索アルゴリズムの高度化よりも、データの品質管理の方がROIが高い。ここが今後最も発展する領域かもしれない。
  • ローカルRAGの台頭 … ローカルLLMの性能向上により、機密データを外部に出さずに実用的なRAGを構築できるようになりつつある。ここも企業活動からすればメリットが大きい。

原理的な限界と、それでもできること

RAGは「既知の情報の検索と再構成」の技術であり、「まだ存在しない知識の創出」はできない。LLM自体が学習データの確率分布からのサンプリングである以上、RAGで高品質なデータを注入しても、「確率的にありそうな出力の精度が上がる」以上のことは原理的に起きない。

しかし、だからといってRAGに価値がないわけではない。RAGは「人間の知的活動を代替すること」ではなく、「人間が考えるための足場(scaffolding)を提供すること」ではないかと考えている。 所詮、完全な知識継承は、実は人間同士でも不可能なのだから。知識というものは、受け手の中で常に「別のもの」として再構築されることが往々にある。AIにできるのは、その再構築を効率よく促す「良い足場」を提供するところであろう。

今回みた、4つのパターンは、その足場の組み方のバリエーションだ。どのパターンが優れているかではなく、どの場面でどの足場が有効かを見極めることが、RAGを活用する上での本質ではないかと。


少し真面目に考えたので、頭が痛くなった🤣

llamafile + USBメモリで持ち歩くローカルLLMを作成する!実用的なモデルサイズは?

最近、ローカルLLMの実行環境としてOllamaやllama.cppを使うことが多くなりました。そんななか、「もっとポータブルにできないかな?」と想像してしまいます。出先のPCでサクッとLLMを動かしたい場面って意外とあるんですよ😊特に、勉強会でのデモや、企業の社内PCでちょっと試してみたいときなど、インストール不要で動かせる環境があると便利なんです。

以前、ネットで見かけた「USBメモリからLLMを起動する」というアイデアはllama.cppをUSBに入れて持ち歩くというものでしたが、llama.cppをビルドする必要があり、それにより動作環境の依存が発生することもあり、面倒な印象がありました。

そんなときに見つけたのがllamafileというプロダクトを使用して、USBメモリからLLMを起動するという方法です。これがなかなか面白い方向性だったので、備忘録としてまとめておきます。

llamafileとは?

llamafileMozilla.aiが開発・メンテナンスしているプロジェクトで、llama.cppとCosmopolitan Libcを組み合わせることで、LLMを単一の実行ファイルとして配布・実行できるようにしたものです。(LLMのエンジンのみも配布可能)

https://github.com/mozilla-ai/llamafile

特徴的なのはActually Portable Executable(APE)という仕組みを使用している点で、1つのバイナリでWindows、macOS、Linux、FreeBSDで同時に動作するという変態的な設計(🤩褒め言葉🤗)になっている点です。そのため、インストールは不要、Python環境も不要、Dockerも不要。まさにポータブルAIの究極形と言えそうです。

2026年3月にv0.10.0がリリースされ、ビルドシステムが大幅に刷新されました。この記事ではv0.10.0をベースに解説していきます。v0.10.0ではllama.cppの最新版に追従するようになり、Qwen3.5など新しいモデルにも対応しています。

なお、llamafileにはモデルウェイトをバンドルした「プリビルトllamafile」(1ファイルにエンジン+モデルが入っている形式)も配布されていますが、Windowsには実行ファイルサイズ上限が存在し、モデルサイズが大きくなってしまう「プリビルトllamafile」ではWindowsでは実行できなくなってしまうこともあります。そのため、今回はllamafile実行ファイル+外部GGUFファイル(引数でモデルを指定する形式)で行なっていきたいと思います。

ポケットに収まるオフラインAI

今回行うのは「USBメモリにLLM実行環境を丸ごと入れて、どのWindows PCでも挿すだけでAIチャットを始められるようにする」というものです。

そこでのポイントは以下の3つとなります。

  • インストール不要 … ソフトウェアのセットアップが一切不要
  • インターネット不要 … 完全オフラインで動作
  • 管理者権限不要 … 企業PCや学校のPCでも使える可能性

これ、ワークショップとかハンズオンの環境構築で地味に嬉しいポイントなんですよね。「事前にOllamaをインストールしておいてください」って案内しても、当日になって「インストールできませんでした」という場面が必ず出てくるので...😅

必要なもの

  • USBメモリ(USB 3.0対応、64GB以上推奨)
  • Windows PC(モデルのロードがあるのでUSB 3.0ポートがあるのが望ましい)
  • インターネット接続(事前準備のダウンロード時のみ)

手順

Step1 USBメモリの準備

まずはUSBメモリをフォーマットします。

  1. USBメモリをPCに接続
  2. エクスプローラーでドライブを右クリック → 「フォーマット」を選択
  3. ファイルシステムをexFATに設定してフォーマットを実行

今回は以下のUSBメモリを準備しました。

https://amzn.to/4mhDbGY

今回はUSB メモリのフォーマット形式にexFATを選んでいます。exFATは、大きなファイル(GGUFモデルは数GB〜十数GBになる)を扱えることと、Windows/macOS/Linuxの互換性が高いためです。

⚠️ USBポートは必ずUSB 3.0以上のポートに挿してください。USB 2.0だとモデルの読み込みがかなり遅くなります。いっそのことUSBタイプのSSDを使うのもアリかもしれません。

Step2 llamafileのダウンロードと配置

USBの準備ができたら、次はllamafileの実行ファイルをダウンロードしてUSBに配置します。

  1. (GitHubのllamafileリリースページ)https://github.com/mozilla-ai/llamafile/releasesにアクセス
  2. v0.10.0のリリースを探し、Assetsセクションからllamafile(実行ファイル本体)をダウンロード
  3. ダウンロードしたファイルをllamafile.exeにリネーム(リネームしても他のOSでちゃんと動作します)
  4. リネームしたファイルをUSBメモリのルートに移動

github.com

⚠️ v0.10.0のリリースページには、プリビルトllamafile(モデル内蔵版)と、llamafile実行ファイル単体の両方が置かれています。今回はモデルを外部GGUFファイルとして別途用意するので、llamafile実行ファイル単体をダウンロードしてください。

⚠️ v0.9.x系のllamafileだと、Qwen3.5などの新しいモデルアーキテクチャに対応していないためfailed to load modelエラーになります。新しいモデルを使いたい場合はv0.10.0を使うようにしましょう。ただし、v0.10.0はGPUオフロードが実質的に動作せず、CPU推論前提で使うことになります。GPUによる高速化が必要な場合には、llamafileのv0.9.x系を使用するか、llama.cppをセルフビルドするか、Ollamaを使うのが現実的のようです。バージョンアップで対応してくれるとは思いますけどね。

Step3 AIモデル(GGUF)のダウンロード

次にLLMのモデルファイルを入手します。

  1. Hugging Face にアクセス
  2. 上部メニューから「Models」をクリック
  3. 左側のフィルタで Libraries → GGUF を選択

ここからはお好みのモデルを探すという話です。ただし、USBメモリからの実行という制約上、モデルサイズには注意が必要となります。USBポータブル+CPU推論という条件だと、使用に我慢できる速度(5〜10 tokens/sec程度)が出るのは4Bクラス(量子化あり)くらいまでというのが正直な感想です。8B以上のモデルだとかなーり待たされる印象でした🥲

普段、Ollamaで使い慣れているQwen系のモデルが日本語の対応もそこそこ良いので、個人的にはおすすめです。今回はいくつかのモデルを実際に試しています。

  1. 目的のモデルページで【Files and versions】タブを開く
  2. Q4量子化版の.ggufファイルをダウンロード
  3. ダウンロードした.ggufファイルをUSBメモリに移動

今回試したモデルは以下のとおりです。

モデル ファイル名 サイズ
LFM2.5 1.2B Thinking Q4 LFM2.5-1.2B-Thinking-Q4_K_M.gguf 約700MB
LFM2.5 1.2B Instruct Q4 LFM2.5-1.2B-Instruct-Q4_K_M.gguf 約700MB
Qwen3 4B Q4 Qwen3-4B-Q4_K_M.gguf 約2.5GB
Qwen3.5 4B Q4 Qwen3.5-4B-Q4_K_M.gguf 約2.7GB
gemma 3 4B it Q4 gemma-3-4b-it-Q4_K_M.gguf 約2.5GB

1.2Bモデルなら700MB程度、4Bモデルでも2.5GB前後なので、64GBのUSBメモリなら複数モデルを余裕で持ち歩けます🤗

Step4 起動用バッチファイルの作成

ここが大事なステップかもしれません。メモ帳(Notepad)などのエディタでバッチファイルを作成します。

エディタで以下のように記述します。

run_Qwen3-4B-Q4_K_M.bat(例)

@echo off
llamafile.exe -m Qwen3-4B-Q4_K_M.gguf
pause

⚠️ pauseを入れるのを忘れないでください … pauseがないと、エラーが発生した場合にウインドウが一瞬で閉じてしまい、エラーメッセージが読めません。実際に自分もこれでハマりました。pauseがあれば「続行するには何かキーを押してください...」で止まるので、エラー内容を確認できます。

⚠️ モデルのファイル名は、USBメモリに置いた実際のファイル名と完全に一致させてください … .ggufの拡張子も含めて正確に書く必要があります。ここを誤記すると起動時にエラーになります。

このbatファイルをUSBメモリに.bat拡張子で保存します。ファイル名は後で分かりやすいようにrun_Qwen3-4B-Q4_K_M.batのようにしておくとよいでしょう。

⚠️ メモ帳で保存する際、「ファイルの種類」を「すべてのファイル」にしないと.bat.txtになってしまうことがあります。よくあるハマりポイントなので気をつけてください。

保存後、USBメモリの中身はこんな感じになるはずです。

E:\(USBメモリ)
├── llamafile.exe
├── Qwen3-4B-Q4_K_M.gguf
└── run_Qwen3-4B-Q4_K_M.bat

Step5 実行してみる

いよいよ実行です。USBメモリ内のrun_Qwen3-4B-Q4_K_M.batをダブルクリックします。

モデルがシステムメモリ(RAM)にロードされます。これはモデルサイズとPCのスペックによって所要時間が変わります。4Bクラスのモデルであれば、USB 3.0の環境であれば数十秒〜1分程度でロードが完了します。

ロードが完了すると、ターミナル上にチャットインターフェースが起動します。v0.10.0ではTUI(ターミナルユーザーインターフェース)がデフォルトで、ブラウザからもhttp://localhost:8080/にアクセスすればWeb UIを利用できます。

あとはターミナル上で直接質問を入力するか、ブラウザのWeb UIから質問を入力すればOKです。システムプロンプトやユーザー名、ボット名などはお好みで設定できますが、デフォルトのままでも問題なく使えます。

ではパフォーマンスは如何に?

実際にいくつかのモデルをUSBメモリから起動して試してみた感想ですが、CPU推論で使用に我慢できるスピード(5〜10 tokens/sec程度)が出るのは4Bクラスの量子化モデルまでという印象でした。

1.2BのLFM2.5は軽快に動きますが、生成の質はそれなり。4BのQwen3やgemma3あたりが「ポータブル環境での実用ライン」かなと感じました。Qwen3.5-4Bも動きますが、Qwen3-4Bと比べてアーキテクチャが新しい分、少し遅くなるように感じました。質を取るか速度を取るかのトレードオフかもしれません。

⚠️ 8B以上のモデルだとCPU推論ではかなり遅くなるので、今回のようなパターンに向いていません。後述しますが、v0.10.0ではGPUオフロードも現状動作しないため、使うモデルは4Bクラスまでに絞るのがおすすめです。

GPU / CPU の切り替え:挿す先のPCに合わせる

このようなLLMをすぐ動かす事ができるUSBメモリを持ち歩くということは、当然ながら挿す先のPCは毎回違うことになります。NVIDIA GPUが載っている環境もあれば、Intel内蔵GPUしかないノートPCもある。ここがポータブル運用ならではの悩みどころなんですよね。

llamafileは公式ドキュメント上、Apple Metal / NVIDIA / AMDのGPUに対応していると記述されています。しかし、v0.10.0の時点では実際にGPUオフロードが動作する環境はかなり限定的でした(私の持っている環境では少なくとも動かなかったです)。

【実測】v0.10.0のGPUサポート状況

実際に手元の環境で試した結果をまとめておきます。

環境 GPU OS 結果
ノートPC GTX 1070 Mobile(Pascal) Ubuntu 24.04 + CUDA 12.8 CUDA errorでクラッシュ
miniPC Radeon 680M(RDNA 2) Windows support for --gpu amd was explicitly requested, but it wasn't available

どちらもGPUオフロードは動作せず、CPU推論のみ使用可能という結果でした。

NVIDIA(Linux)の場合 … --gpu nvidia -ngl 999を指定するとggml-cuda.cu:97: CUDA errorでクラッシュ。-ngl 10に減らしても同様でCUDAの初期化自体が失敗しています。おそらくv0.10.0がPascalアーキテクチャ(Compute Capability 6.1)をビルドターゲットに含めていないことが原因と考えられます。llama.cppを-DCMAKE_CUDA_ARCHITECTURES="61"を指定してセルフビルドした場合はGPUが正常に認識されていたので、GPU自体の問題ではなくllamafile側の問題と推測しました。

AMD(Windows)の場合 … --gpu amd -ngl 999を指定すると「サポートが利用できない」旨のエラーで即座に終了。公式ドキュメントにはWindowsリリースバイナリにAMD向けプリビルトDLLが含まれるとの記載がありますが、v0.10.0では実際には含まれていないようです。

このあたりはちょっと残念ですね。ゲーミングPCのある環境があれば、LLMを高速に動かせると期待していたのですが…今後のアップデートでGPUサポートが改善されることに期待したいところです🥲

結論 … v0.10.0はCPU推論前提で使うのが現実的

v0.10.0のGPUサポートは公式にも「まだ全環境でテストが完了していない」とされており、実際に試してみても動作しない環境が多い印象です。現時点ではCPU推論前提で使うのが確実です。 CPU推論でもQwen3 4B Q4なら5〜10 tokens/sec程度は出るので、ちょっとした質問応答には使えます。今後のアップデートでGPUサポートが改善されることに期待ですね。

⚠️ Apple Metal(macOS ARM64)については手元に検証環境がないため未確認です。v0.10.0のリリースノートではMetal対応が明記されているので、macOS環境では動作する可能性があります。

Intel内蔵GPUについて

なお、Intel iGPUはllamafileのGPU対応対象に含まれていません。 Intel iGPUを活用したい場合は、llamafileではなくllama.cppをSYCLでビルドして使うのが現実的です。ポータブル運用の文脈ではCPU推論で割り切るのが無難です。


【補足】v0.9.x系との違いと注意点

調べてみたところ、v0.9.x系(0.9.3など)と、今回使用したv0.10.0では大きな違いがあるようです。

v0.10.0ではllama.cppのコアがゼロから再構築され、最新モデルへの追従が大幅に改善されました。Qwen3.5のビジョンモデル、ツールコール対応、Anthropic Messages API互換など、v0.9.x系では使えなかった機能が追加されています。

一方で、v0.10.0にはまだ移植されていない機能や、テストが完了していない部分もあります。

  • GPUオフロードが実質的に動作しない(NVIDIA Pascal / AMD RDNA 2で検証、いずれも失敗)
  • Stable Diffusionのコードがまだ未ポート
  • pledge() / SECCOMPサンドボックス機能が未実装
  • 一部のCLI引数がまだ動作しない

また、v0.9.x系とv0.10.0はGPUサポートとモデル対応がトレードオフの関係になっています。

v0.9.x系(0.9.3) v0.10.0
GPU対応 ○ ドキュメント上は対応(WindowsのプリビルトDLL含む) ✕ 実測で動作せず
新しいモデル △ 2025年5月までのモデル ○ Qwen3.5への対応
安定性 ○ 長期間メンテナンスされた成熟したコード △ ゼロから再構築、まだ発展途上

👉️v0.9.3をUbuntu+GTX1070mで動作しましたがGPUでの動作は問題なく行われていました。

v0.9.3で動くモデル・動かないモデル

v0.9.3(2025年5月リリース)のリリースノートを追いかけると、対応モデルはこのようになっています。

v0.9.3で動くモデル(リリース履歴より)

追加バージョン 対応モデル
v0.9.3 Qwen3、Phi-4
v0.9.2 Gemma 3、DeepSeek Distil R1、IBM Granite
それ以前 Llama 3/3.1/3.2、Qwen2/2.5、Gemma 2、Mistral/Mixtral、Phi-3 等

v0.9.3では動かないモデル: Qwen3.5、Gemma 4などの新しいアーキテクチャのモデル。

つまり、今回試したモデルで言うと:

モデル v0.9.3 v0.10.0
Qwen3-4B Q4
Qwen3.5-4B Q4
gemma-3-4b-it Q4
LFM2.5-1.2B Q4

Qwen3-4Bとgemma-3-4bは両方のバージョンで動くので、「v0.9.3でGPUを使いつつ、そこそこ新しいモデルを動かす」という選択肢もなくはないです。ただし、v0.9.3の最終更新が2025年5月なので、今後新しいモデルが出るたびに使えないものが増えていく可能性があります。

どちらを選ぶべきか

v0.9.x系はGPUサポートが長い期間をかけて作り込まれていたため、ドキュメントの記載通りにGPUオフロードが動作する可能性が高いです(未検証ですが)。GPU搭載PCでの高速化を重視し、かつ使うモデルがQwen3やGemma 3など2025年5月以前のもので固定できるなら、v0.9.3を選ぶメリットはあります。

一方で、ポータブル用途でCPU推論前提であれば、新しいモデルが使えるv0.10.0の方がメリットが大きいです。GPU高速化が必要な場合はllamafileにこだわらず、llama.cppをセルフビルドするか、素直にOllamaを使った方が良いでしょう。

⚠️ v0.9.x系を使う場合の注意点として、Qwen3.5などの新しいアーキテクチャのモデルはfailed to load modelエラーで読み込めません。 実際に自分もv0.9.x系 + Qwen3.5-9Bの組み合わせで遭遇しました。

また、v0.10.0ではモデルウェイトをバンドルした「プリビルトllamafile」も提供されています。例えばQwen3.5 0.8B Q8のllamafileはRaspberry Pi 5でもGPUなしで約8 tokens/secで動作するとのことです。Raspberry Pi 5ユーザーとしてはちょっと気になる情報ですね。ただし前述のとおりWindowsでは4GBの上限があるため、プリビルトllamafileの多くはWindowsでは使えません。

USBメモリ内の最終的なファイル構成

複数モデルを切り替えて使いたい場合はこんな構成にしておくと便利です。

E:\(USBメモリ)
├── llamafile.exe
├── Qwen3-4B-Q4_K_M.gguf
├── Qwen3.5-4B-Q4_K_M.gguf
├── gemma-3-4b-it-Q4_K_M.gguf
├── LFM2.5-1.2B-Instruct-Q4_K_M.gguf
├── run_Qwen3-4B-Q4_K_M.bat
├── run-Qwen3.5-4B-Q4_K_M.bat
├── run-gemma-3-4b-it-Q4_K_M.bat
└── run-LFM2.5-1.2B-Instruct-Q4_K_M.bat

v0.10.0ではGPUオフロードが実質的に動作しないため、GPU版バッチファイルは不要です。モデルごとにバッチファイルを1つ用意するだけのシンプルな構成でもOKです。

おわりに

USBメモリ1本でローカルLLMがオフライン実行できるというのは、やはりロマンがありますね🤗llamafile単一ファイルでどこでも動くという設計思想は、Ollamaやllama.cppとはまた違った方向性で興味深いです。 「インストール不要・オフライン・管理者権限不要」という3拍子が整ったポータブルLLM環境としては十分に面白いプロダクトです。llamafile入りのUSBメモリを1本カバンに忍ばせておくとなにかの役に立つかも?

GPUサポートの改善や対応モデルの拡充など、今後のアップデートにも注目していきたいと思います🤩🤩🤩

参考リンク