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 導...
結婚快一年了，有了小孩後，本來要上傳的影片就都忘了上傳分享。
我本來計劃做三段影片，婚紗篇是在開桌前的會場裡播放，另外還有戀愛篇及成長篇，分別是換裝跟敬酒前可以放，不過後來只再完成了戀愛篇。
婚紗的照片，我們都是在三芝淺水灣拍的，室內場景是「旅途中民宿」，會選擇這裡是因為交往的時候，我們曾在一個颱風天住在這裡，沒辦法事先訂好了，那晚的風，很可怕。
其實本來日本行也要拍些婚紗的照片，但都忙著 Shopping 了。
婚紗也是走 DIY 的風格，但還是輸給了另一對只帶一台單眼，穿著婚紗就跑來的新人。我們是請大姨子攝影，我權充攝影助理，拿拿反光板，老婆則是把訂做的跟買的婚紗帶著，化妝造型自己來。
影片的部份，我是用了 muvee autoProducer 這一套軟體，很容易上手，選選預設的模版，配樂調場景，就完成了，時間都是花在配合音樂的場景選擇，還有最後轉檔，當時是拿用了 5 年的 NB 來做，平白花了不少時間。
來看看影片：
相關連結：
1.旅途中民宿：http://www.j-shop.idv.tw/travel/
2.muvee autoProducer：http://www.muvee.com/
留言
張貼留言
回應不用錢，請多多益善！懶得寫字按個讚也是相當感謝！