本機推論
gemma4.c 以約七百行純 C 重現 Gemma 4 E2B 推論，單機 CPU 實測超越通用框架
開源專案 gemma4.c 把 tokenizer、Transformer、KV 快取、取樣及 SIMD 核心放進單一 C 檔案，毋須外部推論函式庫。作者的 Ryzen 7 7700 測試領先 llama.cpp，但成果依賴固定模型、單一 CPU 後端與專用資料配置，不能視為通用效能結論。
社群專案 [gemma4.c](https://github.com/ryanssenn/gemma4.c) 用約七百行純 C 實作 Gemma 4 E2B 的完整文字推論路徑，涵蓋 tokenizer、模型張量、Transformer、KV cache、取樣與 CPU 核心。執行階段不依賴 PyTorch、GGML 或其他推論函式庫；Python 只在匯出權重及數值驗證時使用。這使開發者能從 `main()` 開始，逐步追蹤提示如何經過記憶體配置、矩陣運算與注意力，最後成為下一個 token。
專案先以 `exporter.py` 把 Hugging Face checkpoint 轉成執行器預期的固定二進位布局。矩陣權重採 int8、比例因子採 FP16，線性層輸入亦動態量化成 int8，其餘 activation 保持 float32；模型檔約 5GB，建議至少 8GB RAM。核心使用 OpenMP、AVX2，並在可用時啟用 AVX-512 VNNI，因此仍要求相符的 x86 CPU 與編譯工具鏈，並不是跨架構的可攜式最小實作。
作者在 AMD Ryzen 7 7700 上以十二次正式測量比較，報告 gemma4.c 的 512-token prefill 約為每秒 633 token、128-token decode 約為每秒 25 token；同一測試中的 llama.cpp Q8_0 分別約為 262 與 23 token。數值驗證則以 WikiText-103 的 2,388 個位置對照 Transformers BF16 參考輸出，top-1 logits 一致率為 96.5%，平均 KL divergence 為 0.005207。這些結果顯示高度專用的資料布局與核心融合，能消除通用圖調度器的部分成本。
不過，[社群討論](https://www.reddit.com/r/LLMDevs/comments/1w0r1ro/i_implemented_a_modern_llm_runtime_in_700_lines/)也點出速度來自「刪除通用性」：它只支援一種模型架構、一套量化格式及 CPU 後端，沒有動態圖、GPU、批次服務、廣泛取樣器或多模型相容層。下一步值得觀察的是其他硬體能否重現數字、長上下文下的 KV 記憶體行為，以及專案在加入第二種架構後，是否仍能保持可讀性與效能。