標籤: gemma4

  • Claude Code 換腦記:雲端便宜但要未雨綢繆,5 萬內路徑

    重點摘要

    • Claude Code 是「身體」(agent loop、tool use、MCP),模型是「腦子」,claude-code-router(ccswitch)是「神經接口」,把腦子接上身體。
    • 雲端 LLM 現在真的便宜:DeepSeek V3.2 每百萬 token USD 0.28/0.42,SWE-bench Verified 72-74%,夠用 80% 場景。不需要為了省錢買硬體
    • 但 Anthropic 改價、限額、ToS 變動隨時可能 — 未雨綢繆有必要,可是不要花過頭。5 萬內買「合理保險」夠了。
    • 10 萬內 3 條路徑:0 元全雲端(屁股電腦 + cheap API)、3 萬二手 GPU5 萬 RTX 5070 Ti。20+ 萬路徑(RTX 5090 + Mac Studio Ultra)完全不必要。
    • 腦子可以換,工具不能綁架你 — 也不要綁架你家庭預算。

    為什麼要換腦:Claude Code 框架真好用,但要有「萬一」準備

    Claude Code 提供的是身體 + 技能:agent loop、tool use、Bash 執行、MCP server 接入、檔案編輯、git 操作、subagent 派遣。這套框架成熟、穩定、文件齊。問題只有一個:底層腦子綁死在 Anthropic API

    講真的,2026 年雲端 LLM 費用真的便宜。Claude Max USD 100/月、DeepSeek V3.2 一百萬 token 不到 USD 0.5,單看價格就是時代最佳。多數人現階段「為了省錢花 20 萬買 RTX 5090」算式根本算不過來:5 萬月 API 成本 × 80 個月 = 6 年半才回本,而 6 年半後 RTX 7090 都出來了。

    「便宜」不等於「無風險」。Anthropic 可以隨時改價、限額、deprecate model、改 ToS、加區域限制、政策性下架。「便宜」是現在的事實,「能用」是對方願意的事實。未雨綢繆 = 確保「對方變心」的那天不會讓我停工

    這篇講的是合理保險:用 5 萬內的預算建立 fallback,不是為了省錢、不是為了完全自主、不是為了跑分追 frontier。只是讓你睡得安穩

    神經接口:claude-code-router 是什麼,怎麼把腦子接上身體

    claude-code-router(社群稱 ccswitch)是一個 proxy gateway,綁在 localhost:3456。Claude Code 原本打到 Anthropic API 的請求,router 攔截下來、轉換格式、路由到你指定的後端(OpenRouter / DeepSeek / Ollama / Gemini / Volcengine / SiliconFlow)。[GitHub: musistudio/claude-code-router]

    核心能力 3 個:

    • Transformer:把 Anthropic API request schema 轉換成 OpenAI / Ollama 格式,模型不用知道對方是誰
    • 動態切換:聊天中用 /model 指令切後端,不重啟
    • 路由策略:根據 task 類型自動派模型(重任務 → Claude Opus、background → DeepSeek、本地 → Qwen3-Coder)

    實際省錢幅度:[Cut Claude Code Bill 90%] 給的數字是 50-90%,看路由邏輯激進程度。但對保留 Claude Max 訂閱的人,router 真正的價值不是省錢,是削峰 — 把 subagent / background 派出去,Claude Max 的 weekly quota 留給真正需要 Opus 的任務,永不撞 lockout

    腦子替換的 3 種劑量

    劑量 A:全雲端腦(0 元入場)⭐ 我推這個

    router 把全部請求(或除主對話外的全部)丟到便宜 cloud API(DeepSeek V3.2 / Qwen3-Coder API)。本機完全不用裝模型,連 Ollama 都不裝。屁股電腦完美參與 — 它只負責跑 Claude Code 跟 router 本身,推理在雲端。

    適合:多數人。除非你有商業機密 / air-gapped 需求,沒理由花硬體錢。

    劑量 B:半雲半本地

    本地裝中型模型(Qwen3-Coder-30B-A3B 或 Gemma 3 12B)跑 background / 重複性任務,雲端跑重活。需要至少一張 12-16GB VRAM 的 GPU。

    適合:日常 coding 主力 + 想壓 API bill 到極致 + 願意花 3-5 萬硬體錢做「保險」。

    劑量 C:全本地腦(本文不推)

    本地跑 Kimi K2.6(1T MoE)或 DeepSeek V3.2(671B),完全不打雲端。但需要 Mac Studio M4 Ultra 256GB(NT$ 35 萬起)。對 99% 開發者而言不划算 — 不在本文 5 萬內預算範圍

    5 萬內的 3 條路徑(具體 part list)

    路徑 1:NT$ 0(全雲端 + 屁股電腦)

    項目 內容 成本
    機器 手邊任何能跑 Node 20 的機器(屁股電腦 / Mini PC / 舊筆電都行) NT$ 0
    claude-code-router npm install -g @musistudio/claude-code-router 免費
    DeepSeek API 帳號 platform.deepseek.com 註冊,買 USD 5 預付 NT$ 150 起
    月用量(中度開發者) DeepSeek V3.2 USD 0.28/M input, USD 0.42/M output NT$ 500-3,000

    這條路最被低估。多數人以為「本地模型」=「沒網路也能跑」,但實際 90% 場景你有網路,DeepSeek API 比自己跑本地 30B 還快還準。0 硬體成本 + 月 USD 5-15 = 跟 Claude 訂閱比省 70-90%,而且性能 80% 場景夠用。

    路徑 2:NT$ 1.5 萬(二手 GPU 試水溫)

    Part 規格 NT$
    二手 RTX 3060 12GB PTT / 露天 / 蝦皮二手 8,000-10,000
    PSU 升級到 650W 確保 GPU 供電 3,000
    機殼 / 風扇 散熱 1,500
    合計 ~15,000

    可跑:Qwen3-Coder-Next(3B active,記憶體吃 ~6GB)、Gemma 3 12B Q4、DeepSeek-R1-Distill-Qwen-14B Q4。40-60 tokens/sec,互動體驗已過 30 t/s 的「跟 cloud 無感」門檻。[Best GPU for Local LLMs 2026]

    適合:「想玩本地但不想砸大錢」。1.5 萬投資 = 大約 30 個月 DeepSeek API 用量,只在你**確實會用本地** + 想實驗的前提下划算。

    路徑 3:NT$ 5 萬(RTX 5070 Ti 16GB 改現有桌機)⭐ 認真做本地的甜蜜點

    Part 規格 NT$
    RTX 5070 Ti 16GB(新) 2026 最佳 CP 值 LLM 卡 28,000-32,000
    PSU 850W 5070 Ti 需 750W+ 5,000
    RAM 加到 64GB DDR4 / DDR5 雙通道 6,000
    NVMe 2TB 模型 / GGUF 存放 5,000
    合計 ~48,000

    可跑:Qwen3-Coder-30B-A3B(MoE,VRAM 吃 ~14GB),80-120 t/s 飛快。已能應付日常主力 coding,Claude API 退到 background 角色(複雜重構 / 跨檔分析才用)。

    適合:真的認真做本地化 + 有現有桌機可以裝顯卡 + 5 萬預算的人。這條路在 2026 中是「合理保險」最高 CP 值的點。

    為什麼不砸 20+ 萬?算給你看

    很多「玩 LLM」社群推的是 RTX 5090(NT$ 12-15 萬)或 Mac Studio M4 Ultra 256GB(NT$ 35 萬+)。對 99% 開發者而言,這算式根本算不過來

    配置 硬體投入 月省 (vs Claude USD 100) 回本年數 折舊風險
    路徑 1(全雲端) NT$ 0 USD 80-95 立刻省
    路徑 2(NT$ 1.5 萬) NT$ 15,000 USD 80-90 5-6 個月 低(二手 3060 殘值高)
    路徑 3(NT$ 5 萬) NT$ 48,000 USD 80-100 14-16 個月 中(2 年後 RTX 6070 上市)
    RTX 5090 機(NT$ 23 萬) NT$ 230,000 USD 100(只是不付訂閱) 76 個月 / 6.3 年
    Mac Studio M4 Ultra(NT$ 40 萬) NT$ 400,000 USD 100 133 個月 / 11 年 超高

    RTX 5090 機 6.3 年才回本,但 6 年後 RTX 8090 都出來了,你的 5090 殘值剩 30%。Mac Studio Ultra 11 年回本,11 年後 Apple Silicon 已經換了 4 代。

    「未雨綢繆」≠「為了不可能發生的事過度準備」。Anthropic 真的明天倒了,你也能在 5 萬路徑下半天內切到本地 — 那才是「合理保險」。砸 20 萬給「我擔心 Anthropic 變心」,是恐懼定價,不是工程。

    4 個本地腦子怎麼選(為什麼不一定要追 frontier)

    模型 Release 規模 SWE-bench 適合誰
    Qwen3-Coder-Next 2026/02 80B MoE / 3B active SOTA local 5 萬路徑首選 ⭐
    Kimi K2.6 2026/04/20 1T MoE SWE-Bench Pro 58.6% 贏 Opus 4.6 需 Mac Studio Ultra,不在本文範圍
    DeepSeek V3.2 2026/Q1 671B MoE SWE-bench Verified 72-74% 用 API 最划算(自己跑要 256GB RAM)
    Gemma 4 2026/04 多 size Apache 2.0 純開源、小機器友善(路徑 2 OK)

    來源:[Qwen3-Coder GitHub][Kimi K2.6 完整指南][DeepSeek 完整指南][Gemma releases]

    關鍵判斷:不要追 frontier。Kimi K2.6 跑分贏 Opus 4.6 沒錯,但要 256GB RAM 的 Mac Studio Ultra 才跑得動 = 40 萬硬體。對 5 萬內預算而言,Qwen3-Coder-30B-A3B(30B 規模、3B active MoE,16GB VRAM 就跑得起)已經滿足 80% 場景。剩下 20% 的硬任務丟回 Claude 用 router 解決

    ccswitch 路由策略:哪個腦子接什麼活

    1. Heavy(複雜重構、跨檔架構分析、安全 review)→ Claude Opus 4.7(API 或 Max 訂閱)
    2. Medium(一般 coding、debug、寫 test)→ DeepSeek V3.2(API)或 Qwen3-Coder-30B(本地,僅路徑 3)
    3. Light(格式整理、改 typo、寫 commit message、跑 lint)→ 本地 Gemma 3 12B(路徑 3)或最便宜 cloud(DeepSeek background tier)
    4. Background(自動產生 README、批次重命名、log 摘要)→ 本地小模型或 DeepSeek,跑多久都不心疼

    router config 範例:

    {
      "providers": {
        "claude": { "type": "anthropic", "apiKey": "$ANTHROPIC_KEY" },
        "deepseek": { "type": "openai", "baseUrl": "https://api.deepseek.com" },
        "qwen-local": { "type": "ollama", "baseUrl": "http://localhost:11434" }
      },
      "routes": [
        { "match": { "complexity": "heavy" }, "provider": "claude", "model": "claude-opus-4-7" },
        { "match": { "complexity": "medium" }, "provider": "deepseek", "model": "deepseek-chat" },
        { "match": { "complexity": "light" }, "provider": "qwen-local", "model": "qwen3-coder:30b" }
      ]
    }

    實際省下來的成本:[Claude Code Router 完整 2026 指南] 給的數字是月 API bill 從 USD 200 降到 USD 30-50。如果你保留 Claude Max 訂閱,把 subagent / background 路由出去,可以避免撞 weekly quota lockout,實質效益就是 「有效用量翻 2 倍」

    屁股電腦改造案例:32GB RAM + Ryzen 7 4700U 怎麼玩

    我自己手上的 Mini PC:AMD Ryzen 7 4700U(8 cores)、32GB RAM、無獨立 GPU、Linux Mint。前面查過所有資料,這台機器在 2026 的真實處境是:

    • ❌ 30B+ 模型完全跑不動(無 GPU + RAM 不夠)
    • ⚠️ 7B Q4 可跑但 ~3-5 t/s,慢到不能互動
    • ✅ Gemma 3 1B-4B 可跑但太弱,agent 任務跑不完

    結論:路徑 1(全雲端)最 fit 我的場景:

    1. 裝 claude-code-router(5 分鐘)
    2. 申請 DeepSeek API(10 分鐘,USD 5 預付)
    3. router config 把 medium / light 全部 route 到 DeepSeek V3.2
    4. Heavy 留給 Claude(Max 訂閱 或 API pay-per-token)
    5. Mini PC 繼續扛 Claude Code + router process,VRAM 無關緊要

    月成本估:USD 15-30(NT$ 500-1,000)。跟新組 RTX 5070 Ti 桌機(NT$ 5 萬)比,4-8 年才回本。所以路徑 1 是我目前最 fit 的路徑 — 不是因為我堅持本地化,是因為「本地化」對我來說是未來的選項,不是現在的剛需。

    真話:不要為了「本地化迷思」花錢,但也不要裸奔

    很多人買 RTX 5090 是為了「資料安全 / 不依賴雲端 / 終究有一天用得到」。實際統計:

    • 「資料安全」→ 99% 場景你的 code 在 GitHub public repo / company 內部 repo,傳給 DeepSeek 沒比較危險
    • 「不依賴雲端」→ 你每天還是上 Stack Overflow、Google 搜文檔,雲端依賴沒消失
    • 「終究會用」→ 通常買了之後跑兩週就放著積灰塵,1 年後折舊損失 30%+

    真正該本地化的場景:商業機密、air-gapped 環境、隱私法規(GDPR / HIPAA)。個人 / 中小團隊 dev workflow 不在這個 list 內

    但「不要過度準備」≠「不準備」。裝 router 是免費的,就算現在全部 route 給 Anthropic,哪天它變心,你只要改 config 就能切。5 分鐘的事,沒理由不做。這才是真正的「未雨綢繆」:架構靈活、邊際成本接近 0,而不是花 20 萬買「萬一」。

    結尾:腦子可以換,工具不能綁架你 — 也不要綁架你家庭預算

    claude-code-router 的真正價值不在「省錢」,是主權。Anthropic 改價、改 ToS、deprecate model,你不用跟著它的節奏走。換腦只是動作,背後是 ownership 的姿勢:你選你信任的模型、你決定路由邏輯、你不被任何單一廠商綁架

    具體建議按你場景:

    • 偶爾用 / 屁股電腦 / 預算 0:路徑 1(全雲端 + DeepSeek API + 5 分鐘 router setup)
    • 想玩本地但不確定會不會堅持:路徑 2(NT$ 1.5 萬二手 RTX 3060)
    • 真認真做本地化 + 有現有桌機:路徑 3(NT$ 5 萬 RTX 5070 Ti)
    • RTX 5090 / Mac Studio Ultra(20+ 萬):除非有商業機密 / air-gapped 需求,否則 6-11 年回本算式不划算,不推

    不為了「本地化迷思」花錢。留錢給你該花的地方 — 可能是更好的螢幕、更好的椅子、家人的長照、孩子的教育、未來的不確定性。Claude Code 是工具,換腦只是技術選擇,你才是 own 自己工作流的人 — 也是 own 自己家庭預算的人

  • 我該選哪個 AI 模型?從硬體到能力的白話判斷指南

    選 AI 模型不是看誰最厲害,而是看哪個「裝得進你的機器、會做你的工作、跟你脾氣合」。這篇用白話講清楚怎麼判斷,不需要工程背景就能讀懂。最後附上三種人的實際範例和一張機器等級對照表,讓你看完知道下一步該做什麼。

    重點摘要

    • AI 模型有四關:可不可用、裝不裝得下、擅不擅長、合不合作
    • 「總參數」決定要多少記憶體,「激活參數」決定跑多快 — 兩個不一樣
    • 32GB 記憶體的家用電腦能跑 30B 級的本地模型(壓縮後),別被 700B 的數字嚇到
    • 判斷模型擅長什麼,看 第三方榜單 + 自己跑題目,不要相信廠商海報
    • 不會微調、不寫程式的一般人:雲端 ChatGPT/Claude 比地端模型實用 10 倍

    為什麼這篇不是工程師專用

    很多 AI 模型介紹一上來就講 Transformer、MoE、量化、KV cache,看不懂的人乾脆直接問 ChatGPT 算了。但這樣你永遠不會知道:為什麼有時候 ChatGPT 答得不如另一個工具好?為什麼有人在自己電腦上跑 AI?那台主機要花多少錢?

    這篇用「買菜選菜」的角度切入。選模型就像選餐廳:有的店招牌大但你家附近沒有(雲端 vs 地端)、有的菜單大但你只吃其中三道(總參數 vs 激活參數)、有的師傅擅長熱炒但你想吃日料(文字強但圖片弱)。看懂這幾個對應,後面什麼術語都不會卡住你。

    第一步:先問自己這四個問題

    判斷一個模型「對你來說可不可用」,不是看它在排行榜第幾名,而是先答這四個問題:

    1. 我要它做什麼? — 寫文案、翻譯、寫程式、看 PDF、看圖,選的方向完全不同
    2. 我要在哪裡用? — 雲端服務 (ChatGPT 網站、Claude 網站) 還是裝在自己電腦 (地端)
    3. 我有多少預算? — 雲端是月費或按量計費,地端是一次性硬體投資
    4. 資料能不能上雲? — 病歷、客戶資料、未公開的營業資料,丟雲端要先看公司規範

    這四題答完之後,80% 的人會發現:地端模型不是給你的。雲端 ChatGPT/Claude/Gemini 月費 600-800 台幣,你買得到的「能力」遠超過你自己組一台機器跑 Llama 3。地端只有在「資料不能外流」、「想要客製化微調」、「想當興趣研究」這三種情況才划算。

    第二步:看模型「裝不裝得進」你的機器

    如果你決定走地端,這一關是硬門檻。模型有兩個關鍵數字,廠商常常混在一起講,你要會分:

    總參數 vs 激活參數

    名詞 白話解釋 決定什麼
    總參數 模型「整本書」有多厚 要多少記憶體裝它
    激活參數 每次思考翻幾頁 跑得快不快

    普通模型(像 Gemma 3、Llama 3)「整本翻完」才回答你 — 總參數 = 激活參數。MoE 模型(像 Mixtral、DeepSeek、Gemma 4)「只翻其中幾頁」 — 總參數遠大於激活參數,跑得快但還是要把整本書放進記憶體

    記憶體簡易公式

    用「壓縮過」(技術上叫 Q4 量化) 的模型,大致這樣估:

    • 模型體積 ≈ 總參數 ÷ 2 GB
    • 實際記憶體需求 ≈ 模型體積 + 2~4 GB(系統開銷 + 上下文)

    例子:Gemma 3 27B 模型 → 27 ÷ 2 ≈ 14 GB 模型 + 4 GB 開銷 = 18 GB 記憶體需求。一台 16GB 筆電裝不下,32GB 桌機剛好。

    第三步:看模型擅長什麼

    模型不是萬能。同樣 27B 大小,有的會寫程式但不會看圖,有的中文很爛但英文很強。怎麼判斷?

    看第三方榜單(快速篩選)

    你的需求 看哪個榜單分數 大概及格線
    寫文案、知識問答 MMLU-Pro >65 算強
    寫程式 LiveCodeBench、HumanEval LiveCodeBench >30 可用
    中文能力 C-Eval、CMMLU >70 算強
    看圖、讀 PDF MMMU、DocVQA MMMU >60 算強
    數學、邏輯 MATH、GPQA MATH >70 算強
    綜合(一般使用) LMArena Leaderboard 看 Elo 排名

    自己跑題目(最關鍵)

    榜單分數會作弊,你必須跑「自己工作會碰到的題目」。流程:

    1. 準備 20-30 題你實際工作會碰到的問題(不是從網路抄題目)
    2. 同樣的題目餵給 2~3 個候選模型
    3. 蒙著看答案、給分(別看是誰寫的)
    4. 看「一次到位率」、「中文是否流暢」、「會不會瞎掰」

    這比看任何排行榜都準。我之前在本地 AI 模型完整實測那篇就是用這個方法,五款模型結果完全不照 leaderboard 排名走。

    第四步:確認模型「合作說明書」

    同樣強的兩個模型,「會不會聽指令」差很多。這部分用戶最容易踩雷,要看四件事:

    • 支不支援系統指令(System Prompt) — 例如 Gemma 系列不支援系統指令,你只能塞在第一句話。Llama、Qwen、Claude 都支援。不知道這點會發現「怎麼叫它扮演什麼角色都沒效」。
    • 能不能呼叫工具(Function Calling / Tool Use) — 想做 AI Agent、自動查資料、操作 Excel,模型必須會「呼叫工具」。Claude、GPT、Qwen 強;Gemma 弱要靠土法煉鋼。
    • 能不能吃圖、吃 PDF — 多模態能力。Gemma 3 / GPT-4o / Claude 都吃圖;純文字模型(像 Llama 3 base)看不到圖。
    • 上下文(Context)能裝多少 — 4K 只能聊天、32K 可以吃一份合約、128K 可以吃一本書、1M 可以吃整個資料夾。看你的工作內容多長。

    三種人的實例:看完直接套

    實例一:上班族 Mary(行銷專員)

    需求:寫社群貼文、改履歷、翻譯英文信、整理會議紀錄。一台 8GB 筆電,沒在管什麼資料外流。

    判斷:

    • 地端?不要,8GB 連最小可用模型都裝不下
    • 能力需求:文字 + 中文,不需要寫程式
    • 預算:能接受月費 600-800 元

    建議:直接訂 ChatGPT Plus 或 Claude Pro。免費版偶爾用也夠,只是會在尖峰時段斷線。不要花一分錢買硬體,投資報酬率最差的選擇。

    實例二:工程師阿志(後端開發者)

    需求:寫程式、Code Review、技術文件查詢、自動化腳本。32GB 桌機,公司規定客戶資料不能上雲。

    判斷:

    • 分流:涉及客戶資料的問題用地端,公開資料用雲端
    • 地端能力:寫程式 → Qwen2.5-Coder-32B(壓縮後 ~20GB,塞得進)
    • 雲端:Claude Sonnet 寫程式最強,搭配 Cursor 或 Claude Code

    建議:Ollama 裝 Qwen2.5-Coder-32B 跑地端,Claude Pro 月費跑雲端。兩邊加起來月支出 ~800 元 + 一次性 0 元(用現有電腦)。

    實例三:創作者小凱(YouTuber + 部落客)

    需求:腳本撰寫、字幕翻譯、看 PDF 整理重點、看圖寫敘述、長影片轉文字稿。16GB 筆電 + 一張 RTX 4060(8GB VRAM)。

    判斷:

    • 多模態(吃圖)是剛需 → 模型必須支援
    • 16GB 筆電能跑 8B-12B 級的多模態小模型(像 Gemma 3 12B)
    • 長影片字稿要長 context → 32K 起跳

    建議:雲端為主(ChatGPT 或 Gemini 看圖最強),地端裝 Gemma 3 12B 當備援(網路斷或想離線時用)。腳本創意給雲端、批量字幕翻譯給地端省錢。

    機器等級對照表:你的硬體能跑到哪

    下表用 Q4 壓縮後的本地模型尺寸估算。「速度感受」是 CPU 推理(沒獨顯)的體感:

    機器等級 能跑的最大模型 速度感受 適合
    8GB RAM 筆電 放棄,直接走雲端 N/A Mary(上班族)
    16GB RAM 筆電 7B-12B 模型(Gemma 3 12B、Llama 3 8B) CPU 跑會卡,有獨顯才順 輕度離線備援
    32GB RAM 桌機 26B-32B 模型(Gemma 4 26B MoE、Qwen2.5-32B) MoE 模型可用,Dense 慢但能跑 阿志(開發者)
    64GB RAM 工作站 70B 模型(Llama 3.3 70B) CPU 很慢,要獨顯才實用 研究、實驗
    RTX 3090/4090 (24GB VRAM) 27B-32B 模型,速度飛起 流暢,接近 ChatGPT 體驗 認真做地端 AI 的甜蜜點
    2x RTX 4090 / A100 70B 模型流暢、Mixtral 等大 MoE 商用級 公司部署、付費服務

    關鍵原則:沒有獨立顯示卡的話,別買貴的桌機去跑大模型。CPU 推理 30B 級模型每秒只吐 2-5 個字,寫一封信要等三分鐘,用一次就會放棄。要嘛走雲端,要嘛投資一張二手 RTX 3090(約 2 萬台幣)。我之前測過 AMD 內顯 (iGPU) 跑 Gemma 4 也會踩坑,內顯不是省錢方案。

    最後:我該問自己的 7 個問題

    把這份清單存起來,下次有人推薦你「某某新模型超強」時,逐題核對一遍:

    1. 我用 AI 來解什麼具體問題?(模糊回答 = 還沒想清楚,先別買硬體)
    2. 這些問題,雲端的 ChatGPT/Claude 已經能解嗎?(能 → 直接訂閱,不要繞遠路)
    3. 我的資料能不能上雲?(不能 → 才考慮地端)
    4. 我的機器有多少記憶體和顯卡?(對照本文那張表)
    5. 這個模型在我關心的能力(寫程式 / 中文 / 看圖)分數怎樣?(看榜單再自己跑題)
    6. 這個模型的「合作說明書」有什麼坑?(系統指令、工具呼叫、上下文長度)
    7. 用一個月後,我真的有用嗎?(很多人裝完地端模型用三天就涼了,雲端訂閱反而沒浪費)

    結論一句話:普通人選雲端、有資料安全顧慮的選地端、想當興趣研究的選地端 + 雲端混用。買硬體之前,先把第 1、2、7 題答清楚,就會省下七成不必要的開銷。

  • gemma4:e4b 在 AMD Renoir iGPU Vulkan 輸出亂碼的完整排查

    重點摘要

    • gemma4:e4b 在 AMD Renoir iGPU(Vulkan)超過 30 層就輸出亂碼,低層數正常
    • 根本原因:RADV Vulkan shader compiler 的精度優化破壞 f16 運算順序,誤差隨層數滾雪球
    • iGPU 沒有獨立 VRAM,記憶體從系統 RAM 借,RAM 不足會讓模型載入循環崩潰
    • Mac Metal / 純 CPU 不受影響;GGML_VK_DISABLE_F16 等環境變數無法修復底層 compiler bug

    在本地端跑大型語言模型時,GPU 加速聽起來理所當然——更快嘛。但如果 GPU 算出來的答案是錯的,快有什麼用?這篇文章記錄了一次真實的踩坑:gemma4:e4b 在 AMD Renoir iGPU 上透過 Vulkan 跑出亂碼的完整排查過程,以及背後一層比一層深的技術原因。

    事件起因:模型跑得快,答案全錯

    測試環境是一台搭載 AMD Renoir APU 的 mini PC,透過 Ollama 跑 gemma4:e4b 模型。Ollama 偵測到 iGPU 後自動啟用 Vulkan 加速,把 42/43 層 offload 到 GPU。

    速度看起來不錯,約 8 tok/s。但仔細看輸出內容,發現問題大了:

    • 問「什麼是 Kafka Consumer Group Rebalancing」→ 回答泰文的學習理論
    • 問 Python 日期解析函數 → 回答 JavaScript offsetTop 的用法
    • 問燈泡謎題 → 回答哲學框架

    模型完全沒理解問題,像是跑在另一個平行宇宙一樣。

    第一個坑:RAM 不足讓模型連載入都不穩定

    在問為什麼答案亂之前,先碰到一個更早的問題:模型根本載入不起來。第一次啟動時,Ollama 日誌出現了這個循環:

    16:35:53  offloaded 42/43 layers to GPU(模型開始載入)
    16:38:53  llm server not responding
    16:38:54  llm server loading model
    16:39:02  llm server not responding
    16:39:03  llm server loading model
    ...(反覆了將近 6 分鐘)
    16:42:28  llama runner started in 410.58 seconds(終於啟動)
    17:04:49  -- Boot --(機器直接重開機)

    當時系統狀況:OMS 全套服務正在運行,RAM 只剩 1.7 GiB 可用。停掉 OMS 釋放記憶體後重跑:

    llama runner started in 42.04 seconds

    差了 10 倍。問題不在模型,在記憶體。

    為什麼 iGPU 需要大量系統 RAM?

    AMD Renoir iGPU 沒有獨立顯存,它的記憶體架構分兩層:

    類型 來源 大小 特性
    UMA(Unified Memory) BIOS 開機時從系統 RAM 切出 2 GiB(此台設定) 固定預留,GPU 專用,穩定
    GTT(Graphics Translation Table) 從剩餘系統 RAM 動態借用 最多 ~6.8 GiB 依可用 RAM 決定,借不到就崩

    Ollama 顯示「8.8 GiB 可用 VRAM」= UMA(2 GiB)+ GTT 上限(~6.8 GiB)合計。

    跑 gemma4:e4b 需要 2.8 GiB GPU weights + 224 MB KV cache + 289 MB compute graph ≈ 3.3 GiB。流程是:

    1. 先用完 2 GiB UMA
    2. 再向 GTT 借 ~1.3 GiB 的系統 RAM 頁面
    3. GTT 的頁面必須來自空閒的系統 RAM

    OMS 開著只剩 1.7 GB 可用,GPU 借不到足夠的 GTT 頁面,runner 一直崩潰重試,才出現那個 6 分鐘的死循環。最後機器因為 OOM 直接 reboot。

    換句話說:iGPU 的「VRAM」是假的,它在跟你的程式搶同一塊系統 RAM。獨顯不會有這個問題,因為它有真正的 GDDR 記憶體。

    GPU 與 GPU 的差異:不是每顆都一樣精準

    解決了載入問題,答案還是亂的。這時才是 GPU 精度的核心問題。

    GPU API f16 硬體支援 ML 成熟度
    NVIDIA RTX CUDA 原生 Tensor Core,為 ML 設計
    Apple M 系列 Metal Neural Engine + Metal 緊密整合
    AMD RX 獨顯 ROCm / Vulkan 原生支援,ROCm 驗證過 中高
    AMD Renoir iGPU Vulkan(RADV) Vega 架構,遊戲導向,未針對 ML 驗證

    f16 規格一樣,為什麼結果不同?

    很多人的疑問:IEEE 754 fp16 是標準規格,大家都遵守,為什麼不同 GPU 算出來不一樣?

    因為規格只定義單一運算的結果,但沒有規定三件事:

    1. Denormal 數的處理方式:非常接近 0 的浮點數(小於 6×10⁻⁸)稱為 denormal。IEEE 標準要求保留精度處理,但 AMD Vega 架構預設會把這些數 flush to zero(FTZ)——直接歸零——以換取效能。NVIDIA 不做 FTZ。這在遊戲中完全沒影響,但 LLM attention 的 softmax 運算大量出現這個範圍的數值。
    2. 運算順序:浮點數不符合結合律(a + b) + c ≠ a + (b + c) 在 fp16 中是真的。Shader compiler 為了讓 GPU 並行效率最大化,會自由重排運算順序,這對遊戲結果沒有可見影響,但 LLM 的 attention 矩陣乘法有幾萬次浮點運算,順序一改,誤差模式就完全不同。
    3. FMA(Fused Multiply-Add)的使用時機a × b + c 可以分兩步算(兩次取整),也可以融合成一步(只取整一次,精度更高)。NVIDIA CUDA 強制所有路徑用 FMA。RADV 的 ACO shader compiler 根據優化情境決定,在某些 LLM 矩陣模式下選了非 FMA 路徑。

    這三個問題疊在一起,每一層的誤差模式都不同,而且誤差會被下一層當成合法輸入繼續放大。

    為什麼低層數正常、高層數亂碼?

    什麼是 Transformer 的「層」

    gemma4:e4b 是 Transformer 架構,共 43 層。每個 token 的生成,資料要依序流過全部 43 層,每一層的輸出是下一層的輸入:

    Token 輸入
      → Layer 1(基礎語法、token 特徵)
      → Layer 2 ~ 10(語法結構、基礎語意)
      → Layer 10 ~ 25(上下文理解、語意推理)
      → Layer 25 ~ 42(高階抽象、輸出生成)
      → 下一個 token

    當設定 num_gpu=N 時,前 N 層在 GPU 算,剩下的在 CPU 算

    誤差如何滾雪球

    Layer  1:正確值 2.000,Vulkan 算出 2.001 → 誤差 0.001(無感)
    Layer  5:誤差疊加,下層把這個「略偏的 2.005」當成正確輸入繼續算
    Layer 10:誤差影響語意方向判斷
    Layer 20:模型對問題的理解開始偏移
    Layer 30:完全脫離正確答案空間
    Layer 42:輸出隨機語言的 token,變成泰文或法文

    這就像傳話遊戲:每個人傳話都有一點偏差,傳到第 43 個人時,內容已經面目全非。

    為什麼簡單問題(1+1)還能過

    「1+1 等於幾」的答案空間極小——就算誤差很大,最終 token 機率分布仍然在「2」附近。但「請用 Python 寫一個函數處理三種日期格式」的答案空間是整個程式語言的 token 集合,一旦偏移,就隨機落到任何地方。這也是為什麼診斷時不能只用簡單問題測試,必須用複雜 prompt 才能暴露問題。

    診斷過程:二分法找臨界點

    for layers in 1 5 10 20 30 40 42; do
      echo -n "=== num_gpu=$layers === "
      curl -s http://localhost:11434/api/chat \
        -d "{\"model\":\"gemma4:e4b\",
             \"messages\":[{\"role\":\"user\",\"content\":\"1+1等於幾?\"}],
             \"stream\":false,
             \"options\":{\"num_gpu\":$layers,\"num_predict\":30}}" \
        | python3 -c "import json,sys; print(json.load(sys.stdin)['message']['content'])"
    done
    num_gpu 結果 狀態
    1 1+1 等於 2 ✅ 正確
    5 1+1 等於 2 ✅ 正確
    10 (空白) ⚠️ 不穩定
    20 簡單問題偶爾正確 ⚠️ 不穩定
    30 法文回應 ❌ 亂碼
    42 隨機英文片段 ❌ 亂碼

    嘗試修復:三種方案全部失敗,以及為什麼

    方案一:GGML_VK_DISABLE_F16=1

    理論上這個環境變數應該告訴 llama.cpp 在 Vulkan 路徑使用 f32 計算,避開 f16 精度問題。但沒有效果。原因在於 Vulkan 推論的整個管線分四層:

    1. llama.cpp         → 寫 GLSL compute shader 原始碼        ← 環境變數影響到這層
    2. glslang           → 編譯成 SPIR-V bytecode
    3. RADV / ACO        → 把 SPIR-V JIT 編譯成 AMD GCN 機器碼  ← 精度 bug 在這層
    4. AMD Vega 硬體     → 執行機器碼

    精度 bug 在第 3 層——RADV 的 ACO shader compiler 在把 SPIR-V 轉成 GCN ISA 時,對某些矩陣運算的指令做了重排或合併,這個行為由 RADV 自己決定,應用層的環境變數完全碰不到。就算第 1 層寫了 f32,RADV 也可能在編譯時把某些中間值降轉成 f16——這對遊戲是合法的效能優化,對 LLM 是致命的。

    方案二:OLLAMA_KV_CACHE_TYPE=f32

    只影響 KV cache 的儲存精度,不影響主要的矩陣乘法計算路徑。輸出直接變成旁遮普語。

    方案三:num_gpu=20 折衷

    1+1 這種極簡問題可以過,但稍微複雜的 prompt 仍然亂答。誤差臨界點比簡單測試顯示的還要低,不穩定。

    最終結論

    方案 速度 正確性 建議
    純 CPU(num_gpu=0) ~1 tok/s ✅ 正確 唯一可用方案
    Vulkan 全層(num_gpu=42) ~8 tok/s ❌ 亂碼 不可用
    Mac Metal(同款模型) ~8 tok/s ✅ 正確 最佳選擇

    快 8 倍但答案全錯,還不如 1 tok/s 的純 CPU。資料正確性永遠優先於速度。

    如果你也遇到類似問題:排查步驟

    1. 先確認系統有足夠空閒 RAM(至少要比模型大小多 2 GiB),不然連載入都會失敗或 OOM reboot
    2. num_gpu=0 跑純 CPU,確認模型本身答案正確
    3. 逐步增加 num_gpu(1 → 5 → 10 → 20 → …),用複雜問題測試(不要只用 1+1),找到亂碼的臨界層數
    4. 環境變數(GGML_VK_DISABLE_F16、OLLAMA_KV_CACHE_TYPE)對 RADV 底層 compiler bug 無效,不要在這裡浪費時間
    5. 若根本無法修,接受純 CPU 或換有 CUDA / Metal 支援的環境

    這不是 Ollama 的 bug,也不是模型的問題。是 AMD Renoir Vega iGPU + RADV Vulkan shader compiler 在 LLM 工作負載下的精度限制,加上 iGPU 共享系統 RAM 的架構特性,兩個問題同時踩到。