8GB 的 RK3588 能跑多聰明的 LLM？ROCK 5C 用 NPU 實測 5 個模型

先講結論，省得你滑到最後：在一片 8GB 的 RK3588 板子上，用 NPU 跑得最聰明的是 Qwen3-4B-Instruct-2507，我出的 7 題全對，但每秒只吐 3.7 個 token。 想要順一點的對話體驗，Qwen3.5-2B 的 8.4 tok/s 是比較甜的平衡點；最新的思考模式呢？答得準，但一題要等兩三分鐘，在這塊板子上基本不能用。

這篇是我把一片 Radxa ROCK 5C 從出廠映像檔，一路弄到能跑 RKLLM 和 YOLOv8 的完整紀錄。中間踩了四個坑，其中一個很陰險：用舊版工具轉的模型，放到新版 runtime 上，只要寫到半形逗號就自己閉嘴。 回答「玉山海拔大約為 3,」就結束了，整個傻眼。

如果你手上也有 RK3588（ROCK 5B/5C、Orange Pi 5、Turing RK1 之類），想在本地跑 LLM，這篇應該能幫你省下半天。

環境與前置條件

項目	規格
板子	Radxa ROCK 5C，RK3588S2（4×A76 + 4×A55），RAM 8GB
NPU	6 TOPS，3 核心
系統	Radxa 官方 Debian 12（bookworm）桌面映像檔
kernel	6.1.43 → 升到 6.1.84-8
NPU 驅動	v0.9.6 → 升到 v0.9.8
RKLLM	v1.2.3 與 v1.3.0 兩版並存
rknn-toolkit2	2.3.2（aarch64，直接裝在板子上）

根據 Radxa 官方介紹 ，ROCK 5C 標準版用的是 RK3588S2，Lite 版則是只有兩顆大核的 RK3582，買之前要看清楚。CNX Software 的整理 也列得很清楚：NPU 標準版 6 TOPS、Lite 版 5 TOPS。

整體流程長這樣：

出廠映像（NPU 0.9.6）
  → apt full-upgrade → kernel 6.1.84 / NPU 0.9.8
  → RKNN：YOLOv8 暖身
  → RKLLM runtime v1.2.3 / v1.3.0
  → 下載社群轉好的 .rkllm 模型
  → 鎖頻 + 7 題實測

第一關：NPU 驅動要先升到 0.9.8

Radxa 的 RKLLM 安裝文件 寫得很明白：RKLLM 需要 NPU 驅動 v0.9.8，而 Radxa 6.1 系列的韌體只有 0.9.6。我這片的出廠映像檔是 2024 年 8 月的版本，一查果然：

sudo cat /sys/kernel/debug/rknpu/version
# RKNPU driver: v0.9.6

文件叫你開 rsetup 選 System Update，其實背後就是 apt full-upgrade。我這片一共有 440 個套件可以更新，包括新的 kernel 6.1.84 和 rknpu2 2.3.0。既然要遠端操作，我就直接用非互動模式跑：

sudo apt update
sudo DEBIAN_FRONTEND=noninteractive apt-get -y \
  -o Dpkg::Options::=--force-confdef \
  -o Dpkg::Options::=--force-confold full-upgrade
sudo apt install -y rknpu2-rk3588 python3-rknnlite2
sudo reboot

聽起來很簡單對吧？結果第一次跑，SSH 直接斷線，板子叫不醒。

坑 1：桌面版映像檔會自己去睡覺

我後來翻 journal 才看懂發生什麼事：apt 在 13:01:11 開始跑，才 5 秒，dpkg 剛開始解壓套件，GDM 的 gsd-power 就讓系統進了 sleep.target。Radxa 的桌面映像檔預設會在登入畫面閒置後自動休眠，這對拿來接螢幕的人很合理，對拿來當無頭伺服器的人就是陷阱。夭壽，更新跑到一半被休眠打斷，dpkg 還留了三個沒處理完的 trigger。

好在損害不大，處理方式是先把休眠整個關掉，再把 dpkg 修好：

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
sudo dpkg --configure -a

⚠️ 無頭使用前先 mask 休眠

用 Radxa 桌面映像檔當伺服器時，第一件事就是 mask 掉 sleep.target。之後想恢復，改成 unmask 就好。

坑 2：長時間的工作不要掛在 SSH session 底下

第二次我學乖了，用 systemd-run 在背景跑更新。但後來下載模型時又踩到一個類似的雷：我用的是 systemd-run --user，結果下載卡在 87MB 不動。原因是 --user 服務掛在使用者 session 底下，SSH 一斷，服務就跟著被收掉。改成系統層級、再指定使用者就沒事了：

sudo systemd-run --unit=rk-upgrade --collect -p User=radxa \
  -p StandardOutput=append:/home/radxa/upgrade.log /home/radxa/upgrade.sh

更新完、重開機（新 kernel 第一次開機大概要 3 分半，別急著拔電），驅動就到位了：

sudo cat /sys/kernel/debug/rknpu/version
# RKNPU driver: v0.9.8

暖身：YOLOv8 在板子上一條龍跑完

在碰 LLM 之前，我先用 Radxa 的 YOLOv8 教學 驗證 NPU 環境。文件的寫法是在 x86 PC 上轉模型、交叉編譯，再傳到板子上跑。

但其實不用這麼麻煩。Radxa 的 RKNN 安裝文件 本身就有提到，rknn-toolkit2 2.3.2 有 manylinux aarch64 的 wheel，轉換可以直接在板子上做。ROCK 5C 有 8GB RAM，轉 yolov8n 這種小模型綽綽有餘：

# 環境
sudo apt install -y python3-venv python3-dev gcc g++ cmake make
git clone --depth 1 -b v2.3.2 https://github.com/airockchip/rknn_model_zoo.git
python3 -m venv ~/rknn-venv && . ~/rknn-venv/bin/activate
pip install rknn-toolkit2==2.3.2

# 下載 ONNX、轉成 rknn（int8 量化）
cd rknn_model_zoo/examples/yolov8/model && bash download_model.sh
cd ../python && python convert.py ../model/yolov8n.onnx rk3588

# 用板子上的 gcc 原生編譯 C demo，不需要交叉編譯器
cd ../../.. && export GCC_COMPILER=aarch64-linux-gnu
bash build-linux.sh -t rk3588 -a aarch64 -d yolov8

# 執行
cd install/rk3588_linux_aarch64/rknn_yolov8_demo
LD_LIBRARY_PATH=./lib ./rknn_yolov8_demo model/yolov8.rknn model/bus.jpg

轉換在板子上只花了 24 秒。輸出跟官方文件的預期結果一字不差：

person @ (211 241 282 506) 0.864
bus    @ (96 136 549 449) 0.864
person @ (109 235 225 535) 0.860
person @ (477 226 560 522) 0.848
person @ (79 327 116 513) 0.306

我用 RKNNLite 寫了個簡單的 Python 迴圈量速度，大約 36 ms 一張，約 28 FPS。這裡要老實講，這個數字包含 Python 的呼叫開銷，而且是單執行緒送一張等一張。有人在 rknn_model_zoo 的 issue #454 分享過，用 3 核 NPU 加上 MPP 解碼、RGA 縮圖的零拷貝管線，YOLOv8n 在 640 解析度可以跑到約 199 FPS。所以 28 FPS 只是入門數字，你認真優化，天花板高很多。

💡 中國 CDN 的下載坑

download_model.sh 的 ONNX 放在中國的 CDN。我的板子一開始走國外 VPS 出去，30 秒只下載了 65KB。遇到這種狀況，先在電腦上下載再 scp 過去最快。

主戲：RKLLM v1.2.3 還是 v1.3.0？

Radxa 文件寫的是 RKLLM v1.2.3，但我去 rknn-llm 的 Releases 頁面 一看，Rockchip 在 2026-06-17 已經發了 v1.3.0，新增支援 Qwen3.5、Gemma4、SmolLM3。這幾個正好是目前最新的小模型，當然要升。

RKLLM-Toolkit（轉模型用的工具）只支援 x86_64 Linux，所以這次我全部用社群轉好的 .rkllm 模型，runtime 則直接裝在板子上：

git clone --depth 1 -b release-v1.3.0 https://github.com/airockchip/rknn-llm.git rknn-llm-1.3.0
cd rknn-llm-1.3.0
sudo cp rkllm-runtime/Linux/librkllm_api/aarch64/librkllmrt.so /usr/lib/
sudo cp rkllm-runtime/Linux/librkllm_api/include/rkllm.h /usr/include/
sudo /sbin/ldconfig

# 官方 build-linux.sh 寫死了 x86 交叉編譯器，在板子上直接用 cmake
cd examples/rkllm_api_demo/deploy && mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
make -j8
./llm_demo <model.rkllm> 768 4096

坑 3：舊模型配新 runtime，寫到半形逗號就閉嘴

這是整個實測裡最陰險的一個。我用 v1.3.0 runtime 跑用 toolkit 1.2.3 轉的 Qwen3-4B-Instruct-2507，問它台灣最高的山，它回：

台灣最高的山是玉山，其海拔大約為3,

然後就沒了。我一開始以為是輸出被截斷，翻 log 才發現這題真的只生成了 16 個 token，是模型自己送出了結束符號。問 strawberry 有幾個 r，它寫到「s,」也停了。

同一個模型換回 v1.2.3 runtime，一切正常：

模型（toolkit 1.2.3 轉）	v1.3.0 runtime	v1.2.3 runtime
Qwen2.5-1.5B	「海拔高度為3,」後結束	「3952 公尺」完整回答
Qwen3-4B-2507	「海拔大約為3,」後結束	「3,952 公尺」完整回答

有趣的是，用 v1.3.0 轉的 Qwen3.5 寫「3,952」完全沒問題。v1.3.0 的 release note 有一條「新增多 EOS token ID 支援」，我猜跟這個有關，但沒辦法百分之百確認。實務上的結論很簡單：runtime 版本要跟轉檔版本對上。 我的做法是兩版並存：~/rknn-llm 的舊 demo 透過 rpath 指向自己資料夾裡的 v1.2.3 函式庫，系統預設的 /usr/lib/librkllmrt.so 則是 v1.3.0，互不干擾。

坑 4：沒鎖頻，速度只有官方的七成

第一次跑 Qwen2.5-1.5B 只有 12.2 tok/s，跟 官方 benchmark 的 16.69 差了一截。原來官方測之前都會跑一支鎖頻腳本，把 CPU、NPU、DDR 全部固定在最高頻率：

sudo bash ~/rknn-llm-1.3.0/scripts/fix_freq_rk3588.sh

鎖完再跑，12.2 直接跳到 16 tok/s 以上（7 題平均 16.2），跟官方幾乎一樣。鎖頻後滿載時 SoC 溫度大約 49°C，完全沒降頻，風扇甚至沒轉。代價是閒置時也不會降頻，比較耗電，重開機就會恢復。

實測：5 個模型 + 思考模式，誰最聰明？

測試方法

我從官方的 llm_demo.cpp 複製一份改成測試工具，讓思考模式可以用環境變數切換（設定 RKLLMInput 的 enable_thinking）。解碼用 demo 預設的 top_k=1，也就是貪婪解碼，每次輸出都固定，比較起來才公平。每個模型都在鎖頻、沒有其他工作的狀態下獨立跑。

題目是 7 題繁中，刻意混了幾個小模型常翻車的陷阱：

1. 雞兔同籠：14 個頭、38 條腿（答案：雞 9、兔 5）
2. 台灣最高的山和海拔（玉山，3,952 公尺）
3. 9.11 和 9.9 哪個大
4. strawberry 裡有幾個 r
5. 所有貓都是動物、有些動物會游泳，能不能推出有些貓會游泳（不能）
6. 用 Python 寫 is_prime(n)
7. 用繁中條列三點 WireGuard 的優點，每點不超過 15 字（考指令遵循）

模型全部是 w8a8 量化，從 HuggingFace 下載社群轉好的版本：Qwen2.5-1.5B 和 Qwen3-4B-Instruct-2507 來自 GatekeeperZA（v1.2.3 轉），Qwen3.5-2B、Qwen3.5-4B 和 gemma-3-4b-it 來自 HanzoHuang（v1.3.0 轉）。

ℹ️ Qwen3.5 是視覺語言模型的轉檔

HanzoHuang 的 Qwen3.5 repo 是以 VLM 的形式提供，每個平台都有語言模型 .rkllm 和對應的視覺編碼器 .rknn。這次我只下載 .rkllm，用 llm_demo 純文字輸入測試，沒有載入視覺編碼器。純文字對話不需要它；要看圖的話，得改用 multimodal_model_demo 並一起載入 .rknn。

速度與記憶體

模型	runtime	生成速度	記憶體峰值	載入時間
Qwen2.5-1.5B	1.3.0	16.2 tok/s	1.8GB	1.4 秒
Qwen3.5-2B	1.3.0	8.4 tok/s	2.2GB	64 秒
gemma-3-4b-it	1.3.0	4.5 tok/s	4.5GB	36 秒
Qwen3.5-4B	1.3.0	3.6 tok/s	4.7GB	58 秒
Qwen3-4B-Instruct-2507	1.2.3	3.7 tok/s	5.4GB	約 60 秒

Qwen3.5 的載入時間要將近一分鐘，比 Qwen2.5 的 1.4 秒久非常多，拿來做即開即用的服務要考慮進去。

答題結果

題目	Qwen2.5-1.5B	Qwen3.5-2B	gemma-3-4b	Qwen3.5-4B	Qwen3-4B-2507
雞兔同籠	✅	✅	❌ 一直說需要額外資訊	✅	✅
玉山	✅	⚠️ 說是亞洲第一高峰	✅	⚠️ 說僅次於富士山	✅
9.11 和 9.9	✅	❌ 說 9.11 大	✅（解釋錯）	⚠️ 答錯後自己更正	✅
strawberry	❌ 說 2 個	✅	⚠️ 用英文回答	✅	✅ 標出第 3、8、9 位
貓會不會游泳	❌ 答「能」	✅	✅	✅ 還舉反例	✅ 還舉反例
質數函式	✅	✅	✅	✅	✅
字數限制	⚠️	❌ 超過字數	✅	✅ 最精簡	✅
得分	4.5	4.5	5	6	7

最讓我意外的是 gemma-3-4b 的雞兔同籠，直接鬼打牆，一直重複「這個問題需要一些額外的資訊才能解決」，還自己假設有 50 隻雞，廢到笑。它的 strawberry 答對了，但突然切成英文回答，也算小扣分。

Qwen3.5-4B 在 9.11 那題很有戲：先斬釘截鐵說 9.11 比較大，講到一半發現不對，自己補了一句「更正：抱歉，剛才的邏輯推導有誤」，改成 9.9。會自我更正是好事，但放在正式產品裡，使用者會先看到錯的答案。

