最近、Hacker Newsで注目を集めているプロジェクトがある。開発者が作った CanIRun.ai というサイトだ。ブラウザのWebGPU APIを使ってハードウェア情報を読み取り、どのAIモデルがローカルで動くかを教えてくれる。

サイトはシンプルだ。ページを開くだけで、GPUやメモリ帯域を自動検出し、実行可能なモデルのリストを表示する。1247 upvote、309件のコメント——これだけ多くの開発者の関心を集めたということは、確かに普遍的な悩みなのだろう。

動く ≠ 使える

サイトはSからFまでの評価を出す。基準は推定token/sだ。だがコメント欄にはすぐ「現実主義者」たちが現れた。

「3000ドルのMacBookでGPT-OSS 20Bを~16 tok/sで動かせる… それともGroqで120Bを360 tok/sで動かすか」

要約すると：高級MacBookで20Bモデルをぎこちなく動かすか、クラウドで6倍大きいモデルを30倍速く動かすか。Groqの価格設定なら、元を取るのに10年連続稼働が必要だ。

これはローカル実行に価値がないという話ではなく、境界線を理解しろという話だ。

ローカル実行の本当の価値

議論を見ると、開発者がローカルデプロイを選ぶ理由は3つある。

1. プライバシー
機密データ、医療記録、社内コード——こういうものをクラウドに送りたくない。4B-9BのQwen 3.5のような小さなモデルは、Claudeほど賢くなくても、テキスト整形や単純な分類なら十分役に立つ。

2. コスト構造の違い
クラウドAPIの隠れたコストはキャッシュ読み取りやツール呼び出しだ。agentユースケースでは1時間に数百万tokenを軽く消費する。ローカルは遅くても「token無制限」だ。

3. コントロール
量化バージョンを変えられる。temperatureを調整できる。LoRAでファインチューニングもできる。狭いドメインのタスクでは、汎用大モデルより調整済み小モデルの方が効果が良いこともある。

ハードウェアの複雑さ

コメント欄ではCanIRun.aiの限界も指摘されている。

  • MoEモデルの過小評価：GPT-OSS 20Bは実際には3.6Bのactiveパラメータのみ。速度は総パラメータではなくactiveパラメータで計算すべきだ
  • 量化バージョンの未反映：Q4_K_M、Q6_Kといった異なる量子化レベルがメモリと速度に与える影響は大きい
  • CPU offloadの欠落：llama.cppのレイヤーオフロード戦略により、「理論上は動かない」モデルが実際には動くこともある

AMD Strix Haloユーザーは、サイトでは動かないと表示されたQwen 3.5 35B-A3Bを実際には32 tok/sで動かせていると報告している。

開発者への提言

ローカルデプロイを検討するなら、この順序がおすすめだ。

  1. ユースケースを明確にする：コード補完？テキスト要約？RAG？タスクによって必要なモデルは全然違う
  2. 小さく始める：Qwen 3.5 4B/9B、Llama 3.2 3Bといった軽量モデルから試す
  3. 適切なツールを選ぶ：Ollamaが最も簡単、LM Studioが機能豊富、llama.cppが最も柔軟
  4. パラメータ数だけ見ない：MoEアーキテクチャ、量子化レベル、コンテキスト長が実際の体験に影響を与える

ローカルAIはクラウドの代替ではなく、特定のシナリオでの補完だ。CanIRun.aiの価値は、開発者に素早く概算を与えることにある。だが本当の答えは、実際にデプロイしてみないとわからない。

参考ソース