From Transformer to Chip：將 NanoGPT 落地到 Ultra Low Power RISC-V 的工程歷程

January 4, 2026

在資源有限、工具鏈地獄與兩週時程下，將 Transformer 部署到極低功耗晶片的完整歷程。

Transformer on Chip

Transformer on Chip

2026 年 01 月 04 日 · 閱讀時間約 12 分鐘

前言

這不是一個「訓練了超強大模型」的故事，也不是一個「加速器跑出幾十倍效能」的故事。這是一段在資源限制、極短時程下，把 Transformer Model - GPT2 部署進 Endpoint 低功耗等級晶片裡的歷程。

起點：為了硬體加速而生的軟體旅程

最初，這項研究源自公司正在開發的 Compute In Memory 神經網路硬體加速器。CIM的核心價值在於，將運算與記憶體靠得極近，降低資料搬移成本，從架構層面解決能耗、運算時間瓶頸，特別適合深度學習這類 Memory-bound Workload。

為了能在硬體尚未完全成熟前，仍然「看得見、摸得到」CIM 的價值，公司希望有一個 Reference Workload / Golden Model，能夠：

  • 對齊未來CIM的運算模式
  • 能在公司現有產品平台的 Ultra Low Power RISC-V SoC 上跑起來
  • 同時具備Demo價值，展示 Design House 也具備 AI & Hardware & Software co-design 的技能樹

於是，任務落到了我身上。

時間壓力

事情真正變得困難，是在時間被「鎖死」的那一刻。公司在 2026 年 1 月 CES 有一場工程展示，展示上述提到的三個重點，而我拿到「確定要參展CES Demo」的時間點，只剩兩週。一人作業、沒有平行方案、沒有「跑不起來就算了」的空間。這不是研究型的題目，而是交付導向的工程任務。

技術路線選擇

要 Demo 何種模型才能有效展示我們的工程能力，這個任務也落在我身上。經充分研究後，選擇 NanoGPT 當作本次開發的起點：

  • NanoGPT，為 Andrej Karpathy (OpenAI Founding Researcher、Ex-Tesla AI Director) 著名的開源專案
  • 之中使用的 GPT2 架構具有一定的識別度
  • Transformer Block 單元在初步評估後判斷是能對齊嵌入式硬體限制（SRAM、Flash、算力、功耗等等）

這不是做 SOTA 研究，而是實際要能活在晶片上的 Transformer Model。

真正的戰場：Toolchain 地獄

如果你沒有真的把模型 Deploy 到 Micro-controller上，很難理解什麼叫做「生態系不支援」。

這不是某一個 Library 的問題，而是整條 Toolchain 從上到下的每一層都在拒絕你：

Model Layer：TensorFlow Keras

看起來一切正常，模型可以訓練、可以驗證。

Compiler Layer：TFLite Converter

當我以為 TFLite Converter 已經將 Keras 模型成功輸出成 TFLite Graph 時，部署到晶片時仍常常出現 LiteRT Operator 不支援 這樣的羅生門。於是我只能回頭一次次的調整 Keras Layer。

Runtime Layer：TFLite Micro / LiteRT

重複無數次，好不容易將 Operator 支援度問題解決，準備在晶片上跑，結果只留下一句：

AllocateTensors() returned kTfLiteError

沒有 stack trace、沒有 hint、沒有 debug info。

只有我跟整條 Toolchain 的對峙。

第一次成功，但離 Demo 還很遠

經過一番折騰，終於讓 NanoGPT 運行起來。當第一個 Token 生成出來的那一刻，我以為終點到了。

然後我看了一下時間：20 秒。

每一個 Token，都需要 20 秒。

這不是「慢」的問題，而是「完全不可能 Demo」的問題。因為第一版的實作中，每次生成新 Token 時，都會重新計算整個序列的 K 和 V 值——這在理論上是正確的，但在實務上，根本撐不起一場展示。

回頭擁抱 KV-cache：演算法是Free Fruit，但工具鏈不是

於是，我回頭研究主流的 KV-cache 演算法。

在學術上，這是個「Free Fruit」——演算法本身已經被充分驗證，理論也很清楚。