冠軍 Qwen3-4B-Instruct-2507 是唯一連附加資訊都沒講錯的。Qwen 官方模型卡 的數字也支持這個結果：它是 Qwen3-4B 的非思考版更新版，GPQA 從 41.7 拉到 62.0、AIME25 從 19.1 拉到 47.4，進步幅度很誇張。

另外，幾個小模型碰到台灣地理細節都會順手補上錯的資訊，例如「亞洲第一高峰」「僅次於富士山」。需要事實準確的場景，還是要搭配 RAG。

思考模式：答得準，但等不起

Qwen3.5 支援思考模式，我用 4B 開起來重跑一次：

題目	生成 token	耗時	結果
9.11 和 9.9	562	143 秒	✅ 一次答對，不用自我更正
strawberry	637	163 秒	✅
質數函式	492	133 秒	✅
雞兔同籠、玉山、邏輯、字數限制	767	168～207 秒	❌ 到 768 token 上限還沒答完

思考過程全部用英文，每題都要燒 500 到 767 個 token。要讓它每題都答完，max_new_tokens 至少得開到 2048，等於一題要等 5 分鐘以上。答案是比較準，但這個速度拿來聊天就是在哈囉。

為什麼 4B 只有 3.6 tok/s？瓶頸不是 NPU

看到 6 TOPS 的 NPU 跑 4B 模型只有 3.6 tok/s，一開始我也覺得是 NPU 不夠力。其實不是。

LLM 生成文字時，每產生一個 token，就要把整個模型的權重從記憶體讀一遍。The Memory Bandwidth Ladder 這篇講得很白：生成速度的上限大約就是「記憶體頻寬 ÷ 模型大小」，跟 TOPS 關係不大。

那 RK3588 的頻寬有多少？Turing Pi 的 RK1 實測 指出，RK3588 的 64-bit LPDDR4X 理論峰值約 34 GB/s，用 STREAM 實測約 21～22 GB/s。拿我的數字粗估：4B 的 w8a8 權重大約 3.5～4GB，乘上 3.6 tok/s，每秒要搬十幾 GB；1.5B 的權重約 1.3GB，乘上 16 tok/s，也是二十 GB/s 上下。兩個都已經頂到那條天花板了。

更有說服力的是另一個對照：Turing Pi 用 llama.cpp 純 CPU 跑同樣的 RK3588 ，Qwen2.5-1.5B Q4_K_M 有 22.57 tok/s，比我用 NPU 跑 w8a8 的 16.2 還快。原因不是 CPU 比 NPU 強，而是 Q4 量化的模型比 w8a8 小將近一半，每個 token 要搬的資料少。乾，搞半天瓶頸在記憶體。

所以 NPU 在這塊板子上的真正價值，是把 CPU 空出來。NPU 在跑 LLM 時，8 顆 CPU 核心還能做別的事，例如跑 YOLO 的前後處理、網頁服務、Home Assistant。純 CPU 跑 llama.cpp 雖然快一點，但會把 CPU 吃滿。

我的推薦

你想做的事	選這個	runtime	為什麼
要最聰明的回答	Qwen3-4B-Instruct-2507	v1.2.3	7/7，附加資訊也正確
想用最新架構	Qwen3.5-4B	v1.3.0	6/7，會自我更正
聊天要順	Qwen3.5-2B	v1.3.0	8.4 tok/s，邏輯題答得對
簡單問答、要快	Qwen2.5-1.5B	v1.2.3	16 tok/s，載入 1.4 秒
看圖	Qwen3.5-0.8B	v1.3.0	官方實測影像編碼約 0.69 秒（這次沒測）

一般人的閱讀速度大約是每秒 5 到 8 個 token，所以 4B 那 3.6 tok/s 拿來即時聊天會覺得有點卡。我會把 4B 用在背景工作，例如文件摘要、訊息分類、Home Assistant 的語音意圖判斷；真的要對話，就用 Qwen3.5-2B。

至於 8GB 放不下的：社群轉的 Gemma4-E2B 檔案有 7.85GB，太冒險；7B、8B 的模型用 w8a8 量化後都超過 8GB。想跑這些，至少要買 16GB 的版本。

Troubleshooting

Q：SSH 連線突然斷掉，板子叫不醒？
多半是桌面映像檔自己休眠了。接上螢幕或按電源叫醒後，執行 sudo systemctl mask sleep.target suspend.target。

Q：llm_demo 的回答寫到一半就結束，而且總是停在逗號？
檢查模型是用哪一版 toolkit 轉的，runtime 要對上。log 的第一行會印出 rkllm-runtime version 和 rkllm-toolkit version。

Q：速度比官方 benchmark 慢三成？
先跑 scripts/fix_freq_rk3588.sh 鎖頻，重開機後要重跑。

Q：板子換網路埠之後拿不到新的 IP？
ROCK 5C 的 rk_gmac-dwmac 驅動偵測不到短暫的拔插，NetworkManager 會繼續用舊 IP。拔線超過 10 秒再插，或在板子上執行 nmcli connection up "Wired connection 1"。

Q：官方的 build-linux.sh 在板子上編不過？
它寫死了 x86 交叉編譯器的路徑。在板子上直接用 cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ 編譯就好。

結語

折騰一輪下來，我對 RK3588 跑 LLM 的心得是：別被 6 TOPS 騙了，記憶體頻寬才是真正的天花板。 8GB 的板子能跑的最聰明模型大概就是 4B 級，速度 3 到 4 tok/s，拿來做背景的智慧處理很夠用；要聊天，2B 級是比較實際的選擇。

還有最重要的一句：runtime 和模型的轉檔版本要對上。 我這肝差點被那個「逗號就停」的 bug 搞到懷疑人生。

如果你也在 RK3588 上跑過 LLM，歡迎在下面留言分享你的模型和速度。我下一步想試 rkllm_server_demo，把它包成 API 接進 Home Assistant，做一個完全離線的語音助理，有興趣的可以追蹤一下。

參考資料

• Radxa RKLLM 安裝文件
• Radxa YOLOv8 部署文件
• Radxa RKNN 安裝文件
• Radxa ROCK 5C 產品介紹
• CNX Software：ROCK 5C 規格整理
• airockchip/rknn-llm Releases
• RKLLM v1.3.0 官方 benchmark
• rknn_model_zoo issue #454：RK3588 YOLOv8n/YOLO11 實測
• Turing Pi：RK1 Benchmarks（記憶體頻寬）
• Turing Pi：RK3588 LLM GGUF 量化比較
• The Memory Bandwidth Ladder
• Qwen3-4B-Instruct-2507 官方模型卡

延伸閱讀

• 後 Transformer 時代來了？Mamba-3、ICLR Outstanding Paper、7M 模型同時打三個方向的真相
• TTS 文字轉語音完全指南：技術原理、聲音克隆與 2026 選型實戰
• 同一顆基座、兩種靈魂：Holo 3.1 與 Qwythos-9B 怎麼在你本機組成 Claude Computer Use
• 豆包角色 Bot 為什麼一開口就「作為 AI」？字節官方拍板的人設骨架 + 即貼即用範本

後 Transformer 時代來了？Mamba-3、ICLR Outstanding Paper、7M 模型同時打三個方向的真相

2026 年 4-5 月有三件事讓「Transformer 要被換掉」的論調再度燒起來。但你把三件事擺在一起看，會發現它們指的不是同一個方向——其中一件甚至從理論側狠狠打了 SSM 派一巴掌。先別急著重構你的 stack，這篇把張力講清楚。

先看一個讓人心煩的數字

DeepSeek R1，671B 參數，在 ARC-AGI-1 拿 15.8%。
Gemini 2.5 Pro，37.0%。
o3-mini，34.5%。

然後有一個叫 TRM 的東西，7M 參數——少了五個數量級——拿了 44.6%。

你沒看錯。一個你能塞進手機的小模型，在 ARC-AGI（那個讓 AGI 派與懷疑派吵到天昏地暗的「真推理」基準）上面，把市值千億的 frontier model 通通踢開。這篇論文叫 Less is More: Recursive Reasoning with Tiny Networks ，作者 Alexia Jolicoeur-Martineau 來自 Samsung SAIT AI Lab（Montreal），還拿了 ARC Prize 2025 的 Paper Award 1st Place 。

同一時間 ICLR 2026 也辦完了。Mamba-3 拿到 Oral 名額 （4% 論文才有的待遇），把 SSM 推到一個明顯更成熟的位置（Oral 是 ICLR 接受論文中極稀少的高榮譽）。另一頭，Transformers are Inherently Succinct 拿了 Outstanding Paper ——理論派直接證明：RNN/SSM 要做出 Transformer 能做的事，表達成本可能是「指數級」的開銷。

三件事丟在一起像看摔角自由搏擊：每個招式都漂亮，但你根本不知道誰會贏。
這就是我接下來要拆的事。

第一條線：Mamba-3 的「推理優先」翻盤

Mamba-1（2023）證明 selective SSM 可以打到接近 Transformer。
Mamba-2（2024）給了個叫「state space duality」的理論框架，讓 SSM 不再像個玄學咒語。
Mamba-3 （ICLR 2026 Oral）的問題不一樣：「如果一開始就為推理（inference）設計 SSM，它會長什麼樣？」

作者群 Aakash Lahoti、Kevin Li、Berlin Chen、Caitlin Wang、Aviv Bick、Zico Kolter、Tri Dao、Albert Gu 動了三個槓桿：

1. Exponential-Trapezoidal 離散化

過去 Mamba-1/2 都用「指數歐拉法」做連續時間 ODE 的離散化，這玩意是一階近似。Mamba-3 換成梯形法——二階近似，局部截斷誤差從 O(Δt²) 降到 O(Δt³)。直白講：你的 hidden state 更新公式變成三項遞迴：

h_t = α_t · h_{t-1} + β_t · B_{t-1} · x_{t-1} + γ_t · B_t · x_t

這個小改變的副作用很爽——它讓你不再需要短 causal convolution。Mamba-1/2 都靠那個 short conv 補 induction 能力（簡單講就是「記住前面看過什麼」），Mamba-3 把這件事內建進遞迴本身，省一層。

2. Data-Dependent RoPE 補 state tracking

Mamba 系列被詬病最久的就是 state tracking 能力差——你給它 parity 任務（奇偶判斷），它會崩。
Mamba-3 把 hidden state 升級成複數值（complex-valued），用旋轉的方式更新。實作上等於「資料相依的 RoPE」——把 Transformer 早就用爛的旋轉位置編碼，搬到 SSM 的內部狀態。結果：parity 任務接近 100% 解開。

3. MIMO：用閒置的 GPU 算術強度

decode 時 GPU 通常 memory-bound，算術單元在發呆。Mamba-3 的 MIMO（Multi-Input Multi-Output）讓每個 decode step 做更多有用的事，但 latency 不變。

成績：

指標	Mamba-3 (1.5B)	vs 次強模型
下游平均準確度	+0.6 分（SISO） / +1.8 分（MIMO）	對比 Gated DeltaNet
同 perplexity 所需 state size	砍半	對比 Mamba-2

Janu Verma 的論文導讀 給了一句精準的總結：「Mamba-3 是一個押注——推理時代已經到了。」

但——這篇論文還有一個你不會在新聞稿看到的細節。作者在附錄寫得很坦白：要追上 Transformer 的「精準檢索」能力，他們最後跑的是 hybrid（每 5 個 SSM 配 1 個 attention）。
是的。連 Mamba-3 自己都用 hybrid。

第二條線：理論派的當頭棒喝

如果你過去十年讀過 SSM 論文，每篇開頭幾乎都會問同一個問題：「我這個架構能表達 Transformer 能表達的函數嗎？」 大家拼命跑 perplexity、跑 benchmark，最後得到的答案大致是「能」。

ICLR 2026 Outstanding Paper 「Transformers are Inherently Succinct」 ——三位作者來自 RPTU Kaiserslautern-Landau、ETH Zürich 與 Max Planck Institute——把這個問題改了：「你能多『簡潔』地表達它？」

結論用一句話講完：
Transformer 可以比 RNN/SSM 指數級更簡潔。比 finite automata 雙指數級更簡潔。

這不是常數倍數差距，不是多項式倍數差距，是 2^n 等級的差。換成工程白話：有一類概念（論文證明用的是 LTL 公式與某些形式語言），用 polynomial-size 的 Transformer 可以表達，但同樣的概念若改用 RNN 或 SSM，最小尺寸必須是指數級。

這就尷尬了。
業界一直在問「Mamba 表達能力夠不夠？」 答案是「夠」。但這篇論文要你問的是：「夠的代價是多少？」——如果代價是 參數量爆炸到指數級，那你拿掉 attention 省下的東西，馬上又被狠狠補回來。

論文還有一個副產品也很有意思：驗證 fixed-precision Transformer 的簡單性質是 EXPSPACE-complete。對做 AI 安全與形式驗證（formal verification）的人來說，這基本上等於「想做」跟「做得到」隔了一個指數空間。

Towards AI 上 Dr Swarneendu AI 的解讀 講得很狠：「我們花十年回答錯的問題。」

夭壽。

第三條線：7M 參數的 ARC-AGI 小怪

回到開頭那組數字。TRM 的招式說來其實簡單——簡單到讓人懷疑為什麼以前沒人這樣搞：

# 簡化版 pseudocode
y = embed(answer)
z = embed(latent)
for k in range(K):  # K = 16 改進步數
    for n in range(N):  # 內部遞迴 n 次
        z = net(x, y, z)  # 用問題、目前答案、目前 latent 更新 latent
    y = net(y, z)         # 用 latent 更新答案
# 前面幾輪不計算梯度，只有最後一輪做 backprop

兩層網路，7M 參數，遞迴 16 次自我修正。靠的不是參數量，是「test-time compute」——把算力花在推理時的迭代，不花在參數本身。

完整對比：

模型	參數	ARC-AGI-1	ARC-AGI-2
DeepSeek R1	671B	15.8%	1.3%
Claude 3.7 (16K)	?	28.6%	0.7%
o3-mini-high	?	34.5%	3.0%
Gemini 2.5 Pro (32K)	?	37.0%	4.9%
HRM（前身）	27M	40.3%	5.0%
TRM-Att	7M	44.6%	7.8%
Grok-4-thinking	1.7T	66.7%	15.9%
Bespoke (Grok-4)	1.7T	79.6%	29.4%

（資料整理自 ARC Prize Leaderboard 與 TRM 論文 Table 5，時間點為 2025 年 10 月公告；各模型評估時間不同，比較宜以同期評估為準。）

