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的算力需求
訂閱:
張貼留言 (Atom)
-
之前因為 製作Macross Frontier第一話的字幕 ,開始接觸到這塊領域。剛開始我使用Subtitle Workshop製 作字幕,這個軟體的介面還蠻人性化的,但是不支援Unicode是個大問題,時間軸的調整也很難做的精準,此外它對SubStation Alpha (....
-
試了很久才發現成功的方程式…這是因為每次安裝ROCm都需要下載安裝超過30GB的檔案!!! tl;dr 直接說結論 OS: Ubuntu 22.04(因為ROCm 6.1只支援此以下的版本) ROCm: <= 6.1.2,6.2跟6.3都沒辦法正常運行 PyTorch...
-
在Firefox 3正式發布前夕,Mozilla基金會成員之一的 Deb Richardson ,撰寫了一篇圖文並茂的 說明 ,讓你徹底了解Firefox 3的新功能。這些新功能與改進有些非常巨大,有些細微到你完全不會注意到,但是卻讓Firefox 3變得更簡單易用。就整體而言,...
沒有留言:
張貼留言