❯ ls -la ~/blog
176 篇文章 · 20 個系列
- 日期標題
- 2026-09-06
NVIDIA 官方 NVFP4 checkpoint + vLLM nightly + 九個 overlay 檔，一台 DGX Spark 上 40 題中位 41.7 tok/s、散文 27.4、程式 45，比同機 llama.cpp 快 78%。六張圖講模型結構，與 47.68 GiB n-gram 表為何放硬碟。
- 2026-09-06
Ref2VA 是 H3 唯一吃得下多張參考圖的模式。用兩張 z-image 人設圖生一段 10.1 秒的雙角色對話，台詞 ASR 逐字比對 CER 6.8%，三個錯字全是同音字。含六段格式全文與節點接線。
- 2026-09-03
同一張 5090、同樣 14 步、同樣品質設定，六個加速組態各值幾 %。原生 768p 的 15 秒片從 OOM 變成 8.6 分鐘。chunk 參數切越細越快、torch 換成 cu130 省 32%，而 SageAttention 跟 Sol-Attn 這兩個單看 kernel 快 4 倍的東西，端到端只值 2-3%。
- 2026-08-31
StoryScope 完全不看文風，只看敘事結構，93.2% macro-F1 就分得出人寫的與 AI 寫的。我拿它的五個問題掃自己已發布的文章，同一個教訓被抓到講了四次。
- 2026-08-31
RTX 5090 一張卡跑完 MiniMax-H3 的十個效果 embedding。最大的坑是位置:放在提示詞開頭會靜默失效，畫面卻照樣會變，所以「產物不一樣」不能當生效證據。它們也不是關鍵字，是 50 到 142 個預先編好的向量。附十支實測影片與速查表。
- 2026-08-30
單台 DGX Spark(121 GB 統一記憶體)跑 GLM-5.3-Flash 的完整配方:量化怎麼選、CUDA toolkit 為什麼只能是 13.0、中文為什麼比英文快、以及原生視覺跟投機解碼為什麼現在不能一起開。
- 2026-08-28
Qwen3.8-Flash-Next 在單台 DGX Spark 上跑 UD-Q4_K_XL，原生 262,144 context 全開，改檔案 76.65 tok/s。完整設定、四格速度、記憶體怎麼分配。
- 2026-08-28
Qwen3.8-Flash-Next（176.94B）跑在三張改裝 2080 Ti 上：128K context 拿到 23.14 tok/s，開 ngram 投機解碼後改檔案衝到 77.56。附三種量化在相同條件下的對照。
- 2026-08-23
GB10 的頻寬 273 GB/s、語言主幹 18.77 GB，每個 token 都要整份讀過，上限 14.54 tok/s。實測無投機 12.32，吃掉 85%，換 kernel 撈不回來。投機解碼把它拉到 5.28 倍，而關鍵不是換方法，是把草稿預算從 8 調到 12。
- 2026-08-23
Ubuntu 的 libnccl2 跟 CUDA 13 驅動不相容，自編 NCCL 2.31.2 修好之後，prefill 的 PCIe 流量掉了 99%——而速度幾乎沒動。那個看起來很糟的 fallback，其實沒讓你付多少代價。
- 2026-08-23
有人來信要我在跑雙 2080 Ti tensor parallel 時開 nvidia-smi dmon -s t 看 PCIe 頻寬。實測 AllReduce 吐字時只用掉不到 1%、prefill 約 6.6%，最忙的一格是 8%——瓶頸不是頻寬是延遲。
- 2026-08-23
拿 MiniMax-H3 生一段有角色的影片，踩到三件事:非原生解析度會掉下效能懸崖、遠景人臉必糊、以及「鬢邊白髮」在模型眼裡是年齡不是身分。最後靠 z-image 生參考圖走 h3-r2v,121.4 秒把楊過鎖回來。
- 2026-08-22
兩張改裝 2080 Ti 22G 用 llama.cpp 的 tensor parallel 接上 Qwen3.8-27B，配 MTP 投機解碼從單卡 37.1 tok/s 衝到雙卡 59.632 tok/s，還能開到 262K context。內含現在正式在跑的組態、三個上游踩坑，和雙 5060 Ti 社群數字的對照。
- 2026-08-21
派給 Codex CLI 的小工單常常一跑就是 40 分鐘起跳。這篇拆開近兩週 41 個執行紀錄，量出「牆鐘時間≈工具呼叫次數×14.3 秒」的公式，揪出 41 分鐘裡機器真正做事只有 4.4 分鐘，再用四刀把同型工單壓到 73 秒。
- 2026-08-21
Qwen3.8-27B 在 2080 Ti 的免費加速實測:修復版 chat template 讓 KV 快取命中 94.5%,MTP 草稿深度 2 開到 4 讓 decode 從 41.6 到 47.6 tok/s。附完整驗證方法。
- 2026-08-20
為什麼 GGUF 量化後檔案變小，tok/s 卻沒變快?拆開 CUDA 後端 .so 才看懂:Turing(sm_75)的整數 tensor core 只有 s4×s4 跟 s8×s8 兩種同寬組合，4-bit 權重配 fp16 activation 這格在任何架構都不存在。GGUF、AWQ、Marlin 全靠反量化撐過去。
- 2026-08-18
unsloth 的 Qwen3.8-27B-UD-Q4_K_XL 在一張改裝 2080 Ti 22G 上跑得動:16.7 GiB 權重、開到 128K context 還剩 1.7 GB、實測 30-31 tok/s。附一個它一次生成的體素庭園，可以直接開來玩。
- 2026-08-15
- 2026-08-07
從零把 33B 影音同步模型跑在 GB10 上。哪些參數非設不可、時間到底花在哪、為什麼 NVIDIA 自家的放大器在這台裝不上，以及換成 4.3 MB 的開源 SPAN 之後省了 22%。
- 2026-08-06
四個檔案在磁碟上 38 GiB，而卡只有 22 GiB。一張 2018 年的改裝 2080 Ti 22G(sm_75)照樣跑出 15 秒 1080p 有聲片。完整配置、實測速度與畫質，最後才是一路怎麼試出來的。
- 2026-08-06
同一支 15 秒 1080p 有聲影片，出片時間對半砍，畫面沒有變差。步數 20 改 14、SageAttention 2.2.0、放大器換成 RTX Video Super Resolution，三個開關各省多少、怎麼開、坑在哪。
- 2026-08-04
MiniMax-H3 影音同步生成新手教學。完整版 115 GiB 要四張卡，量化後 31.7 GiB 一張 RTX 5090 就夠。要下載哪些檔、放哪、怎麼設、提示詞怎麼寫。
- 2026-08-02
DGX Spark 的統一記憶體讓 284B 的安裝簡單很多——不用分堆、不用調 offload。實測 17.5–17.9 tok/s、256K context;同一份 GGUF 只比一張二手 2080 Ti 快 7%。
- 2026-08-02
DeepSeek 官方 0731 正式版，在好幾個 agentic 評測上跟閉源旗艦同級。這篇從下載 91GB 的 GGUF、設定成開機自動跑，一路寫到怎麼算你那張卡該搬幾層專家上 VRAM。
- 2026-07-29
一篇技術文五關全過,唯一的人類讀者一句話就命中:同一個句型在稿子裡出現了五次。查下去發現該抓的規則白紙黑字寫在 skill 裡、內容也對,但它標著「人工掃」——沒有指令、沒有 exit code、擋不住任何東西,所以從來沒運作過。門檻怎麼用五篇舊文校準、兩次真實攔截、以及一個機械檢查永遠抓不到的變體。
- 2026-07-29
DeepSeek-V4-Flash 是 284B 的 MoE。我把它塞進單張改裝 2080 Ti 22G,跑到 17.85 tok/s、262K context 只吃 16GB VRAM,還比跑同一顆模型的 DGX Spark 快約 18%。過程中我判斷錯了兩次,而且錯法不一樣。
- 2026-07-27
一個有長期記憶的 AI agent，把自己答錯的結論自動寫進記憶，之後每個新對話都翻出來當事實。/new 清不掉，因為幻覺住進了記憶層。五回合探針加三刀解毒的完整病歷。
- 2026-07-25
Entrpi 把 decode 從 14-16 拉到 20,代價是把權重存了第二份 78.71G artifacts、塞爆 128G 的 DGX Spark。大 context 一來就 OOM。我讀原始碼、實測、最後換回舊引擎。
- 2026-07-23
量化不是把整個模型砍成 4-bit。一個 GGUF 裡本來就混著 F16／Q4_K／Q6_K／F32 好幾種精度。這篇用 Laguna 的 attention 換 Q8 當例子，教你怎麼看每張張量的精度、只動該動的那幾張，還有 llama-quantize 的 tensor-type 陷阱。
- 2026-07-22
一張 24GB 消費級顯卡（含改裝 2080 Ti 22G）想跑免費開源模型，我目前的第一名是 Huihui-ThinkingCap-Qwen3.6-27B-abliterated：Q4_K_S 約 16GB、思考少一半、開 MTP ~38 tok/s、不拒答、全 Apache-2.0。
- 2026-07-22
Poolside Laguna S 2.1 是 118B-A8B 的 MoE coding 模型。我把它塞進單張改裝 2080 Ti 22G，用 CPU/GPU 混合 offload + 配套 DFlash 投機解碼跑到 ~29 tok/s，還靠一招 attention 換 Q8 省約 2.45 GiB、decode 再快 7%。
- 2026-07-21
第 13 篇說助理發瘋八成是「車子」壞了不是「引擎」笨。這篇就給你那張健檢表:context_length 設錯層會無聲提早壓縮、Qwen 沒關 thinking 慢 10 倍、MCP 工具接了卻全部失敗、sib 跑的模型跟你以為的不一樣。五個真實設定雷,每個都附一條你可以丟給 agent 自己跑的檢查跟修法。
- 2026-07-21
我只是問 Codex『這個 ds4 repo 有沒有針對單台 GX10 的強化』,結果一個下午,我那台在跑正職的 DGX Spark 就換了引擎(antirez/ds4 的 Blackwell fork,Entrpi)。同一顆 abliterated 模型、什麼都沒換,decode 從 14-16 提到 20、讀 prompt 快約一倍。沿路還實測收掉三個真問題:投機解碼在 abliterated 上為什麼反而更慢、disk-KV 是不是在省記憶體、managed KV 是不是 swap。
- 2026-07-21
一台約 5 萬台幣的二手 EPYC 伺服器,插三張改裝 2080 Ti 22G,共 66G 顯卡記憶體加 128G 一般記憶體。跑得動量化後的 119B 大模型,74 tok/s。想再往上跑 200B–300B、或想騰一張卡出來生圖,靠的是同一招:MoE 的 expert 大多時候在睡覺,把它們丟去便宜的大記憶體給 CPU 算,decode 只慢 2.4 倍。這篇講這招怎麼運作、代價多少(拿一顆小的 26B 先量給你看),還有一個多卡卸載必踩的坑:同一個卸載指令,單卡沒事、三卡直接 OOM。
- 2026-07-18
兩台機器裝的是同一張改裝 2080 Ti 22G,一台生 Z-Image 暖機 median 46.08s,另一台一樣的卡只要 ~9.5s。當天記錄上的結論很硬:46s 就是這張卡的天花板——GPU 全程 100%、模型常駐、卡也對。但我記得另一台一樣的卡跑過 10 秒(那筆沒進知識庫),一查發現數據沒騙人、只是漏了一塊。真兇不是矽晶片,是 ComfyUI 啟動 log 裡一行精度 fallback:Turing 沒有 bf16 tensor core,ComfyUI 為了保精度把權重留在 fp32,算得慢 3.4 倍。這篇是把兇手從『100% GPU 看起來就是天花板』這個舒服答案裡挖出來的偵探故事——外加兩個誠實提醒:這個旗標不省 VRAM、對影片模型也完全沒用。
- 2026-07-17
AI Workflow 系列第 15 篇。某天早上我讀 codex 紀錄,滑到一行:skill 描述被剪短,才塞得進 2% 的 context 預算。我共用的 root 累到 193 個 skill,全載進去撐爆上限,每條描述都被截斷——我天天在用的,被剪掉是為了替我從不碰的一百多個騰位子。這篇講怎麼用 per-agent allowlist(不是刪)砍到 7 個、薄殼配深引擎壓低每個 skill 的載入成本,再用一個閘門加稽核加可逆退場區守住,不讓它肥回去。
- 2026-07-16
這是 AI Workflow 系列裡『兩軸合流』這一段的收尾。回頭看整段路,前面六篇其實在蓋同一套系統的兩條軸:持久知識(我知道什麼,長效、要用再查)和即時狀態(我現在做到哪,易逝、隨時寫)。這篇講清楚兩條軸為什麼互不代替、怎麼匯流到『多 AI 交接』、又受同一套哲學管——以及那條讓一群不完全信任的模型還能安全協作的中心律:沒有收據就不信。
- 2026-07-15
我拿一批 markdown 檔當 AI 的長期記憶,在檢索(搜尋加知識圖譜)之上再疊一層蒸餾層。檢索撈回的是原始材料,每個 session、每個 agent 都得重讀重推一遍;蒸餾層把定案結論冶煉一次、存成一檔一個 claim,之後直接取用。這篇講清楚這層是什麼、為什麼它的目的是『少解釋一次』而不是『逼大家講一樣』、以及我怎麼學會真的去信它。
- 2026-07-14
我拿大約 600 篇 markdown 檔當 AI 的長期記憶,分成三層:檔案本身是唯一的真相源、一個搜尋引擎讓它們找得到、一張知識圖譜用概念把它們連起來。這篇先講清楚這個設計、每一層為什麼存在、換來什麼好處,最後才講我建它時走錯的那幾條路。
- 2026-07-12
退役一個 AI agent 的舊記憶系統,看起來只是半小時的雜活,結果連踩三個暗坑:退役的資料夾其實是現役鏡像、doctrine 說有的備份根本不存在、hub-and-spoke 拓撲讓你從單台機器只看得到半張圖。根源都同一個——白紙寫的 doctrine 早跟實際在跑的 runtime 漂開了。
- 2026-07-12
交辦 AI 工程任務,交出去的不是一段對話,是一張工單檔。這篇講我怎麼把任務寫成自足工單(目標/步驟/機器可驗收/紅線)、detached 背景派工給 Codex、用三個 flag 和一個看門狗擋掉永久卡死,以及為什麼收到完工報告不等於做完——報告是 claim,驗收重跑才是 evidence。
- 2026-07-11
額度斷在任務半路,蒸發的不是知識庫,是這個任務的 live state:做到哪、排除了哪些死路、下一步跑哪個命令。這篇講我怎麼把 state 外部化成一個 handoff 檔,讓 Claude Code 跟 Codex 經 symlink 讀寫同一份、互相接手彼此做一半的活——以及用 hook 上鎖時踩到、又修掉的一個 false-takeover bug。
- 2026-07-10
一台 headless Windows AI 主機上的本地腦,偶發在真實負載下無聲無息地死掉:client 吃到短暫 503,服務自己又活回來,應用程式 log 一片空白。最氣的是真兇不是模型本身,是我自己——重啟前 log 把 crash 當下那行死因截掉了。這篇是把死因從『被自己的 log 掩埋』裡挖出來的偵察故事:為什麼會自我重啟的服務最會掩埋自己的死因、為什麼要先看 OS 層的 Event Log、以及 0xc0000409 到底是什麼。誠實在先:根因我還沒 100% 確認,這是還在查的紀錄,不是結案報告。
- 2026-07-10
本地 LLM 圈到處是被吹爆的優化——外掛 sparse-KV 壓縮器、「省 90% 記憶體」。多數搬到你自己的模型上就垮了。三個很便宜的動作判斷哪些是真的:讀原始碼、找真正的天花板、跑一個能定生死的實驗,全部拿 DeepSeek-V4-Flash 上那次 FlashMemory 調查來對照。
- 2026-07-10
Hermes agent 桌面版自架完整指南:用現有 ChatGPT OAuth 免 API key 當大腦,Mac、Windows 都能裝,接 Telegram、LINE 手機遙控,還能換成本地模型完全自主——一頁把整套帶你走完。
- 2026-07-09
DeepSeek-V4-Flash 本來就有一套 native lightning indexer,追真實 attention 追到 93–96%。FlashMemory 會先把候選 chunk 篩小一圈,但直接拿來用跟亂猜沒兩樣;我重訓到自己的 Q2 build 上,也只爬到 89–92%。GB10 上 NO-GO。
- 2026-07-07
DGX Spark 2026 年中現況整理:現在該用 vLLM、官方 Gemma 4 NVFP4 權重、MTP、長 context 多模態,以及仍然會咬人的坑。
- 2026-07-07
DeepSeek-V4-Flash 是 284B 的 MoE,長 context 還能在 128GB 的 GB10 上跑得動,靠的不是權重小,是它天生就在打 KV cache:混合式 attention(SWA + CSA + HCA)把 KV 壓到 64K 只剩 871MiB;lightning indexer 挑的是壓過的 entry、一步只讀幾百列。這篇拆 ds4 的實作,順便講為什麼你沒辦法再靠量化 KV 省記憶體。
- 2026-07-07
想自架 AI agent，先別鑽進單篇教學。這篇把地圖攤開：桌面身體、ChatGPT OAuth 大腦、Telegram/LINE 通道、工具和本地模型。
- 2026-07-06
推測解碼常被當成免費加速,但在 bandwidth-bound 的 GB10 上,它其實是個會變負的取捨。depth-1 MTP 在 DeepSeek-V4-Flash 上無損,但看工作型態:agent 回合 +9.4%、程式碼 +6.5%,散文 −3.6%、中文閒聊 −3.7%。正負號跟著接受率走,因為這裡的吐字卡在驗證(108ms 驗證 vs 4ms 草稿)。不是全域開關,看工作型態開。
- 2026-07-05
Part 2 誇的『快取命中就順』hot path,一個月重度 agent 用下來悄悄失效。ds4 的 disk-KV cache 在 GB10 上被兩件事餓死:預算填滿的 evict 風暴,加上 tool-call 那輪根本沒存 checkpoint。一段 14K token 的對話只認得 268 個字,剩下整段重 prefill。這篇拆 log 指紋、上游 PR #489、跟一張證明機制修好的 A/B 驗收。
- 2026-07-03
我把家裡那顆 agent 腦的 decode 從別台的 14 tok/s 換成這台 30,結果它感覺更慢。tok/s 這個數字我盯了一年,原來它量的是「吐字多快」,不是「多久才開始吐」。在一顆 hybrid 模型上,一次 cache miss 就把整段 prompt 從頭重算——同一台機、同一顆腦,暖機 2.6 秒、冷掉 216 秒。這篇用 Hina 自己的 log 講:為什麼該盯的是 TTFT。
- 2026-07-02
我想讓慢吞吞的本地 agent 少一點等待焦慮,於是開了 Telegram 的「逐字浮現」串流——每隔幾百毫秒就改寫一次訊息。結果一個一百多秒的回應發出上百次編輯請求,正面撞進 Telegram 的 flood control,被罰等兩百多秒,整個 bot 卡死,連最終答案都送不出去。這篇講一個短而毒的教訓:慢模型不該開漸進式串流,一次性送最終答案反而穩。附 log 實證。
- 2026-07-01
Hermes 有個叫 /learn 的指令,能把『你做過的事』自動整理成一份可重用技能(一份 SKILL.md)。這篇我把它接上自己的艦隊實測:派一張 Kanban 卡,讓一隻跑在改裝 2080 Ti 上的本地 27B 模型,3 分鐘把一次遊戲開發蒸餾成一份合格技能——還挖到兩個文件沒講清楚、實作才會踩到的細節:斜線指令 vs 派工、技能到底存哪。白話講 /learn 是什麼、怎麼用、以及它的真實限制。
- 2026-06-29
養了一群分身之後,我把同一份「做個俄羅斯方塊」的規格——就一句話、細節啥都沒講——一隻分身發一張卡,讓三隻各自一次寫完一個網頁俄羅斯方塊。我一行遊戲碼都沒碰,只負責發布。結果蹦出個意外驚喜:靠 Hermes 這套外框加一顆我自己在家調、跑在改裝 2080Ti 上的小模型,居然一次就把我沒要求的 ghost、wall-kick 都補上了。成品點開就能玩。
- 2026-06-29
在 Windows + RTX 5090 上用 ai-toolkit 訓練,真正開跑前先踩了三個坑:Python 3.13 依賴地獄、HuggingFace 下載卡 0 bytes、ssh 斷線把訓練殺了。每個都是「錯誤訊息指東、真兇在西」,逐個拆診斷跟解法。
- 2026-06-28
訓練好角色 LoRA 之後,怎麼精準控制畫風與身分?lightning 為什麼抹平風格、什麼時候用全步數、風格 LoRA 怎麼疊、為什麼光靠觸發字綁不住外觀——一篇講清楚每個旋鈕。
- 2026-06-27
我數了一下家裡那個 AI 助理每次回話前的開銷:還沒開始處理我輸入的文字,就先吃掉約 23K token,其中 17K 只是『工具的使用說明書』。更慘的是它是 hybrid 模型,快取一沒命中就把這 17K 從頭重算——一個對話回合可能重算十幾次。這篇講一個被嚴重低估的成本:模型開口前的「打底開銷」。解法不是砍工具,是像技能那樣『用到才載』。
- 2026-06-26
對話一長,每傳一句它都要把整段重讀一遍(re-prefill)才回你——重開、被擠掉快取後尤其痛。stock llama.cpp 沒內建把 KV cache 存硬碟(feature 被官方標 not planned),我用一支 60 行的 proxy 騙它做到:restore 比重算快 7×(5K 對話 9.9 秒→1.4 秒)。附:機制、proxy 設計、和為什麼我目前還沒上線它。
- 2026-06-25
主 KV 我量化成 q4 省記憶體,很合理。那 MTP 的 draft cache 順手也量一下吧——它只是個小草稿,直覺穩賺。測下去打臉:q4 draft cache 29.6 tok/s,不量化的 f16 反而 39.7,還更省記憶體。draft cache 是少數「量化淨虧」的地方。附:量化為什麼會同時拉低速度、acceptance 跟省不到記憶體的三重損失。
- 2026-06-24
Hermes 有內建看板，但你在手機上只看得到 Telegram 的純文字。Muninn 這次直接把那塊看板搬上手機：Running / Blocked / Done 分欄、誰在跑什麼、哪張卡被擋下來，一眼看完。零後端、純 P2P。
- 2026-06-24
模型卡片寫 n_ctx_train=262144。22G 的卡。27B 的 Q4 權重才 15.7GB。算盤一打:開滿 256K 啊,還剩好幾 GB。-c 262144 啟動,載入成功、沒報錯。跑幾輪對話就 503、服務自己重啟。日誌沒有漂亮的 out of memory,只有一行 0xc0000409。free VRAM 一看只剩 170 MiB——剩下的 GB 去哪了?這篇是把它查到底的偵探故事:我原本賴給 context checkpoint,讀了 llama.cpp 原始碼才發現它其實住系統 RAM、真正吃 VRAM 的是 KV cache;free-VRAM 對 context 是非線性的,而真正穩的甜蜜點不是 256K,是 128K。
- 2026-06-23
Hermes 裝好了，但出門就失聯——用 LINE 接太麻煩，沒有你自己的介面。Muninn 是專為 Hermes 設計的 iOS app：跟助理說一句話、手機掃 QR，5G 就能直連家裡，中間不經過任何第三方伺服器。
- 2026-06-23
選本地模型我也是先看 tok/s。Gemma 12B 跑 90-100、爽到飛起,可是掛上 kanban 工作板,它做完內容就「結束」,從不回頭把卡標完成。換成慢三倍的 Qwen 27B,board 反而開始乖。這篇講一個反直覺的選擇:當腦要持續守一套程序,吞吐量根本不是該看的數字。附:連我查 log 都差點被 grep 騙。
- 2026-06-22
AI 助理鬼打牆、亂跑、卡住、答非所問，你的第一反應通常是「這模型真笨」。但根據我自己一路 debug 的經驗，八成不是模型的問題，而是它外面那一圈（工具、設定、記憶）出了狀況。模型是引擎，外面那一圈是車子——車子開不動，常常不是引擎壞，是輪胎沒氣、油路堵了。
- 2026-06-22
GTX 970 那系列結尾我說「想在老卡上掛 agent,但 E2B 太小」。與其買新卡,我去二手市場撈了一張改裝 22G 的 2080 Ti——淘寶標價 ¥2079、到手含海運雜費約 NT$11,000——剛好夠把一顆常駐 27B 的 agent 腦養在家裡那台廉價老桌機上。這篇講用合理價錢挖到剛好夠用的好料的爽,跟它背後的工程。
- 2026-06-21
ds4 引擎內建 directional steering — 推理當下推一個方向向量改變模型行為,數學上就是 abliteration 的連續可逆版。我在 GB10/CUDA 上跑通了(官方工具其實偏 Metal,但 CUDA 的 activation dump 也能觸發),抽了一條 verbosity 向量。結果:在 abliterated Q2 上 gradient 非單調、正向 scale 直接崩成標題碎片 —— 兩刀同源,疊起來互相打架。
- 2026-06-20
助理裝好了，但它現在只會講話——只有一張嘴。這篇帶你給它一雙手：接上工具，讓它真的去查你的資料夾、跑你的指令、打你自己寫的小服務。重點概念叫 MCP，就是工具的『萬用插座』標準，插上去助理就會用。整套跑在你自己這邊、接的是你自己的東西。
- 2026-06-19
前面我們用 ChatGPT 當助理的大腦。這篇做一件更狠的事——把那顆腦從雲端換成跑在你自己機器上的本地模型（例如 ds4）。賣點是「腦」這塊整套自主：推論不靠雲端、你跟它講的話不出門、不限額、全在你手上。代價也誠實講：本地腦通常較慢（ds4 實測約 10 tok/s），而且要一台夠力的機器。換腦不換身體，Hermes 這副身體完全不動。
- 2026-06-18
用一張參考圖,在自己的 5090 上訓練一顆 Wan 2.2 角色 LoRA,之後純文字就能叫出同一個人——換衣服、換場景、換畫風、甚至生成影片,免付雲端費用。
- 2026-06-17
一個助理用熟了，想再養第二、第三個？Hermes 讓每個分身有自己獨立的家（設定、記憶、個性），可以各跑不同模型、各管不同任務。這篇用白話講為什麼要分身、怎麼分，以及我實際養的那幾隻。誠實說：一般人一個就夠，這是想玩才需要的進階玩法。
- 2026-06-16
你的 AI 助理只會讀文字？這篇教你幫它接上眼睛跟耳朵——丟一張圖它看得懂、傳一段語音它聽得懂。做法不是換更貴的大模型，是外掛一顆會看圖的小模型當感知小幫手。Hermes 原生 auxiliary.vision + 內建 faster-whisper，端到端實測。
- 2026-06-15
前面那套 LINE 要先開門（ngrok）、再去後台設 webhook，步驟不少。這篇給你更輕的選擇：Telegram。跟一個官方機器人對話就能建好你的 bot、拿到一把鑰匙，填進 Hermes 就通——不用對外網址、不用 webhook。
- 2026-06-14
幫部落格做一個 RAG 客服 bot，跑在一張 2014 年的 GTX 970 加一個約 600MB 的 embedding 模型。embedding 走 llama.cpp 在 CPU 上跑、檢索用 numpy 暴力算 3,475 條 chunk、護欄靠嵌入分數閘、對外走 Cloudflare Tunnel。
- 2026-06-14
在沒有 tensor core 的 Maxwell GTX 970 上跑 Gemma 4 E2B，開 Flash Attention 讓長 context 的 decode 接近翻倍（24.3 → 42.5 tok/s），還省了約 430MB VRAM；而 q8 KV cache 幾乎沒省到記憶體、還拖慢 decode。一般的 KV cache 常識整個翻過來。
- 2026-06-13
DiffusionGemma 26B-A4B 用官方現成 image 就能在 128GB DGX Spark 上跑 vLLM,不用等 PR、不用 cherry-pick。NVFP4 單條 158 tok/s、四條同時 257。但單一個 tok/s 數字會騙人:diffusion 的速度取決於 256 token 的畫布有沒有填滿。
- 2026-06-12
把 DeepSeek-V4-Flash(284B)壓到非對稱 Q2 才塞進 128GB 小盒子。聽起來像自殺式量化,但它只砍 routed experts、把高精度留在該留的層。實際當 agent 跑 280 輪零退化——權重夠大,2-bit 也壓不垮。
- 2026-06-12
一顆 284B、只有 15 tok/s 的模型,要拿來當每天的 agent 大腦,得先做點準備才用得舒服。server 跟 agent 框架兩邊各一組設定:--no-mmap 冷啟砍到 57 秒、KV disk cache 省一半 prefill、context_length 沒設對整個 session 會炸。
- 2026-06-12
DeepSeek-V4-Flash 是 284B 的 frontier 模型。我用 antirez 的 ds4 引擎 + 非對稱 Q2 在單台 GB10 跑起來,15.6 tok/s。本來以為 2-bit 量化讓它假裝呼叫工具,結果真兇是 runtime 沒接 DSML parser。
- 2026-06-11
Qwen3.5-122B-A10B 在 128GB 的 DGX Spark 上,vLLM 怎麼調都卡在 17 tok/s 的 GDN 牆,連 merge 進去的加速 PR 都沒用。我換掉 vLLM、改用 Atlas 引擎跑同一顆解禁 NVFP4 權重,直接翻到 33.9 tok/s(開 MTP 36.5,約 2×)—— 加速 100%,解禁行為原封不動。真正的出口不在量化工具箱裡。
- 2026-06-09
一張 2014 年的 GTX 970 跑 Gemma 4 E2B（看圖 + 聽聲音）再接上 Piper TTS——一個會看、會聽、會說、會寫 code 的完整離線語音助手。端到端約 2.8 秒，硬體約 NT$500。
- 2026-06-09
在 2014 年的 GTX 970 上跑 Gemma 4 E2B 四種量化。3.2GB 的 QAT Q4_0 反而比 2.9GB 的 Q2_K 快（47.6 vs 32.8 tok/s）——因為沒有 tensor core 的 Maxwell 老卡卡在解量化，不是卡頻寬。
- 2026-06-05
我在 DGX Spark 上把 gemma-4-12B 量化成 BF16 / FP8 / NVFP4 weight-only，分別測英文 MMLU 跟繁中 TMMLU+。FP8 兩邊都近無損；NVFP4 繁中掉 6 分、英文只掉 3 分。
- 2026-06-05
系列最後一步，也最有感：設一個會自己跑的任務。用一句白話交代，它每天自動上網研究你關心的事、整理成重點，主動傳 LINE 來找你。設完關電腦，隔天早上它自己叮你。
- 2026-06-05
門開好了，這篇把助理接上 LINE。你做只有本人能做的事（登入 LINE 後台、複製兩把鑰匙、掃 QR 加好友），技術設定交給 Hermes。接完從手機傳一句話，它就回你。
- 2026-06-05
要讓助理接 LINE，得先讓外面的 LINE 伺服器連得到你家裡的電腦。這篇用 ngrok 幫電腦開一扇固定的對外門，一行指令、免費、不用自己有網域，重開機也不會斷。
- 2026-06-05
Hermes Agent Desktop（桌面版）下載 + 安裝教學。不用碰終端機：到官網下載桌面版、第一次打開自動裝好相依套件、用 ChatGPT 帳號登入，十幾分鐘就有一個你自己的 AI 助理在跑。
- 2026-06-04
我在 DGX Spark GB10 上量化 Google 新的 omni Gemma 4 12B。weight-only NVFP4 只要 7.7GB、跑 24.9 tok/s,而且圖片/語音/影片都還能用 —— 全 W4A4 反而沒比較快,還把多模態弄壞。
- 2026-06-04
一個 AI 助理＝大腦＋身體。大腦直接用你的 ChatGPT、身體用 Hermes，固定一套不用挑。這篇講為什麼這樣配，還有動手裝之前要準備什麼。
- 2026-06-04
想要自己的 AI 助理，你不用從零寫程式。agent 框架已經把麻煩事整包做好，裝起來就能用。這篇講為什麼別自己拼，直接用現成的 Hermes。
- 2026-06-04
你平常用 ChatGPT 多半是問一句它答一句。自己養的 AI 助理（agent）則能用你自己的工具把事做完、跑在你這邊、接你天天在用的軟體。從 0 打造自己助理的第一課。
- 2026-06-02
本機 35B agent 生圖生影片一直亂試,我差點跑去微調它。動手前先讀 tool-call log:格式 0% 出錯。模型沒問題,是一個壞掉的 ComfyUI 工具逼它即興。解法是一個乾淨的 ACI skill,不是微調。
- 2026-06-01
NVFP4 把蒸餾版 Sulphur 2(LTX-2.3)影片模型從 29 砍到 19.5 GB,在 GB10 DGX Spark 上畫質速度都沒掉。影片 diffusion 是 compute-bound,跟 LLM decode 剛好相反。
- 2026-06-01
GB10 上 NVFP4 W4A4 拔掉 --enforce-eager 後從 23 衝到 67 tok/s,贏 FP8 29% 還省 16GB。Part 32 說 cudagraph 沒用——那只對 dense,MoE 完全相反。
- 2026-05-30
GB10 DGX Spark 上，純 dense 模型單流 decode，NVFP4 比 FP8 快約 1.5 倍。但快的是頻寬（權重檔變小），不是 FP4 tensor core——最快那條路根本沒碰它。
- 2026-05-27
ChatGPT 剛紅那會兒，AI 是「丟字給你、你照做」。這兩年，它開始能查、能讀、能點滑鼠 — 從聊天機器變成會動手的東西。這篇整理這條演進過程，跟它為什麼重要。
- 2026-05-23
AI 自信地給你錯答案，語氣跟講真話一樣。三個訊號讓你提早警覺 — 數字超出範圍、細節太精確、重複問會跳號 — 加我自己被 ChatGPT 騙的真實案例。
- 2026-05-21
Round 1 在 chat workload 上沒有 2× speedup 後,Round 2 加 30K 中文 instruction data + huihui body 重生 response,訓練 41 小時。結果:Round 2 B drafter chat EN 45 tok/s / ZH 29 tok/s,跟 v1 基本相同,**遠輸 vanilla MTP n=4 的 EN 53 / ZH 45**。確認 EAGLE-3 small head 對上 abliterated body 的架構天花板,more data 救不了。順帶找到 vLLM Gemma 4 preview image(`gemma4-0505-arm64-cu130`,內部 build `0.20.2rc1.dev49+g9b4e83934`)在 long-run extract_hidden_states 的 scheduler deadlock(三次踩到 + watchdog 補完)。
- 2026-05-19
我有一條「發文前要查證」的規則,還是寫了三次說錯。問題不在規則,在它放在哪一層。這篇講我怎麼把它從 skill 升級成 hook — 一段守在「按下送出」那一刻的小程式,沒查證連嘗試都不准。
- 2026-05-16
在 DGX Spark GB10 上把 RedHatAI EAGLE-3 drafter fine-tune 對齊 huihui Gemma 4 26B-A4B abliterated FP8 body 的 distribution。1 epoch / 50k Magpie samples / 11h 訓練。Inference bench(raw `/v1/completions`)pos 3 acceptance 從 vanilla 的 20.5% → 72.7%、n=4 throughput 從 50 → 100.36 tok/s aggregate。**後續 paired bench 發現原 throughput 比較 baseline 跟 retrain 用了不同 endpoint(chat vs raw)— production chat workload 上 retrain drafter 的真實提升遠小於 2×,詳見文首 endpoint correction**。Part 28 證實的「abliterated body deep speculation acceptance 散開」這個機制觀察仍成立。順帶找到 Speculators upstream create_empty_sample dtype bug + Phase 0 整理 6 個社群 prior art。
- 2026-05-14
Part 28 是 mechanism,這篇是 recipe:abliterated Gemma 4 26B-A4B FP8 跑在 GB10 上,搭官方 vanilla draft 開 num_speculative_tokens=1,baseline 39.3 → 52.6 tok/s (+34%),不用重訓 drafter。30 行 docker run + bind-mount PR #41745 head 的 gemma4_mtp.py 就能拿到。包含 sanity check 跟什麼時候 n=1 不夠用的判斷。
- 2026-05-09
自量化 huihui Gemma 4 26B-A4B abliterated 成 FP8 ship 上 HF。完整 n=1..4 sweep 後發現:abliterated body 跟 vanilla baseline 完全一樣快,n=1 上 MTP 加成也一樣;但 n=4 deep speculation 上 huihui 因為 per-position decay 陡(每 step 22pp)而被 vanilla 拉開兩倍。Tax 的真實樣貌是 conditional on num_speculative_tokens,不是固定百分比。
- 2026-05-06
Google 2026-05-05 發 Multi-Token Prediction drafter,vLLM PR 同日開、官方 preview docker 同日有。DGX Spark 上實測 Gemma 4 26B-A4B-it FP8 + MTP γ=4:單流 108 tok/s(2.66× baseline)、8 路並行 674 tok/s 總吞吐。一個沒寫進文件的雷:drafter 不能配 base model,要配 -it。
- 2026-05-05
sysprog21/zhtw-mcp 把繁中規則編譯成執行檔。掃 ai-muninn 全部 72 篇繁中文章三輪修了 128 處陸用詞,但真正的收穫不是修了多少 — 是發現我的盲點不是「不知道台灣怎麼說」,是「碰到陸用詞時預設不會主動懷疑」。
- 2026-05-04
Z-Image Turbo 量化版會不會崩品質?LPIPS(perceptual 距離 vs BF16)+ CLIPScore(image-text 對齊)雙軸跑 6 prompt × 4 config × 3 seed = 72 sample。結論:NVFP4 跟 BF16 圖長得不一樣,但這個 N=72 sample 沒測到任何量化 config 的 prompt fidelity regression — 4 個 config CLIPScore 都在 ±std 0.04 內,差距比 noise 小一個數量級。
- 2026-05-04
DGX Spark GB10 上 Z-Image Turbo 6 種量化組合(BF16 / FP8 cast 標準 / FP8 cast fast / FP8 scaled Kijai / NVFP4 / NVFP4+FP8 encoder)實測。N=10 隔離 GPU 測,NVFP4 5.50s warm 比 BF16 7.55s 快 1.37×,FP8 三條 path 全比 BF16 慢。模型工作集 RSS 從 BF16 20.6 GB 降到 NVFP4+FP8 11.5 GB(省 44%)。
- 2026-05-03
AI 一樣自信地給你對的答案跟編的答案，分不出來。三招 30 秒驗：具體事實 Google 一次、叫 AI 補連結點開看、換家問或開臨時聊天。
- 2026-05-01
同一台 DGX Spark，這次不拚速度，改拚「看完英文影片講給我聽」。3 分鐘 Karpathy 演講 89 秒處理完，5 萬 4 千 prompt token，逐字稿和畫面內容都對。記錄兩個踩過的雷：use_audio_in_video flag 放錯位置會幻覺音訊、b12x patch 過的 image 在 Omni 上會吐 NaN。
- 2026-05-01
十天前我說 NVFP4 在 DGX Spark 上是個坑、FP8 比較快。今天同一台機器跑 Nemotron 3 Nano W4A16 飆到 74.75 tok/s，連我自己之前的 FP8 hack 紀錄一起踩過去。這篇講 4 層 patch、quant variant 怎麼選、跟記憶體頻寬天花板的算法。
- 2026-05-01
三個主流 AI 各自有強項，選錯就是用錯工具。一句話分辨：第一次接觸選 ChatGPT、要寫長文選 Claude、用 Google 服務多選 Gemini。文末有對照表跟快速決策流程。
- 2026-04-30
ai-muninn 這個月 Vercel Edge Requests 用滿 1M/1M，免費額度被擋。原因不是流量，不是 bot，是 Next.js 預設讓 /public/* 回 must-revalidate，連 cache HIT 都算 edge request。修法只有 3 行 config，但本月扣掉的配額拿不回來。
- 2026-04-29
AI 第一句問得不好，後面追多少都是補洞。三個開場白：角色扮演、講清情境、講最終目標——任選一個用，AI 回答品質會明顯差很多。文末有 copy-paste prompt 範本。
- 2026-04-28
把 huihui-ai 的 Qwen3.6-35B-A3B abliterated BF16 量化成 FP8，部署到 DGX Spark GB10。從 4 次 OOM 到 1.68× over BF16 的完整旅程：UMA 物理上限、save_pretrained 的 50GB shard 陷阱、語言模型 prefix bug、MTP speculative decoding，以及為什麼第一個成功的版本根本沒做 FP8 cast。
- 2026-04-27
Qwen 3.6 35B-A3B 在 SWE-bench Lite 拿 48.33%(145/300),貼近 SWE-agent + Claude 3.7 Sonnet。但剩下的 155 題告訴你模型還差什麼:76% 是「找對檔案、改錯邏輯」。Gemma 4 26B 同一套 scaffold 拿 38.67% — 9.66% 落差大概率來自不同失敗類型的比例不同。
- 2026-04-27
打開 ChatGPT 不知道從哪開始？需求不是天生就知道，是被找出來的。從每週重複的事、最常 Google 的問題、一直拖的事、看不懂的東西、卡住的下一步，五個角度幫你挖出 AI 真正能幫你的場景。
- 2026-04-27
ChatGPT 第一次回答不夠好不要放棄。再追三句話：「澄清問題」、「補充情境」、「指定格式」——80% 場景用這個套路就解決。文末有可以直接抄的 prompt。
- 2026-04-26
把 huihui-ai 的 abliterated Qwen 3.6 35B 丟進 Part 21 同一套 TMMLU+ 測下去。總分從 75.07% 掉到 73.22%。代價分布不平均：規範性題目（信託 −7.7、行政法 −7.1）失血最重，純邏輯反而略好。台語也變更差——abliteration 解不了資料缺乏。
- 2026-04-25
同一台 DGX Spark、同一套 harness、同樣 22,690 題。Qwen 3.6 35B-A3B 拿到 75.07%，Gemma 4 26B-A4B 拿到 46.30%。Qwen 在 51 個子科目上一個都沒輸——連我原本以為 Gemma 會贏的台灣題目都沒贏。
- 2026-04-22
Part 19 證明 NVFP4 在 DGX Spark 上是陷阱。這篇直接動手：寫 Triton kernel 把 NVFP4 轉成 FP8，餵 FP8 tensor core。從 40.8 提升到 47.6 tok/s，附完整程式碼。
- 2026-04-21
NVFP4 理論上更快——位元更少、頻寬更省。但在 DGX Spark 的 GB10 (SM121) 上反而慢 32%。根因：缺硬體指令。vLLM 和 SGLang 雙引擎驗證。
- 2026-04-20
一套 scaffold（backticks + edit-tool + budget prompt），三個模型（Gemma 4 E4B、Gemma 4 26B、Qwen 3.6 35B），跑之間零程式碼改動。Qwen 3.6 拿到 48.33%——超越 SWE-agent + Claude 3.7 Sonnet。Scaffold 是固定成本，模型是變數。
- 2026-04-17
Gemma 4 26B-A4B FP8 在 SWE-bench Lite 解了 116/300 題，全球排名 #16。跑在 DGX Spark 上，零 API 費。差距在 scaffold 設計，不是模型大小。
- 2026-04-17
本地 AI 不是便宜版 ChatGPT。它是知識萃取器、私有程式碼助手、離線工具。月電費 NT$41 vs ChatGPT Plus NT$640 — 但便宜不等於好用。這篇教你什麼時候該用哪一種。
- 2026-04-16
AI 很強，但在 2026 年還是有四個地方會踩雷：幻覺、資料過時、記性不好、隱私外洩。寫這篇文章時我自己就被 Gemini 幻覺擺了兩次。
- 2026-04-15
在 GX10 用 mini-swe-agent + vLLM 跑 SWE-bench Lite 單題，從假成功的 doc 一路修到 Gemma 4 38 步乾淨 submit 正確 patch 的 scaffold engineering 紀錄。
- 2026-04-15
Q4_K_M 用 4 bit 怎麼裝得下 14B 模型？答案不是「切掉 75%」，而是 K-quant 的 super-block 分組、TurboQuant 的隨機旋轉、跟 QJL 的 1-bit sign sketch 三層演算法。一篇講清楚機制，但不推公式。
- 2026-04-14
AI 給你的第一個答案只是草稿。學會五種追問技巧 — 加限制條件、要比較、讓 AI 反問你 — 同一個問題的答案品質天差地遠。
- 2026-04-14
AI 聊到一半就忘記你說過的話？不是它壞了，是它的書桌滿了。這篇解釋什麼是 context window、為什麼對話太長會出問題、怎麼避開這個限制。
- 2026-04-13
可行性測試：開源模型能免費在本地跑 SWE-Bench 嗎？Gemma 4 26B 在 OpenHands 上失敗（40+ 錯誤），但在 SWE-agent 上 9 步修好測試 bug。同一個模型，差別在 action 格式。
- 2026-04-13
Gemma 4 E2B / E4B / 26B MoE / 31B Dense 在 DGX Spark、RTX 5090、MacBook Pro 上的完整對照表。一張表看完速度、記憶體、量化格式。附選擇建議。
- 2026-04-13
剛開始用 Claude Code，context window 一直滿。這篇解釋 token 花去哪、哪些浪費了、怎麼讓 Claude 更精準地找資料而不是暴力讀檔。
- 2026-04-13
你問 AI 的第一個問題不該是「幫我做 X」，而是「有沒有已經能做 X 的工具？」這篇教你怎麼用 AI 當研究助手 — 找工具、比較方案、確認它還活著。
- 2026-04-13
CLAUDE.md 和 MEMORY.md 會默默長大，直到每個 turn 吃掉 10K+ tokens。我做了一個 /slim skill 讓 Claude 自己診斷和修復膨脹 — 這是完整做法。
- 2026-04-13
從密封箱到跑出第一個 LLM 的所有步驟。硬體檢查、Ollama 快速上手、vLLM 正式部署、模型選擇、5 個會浪費你整天的坑。
- 2026-04-11
同一個 AI，同樣的問題，結果卻完全不同。覺得 ChatGPT 改變人生的人和覺得它沒用的人，其實在做兩件完全不同的事 — 差別只在一個心態轉換。
- 2026-04-10
Q4_K_M、Q8_0、FP16 — 同一個模型有十幾種版本，名字看起來像亂碼。這篇告訴你量化到底在做什麼、為什麼不會把模型搞壞、以及你該下載哪一個版本。
- 2026-04-10
大部分人不是不會用 AI，是不知道自己工作裡哪些事可以交給 AI。這篇教你用一個簡單的方法，讓 AI 幫你找出每天重複做卻沒意識到的事情。
- 2026-04-10
Gemma、Llama、Qwen、Mistral — 模型清單看得眼花撩亂。這篇用買車的邏輯教你怎麼從大小、速度、品質三個維度選到適合你的 AI 模型。
- 2026-04-09
AI 不是 Google，你不是在搜尋，你在對話。這篇教你打開 ChatGPT 之後該怎麼開口、五個立刻能試的任務、和回答不滿意時怎麼調整。
- 2026-04-09
ChatGPT、Claude、Gemini — 三個你現在就能用的 AI 助手。這篇用最白話的方式介紹它們各自的強項、價錢、和怎麼開始，幫你選到適合自己的那一個。
- 2026-04-08
Gemma 4 31B 在 MBP M1 Max 上用 Ollama 只有 1.5 tok/s（swap）。解法：降 context window（9 tok/s）或用 oMLX（12.8 tok/s）。真正的兇手是 KV cache 分配，不是模型大小。
- 2026-04-08
Gemma 4 E2B 到 31B 在 RTX 5090、M1 Max、DGX Spark、M4 上用 Ollama 完整測試。E2B 在 5090 上 310 tok/s。31B 在 MBP 上 1.5 tok/s — swap 殺死一切。記憶體容量 > 頻寬速度。
- 2026-04-08
Dense 是全員出動，MoE 是專家輪班，PLE 是每層樓有自己的櫃台，SSM 是速讀高手。用零技術門檻解釋四種主流 AI 模型架構的差別，幫你看懂規格表。
- 2026-04-07
Gemma 4 E2B 在 M1 Max 跑到 81 tok/s，比 E4B 快 44-82%。三台機器、相同方法論、每輪獨立 prompt，排除 Ollama 快取干擾後的真實數據。
- 2026-04-07
Gemma 4 E4B NVFP4A16 在 DGX Spark 上跑 49.9 tok/s — 比 BF16 快 2.6 倍。HuggingFace 上第一個 NVFP4 checkpoint。PLE 架構解析、FP8 vs NVFP4、以及差點讓我們放棄的 llm-compressor 版本地獄。
- 2026-04-07
Ollama 像微波爐，vLLM 像專業烤箱。兩個都能在你的電腦上跑 AI 模型，但適合的場景完全不同。這篇用零技術門檻的方式解釋差別、優缺點、和怎麼選。
- 2026-04-05
Gemma 4 31B-IT NVFP4 在 GB10 上只有 7.0 tok/s — 273 GB/s 頻寬是天花板。算術預測 4.4 tok/s，NVFP4 壓縮多了 60% 但逃不出牆。請選 MoE。
- 2026-04-05
同一個 Gemma 4 26B-A4B、同一張 GPU，vLLM NVFP4 跑 52 tok/s，Ollama Q4_K_M 只有 40。根因：Marlin kernel、CUDA graphs，以及 Ollama 靜默的 CPU/GPU split 陷阱。
- 2026-04-05
在 GB10 上用 vLLM 0.19 部署 Gemma 4 26B-A4B MoE NVFP4 — 52 tok/s decode、16.5 GB 模型、82 GB KV cache 可用。包含 Phase 0 決策過程和完整踩坑記錄。
- 2026-04-02
DGX Spark 的供電和過熱問題在 Carmack 批評後引爆社群。這篇整理三種不同症狀的診斷方法：30W PD controller 缺陷（需 RMA）、100W 功耗上限（散熱降頻）、5W driver bug（可修）。一個指令 30 秒確認。
- 2026-03-30
Google TurboQuant 在 GX10 (GB10/SM121) 上的實測數據 — 3-bit KV cache 壓縮的真實壓縮率、Qwen2.5-3B 精度驗證、以及 Qwen3.5-35B 的 hybrid attention 架構為什麼讓事情變得複雜。
- 2026-03-24
openclaw 2026.3.13 加入了 OpenAI OAuth 登入。一行指令讓你的 agent 用 ChatGPT Plus 訂閱取得 GPT-5.4 的 100 萬 token context，不需要另外買 API credits。
- 2026-03-24
怎麼把 NemoClaw 的推理後端指向本地 Ollama 或 vLLM endpoint。Config 位置、模型替換，以及雲端消失後 OpenShell 仍然在做什麼。
- 2026-03-23
NemoClaw 在 DGX Spark 上直接裝會失敗。這篇整理了 4 個官方文件沒提的修正（Node 升級、npm link、OpenShell tar.gz、cgroupns），30 分鐘跑起第一個 AI Agent。
- 2026-03-23
NemoClaw = OpenClaw + OpenShell + NVIDIA Agent Toolkit 三合一。這篇講清楚它解決什麼問題、架構怎麼運作、值不值得在 DGX Spark 上裝。
- 2026-03-21
把 editMessageText 輪詢換成 sendMessageDraft，實現真正的動態串流輸出。patch 方式、thinking block 過濾、以及私訊裡的 optional chaining 坑。
- 2026-03-21
openclaw 串接 gpt-oss-120B，第一條訊息就收到 400 max_tokens must be at least 1, got -1292。Context budget 的數學、config key 的坑、以及修法。
- 2026-03-21
vLLM serve script 加了 --kv-cache-dtype fp8，GB10 上輸出在約 500 token 後退化成重複字。根本原因：沒有 calibration data，q_scale 預設 1.0。
- 2026-03-21
用 claude -p subprocess 建 multi-agent orchestrator，發現中間 turn 全被靜默丟棄。SDK 遷移、session resume、並行執行、以及 setting_sources 的影響。
- 2026-03-19
Bot process 跑著、token 有效、訊息有收到。但沒有任何回應。四個錯誤假設、一張路由表，還有一個大多數人不知道的 Node.js 行為。
- 2026-03-19
怎麼讓 gpt-oss-120B 在 DGX Spark（GB10、SM121）上以 vLLM 跑到 60 tok/s。目標是讓 openclaw agent 用本地 120B 模型，零 API 費用。路上有六個坑，其中一個靜默失效的環境變數比其他五個加起來還難找。
- 2026-03-19
修完四個 SM121 NVFP4 bug 之後，Qwen3.5-122B 能跑、輸出正確。然後你看了速度：14 tok/s。沒有 flag 能修它。為什麼——以及在等什麼。
- 2026-03-18
怎麼在本地 agent loop 裡掛上 callhelp tool，讓它在推理途中 spawn Codex CLI。一個必設的 permission flag，還有為什麼 Claude quota 是我自己的。
- 2026-03-17
CUTLASS FP4 kernel 是針對 SM120（GB200）編譯的。在 SM121（GB10，DGX Spark）上它會靜默執行，但輸出垃圾。完整除錯過程——4 個 bug、row-identical 失敗特徵，以及有效的修正方案。
- 2026-03-16
為什麼我們停止讓 OpenClaw agent 直接編排多步驟任務，改成派生 Codex subprocess。這個模式讓 agent context 保持輕量、任務執行更可靠。
- 2026-03-13
在 ASUS GX10（SM121，128GB）上跑 NVIDIA Nemotron-3-Super-120B-NVFP4。四個 SM121 專屬坑、一個沒有任何作用的環境變數，以及最終可用的 docker 指令。
- 2026-03-07
128GB 統一記憶體的機器 vLLM 重啟時 OOM。原因：Ollama KEEP_ALIVE=2h 把 19-51GB 壓在 GPU 上。診斷指令、手動 unload 方式、以及為什麼要把 KEEP_ALIVE 改成 0。
- 2026-03-06
把 --enable-chunked-prefill 加到 Qwen3.5-35B（SSM+MoE hybrid）上，吞吐量從 47 tok/s 掉到 5.7 tok/s。解釋為什麼 SSM 遞迴架構和 chunked prefill 根本不相容。
- 2026-03-05
TTFT 從幾秒降到 0.12s。DGX Spark GB10 上 Qwen3.5-35B 從 Ollama 換到 vLLM 的實戰筆記，含六個坑：SSM + chunked prefill 陷阱、記憶體衝突、docker 重啟順序。
- 2026-03-05
完整的本地 AI Agent 架構：Mac Mini M4 當長駐 gateway，GX10 跑推理，Telegram 當介面。不需要訂閱，不需要雲端 API。六個部署心得。
- 2026-03-01
GLM-4.7-Flash 短 context 57.8 tok/s，但 8K 時掉到 42 tok/s。Qwen3.5-35B SSM hybrid：短 56 tok/s，8K 仍 56 tok/s。為什麼有長 system prompt 的 agent 應該在乎這個差距。
- 2026-02-26
一個 /debate 指令讓 Codex CLI 和 Gemini CLI 對同一份程式碼互相辯論。訓練資料不同、盲點不同——它們的分歧通常是最有用的輸出。
- 2026-02-26
把截圖導向的 iOS 測試改成 ui_describe_all 優先，BPS Tracker 測試的 context 用量從 81,290 KB 降到 15,215 KB。外加 Fastlane 整合：截圖、App Store 上傳全自動。
- 2026-02-25
花了好幾週每次改設定都重啟 gateway。後來才發現有 file watcher。哪些東西可以立即熱重載、哪些還是要重啟、還有怎麼區分 auth 失敗和短暫網路錯誤。
- 2026-02-19
設定檔裡標了 MANDATORY 的規則，同一個 session 裡被跳過了兩次。這篇解釋三個架構原因為什麼強調沒用，以及三個真正有效的系統設計解法。
- 2026-02-19
在 NVIDIA GB10（128GB 統一記憶體）上，用 7 個任務類別評測 8 個本地 LLM。量化的意外結論、一個連 JSON 都出錯的 120B 模型，以及把整個 token budget 用來思考的 thinking model。
showing 176 篇文章