抡锤者

主要是提供大家另一種玩法，把幾張沒什麼用的顯卡用llamacpp串起來，跑起來也是可行的。

窮人的玩法，在這獻醜了。
一切從零開始，不知道如何設定，學著版主一直罵Gemini罵出這樣的結果，大家可以參考。直到今天看到大家都在用的測試平台，才敢發貼分享，速度還算可以喔。

電腦配備如下:

llama.cpp 設置參數:

llama benchy 測試數據

nvtop 監控畫面

以下為GOOGLE對測試結果的評論

各測試項目的數據解析

1. Prefill 階段（pp2048：處理 2048 個 Token 的 Prompt）
   t/s (Tokens per Second) = 1279.27 ± 113.97

含義：Prompt 處理吞吐量（Prefill 速度）。

解讀：伺服器每秒能處理約 1279 個 Token 的長輸入。這代表輸入文本的吞吐能力相當優異。

ttfr (ms) (Time To First Response) = 1464.49 ± 34.91

含義：發送請求到收到伺服器回傳第一個 Data Chunk 的總時間（包含網路延遲）。

est_ppt (ms) (Estimated Prompt Processing Time) = 1463.74 ± 34.91

含義：扣除網路與系統延遲後，伺服器純粹用來處理 2048 個輸入 Token 的預估時間。

解讀：處理 2048 個 Token 約花費 1.46 秒（1463.74 ms）。

e2e_ttft (ms) (End-to-End Time To First Token) = 1464.49 ± 34.91

含義：端到端使用者看到第一個生成文字（Content Token）的等待時間。

解讀：在此測試中，TTFR 與 e2e_ttft 幾乎相同，代表第一個回應區塊就包含了生成的文字。

2. Decode 階段（tg32：生成 32 個 Token 的 Output）
   t/s (Tokens per Second) = 88.83 ± 3.65

含義：文字生成速度（Decode 速度）。

解讀：模型開始輸出後，平均每秒產生約 88.8 個 Token。一般人類閱讀速度約為每秒 5~10 個 Token，因此這個生成速度非常順暢。

peak t/s (Peak Tokens per Second) = 91.69 ± 3.76

含義：在 1 秒的時間窗口內所觀測到的最高生成速度，約為每秒 91.7 個 Token。

綜合效能評估總結
首字延遲 (TTFT)：輸入 2048 個 Token 時，需等待約 1.46 秒 才會看到第一個字。對於 35B 規模的模型來說，這個 Prefill 時間屬於 reasonable 範圍。

生成體感 (Decode Speed)：每秒 88.8 Token 的輸出速度極快，能提供流暢且無停頓的即時對話體驗。

給大家參考囉，沒錢也是能這樣玩的。

附上我的電腦
PS:無法上傳照片了，負載過大，晚點再上傳