Prefill（預填充階段）：運算性能。處理使用者輸入的提示詞，運算速度卡在GPU的性能。影響首字輸出時間（Time to First Token, TTFT），如果處理的的上下文很大，就需要花很長的時間才會開始輸出結果。比如說我的Radeon 780m能夠處理400t/s，處理32k的上下文大約得花80秒。
Decode（解碼階段）：記憶體頻寬。逐一生成 Token 的過程，卡在GPU與VRAM之間的頻寬。每生成一個新 Token，模型都必須把所有的模型參數從顯示記憶體重新讀取到運算單元中一次，只為了計算「那一個」Token。以Radeon 780m為例，搭配雙通道DDR5-5600 SODIMM理論上有89.6GB/s的頻寬，跑Gemma 4 26B A4B Q5_K_M，因為量化加上只有啟動3.8B的參數，每次從記憶體讀取的量約為2.6GB。這樣可以估算生成速度約在34t/s，但實際上會有額外耗損，根據我的實測是在20~14t/s左右。不算快，但高於一般人的閱讀速度。我有試過跑Gemma 4 31B IQ4_XS的量化稠密模型，生成速度大約是2t/s，太慢了。
結論
如果要處理的文本很大，優先考慮GPU運算性能。
如果輸出的內容很大，優先考慮記憶體頻寬。
若是兩者都需要，RTX 6000 Blackwell 96GB在旁邊招手呢，一張約新台幣30萬左右，比買三張RTX 5090貴，但是配置較簡單。
2026年5月4日 星期一
本地跑LLM的算力需求
2026年5月2日 星期六
Ryzen 8845HS w/ Radeon 780M的LLM性能測試
Rentry的易讀表格版本：https://rentry.co/5utrg5cy
LLM性能測試
硬體
GMKTek K8 Plus
CPU: AMD Ryzen 8845HS
RAM: 64GB DDR5-5600 SODIMM（雙通道）
GPU: Radeon 780m 8GB（透過BIOS設置VRAM大小）
OS: Ubuntu 24.04
系統配置調整：
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.gttsize=49152 ttm.pages_limit=12582912"
主要是讓單一程序可以使用最多48GB的記憶體。
測試軟體：llama-benchy 0.3.7
指令
llama-benchy --base-url <api url> --model
zerofata/G4-MeroMero-26B-A4B --depth 0 4096 8192 16384 32768 --tg 128
--latency-mode generation --enable-prefix-caching
測試模型：G4-MeroMero-26B-A4B Q5_K_M量化版本（Gamma 4 26B A4B的微調版本）
測試標的
koboldcpp-1.112.2
啟動指令
./koboldcpp-linux-x64-nocuda --model
./G4-MeroMero-26B-A4B-Q5_K_M.gguf --host 0.0.0.0 --threads 7 --usevulkan
0 --blasbatchsize 2048 --gpulayers 49 --contextsize 32768
--flashattention --skiplauncher --jinja --mmproj
./mmproj-Gemma-4-26b-a4b-f16.gguf --mlock --usemmap --jinjatemplate
./chat_template.jinja
| model | test | t/s | peak t/s | ttfr (ms) | est_ppt (ms) | e2e_ttft (ms) |
|---|---|---|---|---|---|---|
| zerofata/G4-MeroMero-26B-A4B | pp2048 | 419.95 ± 2.39 | 5288.49 ± 27.66 | 4879.28 ± 27.66 | 5288.49 ± 27.66 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 | 18.41 ± 0.04 | 20.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d4096 | 384.90 ± 3.16 | 11054.21 ± 87.02 | 10644.99 ± 87.02 | 11054.21 ± 87.02 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d4096 | 17.54 ± 0.05 | 19.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d4096 | 350.57 ± 2.01 | 6251.27 ± 33.44 | 5842.05 ± 33.44 | 6251.27 ± 33.44 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d4096 | 17.30 ± 0.02 | 19.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d8192 | 357.27 ± 1.90 | 23341.93 ± 122.05 | 22932.71 ± 122.05 | 23341.93 ± 122.05 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d8192 | 16.97 ± 0.02 | 18.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d8192 | 313.21 ± 0.19 | 6947.91 ± 3.87 | 6538.69 ± 3.87 | 6947.91 ± 3.87 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d8192 | 16.75 ± 0.02 | 18.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d16384 | 311.77 ± 1.46 | 52964.47 ± 245.13 | 52555.26 ± 245.13 | 52964.47 ± 245.13 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d16384 | 16.19 ± 0.08 | 17.33 ± 0.47 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d16384 | 254.26 ± 0.49 | 8464.01 ± 15.68 | 8054.79 ± 15.68 | 8464.01 ± 15.68 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d16384 | 15.94 ± 0.02 | 17.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d32768 | 261.11 ± 1.65 | 125417.69 ± 791.20 | 125008.48 ± 791.20 | 125417.69 ± 791.20 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d32768 | 14.70 ± 0.02 | 16.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d32768 | 142.70 ± 1.09 | 14761.37 ± 109.20 | 14352.15 ± 109.20 | 14761.37 ± 109.20 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d32768 | 14.77 ± 0.02 | 16.00 ± 0.00 |
llamacpp-rocm b1256
啟動指令
./llamacpp-rocm/llama-server -m ./G4-MeroMero-26B-A4B-Q5_K_M.gguf
-ngl 99 -c 32768 --temp 1 --top-k 64 --top-p 0.95 --host 0.0.0.0 -mm
./mmproj-Gemma-4-26b-a4b-f16.gguf --chat-template-file
./chat_template.jinja
在16k的測試出現異常，可能是模型崩潰與重複輸出造成。
| model | test | t/s | peak t/s | ttfr (ms) | est_ppt (ms) | e2e_ttft (ms) |
|---|---|---|---|---|---|---|
| zerofata/G4-MeroMero-26B-A4B | pp2048 | 335.70 ± 14.45 | 6233.64 ± 258.34 | 6115.70 ± 258.34 | 6233.64 ± 258.34 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 | 15.42 ± 0.01 | 16.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d4096 | 290.31 ± 12.24 | 14253.80 ± 580.96 | 14135.86 ± 580.96 | 14253.80 ± 580.96 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d4096 | 14.07 ± 0.01 | 15.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d4096 | 238.90 ± 2.19 | 8691.36 ± 78.59 | 8573.42 ± 78.59 | 8691.36 ± 78.59 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d4096 | 13.79 ± 0.01 | 14.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d8192 | 260.37 ± 3.20 | 31589.77 ± 383.96 | 31471.83 ± 383.96 | 31589.77 ± 383.96 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d8192 | 13.67 ± 0.01 | 14.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d8192 | 218.36 ± 0.69 | 9497.17 ± 29.59 | 9379.23 ± 29.59 | 9497.17 ± 29.59 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d8192 | 13.55 ± 0.00 | 14.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d16384 | 241.87 ± 3.54 | 67874.56 ± 1000.78 | 67756.62 ± 1000.78 | 67874.56 ± 1000.78 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d16384 | 66.75 ± 0.02 | 70.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d16384 | 204.84 ± 2.69 | 10117.85 ± 130.36 | 9999.91 ± 130.36 | 10117.85 ± 130.36 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d16384 | 66.23 ± 0.04 | 69.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d32768 | 191.92 ± 10.78 | 171424.55 ± 10017.11 | 171306.61 ± 10017.11 | 171424.55 ± 10017.11 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d32768 | 12.37 ± 0.07 | 13.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d32768 | 142.47 ± 3.70 | 14502.40 ± 380.91 | 14384.46 ± 380.91 | 14502.40 ± 380.91 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d32768 | 12.34 ± 0.00 | 13.00 ± 0.00 |
llamacpp b8999 (vulkan backend)
啟動指令
./llama-b8999/llama-server -m ./G4-MeroMero-26B-A4B-Q5_K_M.gguf
-ngl 99 -c 49152 --temp 1 --top-k 64 --top-p 0.95 --host 0.0.0.0 -mm
./mmproj-Gemma-4-26b-a4b-f16.gguf --chat-template-file
./chat_template.jinja
在32k的測試出現異常，可能是模型崩潰與重複輸出造成。
| model | test | t/s | peak t/s | ttfr (ms) | est_ppt (ms) | e2e_ttft (ms) |
|---|---|---|---|---|---|---|
| zerofata/G4-MeroMero-26B-A4B | pp2048 | 315.62 ± 12.25 | 6633.52 ± 244.36 | 6502.53 ± 244.36 | 6633.52 ± 244.36 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 | 20.70 ± 0.02 | 21.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d4096 | 291.80 ± 10.49 | 14189.23 ± 493.34 | 14058.24 ± 493.34 | 14189.23 ± 493.34 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d4096 | 19.54 ± 0.00 | 20.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d4096 | 275.22 ± 1.81 | 7572.64 ± 49.08 | 7441.65 ± 49.08 | 7572.64 ± 49.08 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d4096 | 19.53 ± 0.01 | 20.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d8192 | 286.29 ± 1.35 | 28747.85 ± 134.81 | 28616.86 ± 134.81 | 28747.85 ± 134.81 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d8192 | 19.68 ± 0.03 | 20.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d8192 | 252.09 ± 0.21 | 8254.93 ± 6.84 | 8123.94 ± 6.84 | 8254.93 ± 6.84 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d8192 | 18.64 ± 0.03 | 19.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d16384 | 269.11 ± 1.28 | 61018.78 ± 289.55 | 60887.79 ± 289.55 | 61018.78 ± 289.55 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d16384 | 18.08 ± 0.00 | 19.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d16384 | 217.98 ± 1.58 | 9526.90 ± 67.69 | 9395.91 ± 67.69 | 9526.90 ± 67.69 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d16384 | 18.01 ± 0.02 | 19.00 ± 0.00 | |||
| zerofata/G4-MeroMero-26B-A4B | ctx_pp @ d32768 | 231.32 ± 0.68 | 141795.99 ± 417.40 | 141665.00 ± 417.40 | 141795.99 ± 417.40 | |
| zerofata/G4-MeroMero-26B-A4B | ctx_tg @ d32768 | 31.67 ± 20.37 | 41.67 ± 33.47 | |||
| zerofata/G4-MeroMero-26B-A4B | pp2048 @ d32768 | 168.40 ± 1.35 | 12292.98 ± 97.49 | 12161.99 ± 97.49 | 12313.51 ± 124.96 | |
| zerofata/G4-MeroMero-26B-A4B | tg128 @ d32768 | 16.47 ± 0.01 | 17.00 ± 0.00 |
綜合測試結論（使用Gemini做的分析
1. 硬體潛力與系統優化
- 記憶體配置與優化： 透過調整 Linux 核心參數（GRUB）將
amdgpu.gttsize設為 48GB，是成功在此類 iGPU 設備上順暢執行 26B 大模型量化版的關鍵。64GB 的實體記憶體為 780M 提供了充足的空間來處理大型模型文件及高達 32K 的 Context 需求。 - 推論效能： 整體而言，在 8845HS 的平台上，26B Q5 模型能達到約 15~20 t/s 的生成速度，對於單人使用情境已具備極高的實用性，接近一般人的閱讀速度。
2. 後端軟體性能對比 (Backend Comparison)
| 測試項目 | Koboldcpp-1.112.2 | Llamacpp (Vulkan) | Llamacpp-rocm |
|---|---|---|---|
| 提示處理 (Prompt Processing) | 最快 (~420 t/s) | 中等 (~315 t/s) | 較慢 (~335 t/s) |
| 權杖生成 (Token Gen) | 穩定 (~18.4 t/s) | 最高 (~20.7 t/s) | 較慢 (~15.4 t/s) |
| 長文本穩定性 (Stability) | 極高，隨 Context 增加性能衰減平緩。 | 高 Context (32k) 時出現數據異常。 | 中 Context (16k) 時出現異常。 |
- Koboldcpp： 在本次測試中表現最為均衡且可靠。其 Prompt Processing 速度大幅領先，且在高 Context (32768) 下依然維持穩定的生成速度（14.7 t/s），沒有出現模型崩潰或邏輯異常，是長文本應用的首選。
- Llamacpp (Vulkan)： 提供了最高的初始生成速度（超過 20 t/s），但在 Context 達到 32k 時出現數據劇烈波動與異常（Variance 較大），顯示在極端上下文負荷下驅動或後端尚不夠穩定。
- Llamacpp-rocm： 在此硬體配置下表現差強人意，不僅生成速度最低，且在 16k Context 時便提早出現模型異常，推測 ROCm 在此 APU 上的優化或記憶體管理仍有改進空間。
3. 測試異常觀察
- 在
llamacpp-rocm(16k) 與vulkan(32k) 的測試中，出現了速度異常（如跳升至 66 t/s）或誤差值過大的現象，這通常與模型崩潰、重複輸出 (Repetition) 或 K-V Cache 溢位有關。這指出在 iGPU 環境下進行超長文本推論時，後端軟體的穩定性 (Robustness) 比純粹的峰值速度更為重要。
總結建議
對於使用 AMD Ryzen 8000 系列 APU 的用戶，若要執行 26B 規模 的模型：
- 推薦後端： 優先選用 Koboldcpp，其在長文本處理的穩定度與 Prompt 處理速度上具有明顯優勢。
- 效能追求： 若僅進行短文本對話，可嘗試 Llamacpp (Vulkan) 以獲取最高生成速度。
- 環境設定： 務必修改系統核心參數以釋放顯存限制，否則無法充分發揮 64GB 記憶體的硬體優勢。
2025年2月21日 星期五
在Ryzen 7 8845HS w/ Radeon 780M用ComfyUI生圖（Linux）
試了很久才發現成功的方程式…這是因為每次安裝ROCm都需要下載安裝超過30GB的檔案！！！
tl;dr 直接說結論
OS: Ubuntu 22.04（因為ROCm 6.1只支援此以下的版本）
ROCm: <= 6.1.2，6.2跟6.3都沒辦法正常運行
PyTorch: <= 2.4.1，2.5.1版會顯示不支援硬體的警告，圖片有時候無法正確產生。
UserWarning: Attempting to use hipBLASLt on an unsupported architecture! Overriding blas backend to hipblas
2.6以上則完全無法正常運行。使用PyTorch官網的版本而不是AMD提供的。
https://pytorch.org/get-started/previous-versions/
ComfyUI: 當前版本v0.3.14可正常運行。
Update 2024/2/25
使用 Radeon 780M 產生圖片的時候經常會出現全黑的圖，並且出現以下警告
RuntimeWarning: invalid value encountered in cast原本以為是 780M 沒有被 ROCm 支援的問題，但 ComfyUI 在去年的確發生過這樣的 bug，且不限硬體。我從下面的連結得到解法
img = Image.fromarray(np.clip(i, 0, 255).astype(np.uint8))
https://github.com/comfyanonymous/ComfyUI/issues/3500
解法就是：換 scheduler，預設是 normal ，換成 karras 似乎就沒有再出現這樣的問題。
2024年12月20日 星期五
我的Home Assistant配置
Home Assistant 是用於家庭自動化的免費開源軟體。它作為整合平台和智慧家庭中心，允許用戶控制智慧家居設備。該軟體強調本地控制和隱私，設計獨立於任何特定的物聯網生態系統。 - 維基百科
我會使用Home Assistant （簡稱HA）應該是在我買了Sonoff S30智慧插座與Basic R2智慧開關，但我不想使用製造商的平台或App，研究了一下決定在S30刷入ESPHome，Basic R2刷入Tasmota，然後接上HA來控制。而S30還有電流計的功能，可以整合到HA做能源消耗的監測。Home Assistant是裝在Raspberry Pi 4 (4GB RAM，簡稱RPi4）。
之後我想監控每個房間的溫濕度，上網搜尋可用的方案，最多人建議是小米的米家藍牙溫濕度計 2因為這個小裝置非常便宜，並刷入ATC的韌體來改善耗電與連接性。但問題來了，溫濕度計的放置位置離RPi4很遠，肯定收不到訊號。而改善的作法是購買幾個便宜的ESP32-C3-MINI-1刷入ESPHome的Bluetooth Proxy配置。之前提到使用ATC的韌體是要讓溫濕度計定期用藍芽低功耗技術來廣播資料，而這些Bluetooth Proxy則作為中繼，傳送資料回HA，這樣的設計會比主動連接的耗電量少，資料取得比較快且穩定。
後來我買了兩個Reolink的網路攝影機，作為車庫與門口的監控。但跟前面一樣，我不想使用製造商提供的平台或軟體，會選擇這個廠牌是因為它提供區域網路連接功能，網路上最多人推薦使用FRIGATE，這個開源軟體可以與HA深度整合，方便檢視與管理各種事件與錄影，並且支援物件識別的功能，雖然可以使用CPU來做識別但極度推薦專用的AI加速器：Coral USB Accelerator，可以快速識別影像中的物件。當然它提供物件識別的模型並不完美，你可以支付一次性的費用，上傳需要辨識或修正的影像來做訓練，一年內可以訓練12次。就我的經驗只訓練兩次就已經沒碰到識別錯誤的問題。自動化的部份則是使用HA論壇上網友提供的藍圖，在影像偵測到有人時發送通知到HA的手機APP。
因為我家是透天有鐵捲門，我就在想要怎麼把開關鐵捲門的功能整合到HA，但是我不想去修改鐵捲門控制器，因為風險太高。最後我想到的作法是拿一個外殼破損但功能完好的鐵捲門遙控器來改裝，上網研究發現只需要一片Lolin d1 mini、一個12V轉3.3V的降壓模組、然後加上幾個電晶體與電阻做成開關電路，就可以接上遙控器來控制。
幾個月前買了SwitchBot的套件組（主控機器人2、開關機器人、門窗感測器），主控機器人2的功能需要透過雲端連接，但是開關機器人與門窗感測器則可以使用藍芽連接，前面提到的Bluetooth Proxy又可以派上用場。門窗感測器裝在大門，可以很方便知道大門是不是沒關好，有沒有人經過，這也是透過HA來發送通知。而開關機器人則是裝在車庫的電燈開關，透過HA可以設計為打開鐵捲門同時開燈。
最近買了Shelly EM想要強化能源消耗的監控，但是打開配線箱後發現這遠超過我的能力，可能要找水電技師來協助安裝。
總而言之，家庭自動化是一條不歸路，花的錢會越來越多。
2024年12月19日 星期四
我的家用網路配置
紀錄一下我的家用網路配置給有興趣的人參考。
- 路由器：NanoPi R5S (4GB RAM/32GB Flash)
作業系統是使用OpenWRT，但目前還沒有正式發布的版本，因此使用Anael Orlinski發布的版本。除此之外，還有硬體製造商FriendlyARM自行發布的FriendlyWRT可以使用（但不建議）。
選擇使用NanoPi R5S是因為它的性能不需要打開Software flow offloading就可以處理1Gbps的網路連線。除此之外，它還包含有兩個2.5G與一個1G乙太網路界面，可以應對未來網路升級需求。 - 區域網路：Ubiquiti的USW-Lite-8-POE與USW-Flex-Mini
- 無線網路：Ubiquiti的UniFi UAP-AC-Lite與U6-Lite。
看到這應該會有人問為何不使用Ubiquiti的全家桶？我有考慮過，但是在購買NanoPi R5S當時能考慮的是Dream Router，但它提供了我不需要的功能（Wifi），而且性能不足且價格高昂。現在有UXG-Max可以選擇，但是價格還是蠻高的。
應該還會有人問為何要買Wifi AP而不是直接買整合的Wifi Router？這是因為Wifi Router放置的位置受限，某些角落的收訊會很差，而且性能比不上功能單一的Wifi AP。
會選擇Ubiquiti的設備也是因為整合性與維護性，透過UniFi Network應用程式，可以很方便檢視與管理網路狀態。當然如果要看到最完整的網路狀態還是需要搭配UniFi的路由主機。
訂閱：
文章 (Atom)
-
之前因為 製作Macross Frontier第一話的字幕 ，開始接觸到這塊領域。剛開始我使用Subtitle Workshop製 作字幕，這個軟體的介面還蠻人性化的，但是不支援Unicode是個大問題，時間軸的調整也很難做的精準，此外它對SubStation Alpha (.... -
在Firefox 3正式發布前夕，Mozilla基金會成員之一的 Deb Richardson ，撰寫了一篇圖文並茂的 說明 ，讓你徹底了解Firefox 3的新功能。這些新功能與改進有些非常巨大，有些細微到你完全不會注意到，但是卻讓Firefox 3變得更簡單易用。就整體而言，...
-
試了很久才發現成功的方程式…這是因為每次安裝ROCm都需要下載安裝超過30GB的檔案！！！ tl;dr 直接說結論 OS: Ubuntu 22.04（因為ROCm 6.1只支援此以下的版本） ROCm: <= 6.1.2，6.2跟6.3都沒辦法正常運行 PyTorch...
