上個月我在公司做了一件現在想起來還是會冒汗的事：跟主管 demo 地端 RAG。

機器是公司那台雙卡工作機，模型挑了一顆 32B 的新模型——反正兩張卡加起來 24GB,塞好塞滿——向量庫也灌好了文件。我打了一個再普通不過的問題：「這份規範裡的驗收標準是什麼？」然後按下 Enter。

螢幕上什麼都沒有。

五秒，還好，大家在喝水。十秒，主管開始看手機。二十秒，我開始講「地端就是這樣，資料不出門嘛」。四十五秒，答案終於出現，三行字，而且是對的。

但已經沒有人在乎它對不對了。

你有沒有想過，那 45 秒裡，GPU 到底在忙什麼？

先講結論：那 45 秒裡，大部分時間 GPU 在做你根本沒叫它做的事。 它可能在寫一段一千多字、你永遠看不到的自言自語；可能在把上一題就算過的東西從頭再算一遍；最慘的情況，它有一半根本沒在 GPU 上跑——模型塞不下，放不進顯卡的那些層被留在系統記憶體，改由 CPU 用只有顯卡幾分之一的記憶體頻寬硬算，每個字都要 GPU 一段、CPU 一段地接力。你那張 500 GB/s 的顯卡，被 80 GB/s 的系統記憶體拖著跑。

這些，全部修得掉。而且大多數一毛錢硬體都不用花。

圖 1：一次 RAG 請求的完整旅程——你等的 45 秒裡，黃色和紅色那兩段通常是最肥的，而且都有藥醫。

這個系列要幹嘛

一句話：地端 LLM 的效能工程。量測 → 歸因 → 修復 → 驗收，30 天走完一輪。

先說這個系列「不做」什麼，幫你省時間：

• 不教安裝。 Ollama 怎麼裝、vLLM 怎麼起，官方文件跟現有文章已經夠多了，再寫一篇是浪費你我的時間。
• 不教 LangChain 怎麼串。 應用層的文章滿地都是，這個系列待在下面一層：引擎、顯卡、記憶體、還有那些沒人幫你算過的帳。
• 不覆誦規格表。 我們只關心一件事：規格表上的數字，怎麼換算成「你的使用者要等幾秒」。

剩下的時間拿來做正事：把「地端 LLM 好慢」這句話，拆成一筆一筆可以量測、可以驗算、可以修復的帳。

兩台主角：一場不公平但很誠實的對決

這 30 天所有實測都跑在我自己的兩台機器上：

註：546 是 Apple 官方的「up to」，40-core GPU 滿配版才有(32-core 版是 410);504 在 NVIDIA 官方頁上沒列這一欄，是 21 Gbps × 192-bit 換算的值【推算】，與第三方規格庫一致。對，連主角的規格都要標來源——這是本系列的規矩，等下會講。

看到重點了嗎？546 對 504——這兩台機器的記憶體頻寬是同一個量級。 而 LLM 生成文字的速度，恰恰主要由記憶體頻寬決定(第 10 天會證明這件事)。

先講清楚兩件事，免得內行的你現在就想關掉這篇：這是帳面數字，而且只講「一個人、單發問題」時的生成速度。546 是整顆 SoC 共享的頻寬，GPU 實際拿得到幾成，第 10 天會量給你看；至於 prompt 讀取速度和多人同時問，是另外兩條定律——那正是這場對決的勝負分界線。

還有，一邊有 128GB 可以塞 70B 的大模型，另一邊兩張卡加起來只有 24GB,得跨過 PCIe 才能合作——但如果合作得好，兩張卡的頻寬理論上可以疊加。疊不疊得起來？第 12 天見真章。

場邊還站著兩個參照組：一台雙 RTX PRO 6000 Blackwell(96GB × 2)的工作站(代號 T3)——中小企業地端正式環境的新標配；和一組 4× H100 的機房節點(代號 T4)——企業級的標準答案。之後的文章會用 T1–T4 這組代號稱呼四台機器。這兩台我沒有實機，它們的每一個數字都會標【引用】或【推算】——推算用的正是這個系列會教你的那套公式。你會看到同一道題，從幾萬塊的雙卡到幾百萬的節點，答案怎麼變——以及錢花在哪一階，才真的有感。

