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 導...
因為我一直很關注數位內容的發展，不過對於現在的閱讀載具倒沒有那麼有興趣，技術推陳出新，會有更好的載具不斷出現，最主要是對於數位內容有著很高的期待，除了數位內容的共同標準，還有數位化個人出版的智慧產權的發展，個人認為，數位化的內容將是未來趨勢，僅管目前仍有尚待解決的問題，不過趨勢是不會改變的。 以前寫過一篇： 釋放空間．解放圖書館．文明的入口 ，裡頭其實有提到一些看法 (也有關於 epub 的格式的介紹)。 最近也發現了一個網站： Pubu書城 ，提供雜誌、小說、商業理財等各類電子書，支援 pdf 及 epub 檔案下載，PC、手機及電子閱讀器皆可支援，既是出版社的通路，也提供素人作家出版的平台。 覺得還蠻有趣的，至少華文個人出版的平台已經出現了，而數位內容的發展還得繼續觀察，所以先跟大家分享這個網站： http://www.pubu.com.tw/ 底下是閒聊的對話》(歡迎回應加入討論) 一開始是我轉載了一篇文章連結： 您可以想像圖書館的預算被刪減後會怎樣嗎? ，開始聊起來的。 咖哩：不管圖書館預算如何，我希望可以儘快把所有紙本圖書都電子化，讓圖書館成為典藏珍貴書籍的博物館，而實際的圖書館化身成為幾部主機，大家以後出書也都一律電子版，不要再砍樹了！ Jimmy Yen：說實在的，數位化的預算可能還要更高才成 咖哩：目前的收藏要一頁頁掃描甚至OCR成電子檔，是一件困難的事（Google做了好多年了），但假如一旦成為電子化，才有希望將內容做長久的保存以及分享，也才有希望從浩瀚書海中被需要的人『搜尋』到，願那一天儘快來臨！ Jesse Wang：以 IT 人來看電子化藏書不見的比較環保，你需要更多的電力、更多的電腦來儲存及備援，電力的製造跟電腦的製造目前就是非常不環保。更別說若干年後因為儲存媒介跟檔案格式的變更，很可能反而讓一堆電子檔都無法再使用。早期的卡帶現在已經不太能找到設備來讀取，反而幾千年前的羊皮紙跟竹簡還能看內容。 咖哩：儲存不一定需要電力持續support，但是紙本書籍的照顧需要溫濕度控制，你可以想一想，在一般沒有控制溫濕度的空氣中，隨身碟比較耐放還是紙本，更何況隨身碟還只是很隨便的儲存方式。 你如果要說這些硬體的製造很不環保，那麼，紙本書籍世世代代都要吹冷氣控制溫濕度，甚至講究一點還要燈光的控制，長久下來這些照護成本一定超過電子儲存方式，純粹時...