- ローカルマシンでどのAIモデルを実際に実行できるかを確認できるWebベースのツール
- ブラウザのWebGPU APIを活用してハードウェア性能を推定するが、結果は実際の仕様と異なる可能性がある
- モデルごとに**メモリ要件、トークン処理速度、コンテキスト長、実行グレード（S～F）**などを表示
- Qwen, Llama, Gemma, Mistral, DeepSeek, GPT-OSS など主要なオープンソースおよび商用モデルを含む
- ローカルでのAI実行可能性を素早く判断でき、開発者や研究者にとって有用な参考指標として活用できる
サービス概要
- CanIRun.ai は、ローカル環境で実行可能なAIモデルを探索できるWebサイト
- ユーザーは自分のブラウザでサイトを開くと、システム性能に基づいて実行可能なモデル一覧を確認できる
- 結果はWebGPU APIを通じて推定されるため、実際のハードウェア性能とは差が生じる場合がある
- 各モデルは**性能グレード（S～F）**で分類され、実行可能性と効率を直感的に把握できる
モデルのグレード体系
- グレードは S, A, B, C, D, F に分かれており、Sが最もスムーズに実行できることを意味する
- 例: NVIDIA GeForce RTX 4070 12GB を基準にした場合
- Qwen 3.5 9B、Llama 3.1 8B などは S（90/100） と表示され、快適に実行可能
- Phi-4 14B は A（70/100） で「よく動作する」
- GPT-OSS 20B、Mistral Small 3.1 24B などは D（34～39/100） で「ほとんど実行不可」
- そのほか Gemma 3 27B、Qwen 3 32B など27B以上のモデルの大半は F（0/100） で「重すぎる」と表示される
データ出典と技術基盤
- モデルデータは llama.cpp, Ollama, LM Studio から収集
- 各モデルのページには メモリ使用量、コンテキスト長、トークン速度、アーキテクチャ種別（Dense/MoE） などが詳しく表示される
活用意義
- ローカル環境でAIモデルを直接実行しようとする開発者、研究者、オープンソース利用者に実用的な参考資料を提供
- GPU性能に対するモデルサイズと効率を比較し、適切なモデル選定とデプロイ戦略の策定に役立つ
- ブラウザベースで動作するため、インストール不要ですぐにテスト可能なのが特徴
1件のコメント
Hacker Newsの意見
この2年間、ローカルモデルの実験に膨大な時間を注いできた
qwen3.5:9b のような小型モデルは、ローカルツール利用や情報抽出、組み込みアプリケーションにとても適していた
コーディング用途では、Google Antigravity、gemini-cli、あるいは Anthropic Claude のようなクラウドベースのツールのほうが効率的だった
Emacs と Claude Code をローカルで設定して100時間以上試したが、一般ユーザーには勧めない
その代わり、小さくて実用的なローカル組み込みモデルをうまく扱うのが一番おいしい落としどころだと思う
このモデルは小さいが、マルチモーダル推論能力に優れており、内部思考体系（CoT）が安定している
特に VRAM とコンテキストサイズの新しいトレードオフ構造が印象的だ — 100K トークンを 1.5GB VRAM で処理できるため、RTX 3060 でも長い会話や文書処理が可能だ
GPT-OSS-120B ではうまく動いていた Discord チャットボットが、Qwen では ツール呼び出しを真似するだけで実行しない問題 があった
結局、画像は Qwen、一般会話は GPT で処理するように分けた
ローカルのコードリポジトリ探索中、結果の 30〜50% が誤ったファイル名や関数名をでっち上げていた
KimiK2 で検証するとほとんどが間違っていた。小型モデルは良いが、信頼性には注意が必要だ
M4 MacBook Pro（128GB RAM）で ollama を使って実験中だが、まだ満足できる流れを見つけられていない
Claude Code や Codex への依存を減らしたい
このサイトは、モデルの メモリ帯域幅とサイズ を基準に性能を推定しているようだ
ただし MoE モデル（GPT-OSS-20B など）は、毎トークンで全パラメータを使うわけではないので、同じハードウェアでもより速くトークンを生成できる
GPT-OSS-20B は 3.6B のアクティブパラメータを持つため、3〜4B の密モデルに近い速度が出るが、VRAM は全体の 20B モデルサイズを要求する
知能面では約 8.5B の密モデル級と評価されている
MoE モデルの場合、メモリ帯域幅は アクティブパラメータだけ を基準に計算すべきだ
しかし実際の利用では、もっと小さいコンテキストで十分なことが多い
llama.cpp の llama-fit-params はこういう状況で役に立つ
Mixtral 8x7B のような MoE モデルでは、46.7B のうち約 12.9B だけがアクティブになる
つまり、大型モデルの品質と小型モデルの速度を同時に得られるが、モデル全体は依然としてメモリに常駐させる必要がある
canirun.ai ドキュメント
トークン生成速度は近くても、prefill 速度 は大型 MoE のほうが遅い
また speculative decoding を使う場合、小型の密モデルは最大 3 倍の高速化が可能だが、MoE モデルはほとんど恩恵がない
TFA や llmfit のような試みは良いが、自分のハードウェアでどのモデルが最も高品質なのか見つけにくいのがもどかしい
たとえば Qwen 3.5 27B Q6 @ 100k コンテキストはよく動くのに、推奨リストでは旧版の Qwen 2.5 が先に来る
自分は tok/s が 50 以上あれば十分なので、品質基準で並べ替えられるとよい
たとえば「8GB VRAM、32GB RAM で t/s ≥ 30、context ≥ 32K の高品質なコーディング用オープンモデル」なら Qwen2.5-Coder-7B-Instruct
「24GB VRAM、32GB RAM で Web リサーチ用」なら Qwen3-30B-A3B-Instruct-2507
「40GB VRAM、128GB RAM で RAG 埋め込み用」なら Qwen3-Embedding-8B
つまり、ハードウェア別の具体的なモデル推薦 が必要だ
電気代を除けばほぼ無料だが、速度と品質は落ちる
もしかして単に データプライバシー のためにローカルを好んでいるのだろうか
複数のデバイスとモデルを同時に考慮しながら 品質とリソース配分 を最適化しようとすると、複雑さが爆発する
結局、今は単純に一番大きい量子化モデルを選ぶ方式で妥協している
一般的な計算機のように正確である必要はなく、モデル制作者と利用者の目標が異なるため、欲しい結果を予測しにくい
これは単なる llmfit の Web 版 に見える
llmfit GitHub リンク
自分の M2 Max MBP（96GB RAM）でもほとんどのローカル LLM が動くと出る
思った以上に ローカル実行可能なモデル が多くて驚いた
Docker や Python より軽い代替として Rust+Wasm スタック を勧める
LlamaEdge プロジェクト
自分の RTX 6000 Pro Max-Q（96GB VRAM）は正しく認識したが、UI では 4GB と表示される
また 量子化モデル を考慮せず、フル解像度モデルしか表示しない
改善が必要だ
モバイル GPU 一覧が不十分で、CPU メモリ共有や KV キャッシュのオフロード のような戦略を理解していない
自分のシステムは Arc 750（共有 RAM 2GB）と表示されるが、実際には RTX1000 Ada（6GB GDDR6）だ
Qwen3 Coder Next、Devstral Small、Qwen3.5 4B などはほぼリアルタイムでよく動く
より大きいモデルは遅いが、トークン不足の問題はない
すばらしいアイデアだ
ただ、自分は M3 Ultra（256GB RAM）ユーザーなのに、選択肢が 192GB までしかない
モデルを選んで プロセッサ別の性能比較 もできるとよい
自分のブラウザが ハードウェア情報を Web サイトに自動提供 していることを初めて知った
サイトは自分を iPhone 19 Pro と認識しているが、実際は iPhone SE 第1世代だ
それでハードウェアを検出しているようだ
プライバシー重視ブラウザはランダムな情報を返す
M4 と M5 チップの間に 性能差がまったくないように見える のはおかしい
メモリ容量も大型モデル性能に影響していないように見える
全体的に実測データではなく 推定値ベース に見えるので、「ESTIMATE」と表示すべきだ
参考: Apple M5 Max 関連動画