ローカルでLLMを動かす選択肢として、これまでOllamaがほぼ定番扱いだった。しかしUCバークレーが公開した「FreeToken」は、その前提を崩しかねないスペックを持っている。8GBのGPUで35Bクラスのモデルが動き、速度はOllamaの2〜4倍というのが開発チームの主張だ。この記事では、FreeTokenの仕組みと実際の数字、そして「自分のPCでAIを動かしたい」と考えている会社員にとって何が変わりそうかを整理します。
公開された数字を見てみると
開発チームが示したベンチマーク結果から見ていく。Qwen3.6-35Bというモデルが8GBのGPUで毎秒39.3トークンを出力している。35Bというのはパラメータ数（モデルの規模感を示す単位）で、簡単に言えば「かなり賢いAI」のクラスだ。通常、このクラスのモデルを16ビット精度で動かすには70GB近くのメモリが必要になる。4ビットに量子化（精度を落として軽量化すること）しても18GB前後かかる計算なので、8GBのGPUで動くという数字は額面通りに受け取れば驚異的な数値と言える。
ほかに公開されたデータも見ておくと、DeepSeek-V4-Flash 284Bというさらに大きなモデルが32GBのGPUで毎秒22トークン、GLM-5.2 753Bという超大型モデルが96GBのGPUで毎秒14.9トークンを出している。Ollamaとの速度比較では2〜4倍という数字が出ており、同じハードウェアでこれだけの差が出るなら、ローカルAI環境を持っている人にとっては無視できない話になる。
なぜ「8GBのGPUで35Bが動く」のか
ここがFreeTokenの核心部分で、モデルの構造に着目した設計になっている。先に挙げた3つのモデルはいずれも「MoE（Mixture of Experts＝専門家の混合）」と呼ばれるアーキテクチャを採用している。MoEというのは、モデル全体をいくつかの「専門家」（サブネットワーク）に分けておき、入力された質問に応じて必要な専門家だけを呼び出す設計のことだ。たとえば料理の質問が来たら料理担当の専門家、プログラミングの質問が来たらコード担当の専門家を動かす、というイメージに近い。
この構造の面白いところは、モデル全体の重みは大きくても、一度に使う重みは全体のごく一部で済むという点にある。FreeTokenはこの性質を利用して、使わない専門家の重みをメモリに載せずに必要なときだけ読み込む仕組みを実装していると見られる。全体を70GBのメモリに押し込む代わりに、実際に動くサブネットワークだけをGPUのメモリに乗せることで、8GBという制約の中でも35Bクラスのモデルを動かせるようにしている。速度面での向上も同じ方向の最適化から来ていて、使わない計算をスキップすることで処理が速くなっている。
OllamaとFreeTokenの使い分けはどうなるか
現時点で整理できる範囲で、両者の違いを比較してみる。
| 観点 | Ollama | FreeToken |
|—|—|—||
| 対応モデル | MoE以外も幅広く対応 | 現状はMoEアーキテクチャが主な対象 |
| セットアップのしやすさ | GUIやCLIが充実、導入が容易 | 研究公開段階、実用性は未検証部分あり |
| 推論速度 | 標準的 | MoEモデルで2〜4倍（開発チーム発表） |
| メモリ効率 | 量子化に依存 | MoEの特性を活かした独自最適化 |
| コミュニティ | 大規模、日本語情報も豊富 | 公開直後、情報はほぼ英語 |
この表から判断すると、使うモデルがMoEアーキテクチャかどうかが分岐点になりそうだ。DeepSeekやQwen3などMoE系のモデルを積極的に使っている人なら、FreeTokenが選択肢に入ってくる。一方で、密な構造のモデル（LlamaやMistralなど従来型のアーキテクチャ）を中心に使っている人は、当面はOllamaのほうが安定している。ただしFreeTokenが研究リリースの域を出てコミュニティ実装が進めば、対応モデルの幅も広がる可能性がある。
実際の業務シーンで考えてみる
たとえば、製造業で品質管理の文書作成をしているとする。社内の設計書や仕様書に含まれる機密情報を外部のクラウドサービスに送ることに社内のルールで制限があるケースは珍しくない。そういう状況でローカルLLMは現実的な選択肢になるのだが、問題は「性能の良いモデルを動かすには高価なGPUが必要」という壁だった。FreeTokenが想定通りの性能を実際の環境で発揮するなら、手元にある8GBのGPUでもそれなりのモデルが動くようになり、この壁が下がる可能性がある。
別の例として、社内向けのRAGシステム（社内文書を検索しながら回答するAIの仕組み）を個人で試したい情シス担当が、手元のゲーミングPCを使って実験できるかどうか、という場面を考えてもよい。クラウドAPIを使えばすぐ試せるが、月々のAPI費用が読めないため上長への稟議が通りにくいことがある。その点、ローカルで動かせれば費用が固定されるため、試験的な導入を通しやすくなる。この観点でもFreeTokenの軽量化の方向性は、実用的な意味を持ちうる。ChatGPTのAPIを使ったRAG構築については別途まとめているので、クラウドとローカルの使い分けを考えている人は参考にしてほしい。
「研究公開」と「使える」の間にある距離感
正直に言えば、FreeTokenはまだ「研究成果の公開」段階にある。UCバークレーの研究チームが出した数字は再現実験が進んでいる段階ではなく、独立した検証はまだ少ない。Ollamaが今のポジションを得たのは、コミュニティが何年もかけて動作確認を積み重ね、日本語の解説記事や対処法が溜まったからでもある。FreeTokenが同じ道を歩むには、時間と実ユーザーの検証が必要になる。
ただ、UCバークレーというリソースのある大学が出してきたオープンソースプロジェクトで、しかも技術的な根拠がMoEの特性という明確な理論に基づいているのは、単なる話題先行ではないことを示している。プロンプトエンジニアリングガイドでも触れているように、AIツールの評価は「動く環境での実測」が最終的な判断材料になる。まずは公式のGitHubリポジトリで動作要件を確認し、自分の環境が対象に当てはまるかを見るのが現実的なスタートラインだ。
まとめ
FreeTokenが示しているのは、ローカルLLMの限界がハードウェアの性能だけで決まるわけではない、という点だ。モデルのアーキテクチャを利用した最適化によって、今持っているGPUでもできることが変わる余地がある。すぐに使えるかどうかはコミュニティの成熟度次第だが、「8GBのGPUで35Bが動く」というラインが現実になってくるなら、AI活用のハードルは今後さらに下がっていく可能性がある。あなたの手元にある環境で、ローカルAIという選択肢がどこまで現実的かを、改めて考えてみる価値はありそうだ。
