【2026 最新】tandem.cpp vs llama.cpp：原生 MoE Cache 多做什麼？同檔比較六步教學

tandem.cpp 值得裝嗎？你看到「單張 RTX 4090 快三倍」的貼文，手邊也有 GGUF 模型，第一個念頭可能是換個執行檔。但如果原生 llama.cpp 已經有專家快取，這次究竟多做了什麼？

這篇寫給想嘗試本機模型、卻不熟悉效能比較的讀者。先用工作桌與倉庫的比喻理解原理，再帶你建立同檔案、同版本的三組對照。原理從零解釋；操作段落則需要已備妥 Linux、NVIDIA CUDA 編譯環境與可合法使用的 MoE GGUF。

本文依 2026 年 11 月 2 日查閱的官方文件與程式碼整理，固定 tandem.cpp 提交 b03b001、其基底 llama.cpp f5222f25c。本次編輯環境為 Apple Silicon Mac，未執行 Linux／CUDA 推論；以下是評估方法，作者速度數字均保留作者歸屬。

先說結論：先比原生快取，再決定要不要換

專家快取＝少搬權重；CPU 協作＝有些未命中專家留在原地算。 前者像把常用食材放到廚房桌上，後者像讓倉庫旁的助手先處理一部分食材。兩者可以一起工作，但助手的速度與運送通道都會影響結果。

我的建議是：已有穩定服務就保留原版，另開測試目錄；先固定 GGUF、Context、快取大小與任務，再測 tandem.cpp。採用門檻是答案通過、容量穩定，而且完整任務等待確實縮短。單一最高 tokens/s，還不足以決定遷移。

tandem.cpp 與原生 MoE Cache：差別在未命中之後

MoE（Mixture of Experts，混合專家）把部分網路拆成許多專家，每個 token 由路由選取其中一部分。可以把它想成一個有很多專長的團隊：這一步只找幾位同事，不表示其餘同事的資料就不用存放。模型檔容量、系統 RAM 與顯存 VRAM，仍要各自盤點。想補容量觀念，可先讀 llama.cpp 原生 MoE Cache 教學。

在本文固定的原生版，參數實作已提供 -cmoe 與 --moe-cache-mib N：前者讓 MoE 權重留在主機側，後者替它們配置 GPU 快取。快取程式碼會重用已命中的專家，並把需要的未命中權重上傳。這不是 tandem.cpp 才發明的功能。

tandem.cpp 的 補丁在這條路徑增加 CPU 協作：一部分未命中專家交給 CPU 計算，另一部分上傳，與 GPU 工作配合；自動分工會參考量測到的路徑速度。它也加入 --moe-cache-mib auto 和多項核心、圖執行及模型專用優化。所以「裝上後變快」描述的是整包改動，不能直接把全部收益歸給 CPU。

追一次示意流程：這一步需要 A、C、D，GPU 快取已經有 A。原生快取路徑準備 C、D 的上傳與計算；協作路徑則可能讓 GPU 算 A、接收 C，同時由 CPU 算 D，最後合併結果。這是機制示意，並非模型實際專家數或本次量測。

tandem.cpp 的加速數字，先問比較對象

作者 README 的 Results記載，在 i5-12400F、64GB DDR4、RTX 4090 的一組 Qwen3.8 IQ3_S＋MTP、greedy 測試中，decode 從 29.8 到 97.3 tokens/s；使用前 200 題 GSM8K，單請求、最多生成 2048 tokens。這是作者自測的特定組合，不是本文的測速成績。

關鍵是同頁把原生基準定義為 -fit on 的預設配置，再給兩邊相同 GPU 記憶體預算及草稿模型。它回答「相對這套原生配置提升多少」，並未建立本文要做的原生固定專家快取 B 組。測試說明與 啟動器也呈現這個差異。

因此下面保留兩個問題：A→C 看你從一般原生配置換過去的整體差異；B→C 才更接近「原生快取與補丁整包」的差異。即使 B、C 勝負明確，仍不是純 CPU 協作消融實驗，因為補丁還改了其他預設。

六步建立同檔比較：先取得一張可信的成績單

①「先看能不能放」：不要把顯卡型號當成整機規格

你有 4090 加 32GB RAM，能照搬作者設定嗎？先盤點容量，不要由顯卡名稱推論 RAM 足夠。記錄 CPU、RAM、可用磁碟、驅動與 CUDA 版本；已有工具可用 nvidia-smi、free -h、nvcc --version，缺編譯條件就先完成環境準備。

VRAM 要容納非專家權重、專家快取、KV Cache（對話中間狀態）和運算緩衝；RAM 還要留給模型、工作區與作業系統。權重檔大小不是精準峰值 RAM。先選已有、能載入的小型 MoE 檔案，記下所有分片的 sha256sum；別為追貼文數字直接下載大型模型。

