【2026 最新】Agentic Workload 是什麼？四回合 Trace 驗證 Prefix Cache

Agentic Workload 最容易被低估的地方，是它看起來也只是一串 LLM API 請求。一般聊天 benchmark 會把每個 prompt 當成獨立題目；真正的 coding Agent 卻會把前一輪答案、工具結果與系統規則一路帶進下一輪，還可能同時叫出幾個 subagent。此時單輪 tok/s 很快，不等於整段任務的第一個 token 來得快，也不等於任務早點結束。

這篇不提供 AlphaLab 自己跑出的速度榜，而是給你一套可重跑的四回合 trace：先把 prompt 內容換成合成 token，只保留依賴、長度與時間；再依序跑 cold、warm、restart，讀 TTFT、Prefix Cache 命中、queue、wall time 與成本。最後再改 fan-out、併發與路由，找出你的引擎到底快在哪裡、何時該回滾。

先說結論：Agentic Workload 要看「圖＋前綴＋節奏」

🧭 記憶把手：Agentic Workload＝請求依賴圖＋共享前綴＋到達節奏。

• 圖：下一個請求要等誰完成？哪幾個分支會同時出發？
• 前綴：理論上能重用多少 token？實際又有多少 block 還留在正確 worker？
• 節奏：工具等待、使用者停頓與 subagent burst 何時把 queue 和 KV Cache 塞滿？

只量一個獨立 prompt，像只驗一顆零件；重播完整 Agent trace，才像把整台機器開上路。兩種測試都需要，但回答的問題不同：前者適合找模型或 kernel 的基本上限，後者才適合選 Agent 的引擎、硬體與 router。

Agentic Workload 是什麼？不是「prompt 比較長」而已

這裡的 workload 不是對話文字本身，而是推論服務看到的交通形狀。常見的 coding-Agent trace 會同時出現多輪歷史、長 Context、高前綴重用與短時間 fan-out；這四項是很有用的觀察框架，但不是所有 Agent 的定義。語音 Agent、一次性研究任務與極短工具流程，可能長得完全不同。

2026 年 8 月 19 日，InferenceX 公開的 AgentX 方法頁自述把 393 個經 opt-in、且通過篩選的 coding-Agent sessions 轉成合成內容 replay。它保留近似長度、時間、分支與 prefix block 關係，但不保留原始 prompt 語意，也不評答案品質；因此它能回答 serving 問題，不能代表所有 Agent，更不能當模型能力榜。

另一個公開教學把 simple workload 比成 unit test、agentic workload 比成 integration test，並附上 Veeksha 設定與衍生 trace artifact。它很適合學方法；本文只採用可重跑的框架，不引用單一裝置的延遲數字，也不把特定 H100 設定外推到你的 Mac 或雲端叢集。

若你還不熟模型、runtime、API server 與 client 的分工，先讀 LLM 推論引擎新手指南；Agent 外圍的狀態、工具與權限則可搭配 AI Agent Harness 實作框架。

先拆三層：可重用、可快取、真的命中

看到兩輪文字很像，不代表已經命中 Prefix Cache。你要分清楚三層：

1. 結構重疊：兩個請求理論上共享多少相同的 token 前綴。
2. 引擎可快取：相同 model、tokenizer、chat template、tool schema 與 block 邊界，讓這段前綴能成為相同 cache key。
3. 實體命中：請求抵達時，那些 block 仍在被派到的 worker，沒有被 eviction、重啟或不同租戶隔離策略改變。

vLLM v0.27.1 官方 APC 文件的界線很清楚：共享前綴可跳過已計算部分的 prefill，但不會縮短新 token 的 decode。也就是說，答案很長或前綴根本不同時，cache hit 很漂亮也未必明顯縮短 wall time。想看長 session 的另一套驗收，可對照 oMLX Prefix Cache 長 session 測試。

四回合 Agentic Workload Trace：只留下性能形狀

