客戶要他做一個能處理內部文件的 AI 助理，但文件不能上傳到雲端，預算也有限
想像一下：你的桌上有一台自己的電腦，而你想讓一個「頂尖等級」的 AI 在上面替你工作——不用把資料交給別人的雲端。這門課要談的，就是這件事為什麼突然變得可能。第一步，先把幾個關鍵詞搞清楚。
先講「開放權重」。權重AI 模型訓練完之後留下的一大堆數字，模型的「知識」和「能力」就存在這些數字裡一旦公開，任何人都能下載回家自己跑、自己微調。素材裡的兩個例子都是這樣：Meta 的 Muse Spark Open 在 Hugging Face 上提供下載，Reflection 的 Beam 則明講是給想「在自己的硬體、基礎設施或雲端上」使用並客製化的團隊。注意：「開放權重」不等於「連訓練過程都公開」，你拿到的是訓練好的成品。
再講「Apache 2.0 授權」。Apache 2.0一種很寬鬆的開源授權條款，白話就是：你可以拿去用、改、甚至商用，只要保留原本的授權聲明是 Beam 採用的授權。這讓「擁有（own）」這個詞真正有意義：模型放在你的機器上，你可以改它、客製它。素材中 Meta 那篇沒有在摘錄裡提到授權條款，所以 Muse Spark Open 的授權細節我們不在此下結論，要用之前務必自己看清楚。
最後是「混合專家（MoE）」。混合專家（MoE）把模型裡的神經網路拆成很多個「專家」小區塊，每處理一個字（token）時只叫醒其中幾位這是兩個模型共同的設計。Muse Spark Open 每層有 256 位專家、每個 token 只挑 8 位，總共約 8160 億參數，但每個 token 實際只動用約 420 億；Beam 同樣是 256 位專家挑 8 位，總參數 5010 億、每個 token 動用約 230 億。素材的說法是：它「跑起來的速度像小模型，容量卻像大模型」。
把兩件事擺在一起看，趨勢就浮現了：同一段時間內，Meta 與 Reflection 都釋出了數千億參數、主打寫程式與代理任務、上下文長度達 100 萬 token 的開放模型，而且都用 MoE，連「256 選 8」都一樣。這代表開放權重不再只是小模型的玩具，而是頂尖規模的選項。不過要留意一個現實：所有專家都得放在記憶體裡，所以部署時需要的記憶體仍是「8160 億參數等級」——Muse Spark Open 的 BF16 檔案就約 1.5 TB。這個矛盾，正是下一單元要解的題。
| 項目 | Muse Spark Open（Meta） | Beam（Reflection） |
|---|---|---|
| 總參數 | 約 8160 億 | 5010 億 |
| 每個 token 動用 | 約 420 億 | 約 230 億 |
| 專家配置 | 每層 256 位，挑 8 位 | 每層 256 位，挑 8 位 |
| 輸入 | 文字、圖片、聲音、影片 | 僅文字 |
| 上下文長度 | 最高 100 萬 token | 100 萬 token |
| 定位 | 寫程式與代理任務 | 寫程式與代理任務 |
| 授權 | 素材未載明 | Apache 2.0 |
上一單元我們談到，開放權重的大模型已經可以下載到自己手上。但下載之後有個現實問題：這些模型動輒幾十 GB，甚至上 TB，一般筆電的記憶體根本放不下。這一單元要看的，是兩個素材如何從不同角度解開這個難題。
先看 Meta 公開的 Muse Spark Open。它用的是 MoE（混合專家）把模型裡負責「思考」的那一大塊，拆成很多個各有專長的小專家，每次只叫其中幾位出來工作 架構：每一層有 256 位專家，一個 路由器在每個字詞進來時，負責決定該請哪幾位專家處理的小選擇器 會替每個 token 挑出 8 位來算。素材還說明，這些專家占了整個模型約 97% 的參數量。
結果就是：Muse Spark Open 總共約 816B 參數，但每個 token 實際只動用約 42B。素材的說法很精準——256 位專家全都得待在記憶體裡，所以部署時需要 816B 模型的記憶體，但算起來的速度卻像 42B 的模型。換句話說，MoE 省的是「運算」，並沒有省「放得下」的空間。
這就是 Janas 出場的地方。既然每個 token 只用到少數專家，何必把全部專家都放在昂貴的記憶體裡？Janas 把大型 MoE 模型的專家權重放在 SSD（固態硬碟），需要哪位才從硬碟 串流像看線上影片一樣，邊用邊讀，不必一次全部載入 進來。素材的實測是：48.4 GB 的 Qwen3-Next-80B，在只有 32 GB 記憶體的筆電上，寫字速度達 24 tok/s（加上 drafts 輔助為 37 tok/s），而同機的 llama.cpp 只有 2.8 tok/s。
有趣的是，這個技巧並不只對「放不下」的模型有用。素材的對照表顯示，連放得下的 Qwen3-30B-A3B，寫字速度也是 32 對 15 tok/s。不過取捨也看得到：3 位元量化的 Qwen3-30B 讀取提示詞比 llama.cpp 慢（100 對 112 tok/s），因為它的 Q3_K 權重還沒走上 GPU 的快速路徑，但寫字速度仍快了三倍左右。另外作者也提醒，換一台機器數字就會不同，要用 janas-bench 自己測。
| 模型 | 模型大小／類型 | Janas-LLM | llama.cpp |
|---|---|---|---|
| Qwen3-Next-80B-A3B | 48.4 GB，超過記憶體 | 24 | 2.8 |
| Qwen3-Coder-Next | 48.4 GB，超過記憶體 | 22 | 2.2 |
| Qwen3-30B-A3B | MoE，放得進記憶體 | 32 | 15 |
| Qwen3.8-27B | dense，17.6 GB | 4.4 | 2.1 |
上一單元我們看到，MoEMixture of Experts，把模型切成很多位「專家」，每次只叫其中幾位上工加上 SSD 串流，能把比記憶體還大的模型塞進筆電。這一單元換個角度：模型已經能在自己手上跑了，我們實際拿它來做什麼？素材裡有兩個很具體的例子，一個負責「做事」（代理），一個負責「畫圖」。
先看 Liquid AI 的 LFM2.5-24B-A2B。名字裡的「24B-A2B」意思是總共 240 億個參數，但每產生一個字只啟用其中約 20 億個（A2B = active 2 billion）。它的結構是 40 層、每個 MoE 區塊有 64 位專家、每次挑 4 位（top-4 routing），所以每個 token模型處理文字的最小單位，大約是一個字或一個詞的片段算起來很便宜。素材給的速度是：Apple M5 Max 上 184 tok/s，單張 NVIDIA B300 GPU 上最高 21K tok/s 的輸出。這個模型一定會先寫出完整思考過程再回答，因為每個思考 token 都便宜，所以「先想再答」的成本不高。
它的強項是當「代理」，也就是能自己呼叫工具、完成多步驟任務的 AI。在 LiveClaw 測試中它拿 48.09 分，勝過參數多約 50% 的 Qwen3.6-35B-A3B（38.19）；AutomationBench 更是 27.69 對 8.72。訓練上先用 33 兆 token 預訓練，再歷經 SFT、兩階段 on-policy distillation讓學生模型從多位專科老師身上學本事，並用自己實際產生的答案來被修正，最後在 OpenClaw、Hermes Agent、OpenCode 等代理環境裡做強化學習。但要誠實看表：它不是全面第一。SWE-Bench Verified 只有 51.00，輸給 Qwen3.6 的 66.20；WebArena Verified 與 GPQA Diamond 也落後。亮點在工具呼叫與指令遵循（IFEval 96.75），不是所有任務。
第二個例子是圖像生成。Hugging Face 的 Diffusers 套件支援 Black Forest Labs 的開源模型 FLUX.3 Klein，用 pip install -U diffusers transformers 就能安裝。有兩個版本：蒸餾版（蒸餾讓小而快的模型模仿大而慢的模型，用更少步驟得到接近的結果，預設 16 步、不需 CFG，在 H100 上約 2 秒出一張 1024×1024 圖），以及 50 步並使用 CFG 的基礎版。同一個模型能做文字生圖、多張參考圖的圖生圖、以及用邊界框控制版面。
顯卡較小怎麼辦？素材提到 NVFP4 與 FP8 量化把模型數字改用更少位元儲存，換取更小的體積與記憶體用量權重可用 from_single_file 載入；想客製風格，則有文字生圖與圖像編輯兩種 LoRA 微調腳本。提示詞要寫成完整場景描述：主體、場景、光線、構圖、風格。把這兩個例子放在一起，本機執行的價值就清楚了：資料不離開自己的機器（隱私），也不必排隊等雲端（速度）。
| 基準 | LFM2.5-24B-A2B | Qwen3.6-35B-A3B | Gemma-4-26B-A4B-it |
|---|---|---|---|
| LiveClaw（代理） | 48.09 | 38.19 | 41.25 |
| AutomationBench | 27.69 | 8.72 | 5.46 |
| IFEval（指令遵循） | 96.75 | 93.06 | 92.00 |
| SWE-Bench Verified（寫程式） | 51.00 | 66.20 | 25.80 |
| GPQA Diamond（知識推理） | 74.42 | 83.69 | 74.90 |
素材中的 FLUX.3 Klein 最小範例：從載入模型到存出第一張圖。
import torchfrom diffusers import ModularPipelinepipe = ModularPipeline.from_pretrained("black-forest-labs/flux-3-image-klein")pipe.load_components(dtype=torch.bfloat16)pipe.to("cuda")pipe(prompt="a red fox", output="images")[0].save("fox.png")上一單元我們在自己的裝置上讓本機代理和圖像生成動了起來，接著會冒出一個很實際的問題：這些 AI 寫出來的程式，你敢直接拿去用嗎？Claude Code 團隊正好面對過這件事，而且規模大得多。他們說 Claude 寫了 Claude Code 自己約 90% 的程式碼，所以得認真回答「程式碼多到人看不完時，怎麼審？」
先看壓力有多大。素材提到，在 Anthropic 的 monorepo（monorepo把很多專案的程式碼全放在同一個大倉庫裡管理）裡，每天進來的變更從 5 月約 2,500 筆，到 9 月已超過 30,000 筆。Claude Code 自己的倉庫雖然獨立，也承受類似壓力。團隊直言，在這種速度下，一行一行用人眼逐行審查「就算不是不可能，也極度困難」。
他們的做法不是取消審查，而是換個問法。與其問「有沒有人讀過這段程式碼？」，不如問「這個變更可能出什麼錯？哪一種檢查（自動的或人工的）最適合抓到它？」這也改變了審查的時間點：以前審查是路的盡頭的一道關卡，寫完、開 PR（PRPull Request，把你改好的程式碼提交出去、請別人檢查後才合併進主線的申請單）、等同事看；現在審查像打字時的拼字檢查，持續進行。多數變更在真人看之前，Claude 已經審過並修過至少一輪，把例行錯誤先擋掉，人的注意力留給只有人能判斷的問題。
目標也講得很具體：Claude Code 各個倉庫裡，多數 PR 合併時最多只需一位真人把關（可以就是作者本人），而且還款不能讓還原（還原率已經合併的修改，後來因為出問題又被撤回的比例）或事故增加。他們追蹤每個 PR 的真人核准數（中位數與第 95 百分位）、真人留言數、PR 等人的時間；還原與事故率則是「護欄」。成果是：6 月到 9 月，合併的 PR 數量增加超過一倍，而需要還原的比例下降超過 40%。
回到你自己的情境：用開放模型（例如單元一的 Beam、單元三的 LFM2.5-24B-A2B）產出的程式，也該用同一套思路。Beam 與 LFM2.5 的素材都強調它們擅長寫程式與工具呼叫，但 LFM2.5 的表格也顯示，同樣是程式任務，SWE-Bench Verified（OpenCode）只有 51.00，低於 Qwen3.6-35B-A3B 的 66.20。所以「能不能放心交付」不看模型名氣，而看你有沒有搭配自動檢查，並且讓出錯時能快速撤回。
| 面向 | 傳統審查 | Claude Code 團隊 |
|---|---|---|
| 審查時間點 | 寫完後的最後一道關卡 | 寫的過程中持續進行 |
| 主要閱讀者 | 人逐行閱讀 | 大部分交給機器，人看高層問題 |
| 核心問題 | 有沒有人讀過？ | 可能出什麼錯？哪種檢查最適合抓？ |
| 成功指標 | 人工核准數 | 真人時間下降，且還原與事故不增加 |