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

January 4, 2026

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

Transformer on Chip

我以為戰場在模型規模，後來發現是工具鏈。兩週內把 Transformer 壓進低功耗晶片，是一次把可行性邊界重新畫清楚的過程。

前言

想像一下，你要在兩週內，讓 GPT 在一顆連 GPU 都沒有的晶片上跑起來。

一人作業。沒有平行方案。沒有「跑不起來就算了」的空間。

這就是我接到的任務。而這類任務真正考驗的，不是你會多少模型，而是你能不能在限制裡把事情做成。

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

最初，這項研究源自公司正在開發的 CIM（Compute In Memory）神經網路硬體加速器。

CIM 的核心價值在於，將運算與記憶體靠得極近，降低資料搬移成本，從架構層面解決能耗與運算時間瓶頸——特別適合深度學習這類 memory-bound workload。

但硬體還沒完全成熟。為了讓 CIM 的價值「看得見、摸得到」，公司需要一個 Reference Workload，能夠：

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

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

時間壓力：兩週，從零到 Demo

事情真正變得困難，是在時間被「鎖死」的那一刻。

公司在 2026 年 1 月 CES 有一場工程展示。而我拿到「確定要參展」的消息時，只剩兩週。

一人作業、沒有平行方案、沒有退路。

這不是研究型的題目，而是交付導向的工程任務。

Deadline 不是壓力的來源，「沒有退路」才是。

技術路線選擇：為什麼是 NanoGPT

要 Demo 什麼模型才能有效展示工程能力？這個決定也落在我身上。

經過研究後，我選擇 NanoGPT 作為起點：

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

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

真正的戰場：Toolchain 地獄

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

這不是某一個 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 的對峙。

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 世界裡，它卻是一個異類——私自量化這個值，會造成 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 方向的一次成功探索。

真正的工程能力，不是把事情做到完美，是在不完美的條件下把事情做成。