LLM 推論引擎選錯，一種常見結果不是模型不能跑，而是「明明能回話，卻一多人用就排隊、長對話就爆記憶體」。Ollama、llama.cpp、MLX-LM、vLLM、SGLang、TensorRT-LLM 與 NVIDIA Dynamo 常被放進同一張速度排行榜，但它們其實不全是同一層產品。先排名再理解，等於拿餐廳櫃台、廚房與連鎖店物流比誰炒菜快。
這篇會從零解釋推論的流程，給你可直接執行的本機與 API 範例，再用兩張比較圖與一張決策樹，選出值得在你自己的硬體與工作負載上先測的工具。讀完後，你不必背排行榜；你會知道該測什麼，以及什麼時候才需要換引擎。
先記住這條式子：可用的 AI 服務 ＝ 模型權重 ＋ 推論引擎 ＋ 硬體餘裕 ＋ 服務層。模型像食譜，推論引擎是把食譜做成一道道菜的廚房；硬體決定爐具與倉庫大小，服務層則負責排隊、權限、監控與擴充。只問「哪個引擎最快」，少了後面三個條件就沒有可重現的答案。
先說結論：LLM 推論引擎先分層，再選候選
- 第一次在電腦聊天或接本機 API：先試 Ollama；若要直接控制 GGUF、CPU／GPU 卸載與更多參數，再試 llama.cpp。
- Apple Silicon 上做 Python 實驗：把 MLX-LM 列入候選；它利用 Apple 統一記憶體，但它自己的模型格式與工具鏈不等於 GGUF。
- 把 GPU 做成多人共用 API：先依模型、硬體與必要功能篩選，再把 vLLM 與 SGLang 放進同條件 bake-off；NVIDIA 支援組合可再加入 TensorRT-LLM。
- 已有多 worker／多 GPU，並需要獨立擴縮或拓樸感知路由：可評估 NVIDIA Dynamo。它在既有推論 backend 外圍做編排，不是第四個同級引擎。
這些是「第一個候選」，不是冠軍宣告。推論速度會隨模型版本、精度或量化、輸入與輸出長度、同時請求人數、硬體、驅動與引擎版本改變。真正可靠的答案，要從你的請求紀錄跑出來。
LLM 推論引擎是什麼？模型檔為什麼不會自己回答
下載到硬碟的模型權重，只是一大組數字。推論引擎要讀懂模型架構與權重格式，把文字切成 token，安排 CPU／GPU 運算，管理記憶體，逐步產生下一個 token，最後再串流成你看到的句子。像 AI Agent Harness 會決定模型何時讀檔、用工具與重試；推論引擎則負責把每一次模型呼叫真的算完。
一次回答，其實經過載入、prefill 與 decode
- 載入模型：引擎把權重放進 RAM、統一記憶體或 VRAM；量化能縮小權重，但也可能改變輸出品質與速度。
- Prefill（讀題）：引擎一次處理 prompt，建立之後會重用的 KV cache。可把它想成廚師先看完整張點單。
- Decode（逐字作答）：模型一次預測下一個 token，再把新 token 加回去繼續算。這時常受到記憶體頻寬與搬資料效率影響。
- 排程與串流：服務引擎把多位使用者的請求交錯處理，控制 queue、batch 與輸出，讓 GPU 不必等一位客人整份吃完才接下一位。
KV cache（注意力計算的中間結果快取）能避免每產生一個 token 都重算整段歷史；代價是它會隨 context、batch 與併發增長。因此「權重放得下」只代表通過第一關。實際可用記憶體至少還要容納 KV cache ＋ runtime 暫存 ＋ 安全餘裕。這也呼應AI 推論為什麼常卡在記憶體與頻寬：算力規格很高，不代表資料搬得夠快。
五個指標，分別回答不同問題
- TTFT（Time to First Token）：從送出請求到第一個輸出 token；包含排隊、prefill 與網路時間，對應使用者覺得「有沒有立刻開始回」。
- ITL／TPOT：兩個名稱都用來描述第一個 token 之後的生成間隔；有些工具視為同義詞，有些報每 token 分布或 request 平均。跨工具比較前要先對齊公式。
- 單請求 tok/s：一位使用者的生成速度，適合衡量互動感，但不能代表多人服務容量。
- 系統吞吐量：所有同時請求合計每秒完成多少 token 或 request，用來看 server 能服務多少流量。
- p95／p99 延遲：較慢那批請求等多久；平均值漂亮，尾端延遲仍可能讓產品難用。
NVIDIA 的官方 LLM benchmark 指標說明也把 TTFT、inter-token latency 與總吞吐分開。換句話說，「500 tok/s」若沒寫是單請求還是全系統、輸入多長、同時幾人，幾乎不能拿來做採購決定。
本機 LLM 推論引擎比較：Ollama、llama.cpp、MLX-LM
本機工具的共同目標，是讓你用自己的電腦完成模型推論；差別在於它替你包辦多少事，以及你能控制到多深。下圖不是速度排名，而是依「低摩擦開始、細部控制、Apple 原生實驗」拆成三條路。
Ollama：先把「下載、執行、API」接成一條路
Ollama 適合第一次在 Mac、Windows 或 Linux 上試本機模型的人。它不只是底層 runtime，還整合模型管理、CLI 與本機 HTTP API；所以比較日常體驗時，應看整套產品，而不是只看一個 kernel。先從 Ollama 官方 Quickstart 安裝，再執行：
ollama run gemma3它的價值是把第一次成功所需的步驟變少；代價則是部分底層選項會經過 Ollama 的模型封裝與設定。需要穩定重現環境時，請一併記錄 Ollama 版本、模型標籤、模型 digest 與 Modelfile，不要只留可能漂移的名稱。
安全邊界也要先畫清楚：Ollama 本機 API 不要求認證，OpenAI-compatible client 裡的 API key 只為符合介面而填、實際會被忽略。服務應先維持 loopback；若要改 bind address 或映射 Docker port，請在外層加 firewall、TLS、認證與 rate limit。Ollama 目前也有 cloud models，所以「從 Ollama 啟動」不自動代表請求留在本機；仍要核對模型標籤與資料流。
llama.cpp：GGUF、多種硬體與細部控制
llama.cpp 的重點是 GGUF 生態、廣泛硬體後端與細緻的 CPU／GPU 卸載控制。它涵蓋 Apple Metal、CUDA、HIP、Vulkan、SYCL 與純 CPU 等路徑，也有 OpenAI-compatible server。2026 年 5 月之後，初學者的官方入口已整併成 llama 指令；截至 2026-08-01，現行 Quick Start 如下。若不想直接執行 curl | sh，可先下載檢視安裝腳本，或依 README 選擇 release／套件管理器路徑。
curl -LsSf https://llama.app/install.sh | sh
# 互動聊天
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
# 本機 API
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF舊教學常見的 llama-cli 與 llama-server 建置產物仍可能存在，但新手應以目前 README 的統一 CLI 為準。另一個常見誤解是「llama.cpp 不適合多 GPU」；現行 server 文件有單機多 GPU split 選項，而跨機 RPC 則被官方標成實驗性、脆弱且不安全的 proof of concept。兩件事不能混成同一句禁令；llama serve 本身也應保持在可信網路，公開服務前補齊隔離與認證。
MLX-LM：Apple Silicon 上的 Python 原生路徑
MLX-LM 是基於 Apple MLX、由 MLX 團隊維護的 LLM 推論與微調套件。MLX 的統一記憶體設計讓 CPU 與 GPU 直接存取同一個 memory pool；對想在 Mac 上用 Python 實驗的人，介面很自然。依官方安裝條件，以下範例以 Apple Silicon、macOS 14 以上與原生 arm64 Python 為前提：
python3 -m venv .venv
source .venv/bin/activate
python -m pip install mlx-lm
mlx_lm.generate \
--model mlx-community/Llama-3.2-3B-Instruct-4bit \
--prompt "用三句話解釋什麼是推論引擎"MLX 核心框架目前另有 Linux 套件，但 MLX-LM 官方定位仍聚焦 Apple Silicon；不要把兩者的支援範圍直接畫上等號。MLX-compatible Hugging Face 模型也不是 GGUF 的另一個副檔名。若要開本機 API，官方有 mlx_lm.server；它的 SERVER 文件明示只做基本安全檢查，不建議直接作為 production server。
ExLlamaV3：consumer NVIDIA＋EXL3 的有條件候選
若你使用現代 NVIDIA CUDA GPU、已有受支援模型的 EXL3 量化，而且願意承受較新專案的磨合成本，可把 ExLlamaV3 與 TabbyAPI 加入本機 bake-off。它承接 ExLlamaV2 的開發，支援 tensor／expert parallel；README 同時明列目前沒有 AMD／ROCm 路徑，並提醒早期仍可能有部分功能不完全。這是一條 support envelope 很明確的路，不應用「一張或兩張 GPU」直接代替相容性檢查。
多人 API 的 LLM 推論引擎：vLLM、SGLang、TensorRT-LLM
當目標從「我能聊天」變成「團隊能穩定呼叫」，通常要評估 continuous batching、KV cache、prefix caching、量化、分散式執行與 OpenAI-compatible API；實際需要哪些，取決於流量與模型。主流專案的能力已大量重疊；PagedAttention、連續批次或 prefill／decode 拆分，不能再單獨當作某一家的永久護城河。有同名能力也不代表成熟度與效果相同，例如 vLLM 目前仍把 disaggregated prefill 標為 experimental，且明說它用來分別調整 TTFT 與 ITL，不會自動提高 throughput。
vLLM：先建立可重跑的服務基準
vLLM 支援 continuous batching、PagedAttention、prefix caching、量化與多種硬體後端，是通用服務常見的第一個測試候選。這是選型建議，不是「每個 workload 都最快」的事實。以下是 vLLM 官方 Quickstart 在 Linux＋NVIDIA CUDA 環境的精簡路徑；執行前先依 uv 官方文件安裝 uv：
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct接著用 OpenAI-compatible endpoint 測一個固定請求：
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-1.5B-Instruct",
"messages": [{"role": "user", "content": "用白話解釋 KV cache"}],
"temperature": 0
}'這個端點能跑，仍不等於可以直接放到公網。vLLM 的安全文件指出，單靠 --api-key 不足以完成 production security；實際服務要在外層補反向代理、TLS、網路限制、認證、rate limit 與監控。多節點的內部通訊也要留在可信私網；跨不可信網路時，另用 encrypted overlay、mTLS 或 IPsec 保護。
SGLang：與 vLLM 同場測，共同前綴是加測項
只要精確模型、硬體 backend 與必要功能都相容，SGLang 就可與 vLLM 一起進入 serving bake-off，不必等到共同前綴很多才測。SGLang 的 RadixAttention 會把可重用的 prompt／生成 KV 放進 radix tree，搭配 cache-aware scheduling；若流量共享很長的 system prompt、few-shot 範例或文件前綴，再把 cache hit 列為重點指標。但 prefix cache 只省下重複 prefill，不會讓 decode 自動變快；page size、命中率與流量形狀也會改變結果。
SGLang 現行 Quickstart 的常見 NVIDIA 路徑以 Python 3.10 以上、Linux 與 sm80 以上 GPU 為基準；目前預設套件走 CUDA 13，CUDA 12 要依官方安裝頁選相符的 PyTorch 與 kernel。以下把官方範例的 0.0.0.0 改成只綁 loopback；其他硬體另有平台指南，不能假設功能與效能完全相同：
pip install --upgrade pip
pip install uv
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install --prerelease=allow sglang
python3 -m sglang.launch_server \
--model-path Qwen/Qwen2.5-0.5B-Instruct \
--host 127.0.0.1 \
--port 30000--prerelease=allow 是截至 2026-08-01 官方 Quickstart 的安裝方式；做可重現部署時，請記錄實際解析出的 SGLang、PyTorch 與 kernel 版本並建立 lockfile。這裡保持 127.0.0.1；若改成對外 bind，先設定 server／admin API key，再放到完整 gateway 後面。
TensorRT-LLM：NVIDIA 平台的專門路徑
TensorRT-LLM 適合已在 NVIDIA 官方支援硬體上營運、願意跟隨 NVIDIA 容器與版本矩陣的團隊。它同樣有 in-flight batching、paged KV cache、prefix reuse 與分散式能力。要特別注意版本：截至 2026-08-01，latest 文件對應的 1.3.0rc23已移除舊 TensorRT engine backend，PyTorch 成為唯一 execution backend；照舊文章先轉 checkpoint、再跑 trtllm-build，會把不同版本的流程混在一起。
現行 Quick Start 直接以 Hugging Face 模型啟動。rc 代表 pre-release；以下只是在 nvcr.io/nvidia/tensorrt-llm/release:1.3.0rc23 容器內的啟動片段，不是一條完整安裝流程。也可先完成同版 wheel、CUDA 13.2 與 PyTorch 相依套件，再執行：
trtllm-serve "TinyLlama/TinyLlama-1.1B-Chat-v1.0"這裡談的是 1.3.0rc23 文件；若你的環境固定在目前的 v1.2.1 非預覽版，應只看 1.2.x 對應文件與容器，不能把兩代指令拼在一起。真正比較時，也要先確認模型、量化與目標 GPU 位於該版本支援矩陣內。
NVIDIA Dynamo：引擎外面的交通控制中心
Dynamo 可整合 vLLM、SGLang 或 TensorRT-LLM worker，提供服務發現、KV-aware routing、KV 傳輸、prefill／decode 分工與擴充編排。換句話說，引擎像一間廚房；Dynamo 是連鎖餐廳的派單與物流中心。官方架構說明把這些 backend 明確列為執行層；實際支援組合要依 stable 1.3 compatibility matrix 配對，不能任意混用各專案 latest。
不要因為它聽起來更「企業級」就提早加進架構。NVIDIA 的 disaggregated serving 指南要求以 workload 測試聚合與拆分部署：拆分有利於 prefill／decode 獨立擴縮與分別控制 TTFT／ITL，但 KV 傳輸有成本，平衡型流量也可能更適合聚合部署。多 worker 的拓樸、可用性、autoscaling 或模組化路由，同樣可以是採用 Dynamo 的理由。
一張決策樹：你的第一個候選是哪一個？
案例一：32GB Apple Silicon，只想在本機聊天
先用 Ollama 取得可工作的基準，再用相同 base weights／revision、相近品質量化與固定的十組 prompt，比較 llama.cpp 或 MLX-LM。因權重格式與 runtime 常無法完全一致，這叫 quality-matched deployment comparison，不是純引擎 A/B；差異要明列並做輸出品質回歸。十題只算 smoke test。若要問自己的文件，還要手動把內容放進 context，或另加 RAG／索引／UI／Agent 層；推論引擎不會自行整理與檢索資料夾。
案例二：一台 Linux GPU server，要給團隊共用
先依模型、硬體與必要功能篩選，接著讓 vLLM 與 SGLang 跑同一份 trace；若 trace 有大量相同長前綴，再額外比較 cache hit。若硬體位於 NVIDIA TensorRT-LLM 支援矩陣內，而且團隊能維護 NVIDIA 容器與版本，再加第三組。當部署有多 worker，且需要獨立擴縮、拓樸感知路由、KV 移動或可用性編排時，再評估 Dynamo。這個做法也適合自建 AI Agent Harness：先固定模型端點與測試，再換底層引擎，才能知道變快的是哪一層。
公平 benchmark：不要只跑一次「你好」
把真實請求匿名化後，保留輸入長度與輸出長度分布，做成可重播的 trace。每一組引擎固定以下條件：
- 同模型：盡可能使用相同 base weights、revision、chat template、tokenizer 與最大 context；格式不相容時，明列 confound，改做 quality-matched deployment comparison。
- 同精度：相同 dtype 或量化方法；GGUF、AWQ、GPTQ、MLX 等格式不能只憑「都是 4-bit」視為同一組。
- 同硬體：固定 GPU／CPU、記憶體、驅動、容器、功耗與散熱條件。
- 同流量：短問短答、長文件問答、共同前綴與工具呼叫分開測；逐步提高 concurrency。
- 同輸出：固定 temperature、max tokens 與停止條件，記錄實際 output tokens，並做品質與正確性回歸。
- 同記錄：保留 TTFT、ITL、TPOT、總 throughput、GPU／RAM 峰值、錯誤率與冷啟動時間；樣本量足以代表實際負載後，才解讀 p95／p99。
測試順序是單請求暖機、單請求延遲、逐級併發、長 context、共同前綴，最後才是真實 trace。少量重複只用來 smoke test；尾端延遲要用足以覆蓋實際流量分布的大量請求。若你也在比較模型能力，可套用Claude Code vs Codex 的任務驗收思路：固定輸入、權限與完成定義，不用一次漂亮答案宣布總冠軍。
六個常見的坑
1. 先選引擎，才發現它沒覆蓋你的模型與硬體組合
解法：先畫 support envelope。把模型架構、權重格式、量化、作業系統、GPU 型號、context 與必要功能列成清單，再到該版本官方文件逐項對照。看到「支援 AMD」或「支援 Apple」時，也要追到具體 backend；存在一條路徑不代表與主要平台有相同功能或效能。
2. 把模型放進 VRAM，就以為容量規畫完成
解法：量測權重以外的峰值。把 KV cache、runtime workspace、CUDA graph 或其他 backend 暫存，以及尖峰併發留下的空間一起記錄。長 context 的壓力尤其要獨立測，不要從 512-token prompt 外推。
3. 把 prefix caching 當作所有請求的加速器
解法：先算前綴重用率。Prefix cache 只有在請求共享完全相同的 token 前綴時，才省下那一段 prefill；它不會縮短後續 decode。System prompt 看似相同，但只要前面插入動態時間或使用者 ID，就可能破壞命中。
4. 把 OpenAI-compatible 當作 Agent 相容與安全認證
解法：把介面、語意與安全分開驗收。Compatible 通常描述 request／response 形狀；tool calling、JSON／structured output、reasoning 與 multimodal 行為仍取決於模型、chat template、parser、引擎與版本，必須用真實任務測正確率。它也不代表已完成 TLS、租戶隔離、權限、rate limit 或 audit log；只聽 loopback，經受控 gateway 對外。
5. 直接複製半年前的啟動指令
解法：版本與文件一起 pin。llama.cpp 已新增統一 llama CLI；TensorRT-LLM latest 的 1.3.0rc23 又移除了舊 engine-build backend。先記錄 release／container tag，再開該版本文件；不要把 latest 的安裝與舊版 flags 拼起來。
6. 本機執行，就自動等於資料安全
解法：追資料流，不追「local」標籤。確認模型下載、telemetry、remote code、API bind address、log、瀏覽器 UI 與插件各自會去哪裡。llama.cpp 的安全政策要求把不受信任的模型放進 sandbox；對不受信任輸入，則依風險做隔離或前處理，最高安全需求下再採 sandbox。Multi-tenant isolation 仍是部署者的責任。
截至 2026-08-01，哪些舊印象已經失效？
- 「Ollama 不該用」：這是沒有工作負載與證據的全面禁令。它仍是降低本機上手摩擦的合理入口；是否換到底層工具，要由控制需求與測試結果決定。
- 「llama.cpp 不能多 GPU」：現行文件已列出單機 multi-GPU split；需要警惕的是官方明確標為實驗性且不安全的跨機 RPC。
- 「TensorRT-LLM 一定要先 build engine」：這描述舊 backend；latest 的 1.3.0rc23 文件已改成 PyTorch-only 執行路徑。v1.2.1 環境仍應依自己的版本文件操作。
- 「有 PagedAttention 就一定贏」：主流 server 的排程與 cache 能力持續重疊。功能清單只用來入圍，實際 trace 才用來淘汰。
- 「Dynamo 是另一個更快的 engine」：它是包在 backend 外面的分散式 serving 層；多 worker 的獨立擴縮、拓樸路由、KV 移動與可用性編排，才是評估它的問題空間。
- 「TGI 仍是新部署的現役首選」：Hugging Face 現行文件已把 Text Generation Inference 標成 maintenance mode，repo 也已封存，並把新部署導向 vLLM、SGLang、llama.cpp 或 MLX。
還有一些特殊路徑值得知道，但不必全部裝：MLC LLM 的官方矩陣涵蓋 browser WebGPU、iOS 與 Android；ONNX Runtime GenAI 橫跨多種作業系統與 execution provider，模型與功能要依當前 support matrix 核對；ExLlamaV2 README 表示專案目前暫停／封存，後續開發移到 ExLlamaV3。若它們的 support envelope、部署形態、VRAM 取捨或工作負載吻合，再加入 shortlist。
LLM 推論引擎 FAQ：新手常問的 8 題
1. Ollama 算不算推論引擎？
算推論產品，但不要只用單一層級理解它。它同時提供模型管理、CLI、API 與平台 backend 整合；比較底層 kernel 時應看實際 backend，比較上手與日常操作時則應把整套 Ollama 納入。
2. Mac 上應先裝 llama.cpp 還是 MLX-LM？
看模型格式與工作流。已有 GGUF、想調 CPU／GPU offload 或跨平台重現，先試 llama.cpp；想留在 Python 與 MLX-compatible 模型流程，先試 MLX-LM。若只想少步驟開始聊天，Ollama 通常更省事。
3. vLLM 一定比 llama.cpp 快嗎？
不一定。兩者優先服務的硬體、格式與 workload 不同；同一模型也可能採不同量化。單人桌機與多人 GPU API 要看的指標不同，必須在相同條件下測。
4. 長 context 就應該直接選 SGLang 嗎？
不能只靠 context 長度決定。SGLang 與 vLLM 應先依模型、硬體與必要功能共同入圍；若請求有高度相同的長前綴，再特別量 RadixAttention 的 cache hit。每段 prompt 都不同時，prefix reuse 的收益會變小，但不代表 SGLang 其他 serving 能力失去比較價值。
5. NVIDIA GPU 就應該直接用 TensorRT-LLM 嗎？
不必直接跳過比較。先核對 GPU、模型與版本矩陣，再與 vLLM、SGLang 用相同 trace 比。TensorRT-LLM 的 NVIDIA 專門路徑有價值，也伴隨更緊密的容器與版本管理。
6. 什麼時候需要 NVIDIA Dynamo？
通常是在多 worker／多 GPU 部署需要獨立擴縮、拓樸感知路由、KV 搬移、autoscaling 或可用性編排時。量測到 routing 或 KV 瓶頸是強烈訊號，但不是唯一理由；仍要把簡單的聚合部署放進對照組。
7. 4-bit 模型一定比較快嗎？
不一定。量化通常降低權重占用，但速度仍取決於硬體是否有對應 kernel、反量化成本、batch 與引擎實作；品質也要回歸。不同 4-bit 格式不能只看位元數直接互比。
8. 自架就能保證資料不外流嗎？
不能只憑「自架」兩字保證。模型下載、remote code、telemetry、log、UI、插件與對外 API 都是資料路徑。要逐項關閉或隔離不需要的出口，並測試認證、網路與租戶邊界。
給新手的 5 個重點
- 先分層：Ollama、底層引擎與 Dynamo 不是同一種產品。
- 先看 envelope：模型、格式、硬體、context、併發與必要功能要一起對齊。
- 先做 baseline：本機從 Ollama／llama.cpp／MLX-LM 擇一；server 常可先以 vLLM 建立基準。
- 只比同條件：模型 revision、量化、prompt、輸出、硬體與版本不同，就不要共用一個速度排名。
- 能跑不等於能服務：安全、監控、尾端延遲、錯誤率與升級流程，都是推論系統的一部分。
📚 延伸閱讀：把模型、引擎與 Agent 接成完整系統
- Inferact 與 vLLM 商業化：理解開源推論引擎為何成為 AI 基礎設施戰場。
- AI 推論的 HBM 記憶體瓶頸：看懂為什麼速度常受頻寬、KV cache 與資料搬移限制。
- Kimi K3 怎麼用：用超大模型案例分辨 API、託管與自架的責任邊界。
- AI Agent Harness 是什麼：把推論引擎放回 Agent 的完整執行迴圈。
- 從零搭建 AI Agent Harness：用可驗收步驟把模型端點接進工具工作流。
- Hermes Agent 完整解析：觀察開源 Agent 如何管理模型、工具與記憶。
- AlphaLab AI 專區：繼續追蹤模型、Agent 與基礎設施。
- AlphaLab 實戰課程：把本機 AI、API 與自動化流程做成可重複的工作系統。
下一步：今晚只跑一個小實驗
不要一次安裝七套工具。先寫下你的「模型＋硬體＋輸入／輸出長度＋同時人數＋延遲目標」，依決策樹選一個候選，跑十個真實 prompt 做 smoke test，記錄 TTFT、生成速度與記憶體峰值。若結果已符合需求，就先停在這裡；若不符合，再換第二個引擎，並盡可能固定其餘條件、標出無法消除的格式差異。這樣，你選到的不是網路上的冠軍，而是自己工作負載的答案。