所以這一季不是要幫誰站台，是要把這兩台機器（外加兩台場邊的參照組）一筆一筆算給你看：什麼時候 Mac 贏、什麼時候輸得很慘，而「什麼時候贏」的分界線，正好就是地端 LLM 工程的全部內容。

四張地圖：接下來 30 天怎麼走

整個系列就是四張地圖，一週一張：

圖 2:30 天的路線——先學會量，再算容量，然後把它調快，最後讓它答對。

第 1 週：量測。 修東西之前要先有尺。TTFT、TPOT 這些指標到底在量什麼、壓測為什麼不是寫個 for 迴圈打 API、還有怎麼一眼識破網路上的假 benchmark(對，第 11 天我會示範，網路上查得到的某些數字，在物理上根本不可能)。

第 2 週：容量線。 「裝得下」是一條可以用紙筆算出來的線：權重多大、KV cache 吃多少、你的機器還剩多少、能同時服務幾個人。算完你會發現，大部分「跑不動」的災難，在下載模型之前就能預見。

第 3 週：吞吐線。 把 45 秒裡最肥的那幾刀砍掉的一週。thinking mode、prefix cache、speculative decoding、還有一張卡怎麼同時養 LLM、embedding、reranker 三張嘴——消費卡上真正能用的工具是 time-slicing、MPS 和 HAMi;至於雲端教學最愛講的 MIG?你的 4070 Ti 根本不支援，我會講清楚為什麼、以及每種場景該拿什麼代替。

第 4 週：準確度。 快，但答錯，等於零。chunk 怎麼切、embedding 怎麼選(先講結論：排行榜第一名通常不是你的第一名)、文件一多就找不到東西該怎麼辦——多層 routing 會在這一週登場。

30 天後你會帶走什麼

• 一套自己算容量的公式：看到任何機器 + 任何模型，五分鐘算出「能不能跑、多快、服務幾人」
• 一份依 CP 值排序的加速菜單：每一項標明預期倍數、代價、和適用條件
• 一個**「45 秒 → 2 秒」的完整改造記錄**：每一刀砍在哪、省幾秒、都可以自己乘回去驗算
• 兩台機器的第一手實測數據——包含全網目前找不到可信數字的那幾格

這個系列的數據紀律

效能文章最大的問題是數字來路不明。所以先立三條規矩，30 天不破例：

1. 【官方】：出自官方文件或論文，附連結。
2. 【實測】：我自己的機器跑的，附指令，你可以在你的機器上重現。
3. 【推算】：用公式算的，算式攤開給你檢查。

看到沒有標記的數字，你可以直接在留言區踢館。這不是客套話——第 11 天你會看到，連 Google 搜尋第一頁的數字都可能是編的，我不想成為其中之一。

需要準備什麼

不需要跟我一樣的機器。一張 20 系以後、8GB 以上的 NVIDIA 卡，或一台 16GB 以上的 Apple Silicon Mac,就能跟著做大部分實驗——llama.cpp 和 Ollama 的部分全程可跟(模型換小一號就行);vLLM 的實驗需要 NVIDIA 卡(它沒有 Mac GPU 版，這件事本身第 3 天就會講)；雙卡實驗需要兩張卡，單卡讀者看數據就好。每天文末我會標注「今天的實驗需要什麼」。

真正需要的只有一個：對「為什麼這麼慢」這個問題還沒有麻木。

回到開頭那 45 秒。demo 結束那天晚上，我沒有加卡，也沒有換機器，只做了兩件事：關掉模型的思考模式、換一顆塞得進顯存的量化檔。隔天同一個問題，5 秒。後來又修了四刀，現在不到 2 秒——但真正值錢的不是那幾個設定，而是知道該量什麼，才知道該改什麼。

明天，Day 02，我們從第一張地圖的第一格開始：把「慢」這個字禁用掉，換成三個可以量測的數字——TTFT、TPOT、E2E。你會發現「變快」有兩種，而其中一種根本不用讓模型變快。

咱們明天見。