②「留兩套廚房」：原版與補丁分開編譯

怕安裝後回不去？用獨立目錄保存原版，以下在全新的工作目錄逐條執行。它會下載原始碼並編譯，不會替你下載模型；編譯前先檢視 build.sh 和補丁。CUDA 編譯設定可對照 原生建置文件。

• git clone https://github.com/ewhacc/tandem.cpp tandem-lab，然後 cd tandem-lab。
• git checkout b03b001，接著 git clone https://github.com/ggml-org/llama.cpp upstream。
• git -C upstream checkout f5222f25c，再依序 cmake -S upstream -B upstream/build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release、cmake --build upstream/build -j --target llama-server。
• bash build.sh patched 建立補丁版；兩邊使用同一編譯器與 CUDA 設定。
• upstream/build/bin/llama-server --version 與 patched/build/bin/llama-server --version 各存一份，另存 git rev-parse HEAD、git -C upstream rev-parse HEAD 及 sha256sum tandem.patch。

補丁目錄的 Git HEAD 仍是基底提交，因為變更由 patch 套入；只記 --version 不夠，必須連同補丁雜湊與啟動日誌保存。舊服務留在原目錄，需要回退時先停止測試服務，再啟動原本執行檔與原組態。

③「先鎖旋鈕」：固定模型、Context 與 MTP

不知道差異來自哪裡？先做最小變因比較：相同 GGUF、聊天模板、採樣、Context、batch、KV 格式、CPU 執行緒及單一活動請求，兩個服務輪流跑。第一輪省略所有 speculative decoding／MTP 參數；MTP 是用草稿預測再驗證多個 token 的另一項優化，稍後再獨立加入。

開乾淨的終端環境，檢查既有 LLAMA_*、GGML_* 和 LC_* 變數，避免沿用其他實驗。將 MODEL=/完整路徑/你的MoE模型.gguf 改為實際檔案；若分片，指定第一片並確認所有分片齊全。以下命令均在 tandem-lab 執行。

④「排三位選手」：先短測，再輪替順序

只拿補丁與舊設定比，很容易誤認原因。使用作者隨附測試啟動器，先各跑 5 題確認能啟動、輸出與日誌正常。它會啟動與停止服務，綁定 127.0.0.1；不要同時啟動會爭用 GPU 的其他測試。

• A，原生自動配置：python3 bench/run_cell.py --bin upstream/build/bin/llama-server --model "$MODEL" --tag A-smoke --no-ngl --ctx 8192 --w1-n 5 --extra "-fit on -fitt 1024 --cache-ram 0"。
• B，原生固定快取：python3 bench/run_cell.py --bin upstream/build/bin/llama-server --model "$MODEL" --tag B-smoke --cache-mib 4096 --ctx 8192 --w1-n 5 --extra "--cache-ram 0"。
• C，補丁固定快取：python3 bench/run_cell.py --bin patched/build/bin/llama-server --model "$MODEL" --tag C-smoke --cache-mib 4096 --ctx 8192 --w1-n 5 --extra "--cache-ram 0"。

4096 MiB 是示例，並非任何顯卡的建議值；若啟動失敗，先減小數值、確認非專家與 KV 占用，再讓 B、C 使用相同可行容量。--cache-ram 0關閉的是伺服器的 RAM 提示詞快取容量，不等於所有快取全關。B、C 仍要核對日誌中的實際 expert cache 與整體 VRAM，補丁工作區可能不同。

短測通過後，再改為你選定的題數，至少做五輪，交替 A→B→C、C→B→A，並替每輪換唯一 --tag，避免覆蓋結果。作者完整設定用 200 題；5 題只是接線檢查，不能當品質結論。評估日常繁中工作時，還要補你自己的固定任務。

⑤「拆開兩種冷」：讀題、寫字與整段等待分開記

為何第二輪突然變快？先把冷啟動與暖跑分欄。新 server 的第一次請求，仍可能遇到已暖的作業系統檔案快取；重啟程序不等於 SSD 冷讀。記錄載入到健康檢查通過的時間，再記請求開始、首個可見 token 和結束時間，避免把下載或編譯算進模型 decode。

作者啟動器會保存 boot_s、server log 與逐題結果。其串流客戶端將首個文字片段前的等待記為 TTFT，W1 的生成區間則從第一到最後一個文字片段。W4 改用首片段之後到串流結束的區間，分子也扣掉一個 token；兩種報表不能混成同一套 decode 成績。這些客戶端口徑與伺服器內部計時也要分開。原生 Server 文件另列出 timings.prompt_per_second、predicted_per_second 和提示詞重用量。

同一份 prompt 連續送出可能重用前綴，TTFT 也包含請求與排程成本，所以別把「prompt tokens ÷ TTFT」直接叫作純 prompt processing。需要隔離提示詞重用時，可依 completion 介面明確送 cache_prompt:false，並保存回傳的 tokens_cached 與計時資料；所有組別沿用同一介面與設定。