別過度興奮。
TRM 贏的對手是「拿著 prompt 直接做 ARC」的 LLM。一旦你給 frontier model 大量 test-time compute + 蒸餾（像 Bespoke Grok-4），它還是贏 TRM 一大截。而且 TRM 完全不能回答事實性問題——它的「知識」就是訓練那 1000 筆樣本，它靠的是規則推理而非世界知識。

但 TRM 的存在點出一件事：
參數量 ≠ 推理能力。把算力分到「test-time recursion」，能在特定任務拿到完全不成比例的 ROI。對韌體 / 邊緣場景來說，這是條極大的好消息。

三者擺一起：Hybrid 才是答案

把三條線並起來：

• Mamba-3 用工程把 SSM 推到新高度，但作者自己跑 hybrid
• ICLR Outstanding Paper 證明純 SSM 在某些概念表達上要付指數代價
• TRM 用「小模型 + 遞迴 test-time compute」打開另一條路

Forbes 的訪談 裡 Liquid AI 共同創辦人 Alexander Amini 講得很乾脆：「我們已經看到這個轉變了——今天頂尖、甚至 trillion-parameter 的模型，多數已經是 Transformer 與其他成分的 hybrid。」「我覺得這是今天的主流。」

Alibaba、Qwen 也是同樣路線。
Google 的 Gemma 4 + Multi-Token Prediction 更狠——直接把 speculative decoding 烤進主模型， 官方測試 Pixel 上 E2B/E4B 各跑 2.8x / 3.1x，Apple M4 跑 31B 模型 2.5x 。授權還順便改成 Apache 2.0。

所以工程師現在面對的真實局面，不是「Transformer 死了該換誰」這種小屁孩問題，而是：

「怎麼搭？」

• Attention 給你精準檢索與壓縮表達
• SSM/Mamba 給你線性複雜度、可控 state、長 context、串流
• Test-time recursion 給你不靠參數量的推理深度
• MTP / speculative decoding 給你 inference 加速

這四個是 可組合的元件，不是互斥的選項。會不會搭，是 2026-2027 的真本事。

對嵌入式 / 邊緣 AI 工程師的意義

我寫這篇有一半是寫給自己看的。
我做硬體韌體，過去兩年看 LLM 都帶著一種「這跟我有什麼關係」的距離感——Cortex-M4 上跑 70B？ 笑死。

但 2026 上半年這三件事疊起來，邊緣場景的局勢真的變了：

1. Mamba-3 的 state size 砍半 + 線性複雜度：MCU 上跑 sub-quadratic 模型不再是學術玩具。state 越小，SRAM / Flash 預算越好抓。
2. TRM 的 7M 推理範式：不是讓你在 nRF52 上跑 ChatGPT——而是讓你「用一個小到能塞進 MCU 的模型解決特定推理任務」（感測器決策、序列辨識、規則推理）。1.5MB 的權重檔很多 MCU 都吃得下。
3. Gemma 4 MTP 的 speculative decoding：邊緣不只是「模型多小」，是「inference 多快」。同樣的算力，吞吐 2-3x，這在 voice agent / 即時感測器融合的場景是質變。

如果你跟我一樣是硬韌體背景，要追的不是「LLM 越來越大」，而是 「architecture × test-time compute × inference optimization」這三個方向的交集。
那才是邊緣 AI 真正的窗口。

而軟體端，給用 Claude / Cursor / Codex 的人一句話：
把 prompt 與 skill 當作「可攜資產」設計，因為 6 個月內你下面的模型一定會換——不管是換到 hybrid、換到 SSM 主導、還是換到某種我們現在還沒看到的東西。

寫在最後

2017 年 Vaswani 那篇 Attention Is All You Need 把序列建模壓進一個範式。
2026 年我們同時看到三件事：工程派把 SSM 推到新高度、理論派證明 Transformer 在「簡潔」這個維度有指數優勢、新範式靠 test-time recursion 用 7M 打敗 671B。

我不覺得這是「Transformer 末日」。
我覺得這是「Transformer 終於不再是唯一答案」——一個更健康、更工程化、更 hybrid 的時代。

如果你還在猶豫要不要關注 Mamba / SSM / 後 Transformer，我的建議是：別問「會不會贏」，問「我的場景哪一塊可以用它換性能」。
那才是工程師該問的問題。

---

延伸閱讀

• Mamba-3 論文（arXiv:2603.15569） — ICLR 2026 Oral 原文
• Transformers are Inherently Succinct（OpenReview） — ICLR 2026 Outstanding Paper
• Less is More: Recursive Reasoning with Tiny Networks — TRM 原始論文
• Google 官方 Gemma 4 MTP 解說
• ICLR 2026 Outstanding Papers 官方公告
• ARC Prize 2025 結果分析 — TRM 得獎背景
• Janu Verma：Mamba-3 深度導讀
• Dr Swarneendu AI：RNN 表達能力理論解析
• Forbes：Liquid AI 訪談 — Transformer 與 AGI
• Ars Technica：Gemma 4 MTP 速度測試

延伸閱讀

• 8GB 的 RK3588 能跑多聰明的 LLM？ROCK 5C 用 NPU 實測 5 個模型
• 你的 MCP server 寫錯了：10,000+ 個伺服器、9% 真正能用、整合協議戰已經分輸贏
• TTS 文字轉語音完全指南：技術原理、聲音克隆與 2026 選型實戰
• 同一顆基座、兩種靈魂：Holo 3.1 與 Qwythos-9B 怎麼在你本機組成 Claude Computer Use

Nordic NRF Connect SDK Bare Metal 選項深度解析：從開發者困境到技術突破

前陣子參加了一個嵌入式開發聚會，聊天時發現很多資深工程師都面臨同樣的困境：手上的 NRF52 專案運行良好，但新的 NRF54L 硬體性能誘人，卻不想被迫學習 Zephyr RTOS。

「我們用 NRF5 SDK 已經五年了，程式碼庫穩定可靠，真的要為了新硬體重新學 Zephyr 嗎？」一位做醫療設備的朋友這樣問。

這個問題其實反映了嵌入式開發領域一個普遍的現象：硬體進步很快，但軟體遷移成本往往被低估。幸好，Nordic Semiconductor 最近推出了 NRF Connect SDK Bare Metal 選項，為這個問題提供了優雅的解決方案。

經過深度研究 Nordic 官方 webinar 內容以及實際測試數據，我發現這個新選項不僅解決了遷移問題，更在技術實現上有不少突破。讓我從開發者的角度，詳細分析這個技術方案的來龍去脈。

嵌入式開發的選擇光譜：從底層到抽象

談到 Nordic 的新策略，得先理解嵌入式軟體開發的完整光譜。從直接操作暫存器到運行完整作業系統，每個層級都有其適用場景。

底層直控：暫存器層級開發

最底層是直接操作硬體暫存器。想像你要控制一個 SPI 介面，你需要：

// 直接設置 SPI 暫存器
SPI_CR1 |= SPI_CR1_SPE;  // 啟用 SPI
SPI_DR = data_byte;      // 寫入數據
while (!(SPI_SR & SPI_SR_TXE)); // 等待發送完成

這種方式在 8 位元 MCU 時代很常見，開發者需要深度了解每個暫存器的功能。優點是完全掌控，缺點是開發效率低，程式碼可移植性差。

事件驅動：Bare Metal 的進化

接下來是事件驅動的 bare metal 開發，這也是 Nordic NRF5 SDK 採用的方式。系統基於事件循環運行：

int main(void) {
    // 初始化硬體
    hardware_init();
    bluetooth_stack_init();
    
    // 主事件循環
    for (;;) {
        // 處理藍牙事件
        if (ble_event_pending()) {
            handle_ble_events();
        }
        
        // 處理感測器數據
        if (sensor_data_ready()) {
            process_sensor_data();
        }
        
        // 進入低功耗模式
        power_manage();
    }
}

這種架構適合業務邏輯相對線性的應用：啟動→廣播→連接→數據交換→睡眠→重複。Nordic 稱之為「簡單藍牙應用」的典型模式。

多工處理：RTOS 的領域

當應用複雜度提升，需要同時處理多個任務時，RTOS 就派上用場：

// 不同優先級的任務
void sensor_task(void *param) {
    while (1) {
        read_sensors();
        vTaskDelay(100);  // 每100ms讀取一次
    }
}

void ui_task(void *param) {
    while (1) {
        update_display();
        handle_user_input();
        vTaskDelay(50);
    }
}

void ble_task(void *param) {
    while (1) {
        process_ble_events();
        vTaskDelay(10);   // 高頻處理
    }
}

RTOS 提供任務排程、同步機制、記憶體管理等服務，但也帶來了額外的系統開銷。

Nordic 硬體演進：從 NRF52 到 NRF54L 的技術跨越

NRF52 時代：成熟穩定的選擇

2015 年推出的 NRF52 系列可以說是藍牙 LE 開發的經典平台：

核心規格：

• Cortex-M4 @ 64MHz
• 最大 1MB Flash / 256KB RAM
• 藍牙 5.0 支援
• 豐富的周邊介面

軟體生態：

• NRF5 SDK：bare metal 開發環境
• NRF Connect SDK：基於 Zephyr RTOS

這個組合在過去幾年支撑了數十億顆晶片的出貨，從智能手環到工業感測器都能看到它的身影。

NRF54L 系列：新一代的性能突破

2024 年 11 月推出的 NRF54L 系列代表了 Nordic 在低功耗無線技術上的新突破：

硬體升級亮點：

1. 處理器性能翻倍

   • Cortex-M33 @ 128MHz（vs M4 @ 64MHz）
   • 22nm 製程 vs 90nm
   • 處理效率提升 3 倍

2. 功耗優化顯著

   • 廣播電流：_{115μA（100ms 間隔）}
   • 閒置電流：低至 2.2μA
   • 整體功耗降低約 30%

3. 記憶體配置靈活

   • NRF54L15：1.5MB Flash / 256KB RAM
   • NRF54L10：1.0MB Flash / 192KB RAM
   • NRF54L05：0.5MB Flash / 96KB RAM

4. 新增功能特性

   • 藍牙 6.0 Channel Sounding 支援
   • RISC-V 協處理器
   • 14-bit ADC
   • 強化的安全功能

實際測試數據對比：

項目	NRF52840	NRF54L15	改善幅度
CPU 時脈	64MHz	128MHz	+100%
廣播功耗	165μA	115μA	-30%
連接功耗	19μA	14.5μA	-24%
處理效率	基準	3x	+200%

這些數據來自 Nordic 官方實測，使用相同測試條件和應用場景。

軟體架構深度解析：Bare Metal 選項的技術實現

軟體堆疊架構

Nordic NRF Connect SDK Bare Metal 選項採用了精心設計的分層架構：

┌─────────────────────────────────┐
│        應用程式碼               │
│    (Customer Application)      │
├─────────────────────────────────┤
│       軟體設備 (SoftDevice)      │
│  S115 (周邊模式) / S145 (多角色) │
├─────────────────────────────────┤
│       NRFX 底層驅動             │
│   (硬體抽象層 & 驅動程式)        │
├─────────────────────────────────┤
│        NRF54L 硬體             │
│   (處理器、記憶體、周邊)        │
└─────────────────────────────────┘

軟體設備 (SoftDevice) 詳解

軟體設備是 Nordic 的核心技術，提供預編譯的藍牙協定堆疊：

S115 軟體設備特性：

• 純周邊模式 (Peripheral Only)
• 支援最多 2 個並發連接
• 記憶體優化設計
• 適合簡單藍牙應用

S145 軟體設備特性：

• 多角色支援 (Central + Peripheral)
• 支援最多 8 個並發連接
• LE Coded PHY 支援
• 廣播擴展功能

API 相容性：

// NRF5 SDK 風格的 API 調用
ret_code_t err_code;

// 初始化軟體設備
err_code = sd_softdevice_enable(&clock_lf_cfg, fault_handler);
APP_ERROR_CHECK(err_code);

// 設置藍牙事件處理
err_code = sd_ble_evt_handler_set(ble_evt_handler);
APP_ERROR_CHECK(err_code);

// 開始廣播
err_code = sd_ble_gap_adv_start(&m_adv_handle, BLE_CONN_CFG_TAG_DEFAULT);
APP_ERROR_CHECK(err_code);

這些 API 與 NRF5 SDK v17 高度相容，讓現有程式碼能順利遷移。

NRFX 驅動層深度分析

NRFX 是 Nordic 的硬體抽象層，提供統一的周邊存取介面：

// UART 驅動使用範例
#include "nrfx_uarte.h"

// 配置 UART
nrfx_uarte_config_t config = NRFX_UARTE_DEFAULT_CONFIG;
config.pseltxd = TX_PIN_NUMBER;
config.pselrxd = RX_PIN_NUMBER;
config.baudrate = NRF_UARTE_BAUDRATE_115200;

// 初始化 UART
err_code = nrfx_uarte_init(&uart_inst, &config, uart_handler);

// 發送數據
nrfx_uarte_tx(&uart_inst, tx_buffer, tx_length);

NRFX 的關鍵優勢：

1. 硬體抽象一致性：無論 NRF52 還是 NRF54L，API 保持一致
2. 效能優化：直接操作硬體暫存器，最小化軟體開銷
3. RTOS 無關性：可用於 bare metal 或任何 RTOS 環境

開發環境整合

Nordic 提供了統一的開發環境，bare metal 和 Zephyr 選項共存：

VS Code 整合流程：

1. SDK 安裝

# 使用 nRF Util 安裝
nrf-util toolchain-manager install --sdk ncs-bare-metal --version v0.8.0

2. 專案建立

# 複製範例專案
nrf-util create-app --example peripheral_lbs --sdk ncs-bare-metal

3. 編譯建置

# West 工具鏈編譯
west build -b nrf54l15dk_nrf54l15_cpuapp

4. 燒錄除錯

# 燒錄到開發板
west flash

專案結構範例：

my_ble_app/
├── src/
│   ├── main.c              # 主程式
│   └── ble_services/       # 藍牙服務
├── include/
│   └── app_config.h        # 應用配置
├── boards/
│   └── nrf54l15dk_nrf54l15_cpuapp.overlay  # 硬體配置
├── prj.conf               # Kconfig 配置
└── CMakeLists.txt         # 建置配置

性能實測數據深度分析

記憶體使用量比較

基於 Nordic 官方測試數據，我們看到有趣的記憶體使用模式：

Nordic UART Service 範例：

項目	Zephyr RTOS	Bare Metal	差異
RAM 使用量	31 KB	19 KB	-38%
Flash 使用量	174 KB	154 KB	-11%

LED Button Service 範例：

項目	Zephyr RTOS	Bare Metal	差異
RAM 使用量	22.5 KB	19.3 KB	-14%
Flash 使用量	168 KB	135 KB	-20%

關鍵發現：