最安全的 trace 不保存 prompt、程式碼、工具參數或模型答案，只留每輪的總輸入、這輪新加入的輸入、目標輸出、依賴與等待時間。以下是一個刻意簡化的線性 session：第一輪 8,000 tokens，之後每輪加入 400-token 回答與 400-token 新指令，所以總輸入依序是 8,000、8,800、9,600、10,400。

{"session_id":1,"input_length":8000,"new_input_length":8000,"output_length":400,"session_context":{"node_id":0,"parent_nodes":[],"history_parent":null,"wait_after_ready":0.0}}
{"session_id":1,"input_length":8800,"new_input_length":400,"output_length":400,"session_context":{"node_id":1,"parent_nodes":[0],"history_parent":0,"wait_after_ready":1.2}}
{"session_id":1,"input_length":9600,"new_input_length":400,"output_length":400,"session_context":{"node_id":2,"parent_nodes":[1],"history_parent":1,"wait_after_ready":0.8}}
{"session_id":1,"input_length":10400,"new_input_length":400,"output_length":400,"session_context":{"node_id":3,"parent_nodes":[2],"history_parent":2,"wait_after_ready":1.0}}

把這四行存成 four-turn.jsonl，再用本文固定的 Veeksha v0.4.5 timed_synthetic_session flavor 生成合成 prompt。v0.4.5 官方 trace flavor 文件說明這個格式會保留線性或 DAG（有向無環圖）、等待時間與 history lineage；trace_recorder.include_content保持 false，避免把合成後的完整內容再寫進輸出。

seed: 42

traffic_scheduler:
  type: rate
  interval_generator:
    type: poisson
    arrival_rate: 0.2

session_generator:
  type: trace
  trace_file: four-turn.jsonl
  wrap_mode: false
  flavor:
    type: timed_synthetic_session

client:
  type: openai_chat_completions
  api_base: http://127.0.0.1:8000/v1
  model: REPLACE_WITH_THE_EXACT_MODEL_ID
  request_timeout: 300
  max_tokens_param: max_tokens
  min_tokens_param: min_tokens
  additional_sampling_params: '{"temperature":0}'

runtime:
  max_sessions: 1
  benchmark_timeout: 900

trace_recorder:
  enabled: true
  include_content: false

output_dir: agentic-benchmark

截至 2026 年 8 月 24 日，Veeksha v0.4.5 README 的直接執行方式需要 free-threaded Python 3.14t。先讓你的 OpenAI-compatible endpoint 正常回應，再跑：

export AGENT_API_BASE='http://127.0.0.1:8000/v1'
export AGENT_MODEL='REPLACE_WITH_THE_EXACT_MODEL_ID'

curl -fsS "$AGENT_API_BASE/models" | jq -e \
  --arg model "$AGENT_MODEL" '.data[] | select(.id == $model)'

uvx -p 3.14t 'veeksha==0.4.5' benchmark \
  --config agentic-four-turn.veeksha.yml

不要直接照抄 8,000／400。從你自己的 client usage log 取同一 tokenizer 回報的 prompt／output token 數，再用 node ID 表示「誰等誰」。若原始 log 含私密內容，轉換程序只讀取必要欄位，輸出後檢查檔案只剩數字與拓撲，原始 trace 仍留在原本的受控位置。

第 1 關：固定 manifest，否則 Prefix Cache 對照沒有意義

每一組都固定 endpoint、模型 revision、量化、tokenizer、chat template、tool schema、context 上限、sampling、引擎版本、cache 設定、KV 容量、硬體與 router。版本或模板只要不同，就另開實驗，不要合併成同一張圖。

先把下列 gate 寫進 manifest：四個 request 全部成功、實際 prompt／output 長度在你預設容差內、沒有 context overflow，且 Veeksha 的 health_check_results.txt通過 arrival 與長度檢查。失敗 run 仍留在 error rate 與總 wall time；不能只挑成功樣本。

第 2 關：依序跑 cold、warm、restart 三種情境

