古いタブレットやTV बॉक्स、そして十分にメモリがあるとは言えないスマートフォンで、思ったより大きな language model を走らせる。そんな無茶にかなり本気で取り組んだ GitHub リポジトリが公開されている。単に「動きました」で終わらず、どうやってメモリを削り、どこからモデルを読み込み、どの端末でどの速度が出たのかまで詰めているのが面白い。AI をクラウドで使うのが当たり前になった今だからこそ、手元の古い機械をどこまで使い切れるのかが見えてくる。
このリポジトリは、smolmaxxing という名前の通り、「できるだけ小さな端末で、できるだけ大きな LLM を動かす」ことを目指した実験集だ。ベースは llama.cpp で、そこに複数の patch を当てている。狙いは単純で、CPU、RAM、flash storage が余っているのに普段は眠っている古い端末を、ローカル推論の機械として再利用することだという。しかも、ここに載っている数字はすべて端末上で実測したものだと明記されている。
公開されている結果は、Xiaomi TV Box S (3rd Gen)、iPad Air (2013)、OnePlus Nord CE 2 (2022) の3台分。TV box は Amlogic S7D の 4× Cortex-A55、RAM は 1.9 GB だが実際に使えるのはおよそ 1 GB。Android 14 で root なし。iPad Air は Apple A7 の 2 core、RAM 1 GB で使えるのは約 700 MB、iOS 12.5.7 で jailbroken。OnePlus のスマホは MediaTek Dimensity 900、2× Cortex-A78 + 6× A55、RAM 7.4 GB だが空きは約 3 GB、Android 13 で root なし。
それぞれで「日常的に使うモデル」と「限界まで攻めた最大モデル」が示されている。TV box では Qwen3.5-2B が 7.7 tok/s、最大では Ling-mini-2.0 の 16B を 5.1 tok/s で動かした。iPad Air では Bonsai-1.7B (1-bit) が 24〜26 tok/s、最大は同じく Ling-mini-2.0 16B で 2.6〜4.5 tok/s。スマホでは Qwen3.6-35B-A3B が 4.9〜5.7 tok/s、最大は Qwen3-Next-80B-A3B を 2.6〜3.1 tok/s で動かしている。さらにこの2台の 1 GB クラスの端末では 8B や 16B の mixture-of-experts model を扱い、スマホ側では 35B や 80B まで行っているのが特徴だ。
仕組みは4つある。ひとつは chip 向けに作った kernel で、TV box の Cortex-A55 向けには 1-bit lookup-table kernel や repacked 2-bit、ternary 形式を使い、A7 向けにも dot-product instructions がない前提の版を用意した。ふたつめは RAM 削減で、あまり使われない語彙の output rows を落としたり、TV では launcher や Google services を止める headless mode を使ったりする。みっつめは mixture-of-experts model の expert を flash からページングする方法で、よく使う expert だけ RAM に置き、残りは必要に応じて flash から読み込む。これで 1 GB の端末でも 8B や 16B を回せるという。最後は dense model 向けの streaming で、RAM より大きいモデルを flash の速度いっぱいで流し込む発想だ。
導入手順も用意されている。TV box や別の ARMv8.2 Android device なら docs/tv-box-setup.md、jailbroken iPad on iOS 12 なら ipad-air/README.md、8 GB RAM の Android phone なら docs/phone.md に沿ってセットアップする。モデルファイルは Hugging Face 由来で、TV box と iPad のものは patch 済み llama.cpp が必要、スマホ用は patch がなくても読み込めるが、速度面は expert pager が効く。README には docs/how-it-works.md、docs/models.md、docs/lessons.md、EXPERIMENT.md なども並び、165回の実験と失敗例まで含めて記録している。
まず驚くのは、「古い端末で動いた」という話に終わっていないことだ。多くの実験は、モデルを小さくしました、量子化しました、で止まる。だがこの repo は、CPU の癖、メモリの少なさ、flash の読み出しまで含めて設計し直している。つまり、単に省メモリ化したのではなく、端末の弱点そのものを前提にアルゴリズムを変えている。ここがただの趣味の検証と違うところだと思う。
特に面白いのは、Mixture-of-Experts を flash からページングする発想だ。通常は「大きいモデルは大きい RAM が必要」という理解で止まりやすいが、実際には毎トークンで全 expert を使うわけではない。ならば、頻繁に使う部分だけを手元に置けばよい、というのはかなり素直な解法だ。もちろん万能ではない。flash の速度やアクセスパターンに強く依存するはずで、端末によって体感は変わる。それでも、巨大なモデルを完全に RAM に載せる以外のルートを見せた意味は大きい。
ただ、数字をそのまま眺めると、ここには明確な限界もある。iPad Air で 16B を 2.6〜4.5 tok/s、スマホで 80B を 2.6〜3.1 tok/s というのは、研究としては面白いが、日常の対話用途で快適かというと微妙だ。短い返答なら我慢できても、長い生成や複数回のやり取りでは待ち時間が目立つはずだ。TV box の 16B で 5.1 tok/s も同様で、実験としては見事でも、誰もがこれでローカル AI に移るとは思えない。
だからこの repo の価値は、「クラウドの代わりになる」ことより、「端末の限界をどこまで押し広げられるか」を可視化した点にあると見たほうが自然だと思う。速度が遅いから失敗、ではない。むしろ、どの規模なら辛抱できる速度に落ち着くのか、その境目を測っている。ローカル推論の議論はつい GPU や最新 Mac に寄りがちだが、こうした古い端末の実測は、もっと地味で、でも現実的だ。
この手の成果が刺さるのは、最新スペックを追う層より、眠っている端末を何かに使いたい人だろう。家にある古い Android TV box や、捨てずに残してある iPad、空き容量の少ない中古スマホは、普段はただの荷物になりがちだ。そこに local LLM の居場所を与えると、学習用のサーバー、簡易チャット端末、あるいはオフライン環境での試験機として再利用できる。用途は限られるが、廃棄されるよりずっと健全だ。
一方で、こうした再利用が広がるには、コミュニティ側の面倒見がかなり重要になると思う。README にセットアップ、モデル、失敗ログまで揃えているのはその点で良い。端末ごとに事情が違うローカル推論では、再現手順があるかどうかで価値が決まるからだ。逆に言えば、こういうプロジェクトは一部のマニアが持つ技術デモで終わる危険もある。だからこそ、数値だけでなく、どう再現できるかを丁寧に残していることに意味がある。
この repo を見ていると、ローカル AI の未来は単に「より大きなモデルを載せる」方向だけではないと感じる。むしろ、端末ごとの制約に合わせて、kernel を変え、語彙を削り、expert を分割し、flash を活用する方向に進むのではないかと思う。クラウド前提の時代でも、オフライン動作、プライバシー、低コスト、余っている機械の再活用といった需要は消えないからだ。
ただし、こうした最適化はモデルそのもの以上に実装の質を問う。llama.cpp を patch して延命させるやり方は強力だが、別の chip や別の OS に移った途端にまた作り直しになる可能性がある。だから本当に広く使われるには、個別端末専用の職人芸から、少しずつ共通化された仕組みに落とし込めるかが鍵になる。今回の smolmaxxing は、その入口をかなり具体的に示した試みだと思う。