1. RAM 差異顯著：Bare metal 在 RAM 使用上有明顯優勢，特別是簡單應用
2. Flash 差異適中：Zephyr 的系統服務確實占用額外空間，但差距可控
3. 差異隨複雜度縮小：當應用功能增加時，RTOS 開銷占比會相對減少

功耗性能深度測試

廣播模式功耗分析：

測試條件：100ms 廣播間隔，1Mbps PHY

測試項目	Zephyr RTOS	Bare Metal	差異
平均廣播電流	115.2 μA	113.0 μA	-1.9%
閒置電流	2.2 μA	2.4 μA	+9%
廣播事件功耗	3.9 mA	3.7 mA	-5%

連接模式功耗分析：

測試條件：360ms 連接間隔

測試項目	Zephyr RTOS	Bare Metal	差異
平均連接電流	14.5 μA	14.3 μA	-1.4%

深度分析：

1. 功耗差異微小：兩種方案在功耗表現上幾乎相同
2. 無線電主導：系統功耗主要來自無線電模組，CPU 開銷相對較小
3. 誤解澄清：選擇 bare metal 不會帶來顯著的功耗優勢

這個發現很重要，因為很多開發者誤以為 bare metal 一定更省電。實際上，現代 MCU 的 CPU 功耗相比無線電幾乎可以忽略不計。

實時性能測試

中斷回應時間：

事件類型	Zephyr RTOS	Bare Metal	改善幅度
GPIO 中斷	2μs	0.5μs	75%
UART 中斷	3μs	0.8μs	73%
藍牙事件	15μs	~10μs	33%

Bare metal 在中斷回應時間上確實有優勢，這對需要快速回應的應用很重要。

開發實務與應用場景深度指南

選擇框架的決策樹

基於實際開發經驗和技術特性，我整理了詳細的選擇指南：

選擇 Bare Metal 的場景：

1. 簡單藍牙應用

   • 感測器數據收集器
   • 簡單的遙控設備
   • 基礎的信標 (Beacon) 應用

2. 現有程式碼移植

   • 基於 NRF5 SDK 的成熟專案
   • 已投入大量開發成本的程式碼庫
   • 需要保持 API 相容性的場景

3. 特殊合規要求

   • 醫療設備需要嚴格的軟體驗證
   • 安全關鍵應用需要最小化第三方程式碼
   • 需要完整控制軟體堆疊的場景

4. 資源受限環境

   • 使用 NRF54L05 (96KB RAM) 等小型版本
   • 成本敏感的大量產品
   • 電池供電的極簡設備

選擇 Zephyr RTOS 的場景：

1. 複雜多工應用

   • 同時處理多個無線協定
   • 需要並行執行多個任務
   • 包含 AI 推理的邊緣運算

2. 豐富的生態需求

   • 需要大量第三方函式庫
   • 使用 Bluetooth Mesh 或 Matter
   • 整合網路協定堆疊

3. 快速原型開發

   • 新產品概念驗證
   • 需要快速上市的專案
   • 團隊對 RTOS 開發熟悉

4. 擴展性考量

   • 產品功能可能持續增長
   • 需要支援 OTA 更新
   • 多產品線共用程式碼

實際開發案例研究

案例一：智慧手環心率監測

某客戶開發智慧手環，原本使用 NRF52832 + NRF5 SDK：

// 原有架構（簡化版）
void main(void) {
    // 初始化
    timers_init();
    ble_stack_init();
    gap_params_init();
    services_init();    // 心率服務
    advertising_init();
    conn_params_init();

    // 主循環
    for (;;) {
        if (m_heart_rate_measurement_ready) {
            heart_rate_measurement_send();
            m_heart_rate_measurement_ready = false;
        }
        power_manage();
    }
}

遷移到 NRF54L15 的考量：

1. 硬體優勢：30% 功耗降低，延長穿戴時間
2. 軟體相容：API 相似，遷移成本低
3. 記憶體充足：1.5MB Flash 足夠容納更多功能

實際遷移結果：

• 開發時間：2 週（vs 預估 2 個月用 Zephyr）
• 功耗改善：續航從 5 天提升到 7 天
• 程式碼複用率：85%

案例二：工業感測器閘道器

另一個客戶開發多協定感測器閘道器：

// 需要同時處理的任務
void sensor_task(void) {
    // 每秒收集感測器數據
    collect_temperature_data();
    collect_humidity_data();
    collect_pressure_data();
}

void ble_task(void) {
    // 處理手機 App 連接
    process_ble_events();
    handle_configuration_requests();
}

void thread_task(void) {
    // 處理 Thread 網路通信
    process_thread_messages();
    forward_sensor_data();
}

void storage_task(void) {
    // 本地數據緩存
    manage_flash_storage();
    implement_wear_leveling();
}

為什麼選擇 Zephyr：

1. 多工需求：4 個並行任務需要排程管理
2. 協定複雜性：BLE + Thread 需要 RTOS 支援
3. 社群資源：Thread 實作依賴 OpenThread

開發結果：

• 開發時間：6 週
• 系統穩定性：優秀的任務隔離
• 擴展性：易於增加新協定

遷移實務指南

從 NRF5 SDK 遷移到 Bare Metal 的詳細步驟：

1. 環境準備

# 安裝必要工具
nrf-util install toolchain-manager
nrf-util toolchain-manager install --sdk ncs-bare-metal

# 設置環境變數
export NRF_CONNECT_SDK_PATH=/path/to/ncs-bare-metal

2. 程式碼審查與規劃

// 檢查使用的 API
grep -r "sd_ble_" src/     # 軟體設備 API
grep -r "nrf_drv_" src/    # 驅動 API  
grep -r "app_" src/        # 應用函式庫

3. 逐步移植策略

   • 第一階段：移植基本藍牙功能
   • 第二階段：移植周邊驅動
   • 第三階段：移植應用邏輯
   • 第四階段：優化與測試

4. 常見移植問題與解決方案

問題	原因	解決方案
編譯錯誤	API 版本差異	參考官方遷移指南更新 API
功能異常	配置差異	檢查 prj.conf 和設備樹配置
性能問題	優化設置	調整編譯器優化選項

技術深度剖析：單bank DFU 實現

DFU 機制對比分析

雙bank DFU（傳統方案）：

Flash Layout:
┌─────────────────────┐ 0x00000000
│    Bootloader       │
├─────────────────────┤ 0x00010000  
│  Application Bank A │ (運行中)
├─────────────────────┤ 0x00080000
│  Application Bank B │ (新韌體)
├─────────────────────┤ 0x000F0000
│   User Data         │
└─────────────────────┘

優點：安全性高，更新失敗不會磚機 缺點：需要對等的兩個應用空間，限制應用程式大小

單bank DFU（新實現）：

Flash Layout:
┌─────────────────────┐ 0x00000000
│    Bootloader       │
├─────────────────────┤ 0x00008000
│                     │
│  Application Space  │ (更大的可用空間)
│                     │
├─────────────────────┤ 0x000E0000
│   User Data         │
└─────────────────────┘

優點：最大化應用程式空間，適合資源受限設備 缺點：更新過程中存在風險，需要可靠的更新機制

單bank DFU 技術實現

更新流程設計：

1. 進入更新模式

// 應用程式觸發更新
void enter_dfu_mode(void) {
    // 保存關鍵狀態
    save_application_state();
    
    // 設置更新標誌
    set_dfu_flag();
    
    // 軟重啟進入 Bootloader
    NVIC_SystemReset();
}

2. Bootloader 驗證

// Bootloader 中的驗證邏輯
bool validate_new_firmware(uint32_t fw_addr, uint32_t fw_size) {
    // 1. 檢查數位簽名
    if (!verify_digital_signature(fw_addr, fw_size)) {
        return false;
    }
    
    // 2. 檢查韌體完整性
    if (!verify_checksum(fw_addr, fw_size)) {
        return false;
    }
    
    // 3. 檢查版本相容性
    if (!check_version_compatibility(fw_addr)) {
        return false;
    }
    
    return true;
}

3. 原地更新實現

void update_firmware_in_place(uint32_t new_fw_addr, uint32_t new_fw_size) {
    // 分段更新，避免掉電風險
    uint32_t sector_size = FLASH_SECTOR_SIZE;
    uint32_t sectors = (new_fw_size + sector_size - 1) / sector_size;
    
    for (uint32_t i = 0; i < sectors; i++) {
        uint32_t sector_addr = APPLICATION_START_ADDR + i * sector_size;
        uint32_t src_addr = new_fw_addr + i * sector_size;
        
        // 擦除並寫入新扇區
        flash_erase_sector(sector_addr);
        flash_write_sector(sector_addr, src_addr, sector_size);
        
        // 每個扇區完成後驗證
        if (!verify_sector(sector_addr, sector_size)) {
            // 更新失敗，停留在 Bootloader
            enter_recovery_mode();
            return;
        }
    }
    
    // 更新完成，跳轉到新應用
    jump_to_application();
}

風險控制機制

斷電保護策略：

1. 分段更新：每次只更新一個 Flash 扇區
2. 進度記錄：在專用區域記錄更新進度
3. 回滾機制：保留最小可運行版本

錯誤恢復流程：

void handle_update_failure(void) {
    // 檢查失敗類型
    dfu_error_t error = get_dfu_error();
    
    switch (error) {
        case DFU_ERROR_POWER_LOSS:
            // 斷電恢復，繼續未完成的更新
            resume_interrupted_update();
            break;
            
        case DFU_ERROR_INVALID_FIRMWARE:
            // 韌體無效，回滾到安全模式
            enter_recovery_mode();
            break;
            
        case DFU_ERROR_FLASH_WRITE:
            // Flash 寫入錯誤，嘗試修復
            repair_flash_errors();
            break;
    }
}

市場生態與競爭分析

Nordic 在藍牙 LE 市場的地位

市場占有率數據：

• 藍牙 LE SoC 市場占有率：約 40%（2024）
• 累積出貨量：超過 50 億顆
• 客戶數量：數千家活躍開發者

技術優勢分析：

1. 軟體生態成熟

   • NRF5 SDK：經過 9 年迭代優化
   • NRF Connect SDK：基於 Zephyr 的現代化平台
   • 豐富的範例程式和文件

2. 硬體性能領先

   • 功耗效率業界前茅
   • RF 性能穩定可靠
   • 豐富的周邊接口

3. 開發工具完善

   • nRF Connect for VS Code
   • 功耗分析工具
   • 協定分析器

競爭對手分析

主要競爭對手比較：

廠商	代表產品	優勢	劣勢
Nordic	nRF54L	生態成熟、功耗優秀	價格較高
Silicon Labs	EFR32	多協定支援強	軟體學習曲線陡
Espressif	ESP32	成本低、WiFi 整合	功耗較高
Dialog	DA1469x	超低功耗	生態相對小

Nordic Bare Metal 選項的競爭優勢：

1. 降低遷移門檻：讓現有客戶輕鬆升級硬體
2. 保持生態黏性：避免客戶流失到其他平台
3. 擴大適用範圍：吸引偏好 bare metal 的開發者

第三方生態支援

模組合作夥伴：

• Raytac：AN54L15Q 模組，已通過 FCC/CE 認證
• Laird Connectivity：工業級模組產品線
• u-blox：NINA-B5 系列模組

開發工具整合：

• Segger：J-Link 除錯器支援
• IAR：編譯器工具鏈
• Keil：MDK-ARM 開發環境

Edge AI 生態：

• Edge Impulse：已支援 nRF54L15 DK
• ST：X-NUCLEO-IKS02A1 感測器擴展板
• TensorFlow Lite：微控制器 ML 推理

未來發展路線圖與技術趨勢

Nordic 官方路線圖

2025 年發展計劃：

1. Q1 2025：

   • S115 軟體設備正式版（production ready）
   • 藍牙資格認證完成
   • 單bank DFU 穩定版發布

2. Q2-Q3 2025：

   • S145 多角色軟體設備發布
   • 支援 Central 和 Observer 模式
   • NFC 功能整合

3. Q4 2025：

   • S145 production ready 版本
   • 性能優化和功耗降低
   • 更多範例程式和文件

長期發展方向：

1. 硬體演進

   • nRF54H 系列：面向高性能應用
   • 更先進的製程技術
   • AI 協處理器整合

2. 軟體功能擴展

   • 更多協定支援考慮中
   • 安全功能強化
   • 開發工具持續改善

嵌入式開發趨勢分析

技術發展趨勢：

1. Edge AI 普及

   • TinyML 在 MCU 上的部署
   • 感測器融合與智能決策
   • 即時機器學習推理

2. 安全性要求提升

   • IoT 安全法規趨嚴
   • 硬體安全模組標配
   • 端到端加密普及

3. 多協定整合

   • Matter 生態成熟
   • Thread 與 WiFi 協作
   • 5G RedCap 在 IoT 的應用

4. 開發效率優化

   • 低程式碼/無程式碼開發
   • AI 輔助程式設計
   • 雲端開發環境普及

對 Bare Metal vs RTOS 選擇的影響：

1. Bare Metal 仍有價值

   • 超低功耗應用需求持續存在
   • 安全關鍵應用偏好簡單架構
   • 成本敏感市場的重要性

2. RTOS 功能持續擴展

   • AI 推理需要複雜任務管理
   • 多協定併行處理需求增長
   • OTA 和遠程管理成為標配

開發者技能發展建議

技術能力建構：

1. 基礎技能

   • 深度理解藍牙 LE 協定
   • 熟練掌握 C/C++ 嵌入式開發
   • 硬體除錯和分析能力

2. 進階技能

   • RTOS 原理和實作
   • 無線射頻知識
   • 功耗優化技術

3. 新興技能

   • Edge AI 和 TinyML
   • 資訊安全最佳實務
   • IoT 雲端整合

學習資源推薦：

1. 官方資源

   • Nordic Developer Academy
   • Technical documentation
   • Github 範例程式庫

2. 社群資源

   • DevZone 技術論壇
   • Zephyr Project 社群
   • 技術會議和工作坊

實戰建議與最佳實務

專案啟動檢查清單

技術評估階段：

□ 應用複雜度分析
  □ 任務數量 < 3 個 → 考慮 Bare Metal
  □ 需要嚴格時序控制 → 傾向 Bare Metal
  □ 多協定併行 → 建議 RTOS

□ 資源限制評估  
  □ RAM < 128KB → Bare Metal 優勢明顯
  □ Flash < 512KB → 考慮單bank DFU
  □ 功耗 < 10μA → 兩者差異不大

□ 團隊技能匹配
  □ NRF5 SDK 經驗 → Bare Metal 學習成本低
  □ RTOS 開發經驗 → Zephyr 上手快
  □ 新手團隊 → 建議從範例開始

開發環境設置：

1. 必要工具安裝

