跳到主要內容

發表文章

目前顯示的是 8月 16, 2026的文章

16GB ROCm 本地 LLM-as-a-Verifier 實測數據：Qwen3.5-9B 跑起來到底多快

TL;DR: 用 Qwen3.5-9B（Q4_K）在單張 16GB AMD GPU 上跑本地 LLM-as-a-Verifier，每次 code comparison 約 0.5–2 秒，cache hit rate 66%，正確程式碼穩定給 1.0 分，有 bug 的給 0.0–0.14 分。16GB 跑 9B 模型綽綽有餘，還有空間跑其他服務。 這篇是實測續篇，前兩篇分別講了 架構設計 和 Docker 封裝 。前兩篇講的是「做什麼」跟「怎麼做」，這篇來量「到底多快」。 1. 測試環境 在一台 homelab Linux（CachyOS）上跑的： 項目 內容 GPU AMD 16GB（15.9 GiB）via ROCm 模型 Qwen3.5-9B（8.95B 參數，Q4_K ~5.7GB GGUF） 後端 llama.cpp（llama-server，ROCm HIP build） Verifier Docker container（llm-verifier），port 8010 模型 VRAM ~10.2 GB（模型本身 + 動態 KV cache） GPU 使用率 78% 系統 RAM 62 GB；使用 27 GB（swap 用了 9.3 GB） Context window 131,072 tokens MIN_SCORE 0.8 後端跑在另一台機器上，走 local Gigabit 網路連線。 2. Verifier 在幹嘛 docker-llm-as-a-verifier 包裝了 LLM-as-a-Verifier 這個研究套件，讀取 token-level log probability 來算連續分數，不是簡單的 yes/no 判斷。 Container 開了 7 個 HTTP endpoint： Endpoint Method 用途 /health GET 健康檢查 /v1/compare POST 兩組答案比對評分 /v1/select POST Best-of-N 選最佳 /v1/track POST Agent 軌跡分數追蹤 /v1/directed POST 導...
張貼留言
閱讀完整內容

16GB ROCm 本地 LLM-as-a-Verifier 實測數據：Qwen3.5-9B 跑起來到底多快

TL;DR: 用 Qwen3.5-9B（Q4_K）在單張 16GB AMD GPU 上跑本地 LLM-as-a-Verifier，每次 code comparison 約 0.5–2 秒，cache hit rate 66%，正確程式碼穩定給 1.0 分，有 bug 的給 0.0–0.14 分。16GB 跑 9B 模型綽綽有餘，還有空間跑其他服務。 這篇是實測續篇，前兩篇分別講了 架構設計 和 Docker 封裝 。前兩篇講的是「做什麼」跟「怎麼做」，這篇來量「到底多快」。 1. 測試環境 在一台 homelab Linux（CachyOS）上跑的： 項目 內容 GPU AMD 16GB（15.9 GiB）via ROCm 模型 Qwen3.5-9B（8.95B 參數，Q4_K ~5.7GB GGUF） 後端 llama.cpp（llama-server，ROCm HIP build） Verifier Docker container（llm-verifier），port 8010 模型 VRAM ~10.2 GB（模型本身 + 動態 KV cache） GPU 使用率 78% 系統 RAM 62 GB；使用 27 GB（swap 用了 9.3 GB） Context window 131,072 tokens MIN_SCORE 0.8 後端跑在另一台機器上，走 local Gigabit 網路連線。 2. Verifier 在幹嘛 docker-llm-as-a-verifier 包裝了 LLM-as-a-Verifier 這個研究套件，讀取 token-level log probability 來算連續分數，不是簡單的 yes/no 判斷。 Container 開了 7 個 HTTP endpoint： Endpoint Method 用途 /health GET 健康檢查 /v1/compare POST 兩組答案比對評分 /v1/select POST Best-of-N 選最佳 /v1/track POST Agent 軌跡分數追蹤 /v1/directed POST 導...
張貼留言
閱讀完整內容

窮人的 LLM-as-a-Verifier：16GB 顯卡 + ROCm 打造地端 0 成本 Agent 審查閘門

