你的進度這一站 8 場，你看完 0 場

邊緣裝置上的小模型與微調做法

042Cormac Brick（Google）21:442026-07-25 上架

Why Large? Tiny LMs & Agents on Edge/Robotics — Cormac Brick, Google

Google AI Edge 團隊的技術主管 Cormac Brick，從 DRAM 成本談到 Gemma 小模型在各種裝置上的速度，再說明為何要把任務微調成更小的 tiny 模型，並以語音聽寫與 voice-to-function calling 為例。

這場講了什麼

DRAM 成本是邊緣部署的前提：Cormac Brick 指出，有手機廠商今年放進裝置的 DRAM 比以往少，Raspberry Pi 的價格也漲了。所以量化，以及「這個任務最小能用多小的模型」，成了整場的主軸。
1 到 4 billion 參數算小模型：IoT 與機器人要放這一級模型，通常得有 4 到 8 GB 的 DRAM，所以多半只出現在筆電、手機等較高階的裝置上。Gemma 的 E2B 靠 zero-shot prompting 就有不錯的推理表現，純文字版權重 841 MB，經驗法則是裝置要有 4 GB 以上。
各裝置速度差很多：同一個 2 billion 參數模型，Raspberry Pi 上 decode 約 7.6 tokens per second，Jetson Nano 最高約 24，Qualcomm IoT 板子的 decode 是 31，prefill 近 4,000。
tiny 模型要靠微調：現成的固定任務模型（ASR、視覺、embedding）可以直接用；任務特殊就要微調，起點是 270 million 參數的 Gemma 3 或 Function Gemma，Raspberry Pi 上的速度從個位數跳到 45 tokens per second。
合成資料是主要做法：Cormac Brick 的團隊發現，10,000 到 10 million 筆合成資料就足以把小模型微調到很可靠。摘要、校稿這類用 2 或 4 billion 參數模型就能做得不錯的任務，只要肯花工夫做資料集再微調，小得多的模型也能做到同等或更好的品質。
離線語音聽寫是量產案例：App 由微調過的 ASR 引擎與文字 policy 引擎組成，兩者都是 tiny Gemma 系模型，不需訂閱也能在裝置上完成聽寫、清掉語助詞，並偏向使用者自己常用的詞與名字。

影片從哪一段開始看15 段

