簡介

在本地部署 LLM Agent 時，多數開發者聚焦於模型選型與工具鏈設計，卻往往忽略了支撐 Agent 運作的兩個基礎設施命脈——推理速度與長對話存活。一次完整的科學分析可能需要 50 到 80 次以上的工具呼叫迭代，若每次迭代耗時 10 到 15 秒，整個工作流將漫長到不可接受；更糟的是，對話上下文無節制膨脹最終會撐爆 context window，導致 crash 並丟失記憶體中的分析物件。

本文依據 Hussen Mohammed Ibrahim 在學術 HPC 環境中建構自動化單細胞 RNA-seq 分析 Agent 的實戰經驗，系統化拆解 vLLM 推理伺服器的四層累積優化策略，以及結構化世界狀態（World State）如何取代傳統對話歷史成為 Agent 的 ground truth。核心結論：生產級 Agent 不是 LLM 加上工具就能搞定的事，而是需要刻意的推理伺服器配置與上下文視窗管理。

推理加速的四層累積優化

將單次迭代從 10-15 秒壓縮至 1-3 秒，靠的不是單一手法，而是四層優化的累積效應。每一層都有不同的作用域與硬體前提，缺一不可。

第一層：CUDA Graphs — 消除 CPU 調度瓶頸

decode 階段的每一步 token 生成，都觸發數百次 GPU kernel dispatch，這些 dispatch 的 CPU 端調度開銷在沒有優化時會成為嚴重瓶頸。CUDA Graphs 將整個 decode 迭代的 kernel 序列錄製為單一可重放對象，大幅降低 CPU 調度成本。

一個反直覺的觀察：在未啟用 CUDA Graphs 時，H100 的 decode 速度甚至比 A100 更慢——原因在於 H100 的 FP8 kernel 帶來更高的 CPU dispatch overhead。啟用 CUDA Graphs 後，H100 才真正展現出硬體優勢。

第二層：FP8 量化 — 記憶體減半

FP8 量化分為兩個面向：

• FP8 權重量化：權重從 BF16（2 bytes/param）壓縮至 FP8（1 byte/param），以 Qwen3.6-27B 為例從 56GB 降至約 31GB。此操作依賴 H100 的 FP8 Tensor Core，A100 不支援。
• FP8 KV Cache 量化：KV 向量以 FP8 存儲，注意力計算時 dequantize 回 BF16。這不需要 FP8 Tensor Core，因此 A100 同樣適用，且每 token 的 KV 記憶體直接減半。

第三層：Prefix Caching — 跳過重複 Prefill

Agent 的 system prompt 與工具 schema 在每次迭代中完全相同，卻每次都要重新 prefill。Prefix Caching 快取這些固定前綴的 KV 向量，後續請求直接跳過。

這對 Agent 工作流尤為關鍵，因為工具 schema 就佔了約 36K tokens 的固定開銷。

第四層：MTP 投機解碼 — 預測下一步

Qwen3.6-27B 內建 Multi-Token Prediction（MTP）head，能一次性預測多個後續 token。在實測中達到 89% 的接受率，為 decode 階段帶來額外 20% 到 37% 的吞吐提升。

值得注意的是，使用外部 draft model（如 DFlash）的接受率僅有 4% 到 7%，遠低於內建 MTP head。這說明投機解碼的效果高度依賴 draft model 與主模型的架構對齊程度。

  graph LR
    A[CUDA Graphs] --> B[FP8 Quantization]
    B --> C[Prefix Caching]
    C --> D[MTP Speculative Decoding]
    D --> E[1-3s per iteration]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#4a9eff,color:#fff
    style D fill:#4a9eff,color:#fff
    style E fill:#2ecc71,color:#fff

四層優化的效果是累積的，單獨使用任何一項都無法將迭代延遲從 15 秒降至 3 秒以內。

模型架構決定 KV 效率

選擇 Agent 的基礎模型時，不能只看 benchmark 分數或參數量。KV Cache 的 per-token 記憶體消耗由模型的 attention 層數、head 數與 head dimension 直接決定，這直接影響有效上下文長度。

參數量相近的兩個模型，Qwen 的有效上下文能力是 Gemma 的 4 倍以上。在 Agent 工作流中，這個差距意味著一個能順利完成 80 次迭代的分析，另一個可能中途 crash。

長對話的世界狀態架構

問題本質：上下文溢出

50 到 80 次迭代的科學分析，每次都追加工具呼叫、執行結果、中間觀察與錯誤修正。加上 36K tokens 的固定工具 schema 開銷，在 A100 的某些配置下，有效上下文僅有約 74K tokens。不加管理必然 crash。

為何 Compaction（摘要壓縮）行不通

常見的解法是將舊對話摘要壓縮，但在科學工作流中，prose summary 會丟失恰好是你需要的東西。「分析聚類了數據並做了品質控制」是語義正確的摘要，卻丟棄了 QC 閾值、聚類解析度、保留細胞數等精確參數。這些參數不是裝飾性細節——它們就是分析本身。

世界狀態設計模式

世界狀態的核心思想是：維護一個結構化的 Python 物件，在每個工具呼叫完成後寫入精確的結構化條目，然後將其序列化嵌入 system prompt 中，且永不被裁切。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