1. Cold：用乾淨的推論程序或引擎正式提供的 cache-reset 方法開始，先抓一次 metrics，再重播四回合。不要把「第一個請求」直接當成 cold 證明；cache counter 的增量也要吻合。
2. Warm：推論程序保持存活，以相同 trace、seed、模型與模板再跑一次。目標不是預設它會命中，而是看 hit／query 增量、prefill computed tokens 與 TTFT 是否一起變化。
3. Restart：依正常流程停止並用完全相同的 command／config 重啟，再重播同一 trace。這組量的是你的實際重啟續接結果；不要預先寫成「一定全失效」或「一定能 restore」。

Cold→warm 的順序有依賴，不能任意洗牌。把它們視為一個 block，至少先跑三個 block 當 smoke，逐次保存原始值；三次不是統計充分門檻。若比較兩個引擎或 router，才在 block 層用 ABBA：A1→B1→B2→A2，降低熱狀態與背景負載偏差。

第 3 關：用 delta 讀 TTFT、Cache、wall time 與成本

Counter 是累積值，不能直接抄 dashboard 最後一格。以截至 2026 年 8 月 24 日的 vLLM v0.27.1 為例，官方 Production Metrics在 /metrics提供 vllm:prefix_cache_hits、vllm:prefix_cache_queries、vllm:prompt_tokens_cached、vllm:request_prefill_kv_computed_tokens、queue、TTFT 與 E2E latency。Prometheus exposition 的 counter 可能顯示 _total後綴，先以 live endpoint 名稱為準；每組都抓 before／after，再以差值計算：

cache_hit_ratio = delta(prefix_cache_hits) / delta(prefix_cache_queries)
useful_throughput = successful_sessions / benchmark_wall_seconds
cost_per_success = metered_cost / successful_sessions

• TTFT／TTFC：看 p50 也看 p95；Veeksha 的 request_level_metrics.jsonl與 ttfc.csv保留逐請求和分布。
• Cache：同時看 hit ratio 與 newly computed prefill tokens；命中率高但 queue 更長，體感仍可能更慢。
• Wall time：從第一個 session dispatch 到最後一個完成，包含等待與錯誤，不用 decode tok/s 代替。
• 吞吐：以成功 session／秒為主；token／秒是診斷欄，不是完成工作量。
• 成本：雲端用實際計費 meter；自架可另記 instance-minutes 或實測能耗。沒有 meter 就留空，不用 token 數猜帳單。

第 4 關：把 linear 改成 fan-out，測的是壓力不是「多 Agent 比較強」

把 node 1、2、3 都設成依賴 node 0，就能建立三個同時 ready 的分支；需要匯總時再加一個 merge node，讓 parent_nodes指向三個分支，並選一個 history_parent承接歷史，其他分支結果算進 merge 的新輸入長度。這是在測 serving topology，不是在比較三個 Agent 的作品品質；後者應使用 多 Agent 生產力驗收那種任務 rubric。

先做兩種不同問題，不要混成一句結論：

• 固定總工作量：把相同 token budget 分到 1、2、4 個分支，觀察 topology、queue 與 cache locality。
• 真實 burst：每個 subagent 保留自己的完整工作量，接受總 token 隨 fan-out 增加；這回答容量與成本，不回答 routing 的純因果。

接著掃 concurrency 1→2→4，逐組跑完整 cold／warm／restart block。若改變 prefix 順序，需固定所有 token 長度，只交換 session 到達順序；觀察 kv_cache_usage_perc、eviction sample、queue 與 p95 TTFT。只看全局 hit rate，會把某個熱門 prefix 吃掉大部分命中的情況藏起來。

第 5 關：本機、多人服務、分散式部署怎麼選？

1. 本機單使用者：先把一個 endpoint 的 cold／warm／restart 做對。若 warm TTFT 和 computed prefill 明顯下降、wall time也改善，就保留 cache；若 decode 或工具等待占主體，先處理真正瓶頸，不急著加 router。
2. 多人單機／多 worker：加入 session ID、worker ID、queue 與 eviction。先測 sticky session，再測 load-aware；若熱門 session 把單一 worker 排隊拉長，就設定 spill／回滾線。
3. 分散式 replicas：每個 replica 的 KV state 可能不同。vLLM v0.27.1 Data Parallel 文件也明確說各 DP engine 有獨立 KV Cache，router 應同時考慮 queue 與 KV state。比較 cache-oblivious、prefix-aware 與 load-aware 時，必須保留 worker placement 與轉送／KV transfer 記錄。

