本文與《LM Studio 對 llama.cpp server》、《M4：llama.cpp 與 Ollama》、《OpenAI 相容路由與 vLLM》及《多模型路由成本矩陣》同一座標系：在 Apple Silicon 上常以 llama.cpp server 承載本機或同網段 Mac；「vLLM 類聚合」指具連續批次、多序列排程與分頁式 KV 管理語意的 OpenAI 相容後端（含 vLLM 本體或閘道後掛的同類叢集）。驗收目標是把連線、併發、記憶體三條預算寫進 runbook，避免報表好看、上線即熔斷。
HTTP Keep-Alive 與遠端成本
跨機房或家用寬頻打遠端 Mac，每次新建 TCP／TLS 都會吃掉首包延遲預算。客戶端預設開啟 keep-alive 時，請同步檢查：反向代理的 keepalive_timeout、上游 idle 逾時、以及客戶端連線池上限是否低於伺服器可接受的工作連線數。池子太大會造成「握手變少、佇列變長」的假健康；太小則頻繁建連，放大 CPU 與延遲方差。
建議在閘道與推理節點兩端記錄：連線重用率、每連線佇列深度、以及 499／502 與逾時是否與連線回收相關。與可觀測性欄位對齊可參考《GenAI 可觀測性矩陣》。
llama.cpp server 與 vLLM 類聚合：決策矩陣
| 維度 | llama.cpp server（Mac 常態） | vLLM 類聚合（GPU／多卡語意） |
|---|---|---|
| Keep-Alive 敏感度 | 單程序多連線時收益明顯；注意 --parallel 與 OS 檔句柄 |
批次調度器前常有多層代理；需對齊 idle 與 gRPC／HTTP2 行為 |
| 併發槽位 | --parallel 等顯式上限；超賣即記憶體線性惡化 |
max_num_seqs 等語意；KV 區塊與預取策略影響尾延遲 |
| KV 預算 | 統一記憶體池：上下文、槽位、量化 KV 需一起試算 | 顯存分頁與碎片；與 Mac 路徑疊加時多經閘道轉發 |
| 遠端驗收重心 | 版本釘選、模型檔校驗、浸泡時記憶體壓力曲線 | 路由別名、後端健康與熔斷、批次排程下的 p99 |
可執行 curl 與壓測門檻
將 BASE 換成你的 OpenAI 相容根路徑（含閘道前綴時一併寫入）。下列請求刻意帶短輸出，利於連線重用下的延遲基線比對。
# 單次健康／延遲嗅探（請替換模型 id 與主機）
BASE="http://127.0.0.1:8080"
curl -sS -o /dev/null -w "tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" \
-H "Content-Type: application/json" -H "Connection: keep-alive" \
-d '{"model":"your-model-id","messages":[{"role":"user","content":"ping"}],"max_tokens":8,"stream":false}' \
"$BASE/v1/chat/completions"併發浸泡可使用 hey 或 wrk（自備 Lua 腳本送 JSON）。下列為 hey 範例：請替換模型 id，並依節點調整 -c（併發連線）與 -q（每秒請求上限）。
# 120 秒、8 連線、每連線最多 5 QPS（示例；請勿直接打生產）
hey -z 120s -c 8 -q 5 -m POST -H "Content-Type: application/json" \
-d '{"model":"your-model-id","messages":[{"role":"user","content":"ping"}],"max_tokens":8,"stream":false}' \
http://127.0.0.1:8080/v1/chat/completions請以你自己的冷啟基線重標定下列門檻；表中數字為常見簽核起點。
| 指標 | 建議門檻（相對穩態基線） | 超標時優先動作 |
|---|---|---|
| HTTP 5xx 率（5 分鐘窗） | >0.5% 持續 3 分鐘 | 降併發、縮上下文、檢查上游 OOM／代理逾時 |
| TTFT p95 | 劣化 >30% 逾 5 分鐘 | 查 keep-alive／TLS 重用；減閘道跳數；減槽位 |
| 成功請求解碼吞吐 | 低於基線 <65% 且記憶體壓力黃區 | KV 量化或降 -c；關閉同機競爭行程 |
| 連線建立速率 | 每秒新建連線 > 成功 RPS 的 50% | 放大客戶端池或修正代理 idle；禁止每請求新建連線 |
KV cache 預算：與槽位聯動
每增加一個穩定併發槽，長上下文場景近似多配一份 KV 工作集。請在伺服器端硬夾 max_tokens 與上下文上限，並把「單會話峰值 tokens」寫進 SLO。Mac 統一記憶體路徑上，寧可閘道排隊也不要讓 llama-server 槽位超賣；vLLM 類後端則要額外對齊分頁命中率與搶佔帶來的尾延遲，避免誤判成網路問題。
買斷或租用遠端 Mac：一筆帳怎麼算
買斷適合模型資產與資料治理已內部化、且團隊願意自行處理保固、機房／電費與釋出版本節奏的情境；前期 CAPEX 高，但長期若 7×24 滿載，單位算力成本可攤薄。租用（含按節點時數或訂閱）適合驗收期需要快速橫向擴縮、想把桌面環境與推理隔離、或要把浸泡與釘選版號交給受控映像的團隊；OPEX 可預測，且失敗時換節點比自維硬體快。兩者共通點是：沒有連線／KV／併發三張表，買租都會變成「先付錢再救火」。
遠端節點驗收勾選
- 模型檔雜湊與內部命名一致；禁止同名不同檔。
- 二進位或映像版號寫入資產清冊；閘道路由與後端池快照一併存檔。
- 同一壓測腳本浸泡 ≥2 小時：記錄 p95／p99、5xx、連線重用率與記憶體壓力。
- 熔斷與退避策略與路由成本文對齊，避免重試放大。
小結：先量連線與槽位，再算 KV；門檻寫進儀表板與 runbook，遠端簽核才可重現。