⑥「加長再驗收」：品質與記憶體一起過關

短問答很快，長文件還行嗎？用相同長輸入加第二道門。作者 W4 以抽樣字元／token 比例估計程式庫文字長度，埋入兩個暗號，再用同一對話先後提問；第二問會重用對話。請以輸出的實際 prompt_tokens 驗收長度，別把目標長度當成精確裁切。先確認模型 Context 上限與整機容量，才對 A、B、C 的命令都加 --w4 16384 --corpus upstream，並把 --ctx 8192一併改成 --ctx 32768。這是新條件，需重做容量檢查。

每輪另記 RAM 最低餘裕、VRAM 峰值、Swap 活動與磁碟讀取；可用系統監控工具同步存檔，缺欄位填「未取得」。暖機狀態要一致，保留中位數、最慢一輪與失敗，不只挑最快值。暗號通過只證明這個找回題成功；再用固定繁中摘要、JSON 欄位或你自己的程式測試檢查答案。品質設計可延伸 Qwen PLE 精度 A/B 教學。

怎麼選？先用決策樹，再查三個常見坑

原生版已滿足需求 → 保留原版；B 明顯優於 A → 先用原生快取；C 在同任務比 B 更省等待，且品質與容量通過 → 再採用補丁；結果接近或失敗不穩 → 回到原組態。 這套順序讓你能判斷收益是否值得維護另一套執行檔。

第一個坑是 RAM 不夠卻強制整檔載入。作者建議 RAM 比模型小時保留 mmap，而不是照抄 -lm none。記憶體映射像讓作業系統按需取文件，仍會受可用 RAM、頁面快取和 SSD 影響。本文測試啟動器使用 lazy mode；不要在其中一組額外改載入方式。

第二個坑是把近似加速當成相同計算。補丁的 LLAMA_MOE_TAIL_SKIP會略過部分未命中專家；作者將它標成 approximate，預設不開。本輪維持關閉，避免同時改計算與執行方式。固定 greedy 也不保證逐字一致：作者列明 CPU／GPU 捨入與排程時序會影響輸出，應看固定任務是否通過，而非只看文字雜湊。

第三個坑是直接套容器與其他平台。作者目前明列測試邊界為 Linux／CUDA，並指出部分 RAM 判斷看的是實體容量、不是 cgroup 限額；容器限制記憶體時，列出的處理方式是將 LLAMA_MOE_PIN_EXPS=0與 LLAMA_PLE_GPU_COPY=0設為環境變數。這些邊界見 Limits。Windows、Mac 或不同 GPU 後端應另做相容性驗收，別把 Linux 成績搬過去。

當系統失去回應、持續換頁且任務惡化、OOM 或品質測例失敗，先停止這一輪；縮小模型／Context 或快取後，所有對照組一起重做。要追查長跑與切換造成的等待，接著看 Strata Session Cache 排錯；那篇處理對話停放，與本文專家權重快取是不同層。

常見問題：八個先釐清的判斷

1. tandem.cpp 是新模型嗎？

不是。它是針對 llama.cpp 的補丁；同檔比較要保持模型權重與量化不變。

2. 原生 llama.cpp 已有專家快取嗎？

有。本文固定基底的參數與原始碼都可核對；先跑 B 組，才能知道你原本是否只是少開一個功能。

3. 4090 搭 32GB RAM，一定能跑作者的設定？

不一定。GPU 與 RAM 是兩個預算，還有 Context、背景程式與磁碟工作集；先從手邊容量可行的 MoE 檔開始。

4. 作者快三倍，表示比原生 MoE Cache 快三倍？

不能這樣推。作者主要基準是原生自動配置；本文 B、C 的固定快取比較，要由相同硬體上的測試回答。

5. 一開始就加 MTP 嗎？

先分開。先測未加草稿參數的組合，再讓三組使用相同草稿檔與參數重跑，並重新核對顯存餘裕。

6. 設定 auto 就能跳過容量檢查？

不能。補丁會扣除模型、KV、緩衝與 margin 後估算快取；長輸入、其他 GPU 工作仍要在自己的環境驗收。

7. 找回兩個暗號，表示長 Context 品質完整通過？

不表示。它只是特定找回測例；摘要忠實度、繁中格式與工具任務，要各自設期望答案。

8. 要為這個補丁換硬體嗎？

先別急。先完成同檔對照與資源紀錄；只有確認等待卡在你能改善的路徑，才有理由評估下一筆成本。

給新手的三個重點

• 先固定檔案與版本：模型不變，才知道執行方式改了什麼。
• 先分原生配置、原生快取與補丁：B→C 是本文要補的對照，仍包含整包優化。
• 先驗收答案、容量與總等待：生成快是其中一欄，不是全部。