# 基礎工具鏈
nrf-util install toolchain-manager
nrf-util install device

# VS Code 擴展
code --install-extension nordic-semiconductor.nrf-connect

# 除錯工具
# 確保 J-Link 驅動已安裝

2. 專案模板選擇

應用類型	推薦模板	說明
簡單感測器	peripheral_lbs	LED/按鈕控制範例
數據收集	peripheral_uart	UART 數據傳輸
心率監測	peripheral_hrs	標準健康服務
自定義服務	peripheral_template	空白模板

除錯技巧與故障排除

常見問題診斷：

1. 藍牙連接問題

// 增加除錯訊息
#define NRF_LOG_MODULE_NAME main
#define NRF_LOG_LEVEL 4
#include "nrf_log.h"

void on_ble_evt(ble_evt_t const * p_ble_evt) {
    switch (p_ble_evt->header.evt_id) {
        case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected to device");
            break;
        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected, reason: %d", 
                        p_ble_evt->evt.gap_evt.params.disconnected.reason);
            break;
    }
}

2. 功耗分析技術

// 使用 Power Profiler Kit 配合程式碼標記
void enter_measurement_mode(void) {
    // 標記測量開始
    nrf_gpio_pin_set(DEBUG_PIN_1);
    
    // 執行測量任務
    perform_sensor_reading();
    
    // 標記測量結束  
    nrf_gpio_pin_clear(DEBUG_PIN_1);
}

3. 記憶體使用監控

# 編譯後分析記憶體使用
arm-none-eabi-size build/zephyr/zephyr.elf

# 詳細的記憶體分配報告
arm-none-eabi-objdump -h build/zephyr/zephyr.elf

效能優化策略

程式碼層級優化：

1. 中斷處理最小化

// 錯誤範例 - 在中斷中做複雜處理
void TIMER0_IRQHandler(void) {
    if (NRF_TIMER0->EVENTS_COMPARE[0]) {
        // 避免在中斷中做複雜運算
        complex_data_processing();  // ❌
        NRF_TIMER0->EVENTS_COMPARE[0] = 0;
    }
}

// 正確範例 - 中斷中只設置標誌
volatile bool data_ready = false;

void TIMER0_IRQHandler(void) {
    if (NRF_TIMER0->EVENTS_COMPARE[0]) {
        data_ready = true;  // ✅
        NRF_TIMER0->EVENTS_COMPARE[0] = 0;
    }
}

// 在主循環中處理
int main(void) {
    while (1) {
        if (data_ready) {
            complex_data_processing();
            data_ready = false;
        }
        power_manage();
    }
}

2. 記憶體存取優化

// 結構體對齊優化
typedef struct {
    uint32_t timestamp;    // 4 bytes
    uint16_t sensor_value; // 2 bytes  
    uint8_t  status;       // 1 byte
    uint8_t  reserved;     // 1 byte padding
} __attribute__((packed)) sensor_data_t;  // 總共 8 bytes

系統層級優化：

1. 時鐘配置優化

// 根據應用需求選擇時鐘源
static void clock_init(void) {
    // 高精度應用使用外部晶振
    nrf_clock_lfclk_t lfclk_cfg = {
        .source = NRF_CLOCK_LFCLK_Xtal,
        .accuracy = NRF_CLOCK_LFCLK_ACCURACY_20_PPM
    };
    
    // 成本敏感應用使用內部 RC
    // .source = NRF_CLOCK_LFCLK_RC
}

2. 功耗模式管理

void power_manage(void) {
    // 檢查是否有待處理事件
    if (!pending_events()) {
        // 進入最深睡眠模式
        sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
        sd_app_evt_wait();
    }
}

結論：技術選擇的智慧

經過深入分析，Nordic NRF Connect SDK Bare Metal 選項確實為嵌入式開發社群帶來了有價值的新選擇。它不只是一個技術產品，更是對開發者需求的深刻理解。

核心價值總結

技術層面的突破：

1. 性能數據證實：功耗和記憶體使用的實測數據破除了許多迷思
2. API 相容性：與 NRF5 SDK 的高度相容降低了遷移成本
3. 開發體驗：統一的工具鏈讓 bare metal 和 RTOS 並存

商業價值體現：

1. 降低遷移壁壘：讓現有客戶能夠無痛升級硬體
2. 擴大市場覆蓋：吸引偏好 bare metal 的開發者群體
3. 生態系統完整：從晶片到工具的端到端支援

實務建議精華

選擇決策框架：

• 簡單應用 + 資源受限 → Bare Metal
• 複雜應用 + 豐富功能 → Zephyr RTOS
• 現有程式碼 + 遷移需求 → 優先考慮 Bare Metal
• 新專案 + 未來擴展 → 建議使用 Zephyr

成功要素：

1. 深入理解應用需求：不要被表面的技術特性迷惑
2. 基於數據做決策：參考實測性能而非主觀印象
3. 考慮長期發展：技術選擇要配合產品路線圖
4. 團隊技能匹配：選擇符合團隊經驗的技術路線

未來展望

Nordic 這次推出 Bare Metal 選項，展現了成熟技術公司對市場需求的敏銳洞察。在 RTOS 成為主流趨勢的今天，仍然為 bare metal 開發保留一席之地，體現了技術多元化的價值。

對於嵌入式開發者而言，這意味著更多的選擇自由，也意味著更高的技術判斷要求。關鍵在於理解不同方案的本質差異，結合具體應用場景做出明智選擇。

技術沒有絕對的優劣，只有適合與否。Nordic NRF Connect SDK Bare Metal 選項為我們提供了一個很好的範例：如何在技術進步和開發者需求之間找到平衡點。

無論最終選擇哪種技術路線，持續學習和保持開放心態都是開發者成長的關鍵。畢竟，技術工具會改變，但解決問題的思維方式和對品質的追求永遠不會過時。

---

這篇文章基於 Nordic Semiconductor 官方 webinar 內容以及多方技術資料整理而成。所有性能數據來自官方測試報告，建議讀者在實際專案中進行驗證。

相關資源連結：

• Nordic 官方文件
• NRF Connect SDK Bare Metal 選項
• 開發者學院
• 技術支援論壇

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 你的 BLE 天線為什麼收訊爛透了？Nordic Pi 型匹配網路與 NanoVNA 調試完整實戰
• Raspberry pico 使用 zephyr 進行開發
• 我把整個 Meshtastic 網路搞癱了，然後學會了這些設定技巧
• 當藍牙也能精確定位到 10 公分：我為什麼對 nRF54L 的 Channel Sounding 技術如此興奮

花 50 萬偷走 2 億的能力——Anthropic 蒸餾攻擊事件背後的殘酷經濟學

$50 萬美元和 $2 億美元，差距 400 倍。

這不是什麼創投的槓桿故事，而是 AI 產業正在上演的一場結構性危機：用不到 50 萬美元的 API 費用，就能提取出花了 2 億美元訓練的前沿模型能力。

2026 年 2 月 23 日，Anthropic 發了一篇長達數千字的部落格文章 點名指控：直接說出名字並提出指控或批評 AI 實驗室——DeepSeek、Moonshot AI（Kimi）和 MiniMax——對 Claude 進行了「工業級蒸餾攻擊」。24,000 個假帳號、超過 1,600 萬次交互、橫跨多家雲端平台的「九頭蛇」代理網路。

但在社群炸鍋之前，我想先聊一個更根本的問題：**為什麼蒸餾這麼難擋？**因為答案藏在一道殘酷的經濟學裡。

---

先搞清楚發生了什麼事

簡單版本：三家中國公司透過假帳號大量查詢 Claude，收集回覆來訓練自己的模型。

實驗室	交互次數	主要目標	一句話特色
DeepSeek	15 萬+	推理能力、獎勵模型	量最小，手法最精密
Moonshot AI	340 萬+	Agent 推理、電腦視覺	嘗試逆向工程推理軌跡
MiniMax	1,300 萬+	Agentic coding、工具編排	規模最大，新模型發布 24 小時內重導流量

Anthropic 說它是怎麼抓到的？IP 位址關聯、請求 metadata、基礎設施指標，以及其他 AI 公司的交叉通報。在 DeepSeek 的案例中，同步帳號流量和共用付款方式甚至讓 Anthropic 追蹤到了具體研究人員的身份。

三家公司截至目前均未正式回應。

---

三種手法，三種哲學

這三家的手法差異其實很有意思——它們幾乎代表了蒸餾攻擊的三種不同「流派」。

DeepSeek：用 Claude 當免費獎勵模型

DeepSeek 的交互量最小，只有 15 萬次。但如果你懂 RL（強化學習）訓練的瓶頸，就知道它的手法有多聰明。

訓練推理模型最貴的環節之一不是算力，而是獎勵模型（Reward Model）——你需要一個夠強的模型來評判其他模型的輸出好不好。DeepSeek 做了什麼？讓 Claude 用評分標準（rubric）評估大量輸出。等於把 Anthropic 花了數億美元訓練出來的 Claude，變成了自己免費的 RL 打分員。

另一個手法也很典型：要求 Claude 「想像完成回答背後的內部推理，並逐步寫出來」。這就是在批量產生 chain-of-thought 訓練資料——推理模型最核心的訓練燃料。

還有一個政治層面的細節：DeepSeek 要求 Claude 為「政策敏感查詢」建立審查安全的替代方案——關於異議人士、黨領導人、威權主義的問題。這很可能是在訓練自家模型的政治審查能力。

Moonshot AI / Kimi：逆向工程思考過程

Moonshot 的 340 萬次交互更直接。它聚焦在 Agent 推理、工具使用、Computer Use 代理開發這些能力上，但後期的攻擊方向讓人印象深刻：直接嘗試重建 Claude 的推理軌跡（reasoning trace）。

怎麼說呢，推理能力是前沿模型最難複製的部分。模型架構可以抄，訓練數據可以爬，但思考的「方式」很難靠表面輸出完全還原。Moonshot 嘗試的，接近於逆向工程一個人的思考過程——不只要你的答案，還要你是「怎麼想到的」。

這針對的是最具商業壁壘的那層能力。

MiniMax：工業級流水線

MiniMax 的 1,300 萬次交互在規模上就是另一個量級了。但最讓我在意的不是量，而是它的即時反應能力。

Anthropic 說：Claude 新模型發布後 24 小時內，MiniMax 將近 50% 的流量重導至新版本。

24 小時。

這意味著 MiniMax 有一套持續運作的系統在即時追蹤 Anthropic 的能力邊界。蒸餾對它來說不是一次性的偷襲，而是持續性的供應鏈操作。

更戲劇性的是，Anthropic 在 MiniMax 正在訓練準備發布的模型時偵測到了攻擊——等於在對方「烹飪中」就聞到了味道。

---

殘酷的經濟學：為什麼蒸餾擋不住

這是整件事最核心的問題，也是我覺得大家討論最少的部分。

先看一張表：

模型	估算訓練成本	來源
GPT-4	$78M（僅計算成本）	Stanford 2025 AI Index
Gemini Ultra	$191M	Stanford 2025 AI Index
GPT-5	$500M+	業界估算
DeepSeek V3（最終 run）	$5.6M	官方公布
DeepSeek R1（最終 run）	$294K	官方公布（建立在 V3 基礎上）

根據 Epoch AI 的研究，前沿模型訓練成本以每年 2.4 倍的速度增長，2027 年最大的訓練 run 將超過 10 億美元。

那蒸餾呢？我試著估算 MiniMax 1,300 萬次交互的 API 費用：

Claude Sonnet 級別：$3/$15 per M tokens
每次交互平均 1,500 tokens input + 2,000 tokens output

Input: 1,300萬 × 1,500 = 195 億 tokens → <sub>$58,500
Output: 1,300萬 × 2,000 = 260 億 tokens → </sub>$390,000
──────────────────────────────────────────────
正價 API 成本估算：~$448,500

但它們用的是假帳號和代理服務——免費額度、教育帳號折扣、批量代理價格。實際支出可能更低。

把所有方式攤開來比較：

獲取前沿能力的方式	估算成本	時間	性價比倍數
從零訓練前沿模型	$100M-$500M	12-24 個月	1x
高效訓練（DeepSeek V3 模式）	$5.6M-$50M	6-12 個月	10-100x
RL 蒸餾自家模型（R1 模式）	$294K-$5M	1-3 個月	100-1,000x
非法蒸餾他人 API	$50K-$500K	1-4 週	1,000-10,000x

Databricks CEO Ali Ghodsi 去年說過一句話：「蒸餾技術極其強大且極其便宜，任何人都可以使用。」

歷史先例更誇張——2023 年 3 月，Stanford 研究者用 GPT-3.5 的 52,000 個輸出蒸餾出 Alpaca 模型，成本僅 $600，表現卻接近 ChatGPT。

花 50 萬偷到值 2 億的能力，ROI 400 倍。 這種經濟不對稱，靠 ToS（服務條款）是擋不住的。

---

九頭蛇集群與 11 天三箭齊發

打地鼠遊戲

Anthropic 在中國沒有提供商業存取。那這三家怎麼做到 1,600 萬次交互的？

答案是「商業代理服務」——Anthropic 管這些基礎設施叫「九頭蛇集群」（hydra cluster）。一個代理網路同時管理超過 20,000 個假帳號，把蒸餾流量和正常客戶請求混在一起發送。封一個帳號，立刻冒出兩個新的。

組件	用途
代理網路	偽裝流量來源，管理 20,000+ 帳號
負載平衡	跨多家雲端平台分散請求
流量混合	蒸餾請求藏在正常流量裡
支付輪換	不同帳號用不同付款方式
帳號工廠	利用教育和研究帳號的驗證漏洞批量建立

這本質上是一場打地鼠遊戲，而且地鼠方占有結構性優勢。

但時機也很值得玩味

日期	公司	行動
2/12	OpenAI	向眾議院中國委員會提交蒸餾指控備忘錄
2/12	Google	GTIG 報告 Gemini 遭 100,000+ 提示蒸餾攻擊
2/23	Anthropic	發布部落格，揭露三家中國實驗室

三家美國 AI 巨頭在 11 天內同步揭露蒸餾攻擊。

背景是什麼？川普政府 2026 年 1 月正式允許 Nvidia 向中國出口 H200 晶片。批評者認為這削弱了出口管制。而 Anthropic 的報告直接寫：「蒸餾攻擊強化了出口管制的理由。」

Implicator.ai 的分析說得最精準：「攻擊是真的。編排也是真的。」（The attacks are real. So is the choreography.）

攻擊確實發生了，數據確實存在。但三家公司同步曝光的時機，顯然也帶有政策遊說的意圖。這兩件事可以同時為真。

---

偷竊還是雙重標準？社群炸了

Anthropic 的文章發出來不到幾小時，社群就分成了兩派，而且批評方的聲量明顯更大。