預先寫回滾條件：錯誤率上升、p95 TTFT 超過 SLO、queue 改善卻讓 computed prefill 暴增、cost per success 變差，或 restart 恢復時間超過直接重新 prefill，都回到上一個簡單設定。Router 的任務不是追最高 hit，而是在 locality 與負載之間守住整體 SLO。

最常踩的 6 個坑

1. 把 tok/s 當任務速度：至少補 TTFT、queue、E2E 與 session wall time。
2. 把「文字相似」當 cache hit：tokenizer、模板、工具 schema 或訊息順序變一個 byte，都可能改變 key。
3. Cold、warm 混成平均：三種情境分表，保存原始 run，不只留總平均。
4. 同時換引擎與 cache policy：一次只切一個 causal knob；跨引擎只能叫整套系統選型。
5. fan-out 增加工作量卻歸因給 router：固定工作量與真實 burst 分開報。
6. 看到「Trace Replay」就開錯功能：vLLM 2026 年 8 月新增的 Trace Replay是強制 decode 既定 token、比較 logprobs 的功能；本文的 workload trace replay 是重送請求圖與時間，兩者用途不同。

Agentic Workload FAQ

1. Prefix Cache 命中 90%，是不是就快 90%？

不是。它只表示某個定義下的 prefix token 命中比例；decode、queue、網路、工具與 restore 都還在。用 newly computed prefill、TTFT 與 wall time共同判讀。

2. Restart 一定會變 cold 嗎？

不能預設。結果取決於引擎、cache tier、相容性檢查與實際設定。重啟後以 hit／query、computed prefill 與 restore 時間驗證。

3. 四回合夠做正式容量規劃嗎？

不夠。它是把管線接通的最小 smoke trace。接著換成你的長度分布、DAG、think time、fan-out 與多個 sessions，再增加重複數。

4. 可以保存真實 prompt 讓 replay 更準嗎？

只有在資料治理允許時才做。多數 serving 選型先用長度、依賴與 prefix ID 就足夠；若要保存內容，需另處理程式碼、密鑰、路徑、工具輸出與保留期限。

5. 為什麼 warm hit 高，p95 TTFT 反而變差？

先看 queue 與 worker placement。熱門 prefix 全黏在同一個 worker，可能省下 prefill 卻增加排隊；也可能在高 KV 使用率下發生 eviction。Router 要平衡 locality 與 load。

6. 本機只有一位使用者，也需要 fan-out 測試嗎？

若你的 Agent 會並行 subagent 或工具回填，就值得測。單一人類不等於單一 in-flight request；先從 concurrency 1、2、4 的小 sweep 開始。

7. 要不要完全關掉 Prefix Cache 做基準？

依問題而定。關閉組可隔離 cache 機制；cold／warm／restart 則更接近日常營運。兩者分開命名，不把不同問題的結果混算。

8. 哪些變更後要重跑？

任何會改變 token、cache key、排程或 worker state 的變更。包括模型 revision、量化、tokenizer、chat template、工具 schema、引擎、KV 容量、router、context 與併發。

給新手的 5 個重點

1. 先把 Agentic Workload 記成請求圖、共享前綴與到達節奏。
2. 用數字與拓撲取代 prompt 內容，先做隱私安全的四回合 trace。
3. Cold→warm→restart 是一個 block；每組都看 counter delta 與原始分布。
4. Cache hit 只解釋 prefill，最後仍以成功 session、TTFT、wall time 與成本決定。
5. Fan-out 與 router 先寫 SLO 和回滾線，再逐步提高 concurrency。

若你的 session 會做 compaction，也要把壓縮前後分開測，因為重新取得遺失資訊本身有成本；可搭配 Context Compaction 再取得成本。想把 metrics、trace 與告警接成日常系統，則可延伸到 AI Agent Observability。