巴西工程師用 AI 設計 AI 加速器 openTPU 在 300 美元 FPGA 上跑 Qwen3.5 與 LFM2.5
編按:本文綜合整理自 GitHub 上的 openTPU 專案 README、Hacker News 討論串、lavx.hu 報導、auto-arch-tournament 部落格文章,並加入 Siami 編輯部觀點與分析。原文為英文,本篇為繁體中文編譯版。
GitHub 上一個名為 openTPU 的開源專案,24 小時內突破 213 顆星、在 Hacker News 拿到 215 分與 234 則留言,標題只有一句話:「An open-source AI accelerator, developed by AI」——由 AI 設計的開源 AI 加速器。它的作者是巴西弗洛里亞諾波利斯的開發者 Felipe Sens Bonetto,Twitter 帳號 @reasoningTokens。整個加速器從 RTL 硬體描述、指令集、位元級精確的模擬器、kernel 編譯器,一路到驅動 PCIe 卡的軟體棧,全部由 AI 代理人設計,而且同一張晶片已經能跑 Qwen3、Qwen3.5、LFM2.5、Gemma 4、SmolLM3 與 Phi-4-mini 等現代語言模型。
背景:先有 CPU 專案,才有 AI 加速器
openTPU 不是 Bonetto 的第一個專案。2026 年 4 月到 6 月,他先用同一套方法做了一個姊妹專案 auto-arch-tournament:把 Karpathy 的 autoresearch 自主研究迴圈,套用到一個 5 級 in-order 的 RV32IM RISC-V CPU 核心(SystemVerilog 撰寫)。在 9 小時 51 分鐘的牆鐘時間內,AI 代理人提出 73 個微架構假設,只有 10 個通過驗證關卡被合併進主分支。結果:fitness 指標提升 92%,跑到 2.91 CoreMark/MHz,比人類寫的 VexRiscv 參考線(2.30)高出 26%,而且 LUT 數量少 40%。這套「提假設 → 寫實作 → 真實硬體驗證 → 留下有效的」方法,套用到 AI 加速器上,就成了 openTPU。換句話說,openTPU 是 auto-arch-tournament 哲學的「那晶片真的能跑嗎」延伸題。
專案結構:五層棧,單一 monorepo
openTPU 的 README 開門見山:「everything lives in a single monorepo」。整個加速器分五層,每層小到可以從頭讀完:
olkernel 語言:一個小型的 Python 內嵌語言,用來寫矩陣乘法、attention 與整層模型。Kernel 加上@ol.jit裝飾器,就被編譯器降到 otpu 指令集。- ISA:每道指令 8 個 32-bit 字。包括 DMA、int8 矩陣單元、fp32 向量單元、以及一個 quantizer。沒有快取、沒有 out-of-order 排程;每一筆資料搬移都是一道指令,所以 trace 完全解釋速度從哪裡來。
- 位元級精確的 ISA 模擬器(Python):這是規格書。同樣的位元流從模擬器流到 RTL、再流到 FPGA bitstream。
- SystemVerilog RTL:在
rtl/底下,頂層模組是rtl/top/otpu_top.sv。目前生產版本的映像檔跑在 Xilinx Kintex-7 xc7k480t(Inspur YPCB-00338 礦卡)上,133.33 MHz,兩條 DDR3 通道,4 欄 systolic 矩陣單元。 - 主機軟體:
otpu-chat(與支援模型互動對話)、otpu-smi(單元使用率、溫度、DRAM 頻寬)、otpu-lens(從 RTL、模擬器或實體卡錄製執行過程,在瀏覽器展開成 roofline、時間軸、每道指令的表格)、otpu-selftest與otpu-diag。一個 kernel 寫起來幾乎像虛擬碼:
from opentpu import language as ol
@ol.jit
def mlp(h, gamma, w_gate, w_up, w_down, out, eps):
x = ol.load(h)
xs = ol.quantize(rmsnorm(x, ol.load(gamma), eps))
g = ol.dot(xs, w_gate)
u = ol.dot(xs, w_up)
a = ol.all_gather(silu(g) * u)
y = ol.all_gather(ol.dot(a, w_down))
if ol.program_id() == 0:
ol.store(out, x + y)
實體卡上的數字:與模擬器位元級完全一致
README 公布 10 個模型的 benchmark,全部用 tools/qual/perf.py 在實體卡上量測(512 token prompt 之後取 64 個 greedy decode token,主機 argmax 在迴圈中)。DRAM 頻寬從卡自己的計數器直接讀出。
| 模型 | 權重量化 | Decode(裝置) | 解碼時 DRAM 流量 |
|---|---|---|---|
| LFM2.5-230M | int8 | 59.0 tok/s | 14.5 GB/s(峰值 85%) |
| LFM2.5-230M | 4-bit,int8 head | 85.8 tok/s | 14.1 GB/s(82%) |
| Qwen3-0.6B | int8 | 21.6 tok/s | 14.4 GB/s(84%) |
| Qwen3-0.6B | 4-bit,int8 head | 31.3 tok/s | 13.9 GB/s(82%) |
| Qwen3.5-0.8B | int8 | 17.6 tok/s | 14.5 GB/s(85%) |
| Qwen3.5-0.8B | 4-bit,int8 head | 24.5 tok/s | 14.1 GB/s(83%) |
| Qwen3.5-2B | 4-bit,int8 head | 12.09 tok/s | 15.8 GB/s(92%) |
| Qwen3.5-4B | 4-bit,int8 head | 5.88 tok/s | 15.7 GB/s(92%) |
| LFM2-2.6B | 4-bit,int8 head | 10.96 tok/s | 15.8 GB/s(93%) |
| SmolLM3-3B | 4-bit,int8 head | 8.74 tok/s | 15.7 GB/s(92%) |
| Phi-4-mini (3.8B) | 4-bit,int8 head | 6.56 tok/s | 15.8 GB/s(92%) |
| Gemma 4 E2B | 4-bit,4-bit head | 12.14 tok/s | 15.5 GB/s(91%) |
README 反覆強調:每一組設定都跟模擬器在每個位置、每個 token 完全相符。卡不是「跑出近似結果的黑盒子」,而是跟 Python 參考實作位元級精確一致——這是開發者眼中真正的工程成就。
4 位元權重:不犧牲 LM head
專案內建 4-bit 量化方案,採用 FP4 數值搭配兩級 block scale,每個權重 4.25 bit,但 LM head 保留 int8 以維持準確率。這個方案把每個 token 的位元數砍掉約 1/3,並把 decode 速度提升 40%(Qwen3.5)到 45%(Qwen3、LFM2),代價是 perplexity 略增,README 附上每個模型的 perplexity 成本。主機端幾乎被旁路:對 LFM2 與 Qwen3 來說,卡上跑著一個一次編譯完成的 decode 程式,從暫存器讀取 position,自己查 embedding 與 RoPE;logits 在卡還在算的時候就串流回主機——主機每個 token 只多花 0.17 到 0.30 ms(omarchy 機器)/ 0.45 到 1.3 ms(opentpu 機器)。Qwen3.5 的 decode 也走同樣路徑,prefill 則仍由主機預先編譯每個 chunk 的程式再丟給卡。
MoE 從主機串流:4 GiB DRAM 跑 35B 模型卡只有 4 GiB DRAM,更大的模型從主機串流 expert。卡負責每個 token 的 routing 與 expert 計算,expert 放在 per-layer slot。主機只把缺失的 expert 從 pool file 複製到 slot,速度由 PCIe 鏈路決定。2026-10-01 用 build B 量測,4-bit expert、int8 head:
- LFM2.5-8B-A1B(85 億參數,啟動 17 億):10.6 tok/s,slot 命中率 98.5%,每個 token 串流 5.2 MB。
- Qwen3.5-35B-A3B(347 億參數,啟動 30 億):3.95 tok/s,slot 命中率 62%,每個 token 串流 153 MB,PCIe 1.41 GB/s。兩個都跟模擬器位元級完全一致。
自主研究迴圈怎麼跑
README 對方法論輕描淡寫,但 Bonetto 先前在 auto-arch-tournament 的部落格文章與 repo 講得很清楚。三個 slot 平行跑,每一輪:
- 假設代理人(hypothesis agent):寫一個 YAML 描述微架構變更(例如「compressed resetless I-fetch replay tags」)。
- 實作代理人(implementation agent):在獨立的 git worktree 編輯 RTL。
- 評估管線:Verilator lint → yosys 合成 → cocotb 單元測試 → riscv-formal → Verilator cosim 對 Python ISS → 3 顆種子 FPGA place-and-route → CoreMark。第一個失敗就 short-circuit 標記為
broken: <step>: <stderr tail>。 - 書記代理人(scribe agent):把一條 bullet 蒸餾進
LESSONS.md,下一輪的假設代理人就會讀到上一次為什麼失敗。
表現高於當前冠軍的最高分 slot 才合併;其他 worktree 銷毀,log 寫入,進入下一輪。Orchestrator 永遠不直接合併進
main,每個核心的演進是一條 PR diff:git push -u origin core-<name> && gh pr create --base main。整套工具鏈跑在 macOS arm64,用 OSS CAD Suite(yosys、nextpnr-himbaechel、sby、bitwuzla)、Verilator 5、riscv-none-elf 交叉編譯器。Codex 是預設 coding agent,Claude Code 透過AGENT=claude切換。Orchestrator 會把commit.gpgsign設成false,避免背景跑時被 1Password 生物辨識卡住。
Hacker News 反應
HN 討論串(item 49980715)截至撰稿已有 215 分、234 則留言。重點留言:
- fsbonetto(原作者):「After using AI to develop RISC-V CPU cores, the same technique was used for developing openTPU. An open source AI inference engine. It’s able to run most of the modern models like Qwen 3.5, Gemma 4, and many others.」
- skybrian:「This seems to be running on an FPGA board that costs ~$300? Anyone know more about the hardware?」——答案是肯定的,Inspur YPCB-00338(Kintex-7 xc7k480t)礦卡超額供應,在 AliExpress 上 €80 到 $300 都有。
- pcarolan:「Why aren’t the labs burning their frontier models into chips already? Seems like the performance gains and cost per request would be worth it.」——還沒人回答,但隱含的問題是:AI 設計的矽晶片最終會不會吃掉 Nvidia 的午餐?
- xg15:「‘Recursive self-improvement will kill us all!’ Also: here is our recursive self-improvement hard at work…」
- bitwize:「Colossus is building Colossus II.」——一句話呼應 Anthropic 內部自研 AI 叢集的故事。
- athrowaway3z:「I haven’t really dug into the results yet, but my guess is that a SOTA model has been able to produce an accelerator that runs a model since around December. The obvious next step is to get enough memory throughput to run that SOTA model itself so that it develops its own hardware.」
另一邊 Reddit 的 r/FPGA 也有一篇 「OpenTPU: A learning FPGA AI accelerator project running Qwen 3.5」 在發燒,留言者普遍認為這個專案對開源加速器來說「異常有文件」。
🚨 為什麼這件事重要
編按:以下為 Siami 編輯部分析,與原文事實分開。這不是「又一個 TPU 開源複刻」。UC Santa Barbara ArchLab 在 2024 年就發布過 OpenTPU,是 Google 第一代 TPU 的 Python 模型,目的是保存已淘汰加速器設計的知識。哈佛圖書館創新實驗室在 2026 年 6 月還為它寫過一篇專欄。但沒有一個能跑現代 LLM。
Bonetto 的 openTPU 不同之處在 agentic design loop——同一個 AI 既提議、驗證、實作整個架構,最後還跑在這個架構生產出來的晶片上。這正是黃仁勳在 2024 年 2 月講的 「literally, none of our chips are possible today without AI」 的開源對照版——只是由巴西一位開發者,用一張 300 美元的 FPGA 礦卡、Apache 2.0 授權做出來。整個故事最尖銳的一句話藏在 README 末段:「the TPU started able to produce only a few tokens per second and through a recursive loop… it now runs the models that helped design it.」——那顆 TPU 從一開始只能每秒產出幾個 token,經過遞迴迴圈,現在能跑當初設計它自己的那些模型。這句話是 openTPU 給整個 AI 硬體圈丟出的真問題:AI 設計 AI 的硬體,到底是「在 €80 FPGA 上的聰明展示」,還是「AI 設計 AI」這件事的硬體初稿?
🚨 數據解讀與質疑
編按:以下為 Siami 編輯部獨立觀察,引用事實、保留質疑。
- 沒有「人類設計」對照組。 README 說「10 個現代模型、真實權重、位元級精確」。它沒說「這裡有一個手寫矩陣單元跑同樣工作負載」。少了這個對照,「AI 設計」說的是設計流程的故事,不是結果本身比手寫更好的故事。
- 整體 DRAM-bound。 卡讀到 DDR3-1066 峰值的 82–85%。剩餘 15% 是優化空間。目前映像檔在 133.33 MHz 收斂,時序餘量只剩 0.032 ns。
- Qwen3.5 的 prefill 仍受主機限制。 Decode 路徑用一個預先編譯的程式常駐卡上,主機 argmax 在迴圈中。Prefill 則是主機提前編譯每個 chunk 的程式,再丟給卡——更大的 prefill context 需要更聰明的 kernel 編譯器。
- 沒有對 int8 矩陣單元做形式驗證。 riscv-formal 把 CPU 設計的關卡守好;矩陣單元的驗證方式是跑模型、比對與模擬器每個 token 的相等性,是經驗式而非形式化的驗證。
- 10 個模型在 Kintex-7 上的速度比不上消費級 GPU,但這不是重點。 重點是同一張卡、同一條工具鏈、同一套量化方案,能在 300 美元硬體上跑 Qwen3.5-2B、Gemma 4 E2B、Phi-4-mini 等模型——而且跟模擬器位元級精確一致。
還缺什麼
README 對下一步很坦白。Decode 受 DRAM 限制,prefill 受矩陣單元乘法率限制。專案歡迎貢獻者——repo 用 Apache 2.0 授權,PR 開放,「大部分工作只需要 Python 與 Verilator,不需要 FPGA」。對整個 AI 硬體世界來說,openTPU 丟出的問題是:「AI 設計 AI 的硬體」這件事,是 300 美元 FPGA 上的聰明展示,還是 Nvidia、Google 應該開始擔心的早期訊號?
參考資料
- openTPU repo — github.com/FeSens/openTPU(Apache 2.0,撰稿時 213 顆星)
- auto-arch-tournament — github.com/FeSens/auto-arch-tournament,驗證方法論的前作 CPU 專案
- HWE Bench 排行榜 — hwebench.com,LLM 設計 RISC-V CPU 的即時榜
- HWE-Bench 論文 — Cui 等人,HWE-Bench: Benchmarking LLM Agents on Real-World Hardware Bug Repair Tasks,arXiv:2604.14709
- 〈An AI accelerator built by AI now runs Llama and Qwen models on a PCIe card〉 — news.lavx.hu,Sofia Ricci,2026-10-06
- Hacker News 討論串 — news.ycombinator.com/item?id=49980715
- Felipe Sens Bonetto — github.com/FeSens,巴西弗洛里亞諾波利斯,Twitter
@reasoningTokens - Inspur YPCB-00338(Kintex-7 xc7k480t)bring-up 筆記 — controlpaths.com 與 Chester-Gillon 的逆向工程 gist
網友熱門留言 (8)