Elon Musk 在 X 上直接開砲：

「Anthropic 在大規模竊取訓練數據方面有罪，已經不得不支付數十億美元的和解金。」

IO.Net 共同創辦人 Tory Green：

「你用公開網路訓練，然後別人從你學就叫『蒸餾攻擊』。」

Reddit r/LocalLLaMA 上的高讚留言：

「很難認真看待，當每個基礎模型都建立在未經同意爬取的網路數據上。」

The Register 的標題更直接：「Anthropic 指控中國 AI 實驗室抄襲內容——就像它自己做的那樣。」

說實話，這些批評不是完全沒道理。Anthropic 確實面臨多起版權訴訟（Reddit v. Anthropic、Bartz v. Anthropic 等），而且用公開網路數據訓練模型的合法性到今天還在法庭上打。

但我覺得這個討論很容易滑入一個假二元對立。

爬取公開網路數據和針對性提取商業 API 的專有能力，在性質上還是不同的。打個比方：去圖書館讀書學習，和闖進一家公司的辦公室偷拍他們的研究筆記，就算「學到的東西」很像，行為的性質也不一樣。

更具體地說：

• 公開網路數據被廣泛視為接近「公共財」（雖然也有爭議）
• 蒸餾攻擊使用假帳號、違反服務條款、繞過地區限制——這些是明確的違規行為
• 蒸餾是高度針對性的：不是泛泛地學習，而是精準提取推理、coding、tool use 這些最值錢的能力
• 蒸餾可能移除安全護欄，讓被提取的能力失去安全限制

所以我的看法是：Anthropic 的「偽善」指控有部分道理，但它不構成對蒸餾行為的完整辯護。真正的問題不是「Anthropic 是不是虛偽」——而是蒸餾的經濟不對稱讓這件事幾乎無法靠道德呼籲來解決。

---

法律？幾乎是真空地帶

法律層面的情況比大多數人以為的更模糊：

問題	現狀
AI 模型輸出有版權嗎？	沒有。 美國著作權局 2025/1 明確要求人類創作
蒸餾是 IP 盜竊嗎？	從未被法院測試過。 白宮和 OpenAI 認為是，法律界有分歧
違反 ToS 算違法嗎？	民事違約，不是刑事犯罪
用公開數據訓練合法嗎？	傾向合理使用（2025/6 兩個判例支持），但也有反例

UC Law SF 的一篇學術論文分析了蒸餾的版權問題，結論是：「模型輸出——尤其是預測、補全或生成的回應——更可能被視為事實性或功能性數據，而非表達性作品，因此可能不受保護。」

翻成白話：你問 Claude 一個問題，Claude 的回答在法律上可能不受版權保護。用這些回答來訓練另一個模型，在現行法律下不一定違法——雖然違反了服務條款。

CSIS 建議國會填補這個法律空白，甚至考慮將蓄意蒸餾刑事化。但在那之前，Anthropic 手上最強的武器還是 ToS 和出口管制的政策遊說。

---

所以接下來會怎樣？

這件事揭示了前沿 AI 模型的一個根本矛盾：你要讓模型有用，就必須提供 API。但只要有 API，蒸餾就是可能的。

短期內，我們會看到 API 存取收緊——更嚴格的速率限制、行為指紋偵測、身份驗證。Anthropic 已經在做了：部署了 chain-of-thought 偵測分類器、協調活動偵測工具，還加強了教育帳號的驗證。

但說到底，這是一場打地鼠遊戲。只要蒸餾的 ROI 還是 400 倍、1000 倍，經濟動機就不會消失。

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

graph TD A[前沿模型需要 API 才能商業化] --> B[API 存取讓蒸餾成為可能] B --> C[蒸餾 ROI 極高: 1000-10000x] C --> D[經濟動機驅動持續蒸餾] D --> E[收緊 API → 傷害合法用戶] D --> F[不收緊 → 持續被蒸餾] E --> G[根本矛盾: 無完美解] F --> G

幾個值得觀察的方向：

模型級防禦。 在輸出中嵌入浮水印或「毒丸」——讓蒸餾出來的模型帶有可追蹤的特徵，或在特定條件下性能下降。這在技術上可行但會增加複雜度。

法律武器。 美國國會可能推動蒸餾相關立法。如果 AI 輸出被賦予某種 IP 保護，整個遊戲規則就會改變。

能力許可模式。 也許未來前沿模型不只是賣 API，而是賣「能力許可」——允許你用模型的推理能力但限制你用輸出來訓練。技術上怎麼做到是個大問題。

開源的尷尬位置。 蒸餾指控可能溢出到開源社群。當一個開源模型的表現「太像」某個閉源模型，質疑聲就會出現。DeepSeek 即將發布的 V4 據報導在 coding 上可能超越 Claude 和 ChatGPT——到時候一定會有人問：多少是自研的？多少是蒸餾的？

---

寫在最後

回到開頭的那個數字：$50 萬 vs $2 億。

這不只是一個「中國公司偷美國技術」的故事。它揭示的是 AI 產業的一個結構性問題——前沿能力的價值和保護它的難度之間，存在巨大的鴻溝。

Anthropic 的揭露是真實的。三家公司的蒸餾行為確實違反了服務條款。

但政策遊說的編排也是真實的。11 天內三家美國公司同步行動，時機剛好卡在晶片出口管制辯論的節骨眼。

而社群對「雙重標準」的質疑也有部分道理——雖然爬取公開數據和針對性提取商業 API 在性質上確實不同。

最終，這不是一個「誰對誰錯」就能解決的問題。蒸餾的經濟激勵太強，道德呼籲和 ToS 擋不住 1000 倍的 ROI。它需要技術防禦、法律框架、國際協調同時到位——而這三樣東西目前都還在起步階段。

三家中國公司截至今天都沒有正式回應。DeepSeek V4 據說即將發布。這個故事還遠沒結束。

---

延伸閱讀

• Anthropic 官方部落格：Detecting and preventing distillation attacks
• Google GTIG AI Threat Tracker 報告
• Epoch AI：前沿模型訓練成本分析
• Quanta Magazine：蒸餾如何讓 AI 模型更小更便宜
• CSIS：保護我們的優勢——貿易秘密與全球 AI 軍備競賽
• Implicator.ai：攻擊是真的，遊說也是真的
• Ars Technica：攻擊者用 100,000+ 提示嘗試克隆 Gemini
• UC Law SF：從 Prompt 到 Clone——AI 模型蒸餾的版權挑戰

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 2025 年 LLM Agent 開發框架完整指南：AutoGen、CrewAI、LangGraph 到底該選哪個？
• 當 AI 開始設計 AI：一份讓人睡不著的 2027 預言
• 一週三次改名、加密貨幣詐騙、18 萬顆 GitHub 星 — OpenClaw 如何成為 2026 年最瘋狂的 AI 專案
• OpenClaw 完整攻略：從必設參數到超好用 Skills，一篇搞懂這個 199k Stars 的 AI Agent

小訊號 PCB 設計指南

1. 什麼是小訊號 PCB 設計及其重要性

小訊號通常指電壓或電流幅度較低的訊號，這些訊號非常容易受到外部和內部雜訊源的干擾。因此，小訊號 PCB 設計的核心目標是保護這些脆弱的訊號，確保其完整性，並最大限度地減少雜訊耦合。

為何重要？

• 訊號完整性： 在許多應用中，小訊號攜帶關鍵資訊。任何失真或雜訊都可能導致系統性能下降或完全失效。
• 雜訊敏感性： 低幅度訊號的信噪比 (SNR) 通常較低，使得它們對雜訊更加敏感。
• 應用廣泛： 精密的類比電路，如感測器接口、音訊放大器、醫療儀器和科學測量設備，都依賴於高品質的小訊號處理。

一個成功的設計能夠確保訊號從源頭到目的地都能準確無誤地傳輸，不受雜訊干擾。

2. 小訊號設計中的關鍵挑戰與雜訊來源

在小訊號 PCB 設計中，主要的挑戰在於如何有效地抑制各種雜訊源對訊號的影響。這些雜訊可以分為內部雜訊和外部干擾：

內部雜訊：

• 熱雜訊 (Thermal Noise)： 由於導體中電子隨機運動產生，與溫度和頻寬有關。
• 散粒雜訊 (Shot Noise)： 由於載流子（電子或空穴）通過勢壘（如 PN 結）時的隨機性產生。
• 閃爍雜訊 (Flicker Noise / 1/f Noise)： 在低頻下較為顯著，其來源複雜，與材料缺陷和表面效應有關。與白雜訊和散粒雜訊不同，閃爍雜訊的功率譜密度隨著頻率的增加而降低。

外部干擾：

• 電磁干擾 (EMI)： 來自外部電磁場的耦合，例如電源線、無線通訊、馬達等。
• 串擾 (Crosstalk)： 不同訊號線之間的電磁耦合，導致訊號互相干擾。
• 接地與電源雜訊： 不良的接地和電源分配系統會引入雜訊，影響訊號的參考電壓。

理解這些雜訊來源的特性和傳播途徑，是制定有效抑制策略的基礎。

3. 小訊號 PCB 設計的基本原則

為了有效地抑制雜訊並確保訊號完整性，需要遵循一些基本設計原則：

• 良好的接地策略：

  • 單點接地 (Single-Point Grounding)： 適用於低頻電路，避免地迴路。
  • 多點接地 (Multi-Point Grounding)： 適用於高頻電路，利用低阻抗接地層。
  • 接地層 (Ground Plane)： 提供低阻抗的電流回流路徑，有效降低地彈 (Ground Bounce) 和雜訊耦合。應盡可能使用完整的接地層，並考慮使用接地網格作為屏蔽層。

• 乾淨的電源分配：

  • 專用電源層和接地層： 在多層板中，使用獨立的電源層和接地層可以為電流提供低阻抗路徑，有效減少 EMI。
  • 去耦電容 (Decoupling Capacitors)： 靠近 IC 的電源引腳放置，提供瞬時電流，降低電源雜訊。
  • 濾波 (Filtering)： 使用電感、磁珠或濾波器來隔離不同電路部分的電源雜訊。
  • 多個過孔： 在電源或接地走線上使用多個過孔可以降低電阻，確保連接穩定，尤其是在大電流路徑中。

• 合理的元件佈局：

  • 隔離敏感訊號： 將小訊號電路與大訊號、數位或開關電源電路分開佈局。
  • 最小化迴路面積： 訊號路徑及其回流路徑形成的迴路面積應盡可能小，以減少感應雜訊。較小的迴路意味著較低的電感，從而減少雜訊耦合。
  • 熱管理： 識別發熱元件並將其遠離熱敏元件。使用銅澆注和散熱孔 (Thermal Vias) 來幫助散熱。

• 訊號走線策略：

  • 差分對 (Differential Pairs)： 對於高速或對雜訊敏感的訊號，使用差分對走線可以提高抗雜訊能力。
  • 屏蔽線 (Shielded Traces)： 在必要時，可以使用接地線包圍敏感訊號線進行屏蔽。
  • 避免直角走線： 應使用圓弧或 45 度角走線，減少阻抗不連續和反射。
  • 避免並行走線： 並行走線可能導致串擾，應盡量避免或增加間距。
  • 訊號線敷設在電（地）層上： 在多層板中，將訊號線走在靠近電源或接地層的層上，可以利用這些層作為回流路徑，提高訊號完整性。

遵循這些原則可以顯著提高小訊號電路的性能和可靠性。

4. 小訊號 PCB 設計的進階技術

對於對雜訊極為敏感的應用，可能需要採用一些進階技術來進一步提升性能：

• 屏蔽技術：

  • 法拉第籠 (Faraday Cage)： 使用導電外殼完全包圍敏感電路，有效阻擋外部電磁場。
  • 屏蔽線 (Shielded Cables/Traces)： 使用接地層或接地走線包圍訊號線，減少電磁耦合。

• 隔離技術：

  • 光耦 (Optocouplers)： 通過光信號傳輸，實現電氣隔離，有效阻斷共模雜訊。
  • 變壓器 (Transformers)： 提供電氣隔離，常用於音訊和電源隔離。

• 濾波技術：

  • 主動濾波器 (Active Filters)： 使用運算放大器等元件實現高階濾波，提供更陡峭的濾波特性。
  • 被動濾波器 (Passive Filters)： 使用電阻、電容、電感等元件構成，簡單有效。

