打造 token 高效的 OpenClaw Agentic 系統

形式:前 10 分鐘為 AMD 的簡報(原講者為 AMD 副總,因故未到,由 Mahdi Ghodsi 代講),其後約 40 分鐘為現場動手工作坊,由 Mahdi Ghodsi 與 Satya Devineni 帶領,現場另有 TA 協助。以下依主題整理。

TL;DR

• 計價單位變了:chat 是有界任務(prompt → response → 結束);agentic 是無界的(規劃、呼叫工具、看結果、不滿意再來一次),同一份工作可能幾秒也可能幾小時。因此該報的指標是每個成功完成任務的成本與時間,不是 tokens/sec。
• 這打壞三件事:預算(同一個服務,兩個使用者的成本可能差 10–100 倍——他們自己年初編的全年算力預算幾週就燒光了)、最佳化目標(從 flops 變成 memory-bound 的全系統問題)、以及計分卡本身。
• 一切都回到快取:每一輪都在重算上一輪算過的東西。三條戰線同時做——模型層(Kimi K3 的 93 層中有 69 層是 KDA 線性注意力,固定大小的遞迴狀態而非不斷長大的 KV cache)、GPU serving 層(HBM → CPU DRAM → SSD → pooled memory 的分層快取,P99 TTFT 從 17.3 秒降到 5.4 秒)、CPU 層(tokenization 快取:1.7 秒 → 0.09 毫秒)。
• 反直覺的一課:快取命中率從 88.5% 降到 87.5%,但 TTFT 快了 3 倍——因為命中率不是使用者體驗,完成任務的時間才是。
• 工作坊主軸:用 OpenClaw 做 mixture of models(而非 mixture of experts),依成本、品質、隱私三個理由把請求路由到本地或雲端模型;四種難度遞增的路由方式一路做到 Lemonade Router 的語意路由。

主題與內容

主題一:從 tokens 到 outcomes——為什麼計價單位變了(約 01:27–01:31)

聽起來理所當然但後果昂貴的一件事:AI chat 是有界任務——使用者送出 prompt、拿到回應、人讀完,結束。Agentic AI 不是:同一個查詢進去之後,agent 會規劃、也許呼叫工具、看結果、可能不滿意再叫一次,甚至展開一整張 agent 的圖。同樣一份工作,可能是幾秒,也可能是幾小時。

這對規劃容量或編列團隊預算的人來說是根本性的改變:過去是按「席次」把使用者掛到模型或服務上;現在一個使用者可能幾秒就結束,另一個可能跑幾小時,兩者所需算力是完全不同的數量級。

他點名這會打壞三件事:

1. 預算。同一個服務,兩個人的成本可能差 10 倍或 100 倍。他直說這大概就是他們副總把這頁放進來的原因——他們在年初編了整年的團隊算力預算,幾週就燒完了,而且整個產業都在發生同一件事。
2. 最佳化目標。過去大家執著於 flops 與 tokens/sec、GPU 夠不夠快;現在 multi-turn agent run 讓 context 長得飛快,問題變成整個系統的、而且大量是 memory-bound 的。
3. 計分卡。tokens/sec 已經說明不了什麼,因為重點是完成的任務,不是單次回應。

主題二:三條戰線上的同一個原則——快取(約 01:31–01:38)

原則一句話:每一輪都在重複上一輪已經做過的工作。跑到第 12 輪時,你其實還在重算前 11 輪算過的東西,只為了處理第 12 輪多出來的一點內容。答案很明顯——別重算,把它留著。這件事做了好幾年,但 agentic 讓它的重要性完全不同。他們在模型、GPU stack、CPU 三條線上並行處理,以下例子來自與 Moonshot AI 就 Kimi K3 的 day-zero 支援合作。

• 模型層:KV cache 每來一次回應就長大一次,大模型可以長到數百 GB,不可能全放進 HBM(GPU 最快的記憶體)。Kimi K3 的做法是:93 層裡有 69 層用 KDA(Kimi Delta Attention)——帶遞迴層的線性注意力,那些層計算的 token 量是固定的。在 AMD MI355 上(一個節點八張 GPU、每張 288 GB)實測只用了約 15.5 GB。
• GPU serving 層:如果每個請求的 cache 都要放在 HBM,資料中心的經濟性不成立。他們對新模型重做了分層快取:HBM → CPU 的 DRAM → SSD → pooled memory。關鍵洞見是 agentic run 有大量閒置時間(agent 送出任務後在等工具或 CPU 的結果),所以要讓 eviction 發生時 GPU 仍然忙著;分層之後,模型準備好跑下一步時 prefix 已經就緒。成績:P99 的 time-to-first-token 從 17.3 秒降到 5.4 秒,約 3.2 倍。
• CPU 層:agentic 讓 CPU 變得重要得多——大量計算發生在那裡,工具呼叫與執行都可以更有效率。他舉的例子是 tokenization 也可以快取:只算新的部分就得到固定 0.09 毫秒,而整份重算是 1.7 秒。

最反直覺的一頁:很多人報快取命中率,但他們的例子裡命中率從 88.5% 掉到 87.5%。乍看變糟了,但前面說的 TTFT 快了三倍——因為如果你還是得重算第一個 token,那 88.5% 並不代表什麼。結論:該報的是每次成功執行的成本與時間,不是 tokens/sec、也不是命中率。

主題三:mixture of models 與它的三個理由(約 01:41–01:47)

工作坊的主軸是把「routing」從模型內部搬到模型之間。他先鋪背景:多數開發者聽到 routing 想到的是 MoE(mixture of experts)——1991 年 Geoffrey Hinton 團隊那篇早期論文,2017 年在大得多的模型上重新探索並帶出 sparse gating 等技術,至今仍是主流方向。但同一個 routing 想法可以把端點從「expert」換成「model」,這就是這天要做的 mixture of models。

