FPGA上で動くオープンソースのAI accelerator「openTPU」が公開されました。面白いのは、単に高速化の回路図を置いただけではなく、RTL、ISA、シミュレータ、compiler、profilerまでを一つのリポジトリにまとめ、しかも実機でQwen3やLFM2.5、Qwen3.5を動かしている点です。最近のAI関連の発表は「何が速いか」ばかりに寄りがちですが、このプロジェクトは「どう作ったか」「どこで時間を使っているか」まで見せています。研究寄りの好奇心にも、実装寄りの目線にも刺さる内容です。
openTPU は、AIそのものを使って設計されたオープンソースのAI acceleratorだと名乗っています。開発者は、AI agents がどこまで hardware design を進められるか、そして自分たちが作った chip で自分たちの inference を回せるのか、という問いを立てています。リポジトリの中には SystemVerilog の hardware、instruction set、bit-exact な simulator、kernel language とその compiler、さらに実機を動かす host software まで入っています。README では、Python の matmul から wire のレベルまで、AI accelerator の仕組みをひと通り追える学習用の場所でもあると説明しています。
実機は Inspur YPCB-00338 の Kintex-7 xc7k480t 搭載カードで、DDR3 は 2 チャネルです。ここで、複数の modern models を real weights のまま動かし、シミュレータと完全に同じ token を出したとしています。たとえば LFM2.5-230M は int8 で decode が device で 59.0 tok/s、wall で 52.3 tok/s、prefill は 295.6 tok/s でした。4-bit, int8 head にすると decode は 85.8 tok/s まで上がっています。Qwen3-0.6B は int8 で 21.6 tok/s、Qwen3.5-0.8B は 17.6 tok/s、Gemma 4 E2B は 4-bit, int8 head で 10.57 tok/s といった具合です。大きめのモデルでは LFM2-2.6B が int8 で 6.05 tok/s、SmolLM3-3B が 5.00 tok/s、Phi-4-mini (3.8B) が 3.99 tok/s。Qwen3.5-2B は int8 で 8.02 tok/s、4-bit 化すると 12.09 tok/s に伸びています。
ここで重要なのは、これらの数字が「だいたい動いた」ではなく、simulator と bit for bit で一致していることです。しかもカード自体が token を選ぶ decode loop でも動き、Gemma 4 の E2B では int8 と 4-bit head の両方で Hugging Face の greedy tokens と一致したと書かれています。さらに Mixture-of-experts のような、カードの 4 GiB を超えるモデルについては、expert を host storage から必要に応じて stream する仕組みも用意しています。LFM2.5-8B-A1B は 10.6 tok/s、Qwen3.5-35B-A3B は 3.95 tok/s を記録し、こちらも simulator と一致したとのことです。
このプロジェクトでいちばん目を引くのは、単に速いかどうかより、「設計したものを、その設計系ごと説明している」点だと思う。多くのFPGAやAI accelerator の話は、RTL かベンチマークのどちらかに寄りやすい。ところが openTPU は、kernel language から ISA、simulator、bitstream、host software まで一本につながっていて、どの層で何が起きたかを追える。これは教育的というだけでなく、検証可能性の面でも強い。特に「実機と simulator が同じ token を返す」と言い切れるのは、AI hardware の世界ではかなり価値があるはずだ。
一方で、ここには面白さと同時に癖もある。カードは Kintex-7 世代で、最新GPUの競争に真正面から殴り込む構図ではない。それでも LFM2.5 や Qwen3 系、Gemma 4 のような現行のモデルを動かして見せているのは、最新の勝負ではなく「設計の筋の良さ」を見せるためだと受け取れる。速度の絶対値より、DRAM traffic や prefill / decode の分離、quantization の効き方まで観察できることが肝に見える。研究用途では、こういう「中が見える性能」はかなり強い。
元記事では 4-bit weights がかなり重要な役割を持っています。FP4 values に two-level block scales を組み合わせ、4.25 bits per weight に抑えつつ、LM head は accuracy のために int8 に残す。これで bytes per token が約3分の1になり、decode speed が Qwen3.5 で 40%、Qwen3 と LFM2 で 45% 伸びたとしています。単なる圧縮ではなく、帯域の節約がそのまま速度に効いているわけです。
ここで気になるのは、今のAIハードウェアの競争が、計算性能そのものより memory bandwidth との綱引きになっていることです。openTPU の表でも DRAM while decoding は 82〜94% もの高い比率に達していて、decode がほぼ帯域律速であることが見て取れます。つまり、演算器を速くするだけでは伸びず、重みをどう置くか、どこを host に逃がすか、どこを 4-bit にするかで結果が変わる。これは最新GPUでも同じ方向の話ですが、FPGAで露骨に見えるぶん、問題の輪郭がかなりはっきりします。
ただし、4-bit にすれば何でもよいわけではありません。元記事でも、モデルごとに perplexity への影響を docs/quant.md で報告していると書かれています。つまり、速くなったぶん正確さをどれだけ払ったかをちゃんと見ている。ここを省かずに出しているのは誠実だと思う。性能向上の話は派手だが、実運用では精度劣化のほうが先に問題になるからです。
もう一つ面白いのは、host の存在感をかなり薄くしていることです。LFM2 と Qwen3 では、card が一度 compile した decode program を使い回し、位置情報は register から読み、embedding や RoPE の row もカード側で引く。logits も card が動いているあいだに stream back されるので、host が token ごとに大きく介入しない。記事では host の追加遅延が 0.17〜0.30 ms per token on omarchy、0.45〜1.3 ms on opentpu とされています。Qwen3.5 の decode でも同じ方式だが、prefill はまだ host 側で chunk ごとに compile しているようです。
この構成は、推論基盤の理想像を少し変えるかもしれないと思う。今は「大きなGPUに全部載せる」か「サーバー側でうまく分割する」発想が強いが、openTPU は、できるところまで card に寄せて、host は不足分だけ補う。Mixture-of-experts の expert を必要時だけ stream する仕組みもその延長です。大規模モデルを動かすとき、すべてを常駐させるのではなく、動的に引っ張ってくる設計は、実際のコストや配置制約に効いてくるはずです。特にエッジ寄りや組み込み寄りの環境では、この発想がそのまま価値になります。
openTPU を見ていて感じるのは、これは「デモ」ではなく、かなり本気の研究ノートに近いということです。測定条件、clock、DRAM peak、旧 image との比較、calibration 時間まで出していて、数字の置き方が雑ではありません。しかも、以前の production image と比べて decode は同等圏内、prefill は 1.3x から 2.0x 速い、起動時の calibration も host 不要で 12 秒、と差分まで書いてある。こういう書き方は、派手さより再現性を優先している印象を受けます。
個人的には、ここが一番信頼できるところだと思う。AI hardware はどうしても「速いです」「賢いです」で終わりがちだが、openTPU はその逆を行く。何をどこまで公開したか、どこで帯域を食っているか、どのモデルで何 tok/s だったかまで出している。最新の巨大GPUと比べれば地味かもしれないが、設計の見通しという意味ではむしろこちらのほうが面白い。AI agents が hardware design に入っていく未来が本当に来るのかはまだ分からない。ただ、その入口としてはかなり筋のいい答えを見せた、というのが率直な感想です。
