本機推論
gemma4.c、約700行の純粋なCでGemma 4 E2B推論を再現、単一マシンのCPU実測で汎用フレームワークを上回る
オープンソースプロジェクトのgemma4.cは、tokenizer、Transformer、KV cache、sampling、SIMD kernelを単一のCファイルに収め、外部の推論ライブラリを必要としない。作者によるRyzen 7 7700でのテストではllama.cppを上回ったが、この成果は固定モデル、単一のCPU backend、専用のデータレイアウトに依存しており、汎用的な性能評価とは見なせない。
コミュニティプロジェクトの[gemma4.c](https://github.com/ryanssenn/gemma4.c)は、約700行の純粋なCでGemma 4 E2Bの完全なテキスト推論パスを実装している。tokenizer、モデルtensor、Transformer、KV cache、sampling、CPU kernelまでを網羅する。runtimeはPyTorch、GGML、その他の推論ライブラリに依存せず、Pythonはweightのexportと数値検証にのみ使用される。これにより開発者は`main()`から始め、promptがメモリ割り当て、行列演算、attentionを経て、最終的に次のtokenになるまでを段階的に追跡できる。
プロジェクトではまず、`exporter.py`を使用してHugging Face checkpointをexecutorが想定する固定バイナリレイアウトへ変換する。行列weightにはint8、scale factorにはFP16を採用し、linear layerへの入力も動的にint8へquantizationする一方、その他のactivationはfloat32のまま維持する。モデルファイルは約5GBで、少なくとも8GBのRAMが推奨される。kernelはOpenMPとAVX2を使用し、利用可能な場合はAVX-512 VNNIも有効にする。そのため、対応するx86 CPUとコンパイラtoolchainが必要であり、アーキテクチャをまたいで移植可能な最小実装ではない。
作者はAMD Ryzen 7 7700上で12回の正式測定を行い、gemma4.cでは512-token prefillが約633 tokens/s、128-token decodeが約25 tokens/sだったと報告している。同じテストにおけるllama.cpp Q8_0は、それぞれ約262 tokens/sと23 tokens/sだった。数値検証では、WikiText-103の2,388箇所についてTransformers BF16の参照出力と比較し、top-1 logitsの一致率は96.5%、平均KL divergenceは0.005207だった。これらの結果は、高度に特化したデータレイアウトとkernel fusionによって、汎用graph schedulerに伴うoverheadの一部を排除できることを示している。
ただし、[コミュニティでの議論](https://www.reddit.com/r/LLMDevs/comments/1w0r1ro/i_implemented_a_modern_llm_runtime_in_700_lines/)では、この速度が「汎用性を削除すること」によって得られているとも指摘されている。対応するのは1種類のモデルアーキテクチャ、1つのquantization format、CPU backendのみで、dynamic graph、GPU、batch serving、幅広いsampler、複数モデル向けの互換レイヤーは備えていない。今後の注目点は、ほかのhardwareでも同じ数値を再現できるか、long contextにおけるKV cacheのメモリ挙動がどうなるか、そして2種類目のアーキテクチャを追加した後も可読性と性能を維持できるかどうかだ。