Program-as-Weights：把 LLM 的智慧「編譯」進 23MB 的小檔案

先從一個痛點說起

假設你要寫一個程式，判斷一封 email 是否「緊急」。

最直覺的做法是：

response = gpt("判斷這封 email 是否緊急", email_content)

每次有新 email，就打一次 API。這樣能跑，但有三個問題：

1. 貴：每次輸入都消耗 token 費用
2. 慢：每次都要等 API 回應
3. 不穩定：模型更新、provider 下線，程式就壞了

Program-as-Weights（PAW）提出一個根本性的問題：我們有沒有辦法只呼叫一次 LLM，然後把它的「智慧」打包成一個可以本地執行的小程式？

答案是：可以。

類比：從傳統編譯器說起

要理解 PAW，先想想你每天在用的編譯器。

你用 Python 或 C++ 寫程式，編譯器把它翻譯成機器碼。機器碼可以直接在 CPU 上執行，之後不需要再讀懂你的原始碼。

PAW 做的事情完全類似，只是把「高階語言」換成「自然語言需求描述」，把「機器碼」換成「神經網路權重（LoRA）」。

流程是這樣的：

自然語言描述你的需求
        ↓
PAW 神經編譯器把它翻譯成一個 LoRA 權重
        ↓
這個 LoRA 插入本地小模型，直接執行

編譯只做一次。之後所有輸入，都交給本地的輕量模型處理，不再需要大模型、不再需要網路。

什麼是「模糊函數」？

PAW 解決的核心問題叫做模糊函數（Fuzzy Function）。

傳統函數很明確：

def add(a, b):
    return a + b

但有些任務根本寫不出清楚的規則：

• 「這行 log 重要嗎？」
• 「這段 JSON 格式跑掉了，幫我修」
• 「這個搜尋結果跟使用者意圖有多相關？」

這些任務都有模糊性、有邊界、有上下文依賴，所以開發者只好每次都打 LLM API 來「外包」判斷。PAW 的目標，就是把這類模糊函數「編譯」成可以本地執行、可版本控制的程式。

PAW 的三個角色

1. 偽程式編譯器（Pseudo Compiler）

把你的自然語言需求，整理成一份清楚的「規格書」：乾淨的描述 + 幾個具代表性的輸入輸出範例。

這步驟使用現成的 Qwen3-4B，不需要特別訓練。主要作用是去噪聲——把你草草打的需求，變成清楚的規格，讓下一步的編譯更穩定。

2. LoRA 編譯器（LoRA Compiler）

這是整個系統的核心。它讀入整理好的規格，輸出一組 LoRA 權重。

LoRA 是一種輕量化的模型微調技術，每一組 LoRA 只有約 23MB，但它讓底層的小模型「學會」這個特定任務的行為模式。

技術上，LoRA Compiler 提取規格的語意特徵，透過一個學習好的映射層（LoRA Mapper），輸出一組低秩矩陣，直接注入到解讀器的注意力層和 MLP 層中。

這個 Compiler 本身是訓練過的——它學會了「如何把規格翻譯成有效的 LoRA」。

3. 解讀器（Interpreter）

一個參數凍結的小模型（如 Qwen3 0.6B，約 500MB）。

使用時，把對應任務的 LoRA 掛上去，輸入資料，本地推論，直接出結果。整個執行過程不需要網路，不需要大模型。多個任務只需切換 23MB 的 LoRA，解讀器本身不動。

結果有多驚人？

論文在 FuzzyBench（1000 萬個範例的基準資料集）上測試：

0.6B 的模型搭配 PAW 編譯的 LoRA，打敗了 50 倍大的 Qwen3-32B。

在 MacBook M3 上，每秒可以跑 31.6 個 token，冷啟動只需 0.48 秒。甚至連更小的 GPT-2（1.24 億參數）插上編譯好的 LoRA，也能達到 54% 正確率，遠超同規模的直接提示。

為什麼小模型 + LoRA 會贏過大模型？

直覺上有點難理解，這裡是關鍵洞見：

當你用大模型直接解決一個任務，它必須從龐大的通用知識中，即時找出跟這個任務相關的部分，同時還要處理你模糊的規格描述。

PAW 做的是：提前把「對這個任務有用的知識與行為模式」壓縮進 LoRA 權重。執行時，小模型不需要自己摸索——它已經被「預設定」成這個任務的專家了。

類比：與其每次臨時教一個通才做某件特定的事，不如提前訓練一個針對這件事的專才。通才很強大，但臨時上陣的效率比不上準備好的專才。

開發者實際怎麼用？

API 設計得很簡潔：

import programasweights as paw

# 只需編譯一次（在雲端做）
spec = "判斷這封 email 是否需要立即處理"
program = paw.compile(spec, slug="email-triage")

# 之後本地永遠可以執行，不再需要打 API
fn = paw.function("email-triage")
result = fn("論文口試移到今天下午三點，需要你的簽名")
# 輸出: "urgent"

編譯好的程式可以版本控制、打包成庫、離線使用，就像一般的軟體元件。

延伸思考

這個典範的根本轉變是什麼？

• 舊思路：大模型是「問題解決者」，每次輸入都叫它解決一個問題
• PAW 思路：大模型是「工具製造者」，它負責製造工具（編譯），小模型負責執行工具

這讓人想到 Unix 哲學：「做一件事，把它做好」。每個 LoRA 是一個精確的小工具，大模型只在設計階段參與，不在執行階段消耗資源。

幾個值得繼續追蹤的方向：

• 如果每個 LoRA 都是一個「神經程式」，是否可以出現像 npm 一樣的 LoRA 生態系？
• 手機 App 可以在裝置端本地執行 AI 功能，不依賴雲端 API
• LoRA 的可組合性：把兩個 LoRA 疊加，能不能完成更複雜的任務？

當然，PAW 目前對長文本輸出任務（如撰寫文章、LaTeX 渲染）效果仍有限制，也不適合需要開放創意的生成場景。但對「輸入 → 分類 / 提取 / 判斷」這類模糊函數，它已經是個非常有說服力的答案。

核心洞見：把「每次呼叫 LLM」改成「編譯一次，本地執行」——這不只是效能優化，而是整個 AI 應用開發範式的根本轉移。