三個理由:

1. 成本——「不是每個 token 都值得那個最好的前沿模型」。找一個檔案、跑一個簡單指令,沒必要送去 Fable 5。
2. 品質——需要時再升級(escalate),也可以讓專門模型處理專門任務。
3. 隱私與安全——他個人電腦上有大量私人檔案,「我不想我的社會安全號碼出現在別人的訓練資料裡」,那就留在本機。

他也點名這不是 AMD 的原創,學界早有探索:FrugalGPT(2023)用一個模型判斷小模型的回應,滿意就留、不滿意才升級到雲端模型,宣稱省下 98% 總成本且結果與當時的 GPT-4 相當;RouteLLM(Berkeley)則改成先用 router 決定該用哪個模型,同樣顯示 2 倍以上的成本節省;再往下就是語意路由——把進來的請求 embed 成向量,依你定義的規則用餘弦相似度分類該送去哪個模型。

硬體與環境:本地模型跑在 AMD Ryzen AI「Halo」box(Ryzen AI Max+ 395,市面可買的小型機),CPU/iGPU/NPU 共用 128 GB 統一記憶體,低精度下可跑到約 2,000 億參數等級;需要升級時走 Fireworks AI,其後端是 AMD MI355 GPU。本地推論用 AMD 自研的 Lemonade(桌面 app 下載模型即可跑,語意路由內建),Lemonade 的一位創辦人 Krishna 也在現場。

OpenClaw 的角色:當天的 agentic runtime。他形容它「今年稍早爆紅,現在大概是最熱門的開源軟體」,創辦人也在會場。工作坊只用到它的 agent 建立機制:每個 agent 有自己的 workspace,裡面是一批 .md 設定檔(例如 SOUL.md、AGENTS.md)與 openclaw.json(模型設定與權限)。主辦方預先建好三個 agent:local-brain(接本地模型)、cloud-brain(接雲端 Kimi)、smart-router。

主題四:四層路由,由淺入深(約 01:47–02:06)

1. 手動 /model 切換。任何用過 coding agent 的人都會,最簡單。
2. 一個模型一個專屬 agent。現場有人問「為什麼不用一個大 agent 就好?」答案是規則、權限與 context 都能按 agent 分開設定——例如規定「雲端 agent 永遠不准碰我的個人檔案」。示範:把 cloud-brain 的本地檔案權限關掉並重啟 gateway 後,叫它讀一份財務 CSV,它回「我沒有本地檔案系統的存取權」;切到 local-brain 同樣的指令則正常讀出。
3. 自動升級路由。改 smart-router 這個 agent 的 SOUL.md,規定每則回應都必須以 CLOUD 或 LOCAL 其中一行開頭,並給出分類規則(要寫程式 → cloud;要讀檔案 → local)。示範兩則:「什麼是四年 vesting、一年 cliff?」→ 分類 LOCAL,本地模型回答;「寫一個計算貸款利息的 Python function」→ 分類 CLOUD,轉去 Fireworks 模型。實作上升級是開一個帶雲端模型的 sub-agent,把 context 傳過去、等它回來再取結果。
4. Lemonade Router 的語意路由(Satya Devineni 主講)。架構是:prompt → OpenClaw → 本機的 Lemonade Router → 依判斷分流:敏感問題走小型本地模型、複雜問題走雲端 Kimi K2.6、既複雜又敏感則走較大的本地模型。

主題五:語意路由實作——三個 agent、三種規則(約 02:06–02:19)

情境設定是「你在管一家新創」:員工到職離職、福利、財務、法務。每個 agent 用 OpenClaw 的 skills(skills/ 資料夾下的 SKILL.md)界定資料來源、輸出期待、可以做與不可以做的事。

• HR admin agent —— LLM-as-router。employees.csv 裡有 SSN、email、電話等 PII。先用雲端模型做到職,資料就外流了;改用 user.hr-admin-router 之後,routing prompt 只有一句話:「看到任何 PII 就送本地模型,其餘送 Fireworks」。同樣的到職請求就由本地模型完成,零資料離開機器。Lemonade dashboard(localhost:1305)可以看到本地模型被載入,以及 TTFT、TPS 等指標。
• Benefits agent —— 關鍵字與規則路由。對 benefits-handbook.md 做 RAG。規則是:出現 401k、vesting 等關鍵字且 prompt 短於 400 字元 → 本地;涉及比較、分析、benchmarking,或 prompt 長於 800 字元 → 雲端 Kimi K2.6。兩則示範分別命中兩條規則,而使用者完全不需要自己切模型。
• Finance agent —— 語意相似度 + LLM 分類器。對 CSV 做資料分析。用 embedding 模型計算輸入 prompt 與預先定義概念之間的餘弦相似度(0–1 分):「what is our current burn rate」對應到 "simple metric lookup",門檻 > 0.6 → 本地;多來源分析則對應 "deep modeling",此處兩條規則任一觸發就升級——LLM 分類器判定為 complex 且分數 > 0.5,或語意相似度 > 0.72 → 雲端。

挑戰與收尾:最後留約 10 分鐘讓與會者解一道題,規則是用最少 token 完成(本地、雲端、Lemonade Router 隨你選),排行榜計分、AMD 周邊當獎品。線上參加者可透過表單申請 AMD Developer Program 的免費算力額度,之後以 email 收到專屬連結跟做同一份工作坊。

金句

"So the winner is whoever finishes the most tasks per dollar."(約 01:38:29)

一句話定義 agentic 時代的計分卡。

"…not every token deserves that best frontier model out there. If for example you're looking for a file or looking for simple command, you don't need to send that to your Fable 5."(約 01:44:37)

mixture of models 的全部理由,濃縮成一句。