• 訊號完整性分析 (Signal Integrity, SI)：

  • 訊號完整性是指訊號在傳輸過程中保持其原始波形的能力。在小訊號和高速設計中，訊號完整性至關重要，它直接影響電路的時序和電壓裕度。
  • 邊緣速度與頻寬： 數位訊號的快速邊緣（上升/下降時間，$T_r/T_f$）是導致訊號完整性問題的主要原因。訊號的有效頻寬 (Bandwidth) 約為 $f_{knee} = 0.35 / T_r$ (或 $T_f$)。這表示即使是相對低速的訊號，其快速的邊緣也包含高頻成分，這些高頻成分容易受到傳輸線效應和雜訊的影響。
  • 傳輸線效應： 當走線長度超過訊號邊緣傳播距離的臨界長度時，走線必須被視為傳輸線。臨界長度約為 $L_{critical} = T_r \times v / 2$，其中 $v$ 是訊號在 PCB 材料中的傳播速度。在傳輸線中，訊號的傳播行為由走線的特性阻抗決定。
  • 特性阻抗 (Characteristic Impedance, Z0)： 傳輸線的特性阻抗是沿著走線傳播的電壓波與電流波之比。它是一個與頻率無關的參數（理想情況下）。Z0 主要由走線的幾何形狀（寬度 W、厚度 T）、PCB 材料的介電常數 (Dielectric Constant, Er) 以及走線與參考平面（接地或電源平面）的距離 H 決定。對於微帶線，Z0 約與 $\sqrt{E_r}$ 成反比，與 H 成正比，與 W 成反比。對於帶狀線，Z0 約與 $\sqrt{E_r}$ 成反比，與走線到兩個參考平面的總距離成正比，與走線寬度成反比。精確的 Z0 計算需要使用場求解器或經驗公式。
  • 阻抗匹配 (Impedance Matching)： 確保訊號源阻抗 ($Z_s$)、傳輸線特性阻抗 ($Z_0$) 和負載阻抗 ($Z_l$) 匹配（$Z_s = Z_0 = Z_l$），可以最大限度地減少訊號反射，防止訊號失真。不匹配的阻抗會導致訊號在阻抗不連續點發生反射，反射係數 (Reflection Coefficient, ρ) = $(Z_l - Z_0) / (Z_l + Z_0)$。反射波與原始波疊加，產生過衝 (Overshoot)、下衝 (Undershoot) 或振鈴 (Ringing)，嚴重影響訊號質量。
  • 反射 (Reflection)： 訊號在阻抗不連續點（如連接器、過孔、元件引腳、走線寬度變化）會發生反射。過孔會引入寄生電容和電感，改變走線的局部阻抗，尤其是在高速訊號路徑上應盡量減少過孔的使用。
  • 串擾 (Crosstalk)： 不同訊號線之間的電磁耦合會導致串擾。主要耦合機制包括：
    • 容性耦合 (Capacitive Coupling)： 通過線間電容 ($C_m$) 耦合，與訊號電壓的變化率 ($dV/dt$) 有關。
    • 感性耦合 (Inductive Coupling)： 通過線間互感 ($L_m$) 耦合，與訊號電流的變化率 ($dI/dt$) 有關。 串擾的大小與平行走線的距離、長度、訊號的邊緣速度以及回流路徑的完整性有關。增加線間距、縮短平行走線長度、使用屏蔽線或接地過孔隔離都可以減少串擾。
  • 損耗 (Losses)： 在高頻下，訊號在傳輸線中會發生損耗，導致訊號幅度衰減和波形失真。主要損耗來源包括：
    • 導體損耗 (Conductor Loss / Ohmic Loss)： 由於導線電阻引起，在高頻下由於集膚效應 (Skin Effect) 更加顯著，電流趨向於沿導體表面流動。
    • 介電損耗 (Dielectric Loss)： 由於 PCB 材料的介質損耗角正切 (Loss Tangent, tanδ) 引起，與頻率和介電材料特性有關。高頻下介電損耗更為顯著。
  • 地彈 (Ground Bounce) 和電源雜訊 (Power Integrity, PI)： 當數位電路中的多個輸出同時開關時，會導致瞬時大電流流過接地或電源平面。由於平面的寄生電感 (L) 和電阻 (R)，會產生電壓波動，即地彈 ($V_{bounce} \approx L \times di/dt$) 和電源雜訊 ($V_{noise} \approx I \times R$)。這會影響電路的參考電壓，對小訊號電路造成干擾。良好的電源去耦（使用不同容值的去耦電容並靠近 IC 放置）和低阻抗的電源/接地分配（寬的電源/接地走線或平面）是解決 PI 問題的關鍵。
  • 回流路徑 (Return Path)： 高速訊號電流總是尋找阻抗最低的路徑返回源端，通常是緊鄰訊號走線下方的接地或電源平面。確保回流路徑的連續性和完整性對於控制阻抗、減少迴路面積和抑制 EMI 至關重要。避免在高速走線的回流路徑上開槽或分割平面，否則回流電流會被迫繞道，增加迴路面積和感應雜訊。
  • 終端 (Termination)： 在傳輸線的末端或中間添加匹配電阻，以吸收訊號能量，防止反射。常見的終端方式包括串聯終端（源端終端，適用於點對點拓撲）、並聯終端（負載端終端，適用於多點拓撲）等，選擇哪種方式取決於訊號的拓撲結構、驅動能力和功耗要求。
  • 差分訊號完整性： 對於差分對，除了考慮單端阻抗，還需要考慮差分阻抗 (Differential Impedance) 和共模阻抗 (Common-mode Impedance)。良好的差分對走線（等長、等距、緊密耦合）可以提高抗共模雜訊和 EMI 的能力。
  • 訊號品質評估：
    • 眼圖 (Eye Diagram)： 通過將接收到的數位訊號的多個週期疊加顯示在示波器上形成的圖形。眼圖的「眼睛」張開程度反映了訊號的質量。眼睛越大，訊號裕度越大，抗雜訊能力越強。眼圖可以直觀地顯示反射、串擾、雜訊、時序抖動 (Jitter) 等問題。
    • 時域反射計 (Time Domain Reflectometry, TDR)： 通過發送一個快速上升沿的訊號到走線中，並測量反射訊號來分析走線的阻抗特性和不連續點。
    • S 參數 (S-Parameters)： 用於描述電路或傳輸線在不同頻率下的散射特性，可以分析插入損耗 (Insertion Loss)、回波損耗 (Return Loss) 等，在高頻 SI 分析中非常重要。
  • 模擬分析： 使用專業的 SI/PI 模擬工具（如 Ansys SIwave, Keysight ADS, Cadence Sigrity, HyperLynx 等）可以對特性阻抗、反射、串擾、地彈、電源雜訊、損耗等進行精確分析和預測，幫助設計師在製造前優化佈局、走線和元件選擇。

這些進階技術和理論是確保小訊號在複雜 PCB 環境中可靠傳輸的基礎。深入理解這些概念並結合實際設計經驗，是成為優秀 PCB 設計師的必經之路。

5. 小訊號 PCB 設計中的軟體工具和模擬

現代 PCB 設計離不開專業的軟體工具，特別是在小訊號設計中，模擬和分析工具的作用尤為重要。

• EDA 工具 (Electronic Design Automation)：

  • 常用的工具包括 Altium Designer, KiCad, Eagle 等。
  • 這些工具提供原理圖設計、元件庫管理、PCB 佈局和走線等功能。
  • 在小訊號設計中，特別關注其在佈局規劃、差分對走線、阻抗控制和設計規則檢查 (DRC) 方面的能力。

• 訊號完整性 (Signal Integrity, SI) 模擬工具：

  • 專業的 SI 模擬工具，如 Ansys SIwave, Keysight ADS, Cadence Sigrity, HyperLynx 等。
  • 這些工具可以對訊號傳輸線的阻抗、反射、串擾、電源完整性 (Power Integrity, PI) 進行精確模擬。
  • 通過模擬，可以在製造前發現潛在的問題，優化佈局和走線，確保訊號在高速或敏感電路中的可靠傳輸。

• 如何利用工具：

  • 在設計早期進行佈局規劃和關鍵訊號的預佈線。
  • 利用工具的阻抗計算器來確定走線寬度和間距。
  • 運行 DRC 檢查，確保設計符合製造規範和訊號完整性要求。
  • 對關鍵訊號進行 SI/PI 模擬，驗證設計的性能。

熟練掌握這些工具並結合理論知識，是進行高品質小訊號 PCB 設計的關鍵。

6. 實際案例與注意事項

將理論應用於實踐是小訊號 PCB 設計成功的關鍵。以下是一些實際案例和需要注意的事項：

• 混合訊號電路設計：

  • 在同一塊 PCB 上處理類比和數位訊號時，需要特別小心，以防止數位雜訊干擾敏感的類比電路。
  • 通常建議將類比和數位部分分開佈局。
  • 接地處理： 數位接地和類比接地應盡可能分離。理想情況下，整個 PCB 只有一個連接到外部世界的接地點。板內的數位接地和類比接地實際上是分離的，它們在連接 PCB 到外部世界的介面處（如插頭等）進行短路連接，只有一個連接點。這有助於避免地迴路和雜訊耦合。

• 元件選擇：

  • 選擇低雜訊的運算放大器、穩壓器和精密電阻等元件。
  • 考慮元件的封裝類型，表面貼裝元件 (SMD) 通常比通孔元件 (Through-hole) 具有更好的高頻性能和更小的寄生參數。

• 電源濾波：

  • 除了去耦電容，還可以使用 RC 或 LC 濾波器來進一步濾除電源雜訊，特別是對於敏感的類比電路。

• 熱管理：

  • 雖然小訊號電路功耗通常較低，但某些元件（如功率放大器）可能產生熱量。良好的熱管理可以確保元件穩定工作，並減少溫度變化對訊號的影響。識別發熱元件並將其遠離熱敏元件。

• 製造考慮 (Design for Manufacturing, DFM)：

  • 選擇合適的 PCB 材料，考慮其介電常數和損耗角正切。
  • 控制製造公差，特別是走線寬度和間距，以確保阻抗控制的準確性。
  • 考慮元件的可製造性，例如元件間距、焊盤尺寸等，以確保順利組裝。
  • 元件方向和佈局應考慮到自動化組裝的需求，例如方向一致性、易於抓取等。

• 調試與測試：

  • 在設計完成後，進行充分的測試和調試，使用示波器、頻譜分析儀等儀器來檢查訊號完整性和雜訊水平。
  • 規劃測試點 (Test Points) 以方便測試和故障排除。
  • 考慮設計的可測試性 (Design for Testability, DFT)。

通過實際操作和不斷學習，可以積累經驗，提高小訊號 PCB 設計的能力。

7. 總結與關鍵點

小訊號 PCB 設計是一項需要細心和經驗的工作。成功的關鍵在於「預防勝於治療」。在設計的早期階段就考慮並實施良好的設計原則，遠比在後期嘗試修復雜訊問題更有效和經濟。

關鍵點回顧：

• 理解雜訊來源： 識別內部和外部雜訊源是制定抑制策略的第一步。
• 優化接地和電源： 乾淨、穩定的接地和電源是小訊號電路正常工作的基礎。
• 合理的佈局： 隔離敏感電路，最小化雜訊耦合路徑。
• 精心的走線： 採用差分對、屏蔽等技術，控制阻抗，減少反射和串擾。
• 利用工具和模擬： 藉助 EDA 工具和 SI/PI 模擬，驗證設計並發現潛在問題。
• 考慮實際因素： 注意混合訊號處理、元件選擇、熱管理和製造公差。

將這些原則融入到日常設計流程中，將有助於設計出高性能、高可靠性的小訊號 PCB。

8. 持續學習與資源

PCB 設計領域，特別是小訊號和高速設計，是一個不斷發展的領域。新的技術、材料和工具層出不窮。因此，持續學習對於保持競爭力至關重要。

學習資源建議：

• 經典書籍：
  • "Signal Integrity Issues and Printed Circuit Board Design" by Douglas Brooks
  • "High-Speed Digital Design: A Handbook of Black Magic" by Howard Johnson and Martin Graham
  • "Printed Circuit Board Design Layout" by Walter C. Bosshart
• 技術文章和白皮書： 許多元件製造商和 EDA 軟體供應商會發布有關 PCB 設計的技術文章和應用筆記。
• 線上課程和研討會： Coursera, edX, Udemy 等平台提供相關課程；參加行業研討會可以了解最新趨勢和技術。
• 專業論壇和社群： 參與線上論壇（如 EEVblog Forum, Stack Exchange Electrical Engineering）可以與其他工程師交流經驗，解決問題。
• 動手實踐： 最好的學習方法是通過實際項目來應用所學知識，從錯誤中學習。

不斷學習和實踐，將使您在小訊號 PCB 設計領域更加得心應手。

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• TileLang 完整解析：當 80 行 Python 打敗 500 行 CUDA，GPU 編程的新革命
• 8GB 的 RK3588 能跑多聰明的 LLM？ROCK 5C 用 NPU 實測 5 個模型
• 後 Transformer 時代來了？Mamba-3、ICLR Outstanding Paper、7M 模型同時打三個方向的真相
• KiCad 設計DRC規則

TileLang 完整解析：當 80 行 Python 打敗 500 行 CUDA，GPU 編程的新革命

80 行 Python，實現了跟 FlashMLA 手寫 CUDA 版本同等效能的 GPU kernel。比 PyTorch 快 3.76 倍，比 Triton 快將近 2 倍。而且同一份程式碼，能同時跑在 NVIDIA H100、AMD MI300X、華為 Ascend NPU 上面。

這不是某個 AI 生成的幻覺數據。這是 TileLang 在 ICLR 2026 以 Oral paper 身份發表的實測結果 —— 在近兩萬篇投稿中，只有 1.18% 的論文拿到 Oral。

你可能已經隱約聽過這個名字。2025 年 9 月 DeepSeek 發布 V3.2-Exp 模型時，技術報告裡藏了一段耐人尋味的話：「我們使用高階語言 TileLang 進行快速原型設計......建議社群使用 TileLang 版本進行研究實驗。」同一天，華為、寒武紀、海光同步宣布支持。

這到底是一個純粹的技術突破，還是 GPU 編程生態的板塊位移？我花了相當長的時間研究這個項目的每一個面向。這篇文章，就是我的完整拆解。

---

TileLang 到底是什麼？一句話說清楚

先釐清一個容易混淆的點：TileLang 不是一個新的程式語言，也不是 CUDA 的替代品。它是一套 Python 嵌入式的領域特定語言（DSL），專門用來寫 GPU/CPU/加速器上的高效能運算 kernel。

什麼意思呢？你用 Python 的語法寫程式碼，但 TileLang 的編譯器會把你寫的東西轉換成跟手寫 CUDA 同等效能的底層指令。

它的核心抽象是 Tile（方塊/磁磚）。在 GPU 的世界裡，效能瓶頸往往不在運算本身，而在資料搬運。資料要從全域記憶體搬到共享記憶體，再搬到暫存器，每一層的頻寬和延遲都天差地別。TileLang 讓你用「方塊」的視角來思考這些資料搬運 —— 你告訴編譯器「把這塊資料放到共享記憶體」、「在暫存器裡做矩陣乘法」，至於底下怎麼分配線程、怎麼做記憶體排列，編譯器幫你搞定。

這跟 CUDA、Triton 有什麼不一樣？看一個直覺的對比：

框架	你需要管什麼	編譯器幫你做什麼
CUDA	線程、warp、共享記憶體、同步、指令排程	幾乎不幫你
Triton	Block 級運算邏輯	記憶體管理、部分排程
TileLang	Tile 級資料流和記憶體放置	Layout 推導、流水線、warp 特化

簡單說，CUDA 是手動擋，Triton 是半自動，TileLang 是帶主動安全輔助的自動擋 —— 但你仍然可以隨時切回手動模式。

---

從北大實驗室到 ICLR Oral：背後的故事

TileLang 的故事要從北京大學說起。主要開發者 LeiWang1999（王磊）在楊智教授的指導下，和團隊成員 chengyupku、nox-410 一起打造了這個專案。部分工作是在微軟研究院實習期間完成的，微軟的 Lingxiao Ma、Yuqing Xia 等研究員也提供了重要指導。

時間線大致是這樣的：

• 2024 年：核心開發期，同時開發了 BitBLAS（混合精度計算庫）作為早期驗證
• 2025 年 1 月 20 日：正式開源，首個版本發布
• 2025 年 2 月：v0.1.0 發布，加入 debug 工具和 WebGPU 支持
• 2025 年 3 月：80 行 Python 實現 FlashMLA，效能打平手寫 CUDA
• 2025 年 4 月：論文提交 arXiv（2504.17577）
• 2025 年 9 月：DeepSeek V3.2-Exp 正式採用 TileLang operators
• 2025 年 12 月：加入 CuTe DSL 後端；同月 NVIDIA 推出 CUDA Tile
• 2026 年 1 月：被 ICLR 2026 接受為 Oral paper
• 2026 年 2 月：TileLang Puzzles 互動學習工具上線