TL;DR: 這篇寫給不想被雲端 API 掏空錢包、又怕 AI Agent 盲目重構改爆 Codebase 的開發者。我們用 Radeon RX 9060 XT 16GB、Linux ROCm (HIP) 硬體加速，加上 Rust 寫的確定性 2PC 防禦門衛，手刻一套符合 PRM（Process Reward Model）規格的地端零成本 AI 外骨骼系統。 1. 痛點：Agent 狂歡背後的帳單破產與程式碼毀滅 Autonomous Coding Agent（OpenCode、Claude Code 等）大幅改變了開發流程，但附帶兩大噩夢： Token 黑洞與 API 帳單爆表 ：為了確保程式碼品質，Agent 需要頻繁自我思考、多方案比較（Best-of-N）與長鏈修復。幾輪對話下來，雲端 API 帳單直接失控。 確定性缺失（Non-determinism） ：沒有 Guardrail 攔截的 Agent 就像沒導航的賽車——隨時在背景修改全域 Interface、弄爛 DB Schema，甚至產生語法幻覺。 解答 ：我們需要 Verifier（過程監督者）。但大廠論文動輒用 A100 叢集配 vLLM 預分配幾十 GB VRAM，一般開發者負擔不起。我們需要一套在地端 16GB VRAM 上順暢跑的「窮人版 Process Supervision 體系」。 2. 硬體與驅動層：為什麼選 Radeon RX 9060 XT 16GB + ROCm (HIP)？ 在 Homelab / Linux (CachyOS) 環境下，配 Radeon RX 9060 XT 16GB 搭 ROCm Backend 是 CP 值很高的搭配： HIP 矩陣加速與 VRAM 吞吐 ：透過 ROCm 原生 HIP 加速，16GB VRAM 能穩穩咬住 Qwen3.5-9B with mmproj（程式碼語意 + 多模態視覺）。 逃離 vLLM 的 VRAM 黑洞 ：vLLM 預分配 90% VRAM 的機制在單機多任務環境是災難。改用 ROCm 版的 llama-server（GGUF 量化），模型權重只吃 5~9 GB VRAM，剩下的空間還能動態分配 KV Cache，主機照樣順跑其他服務。 0 API 成本 ：2PC（兩階段提交）觸發一萬次 /...
張貼留言
閱讀完整內容

用 AI 寫程式的痛：我們做了兩個小工具來解決

用 AI 寫程式最大的問題是什麼？對我們來說，不是模型不夠聰明，而是 不放心 。 LLM token 越來越貴，但大部分都在重複看已經知道的程式碼結構。 Agent 改完程式編譯不過，要來回好幾輪才修好。 工作到一半 context 滿了，重開 session 什麼都不記得了。 有時候改壞了檔案還沒人知道。 這些問題大概不是只有我們遇到。我們的做法是寫兩個小工具來補，一個管 輸入成本 ，一個管 操作安全 。兩者透過 MCP 協定接進 OpenCode，各自只做一件事。 工具一：GraphifyRust — 讓 LLM 不用重看整包程式碼 GraphifyRust 是用 Rust 寫的靜態分析引擎。用 Tree-sitter 解析原始碼，把 function、struct、trait 這些節點抽出來，建成一個有向圖。 AI agent 要改程式時，傳統做法是把整支檔案丟給 LLM。幾百行的檔案可能只有幾段 function 相關，但 LLM 還是得看完所有 import、註解、不相干的邏輯。 Graphify 的 skeleton_extract 只回傳 AST 骨架 — function 名稱、行號、簽名。實際壓縮效果： 檔案 原始 token 骨架 token 節省比例 server.go (BloggerAgent MCP) 1,289 117 90.9% toon.rs (Graphify 核心) 2,132 147 93.1% 骨架不夠用時，用 range mode 精準讀取特定 function。不需要整包丟進去。 選 Rust 的理由很務實：Tree-sitter 的 Rust binding 最成熟。在 110 個檔案、422 條邊的測試專案上，建圖只要 16ms ，比之前 Python 版快 26 倍。節點用 petgraph arena 預分配，減少 heap 碎片。輸出用自訂的 .toon 格式，體積比 JSON 少 60%。 語意搜尋用本機 Qdrant，沒有雲端費用。目前支援 9 種語言：Rust、Python、Go、JavaScript、TypeScript、C、C++、Java、PHP、Swift。 工具二：StateMachineMcp — 永遠不讓壞掉的程...
張貼留言
閱讀完整內容