world_state = {
    "step": 12,
    "tool": "scanpy.pp.filter_cells",
    "params": {"min_genes": 200, "min_cells": 3},
    "result": {
        "cells_before": 15234,
        "cells_after": 12891,
        "filtered": 2343
    }
}

這個結構化日誌通常控制在 1,000 tokens 以內，卻包含了所有關鍵參數與結果。它改變了裁切邏輯的根本前提：對話歷史不再珍貴，因為真正的 ground truth 已記錄在世界狀態中。歷史是有用的上下文，世界狀態才是事實來源。

  graph TD
    subgraph SYS_PROMPT[Never Truncated]
        WS[World State - less than 1000 tokens]
        TS[Tool Schemas - about 36K tokens]
    end
    subgraph Truncatable
        DH[Dialog History]
        TR[Tool Results - remove largest first]
    end
    WS --- DH
    TS --- DH
    DH --- TR
    style WS fill:#e74c3c,color:#fff
    style TS fill:#e74c3c,color:#fff
    style DH fill:#f39c12,color:#fff
    style TR fill:#3498db,color:#fff

上下文預算精算與三大修復

預算公式

可用的對話歷史空間並非整個 context window，必須預先扣除所有固定成本：

1
2
3
4
5
6
7
8

available_history = (
    context_limit        # e.g. 262K
    - tool_schema_tokens # ~36K
    - system_tokens      # world state + instructions
    - completion_reserve # reserved for generation
    - safety_margin       # buffer for estimation errors
)
# 262K context -> about 219K available for history

三大核心修復

1. 固定成本預先扣除 — 不把整個 context window 當作可用歷史。這聽起來理所當然，但許多 Agent 框架的預設行為並未做到這一點。

2. 自我校準 Token 計數 — 比較 API 回傳的實際 token 數與本地估計值，採用單向修正因子：只向上調整。這是因為後果不對稱——低估 token 數會導致 API crash（災難性），高估僅觸發稍頻繁的裁切（可接受）。

3. 策略性裁切 — 按大小排序，優先移除最大的工具結果（單個大型輸出可能佔 50-200KB），永遠不裁切用戶訊息。

架構分析：生產級 Agent 的完整基礎設施

將上述所有要素組合起來，生產級本地 Agent 的基礎設施架構如下：

  graph TB
    subgraph GPU_INF[vLLM Inference Server]
        CG[CUDA Graphs]
        FP8[FP8 Weights + KV Cache]
        PC[Prefix Caching]
        MTP[MTP Speculative Decoding]
    end

    subgraph CTX_MGR[Context Engineering]
        BUD[Token Budget Calculator]
        WS[World State - Structured Log]
        TRU[Strategic Truncation]
        CAL[Self-Calibrating Counter]
    end

    subgraph AGENT_LOOP[Agent Workflow]
        PLN[Plan Next Step]
        TCL[Tool Call Execution]
        RES[Result Integration]
    end

    PLN --> CG
    FP8 --> TCL
    TCL --> RES
    RES --> WS
    WS --> BUD
    BUD --> CAL
    CAL --> TRU
    TRU --> PLN

這個架構揭示了幾個關鍵設計原則：

• 推理伺服器與 Agent 迴圈是分離的關注點：vLLM 負責讓每步足夠快，Context Manager 負責讓迴圈能跑完。兩者獨立最佳化，但缺一不可。
• 世界狀態是 Agent 的記憶骨幹：它使得對話歷史變成可裁切的輔助資訊，而非不可損失的核心資產。
• Token 計數不是精確科學：自我校準機制承認估計的固有誤差，用不對稱的修正策略將風險降到最低。

風險與限制

任何基礎設施決策都有取捨，以下是本案的主要風險點：

總結

本地 LLM Agent 的生產部署，遠比「模型加工具」複雜得多。本文探討的兩個核心挑戰——推理速度與長對話存活——各自需要系統性的工程對策。

在推理層面，vLLM 的四層累積優化（CUDA Graphs → FP8 → Prefix Caching → MTP）將單次迭代延遲從 15 秒降至 1 到 3 秒，每一層解決不同層面的瓶頸，且效果疊加。在上下文管理層面，世界狀態架構以不足 1,000 tokens 的結構化日誌取代龐大的對話歷史作為 ground truth，配合預算精算與自我校準的裁切策略，確保 80 次迭代的分析工作流不會因上下文溢出而中斷。

最根本的教訓是：模型決定 Agent 下一步做什麼，但周圍的基礎設施決定這個迴圈是否足夠快、穩定、可靠來完成工作。 世界狀態模式也不仅適用於科學分析——任何需要精確記錄的 Agent 工作流（財務分析、法律審查、程式碼重構）都適用「結構化日誌優於 prose 摘要」的原則，這是 Context Engineering 的一個重要設計模式。

參考資料

• The Infrastructure Behind Making Local LLM Agents Actually Useful — Towards Data Science
• vLLM Documentation
• vLLM Automatic Prefix Caching
• vLLM Speculative Decoding
• vLLM CUDA Graphs
• Anthropic: Effective Context Engineering for AI Agents