但在工程上，這意味著：

我必須重新走一遍 Toolchain 的坑，而且這上次還要更複雜與痛苦。

因為接下來我才發現…

關鍵現實：KV-cache 是一個生態系黑洞

KV-cache 是種 Multi-head Attention 的 Activation Value。

在PC或GPU上，它是理所當然的設計；但在 Embedded 世界裡，它卻是一個異類：

  • 它是種 activation 私自量化這個值，會造成 Transformer 結果不佳的狀況

實際嘗試時，幾乎所有想用的方案都被擋掉：

  • ❌ INT8 Model 搭配 FP32 KV-cache → LiteRT 不支援 Hybrid Model
  • ❌ 客製化 Full INT8 Model & KV-cache → CMSIS-NN 不支援INT8 Activation

結論其實非常殘酷：

目前最主流的 LiteRT INT8 Ecosystem，沒有一條完整、可落地的 KV-cache 路徑。

工程抉擇：回頭擁抱FP32，但並不是 Free Lunch

於是，短短幾天內做了一個工程導向、而非理論最優的決定：

放棄 INT8，全面使用 FP32。

但這個選擇，一點也不輕鬆。

FP32 解決了生態系問題，卻立刻帶來另一組現實壓力：

  • 記憶體占用瞬間放大
  • 浮點運算吞吐成為瓶頸，本次的硬體平台只有一個 FPU，Decode Latency 明顯上升

如果沒有處理好，模型可以跑，但 Demo 依舊會遇到運算過慢的問題。

KV-cache 拯救了複雜度，但 FP32 拉高了計算成本

KV-cache 的價值是關鍵性的：

  • Attention 運算的時間複雜度從 O(n²) 降為 O(n)

這讓 Transformer 在 Embedded 上「理論上」可行。

但現實是：

  • KV-cache 少算了 Attention
  • FP32 又讓每一步算得更慢

一來一往，如果不針對 運算路徑與記憶體存取 額外做優化，Transformer Decoding 仍然會陷入 Compute bottleneck。

異質記憶體開發經驗變成關鍵

這時候，過去幾個月在 Heterogeneous Memory（Flash / SRAM / DTIM） 的經驗，反而變成了關鍵救命繩。

因為 FP32 + KV-cache 的前提是：

需要提前知道：

  • 哪些資料能放 Flash
  • 哪些一定要在 SRAM
  • 哪些 Code 值得搬進 DTIM

否則：

  • Memory Bandwidth 直接吃滿
  • Decoder latency 爆炸
  • 最後的結果是——跑得起來，但 Demo 不成立

解法不是漂亮，而是務實

最後真正能工作的設計，是一連串「為了活下來」的取捨：

模型端 (Python)

  • 移除 Dynamic Slicing
  • 不在模型中更新 cache
  • 只輸出新的 K / V

Runtime (C/C++)

  • 手動管理 KV-cache

計算策略

  • Full FP32 Computation
  • Window-based KV-cache

系統層

  • Flash / SRAM / DTIM 精細配置
  • -O2、頻率調整、記憶體配置反覆測試

結語：Endpoint AI 工程能力的完整實證

Demo

最終，成功地讓 NanoGPT 在一顆 Ultra Low Power RISC-V SoC 上生成文字，這是公司第一次在晶片上展示如此複雜的 AI 模型運算能力。從 CIM 硬體加速的願景出發，走過 Toolchain 地獄與 KV-cache 掙扎，最終完整地走過了 Neural Network Development → Graph Compilation → on-chip Runtime Computation 的 Full Stack AI Engineering 旅程。

這個系統不只是一個 Demo，更是一個完整的 Software Stack 驗證：從 Model Definition、Compiler Toolchain、到 Runtime Optimization，整條路徑都已經被打通。它證明了我們的晶片與軟體能力，已經準備好迎接下一階段的 CIM 硬體加速 挑戰。

在 2026 CES 的展示中，當 “Once upon a time” 的 prompt 在晶片上逐字生成 TinyStories 時，這不僅是技術可行性的證明，更是對未來 Endpoint AI 方向的一次成功探索與工程能力的實證。

Tags