一年出頭的時間，從零到 5,200+ GitHub stars，被頂級會議 Oral 接受，被 DeepSeek 這種量級的項目採用。這個速度在開源基礎設施項目裡相當罕見。

---

編譯器深度拆解：五階段管線如何運作

TileLang 真正的技術含量藏在它的編譯器裡。你寫的那 80 行 Python，要經過五個階段才能變成 GPU 上飛速運行的機器碼。

管線全貌

Python Code → Parser → IR Builder → Optimization → Codegen → GPU Execution
                ↓          ↓            ↓              ↓
           Python AST   TVM IR    Layout/Pipeline   CUDA C/HIP C/
           → TileLang             Inference         LLVM IR
              AST

第一步 Parser：你用 @T.prim_func 裝飾器寫的 kernel 函式，先被解析成 Python AST，再轉成 TileLang 自己的 AST。

第二步 IR Builder：AST 被轉換成 TVM 的中間表示（IR）。TileLang 建構在 Apache TVM 之上，這讓它能直接利用 TVM 成熟的語法樹基礎設施。

第三步 Optimization：這是魔法發生的地方。三大核心優化在這裡執行。

第四步 Codegen：優化後的 IR 被翻譯成目標平台的程式碼 —— CUDA C/C++、HIP C/C++、或 LLVM IR。

第五步 Execution：JIT 編譯並在目標硬體上執行。

三大核心優化機制

要理解 TileLang 為什麼能用這麼少的程式碼達到這麼高的效能，關鍵在這三個編譯器 pass：

1. Layout Inference（佈局推導）

你在 TileLang 裡分配一塊共享記憶體或暫存器，不需要指定它該怎麼在線程之間分配。編譯器會根據後續的運算（比如 T.gemm）自動推導出最佳的記憶體佈局和線程綁定。

這用一個分層優先級系統實現 —— 越高優先級的運算（比如 Tensor Core 的 GEMM）對佈局有越嚴格的要求，編譯器從上往下逐層推導，直到所有 buffer 的佈局都確定。

2. Pipeline Inference（流水線推導）

在高效能 kernel 裡，資料搬運和計算要重疊執行。傳統做法需要開發者手動設計 software pipeline —— 在 CUDA 裡這意味著大量的 barrier、async copy、多重 buffer。TileLang 只需要你指定 T.Pipelined(iters, num_stages=N)，編譯器會自動分析依賴關係，決定哪些操作可以重疊。

3. Warp Specialization（自動 warp 特化）

在 NVIDIA Hopper（H100）架構上，最佳效能需要 warp specialization：讓一部分 warp 專門負責資料搬運（用 TMA），另一部分專門做計算。手動實現這個需要管理 mbarrier 同步物件、生產者/消費者邏輯 —— 這在 CUDA 裡是極其痛苦的工作。

TileLang 完全自動化了這個過程。它分析 buffer 的使用模式，自動將語句分類為生產者和消費者，然後插入正確的同步屏障。

實際程式碼長什麼樣？

一個用 TileLang 寫的矩陣乘法 kernel，核心邏輯大概是這樣：

import tilelang
import tilelang.language as T

@tilelang.jit
def matmul(A, B, block_M=128, block_N=128, block_K=32):
    M, K = A.shape
    K, N = B.shape
    C = T.empty((M, N), A.dtype)

    with T.Kernel(T.ceildiv(N, block_N), T.ceildiv(M, block_M), threads=128) as (bx, by):
        A_shared = T.alloc_shared((block_M, block_K), A.dtype)
        B_shared = T.alloc_shared((block_K, block_N), B.dtype)
        C_local  = T.alloc_fragment((block_M, block_N), "float32")
        T.clear(C_local)

        for ko in T.Pipelined(T.ceildiv(K, block_K), num_stages=3):
            T.copy(A[by * block_M, ko * block_K], A_shared)
            T.copy(B[ko * block_K, bx * block_N], B_shared)
            T.gemm(A_shared, B_shared, C_local)

        T.copy(C_local, C[by * block_M, bx * block_N])
    return C

注意看 —— 沒有 threadIdx，沒有手動同步，沒有記憶體佈局計算，沒有 warp 分工。你只需要說「分配共享記憶體」、「複製資料」、「做矩陣乘法」、「用 3 階段流水線」。剩下的，編譯器全包了。

---

效能數據不會說謊：TileLang 的硬實力

空談設計哲學沒有意義，看數字。以下數據來自 TileLang 論文和 AMD ROCm 技術部落格的實測結果。

FlashMLA Benchmark（DeepSeek 的 MLA 注意力機制）

框架	相對延遲（越低越好）	代碼量
PyTorch	1.00x（基準）	N/A
Triton	0.655x	200+ 行
TileLang	0.371x	80 行
FlashMLA (CUDA)	~0.37x	數千行 CUDA + CUTLASS

TileLang 用 80 行 Python 達到了跟手寫 CUTLASS 模板相當的效能，這不是小幅改進，這是量級上的開發效率提升。

跨平台效能摘要

根據 ICLR 2026 論文的 Abstract：

• NVIDIA H100：比 Triton 快最高 5 倍
• AMD MI300X：比 Triton 快最高 6 倍

在 AMD MI300X 上的 Flash Attention 測試中，TileLang 實現比原生 PyTorch 快了 2.7 倍，比 Triton 快 1.53 倍。而且自動調優框架搜尋 108 個配置只需要約 1 秒。

什麼場景效能最突出？

TileLang 的效能優勢在 融合型 kernel（fused kernels）上最為明顯 —— 也就是把多個操作合併到一個 kernel 裡的場景。FlashAttention、MLA Decoding、Linear Attention 這類需要精細記憶體管理的複雜 kernel，正是 TileLang 的主戰場。

對於簡單的 elementwise 操作或標準 GEMM，TileLang 和 cuBLAS/Triton 的差距就沒這麼大。Tile 級抽象的優勢在複雜度越高的 kernel 中越能體現。

---

四方混戰：TileLang vs Triton vs CUDA vs cuTile

GPU kernel 編程領域正在經歷一場前所未有的混戰。讓我把幾個主要玩家攤開來比較。

完整對比表

維度	TileLang	Triton	CUDA	NVIDIA cuTile
開發方	北大 / tile-ai	OpenAI	NVIDIA	NVIDIA
語言	Python DSL	Python DSL	C/C++	Python DSL
抽象層級	Tile-level	Block-level	Thread-level	Tile-level
記憶體控制	明確放置	隱式管理	完全手動	隱式
跨平台	NVIDIA + AMD + 華為 + 摩爾	NVIDIA + AMD	僅 NVIDIA	僅 NVIDIA
自動 Warp Specialization	有	開發中	手動	有
自動 Software Pipeline	有	有	手動	有
FP8 支持	部分	完整	完整	完整
生態成熟度	早期	中等	非常成熟	初始
開源	Apache 2.0	MIT	部分	開源

關鍵差異解讀

TileLang vs Triton：最核心的差異在於記憶體控制的粒度。Triton 隱藏了共享記憶體的細節，讓編譯器自動決定。TileLang 則明確暴露記憶體層級，讓開發者可以精確控制資料放在哪裡。這在簡單 kernel 上差異不大，但在複雜融合 kernel（如 FlashAttention）上，TileLang 的明確控制帶來顯著的效能優勢。

TileLang vs cuTile：NVIDIA 在 2025 年 12 月隨 CUDA 13.1 推出了 cuTile，這被廣泛認為是對 TileLang 和 tile 編程趨勢的直接回應。cuTile 的定位跟 TileLang 很像 —— Python DSL、tile 級抽象。但關鍵差異是：cuTile 只支持 NVIDIA GPU，而且目前僅限 Blackwell 架構。TileLang 則是跨平台的。

為什麼 NVIDIA 也跟著做？ Hacker News 上一位用戶一針見血地指出：「NVIDIA 不希望 CUDA 的開發（如 FlashAttention）遷移到 Triton，因為 Triton 也支持 AMD。如果生態從純 CUDA 遷移到 Triton，那對 NVIDIA 的鎖定效應不利。」cuTile 的出現，某種程度上是 NVIDIA 在 tile 編程趨勢下的防禦性佈局。

---

不只是技術：GPU 編程的地緣棋局

如果你只把 TileLang 當成一個技術項目來看，你會錯過故事最重要的一章。

2025 年 9 月 29 日，DeepSeek 發布 V3.2-Exp。同一天，華為 Ascend 團隊更新了 CANN 對 V3.2-Exp 的支持，寒武紀更新了 vLLM-MLU，SGLang 確認了多後端支持。Tom's Hardware 的報導指出，這種同步性暗示著預先協調。

分析機構 HelloChinaTech 的評論更直接：「TileLang 的推出標誌著建構中國自主 AI 軟體棧的第二階段。」第一階段是 FP8 精度標準的建立（DeepSeek V3 的訓練方法論），第二階段就是透過 TileLang 建立跨硬體的編程抽象層。

這個邏輯鏈條是這樣的：

1. 中國的 AI 晶片廠商（華為、寒武紀、摩爾線程、海光）各自有不同的硬體架構
2. 如果每家都要開發者學一套新的編程模型，生態碎片化會極為嚴重
3. TileLang 提供了一個統一的抽象層 —— 同一份程式碼可以編譯到不同後端
4. 這降低了從 CUDA 遷移的門檻，也減少了對 NVIDIA 生態的依賴

但也要保持冷靜。正如 IEEE Spectrum 的分析所指出的，中國晶片廠商的硬體能力與 NVIDIA 仍有代差。軟體棧的統一是必要條件，但不是充分條件。CUDA 的護城河不僅是語言本身，更是 15 年積累的函式庫、工具鏈、開發者社群和 debug 生態。

---

冷靜看待：TileLang 的局限與挑戰

技術文章如果只說好的，不說問題，那就是廣告。TileLang 確實有幾個需要正視的局限。

FP8 支持仍不完善。 學術論文 Tawa（arXiv: 2510.14719）的實測數據顯示，在 FP8 精度下，TileLang 的 GEMM 效能落後 Tawa 最高 3.99 倍，FlashAttention 的 FP8 配置甚至無法成功執行。論文指出原因是 TileLang 缺乏處理 FP8 WGMMA 路徑所需的佈局管理和流水線調度。在 FP8 訓練越來越普及的當下，這是一個必須盡快補上的短板。

生態仍處於早期階段。 5,200 個 GitHub stars 聽起來不少，但跟 Triton 的生態規模相比仍有明顯差距。文件、教學資源、第三方整合都還在建設中。好消息是 TileLang Puzzles 等互動學習工具正在降低入門門檻。

設計上的限制。 社群開發者在實作 DeepSeek DSA（Dynamic Sparse Attention）時發現，TileLang 0.1.6 版本在非 per-head layout 的場景下存在限制，無法很好地支持某些進階開發思路（相關 Issue #1199）。

主要針對 AI workload。 TileLang 的抽象是為深度學習運算（GEMM、Attention、Convolution）量身設計的。如果你的需求是通用的 GPU 計算（圖形渲染、物理模擬、密碼學），CUDA 仍然是更好的選擇。

---

開發者該怎麼做？實際行動建議

說了這麼多，對於不同角色的讀者，我的建議是不一樣的。

如果你是 AI 研究者

TileLang 是你現在就該開始學的工具。原因很簡單：用 80 行 Python 實現一個跟 CUTLASS 同等效能的 MLA kernel，這種開發效率的提升對研究的迭代速度有根本性的影響。DeepSeek 官方推薦研究者使用 TileLang 版本，這不是客套話。

上手路徑：

1. pip install tilelang 安裝
2. 跑一遍 TileLang Puzzles（10 個漸進式題目）
3. 閱讀 FlashMLA 的 80 行實現
4. 在你的研究中嘗試用 TileLang 做快速原型

如果你是 GPU 工程師

把 TileLang 加入你的工具箱，但不要丟掉 CUDA。TileLang 擅長的是快速原型和跨平台部署，CUDA 擅長的是極致效能調優和通用計算。一個合理的工作流程是：先用 TileLang 快速驗證想法和算法正確性，再視需要用 CUDA 做最後一哩路的效能榨取。

同時，密切關注 NVIDIA cuTile 的發展。tile 編程模型已經是確定的趨勢，無論你最終選擇哪個框架，理解 tile 級抽象的思維方式都是值得投資的。

如果你是技術決策者

關鍵觀察：GPU 編程正在從 thread-level 往 tile-level 遷移，這是一個跟 2012 年深度學習框架從手寫反向傳播到自動微分一樣量級的抽象層級提升。TileLang、Triton、cuTile 代表的是同一個方向的不同實現。

現在就要做的：

• 評估你的團隊對 CUDA 的依賴程度
• 在非關鍵路徑上試點 TileLang 或 Triton
• 如果你需要跨 NVIDIA/AMD 部署，TileLang 的跨平台能力是一個實質優勢

---

Tile 編程時代已經到來

回到開頭的問題：TileLang 是真正的技術革命，還是曇花一現？

我的判斷是：TileLang 本身還太早期，無法預測它是否會成為最終的贏家。但 tile 編程模型作為一個範式，已經是確定的趨勢。

證據就在競爭者的反應裡。NVIDIA 推出 cuTile，OpenAI 的 Triton 也在開發 warp specialization，NVIDIA 還發表了 Tilus —— 每個人都在往同一個方向跑。當一個技術方向能讓所有主要玩家同時響應，你就知道這不是曇花一現。

TileLang 的獨特價值在於三件事：它是開源的、它是跨平台的、它已經被工業級項目（DeepSeek）驗證。在一個 NVIDIA 鎖定效應主導的世界裡，這三個特性加在一起，足以讓它成為值得長期關注的項目。

至於那 80 行 Python？那不是重點。重點是它背後代表的理念：GPU 編程不必這麼痛苦，開發者值得更好的抽象。

---

延伸閱讀

• TileLang 官方文檔 - 最完整的入門資源
• TileLang GitHub - 原始碼、範例、Issue 討論
• TileLang 論文 (arXiv: 2504.17577) - 完整技術細節
• ICLR 2026 Oral 頁面 - 審稿意見和討論
• AMD ROCm Blog: TileLang on MI300X - AMD 平台實測
• FlashMLA 80 行實現詳解 - 最佳入門案例
• TileScale 分散式擴展 - 多 GPU/多節點編程
• NVIDIA CUDA Tile 介紹 - NVIDIA 的回應方案

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 花 50 萬偷走 2 億的能力——Anthropic 蒸餾攻擊事件背後的殘酷經濟學
• 小訊號 PCB 設計指南
• KiCad Python API (kipy) 快速入門指南
• 用 Qwen3 1.7B 打造你的 macOS 桌面自動化 Agent 完整指南