00:12為什麼需要 tiny 模型要讓智慧進入大量裝置而不只是昂貴機器人，就得有 tiny 模型；Cormac Brick 預告這場談現況、能做什麼、現在能開始做什麼。
01:20AI Edge 團隊在做什麼Cormac Brick 是 Google AI Edge 團隊的技術主管，團隊做讓 AI 上邊緣裝置的開源專案，與 Gemma 團隊合作，先內部使用、能開源的再開源。
02:19為何放在邊緣理由是隱私、離線可用，以及省錢：使用者規模一大，即使 token 便宜，乘起來也會很快累積。
03:13邊緣部署的難處新出現的問題是 DRAM 成本，其他還有目標裝置種類多，以及很多 LLM 研究時數都投在大模型、低階端較少人研究。
04:42小模型是什麼約 1 到 4 billion 參數，Android 的 AI Core 與 Apple Intelligence 都有內建版本；IoT 與機器人要 4 到 8 GB DRAM，因此到不了低階市場。主要做法是 prompting，也可搭配 LoRA adapters。
06:09Gemma E2B 與量化E2B 的推理表現與一年前大得多的 Gemma 3 相當；混合 2、4、8 bit 量化，壓到約 2.9 bits per weight，純文字版權重 841 MB，加上 runtime 與 KV cache 約需 2 GB 記憶體。
07:28各裝置上的速度Raspberry Pi 約 7.6 tokens per second，Jetson Nano 最高約 24，Qualcomm IoT 板子 prefill 近 4,000、decode 31，一張中等解析度圖約 500 tokens，高解析度影像約每秒三格。
09:27試用與機器狗範例AI Edge Gallery 是完全開源的 iOS 與 Android App，可直接測小模型；DeepMind 的一位工程師用 OpenDog Mini V2 做了兩台機器人，Jetson Nano 版互動即時，Raspberry Pi 版慢很多。
11:24小模型還不夠小的時候小模型限制能接受就停在這裡；否則會遇到舊裝置到不了、互動要更快，或模型只是系統角落裡的小功能等情況。
12:34tiny 模型的取捨部署過約 500 million 參數的模型，記憶體需求低於 2 GB、可以跑得很快，但部署流程比較複雜，要找現成模型或自己微調。
13:24固定任務模型ASR、視覺、embedding 都有現成可用的模型；Apple FastVLM（0.5 billion 參數）在 Android 裝置上用硬體加速跑得很快，可當作邊緣裝置的第一層視覺感知。
14:24微調與 Function Gemma從 Gemma 3 與 Function Gemma 起步，Raspberry Pi 上跳到 45 tokens per second；mobile actions 模型把文字轉成約 10 種函式呼叫，可靠度 86%，前面接 ASR 就成了 voice-to-function calling。
16:23合成資料的做法先選基礎模型、確認效能與記憶體，再合成資料微調；Mobile Actions 資料集已開源在 Hugging Face，經驗是 10,000 到 10 million 筆就夠。
17:34量產案例離線語音聽寫 App 的 ASR 與文字 policy 引擎都是微調過的 tiny Gemma 系模型；Chrome 開發者預覽的摘要與校稿 API 也用 tiny 模型，才能推給更多使用者。
19:24結論與提問小 LLM 好用，在 NPU 上很快；tiny 模型能觸及更多裝置；voice-to-function calling 靠足量合成資料就能做得穩。回答提問時說，下一步是讓 voice-to-function calling 更容易做、更多人用得上，也希望視覺輸入更快。

值得記的話5 句

DRAM cost is really, really significant.DRAM 成本真的非常、非常可觀03:53
the lower end of the LLM spectrum is a lot less studied.LLM 光譜低階那一端的研究少很多04:26
the model you want to run isn't the main feature in the application.你要跑的模型並不是應用程式的主要功能12:18
the playbook we've found works really, really well as we synthetically generate data to fine tune that model.我們發現非常有效的做法，是合成資料來微調那個模型16:23
voice to function calling can now be built to be robust using tiny models.voice-to-function calling 現在可以用 tiny 模型做得很穩19:41

名詞與人物10 個

Gemma: Google 的模型系列；Cormac Brick 的團隊與 Gemma 團隊合作，讓它在各種裝置上跑得好
Gemma E2B: Gemma 的 2 billion 參數小模型，以混合量化壓到純文字版權重 841 MB
Function Gemma: 針對 function calling 模式額外預訓練的 Gemma，起點為 270 million 參數
AI Core: Android 高階手機上，內建的小模型隨它一起出貨
AI Edge Gallery: 完全開源的 iOS 與 Android App，用來在手機上試跑小模型
Apple FastVLM: 0.5 billion 參數的視覺語言模型，場上示範在 Android 裝置上跑得很快
Mobile Actions: 開源在 Hugging Face 的資料集，可重現 voice-to-function calling 的示範並從 Function Gemma 微調
MTP: Cormac Brick 提到 Raspberry Pi 的速度是未啟用 MTP 的數字，啟用後依任務可能快約 2 倍
quantization: 以較少位元存權重，用來壓縮記憶體用量
voice-to-function calling: 先用 ASR 把語音變文字，再由微調的小模型轉成函式呼叫

提到但沒有展開

Cormac Brick 說 voice-to-function calling 對 IoT 與邊緣裝置特別關鍵：小裝置常要靠設定選單操作，那種介面對很多人很難用，能直接開口講要什麼就省掉這一關。
回答提問時，Cormac Brick 舉的普及方法是讓 agent 幫忙產生合成資料；視覺輸入目前也還要花一點時間處理，更快的模型才做得了分割等更多事。

Google模型開源開發工具

在 YouTube 看原片 ↗