Agent System Architecture: CPU / GPU / Tool Call

Request Lifecycle — End-to-End Multi-Turn Agent Flow

一个完整 Agent Task 的执行过程（Client-Heavy 模式，如 Cursor）。展示每个组件何时参与、数据如何流转。

      CLIENT
    

      ORCHESTRATOR (CPU)
    

      LLM (GPU)
    

      TOOLS
    

      TASK START
    
        User sends task
      
"Fix the bug in auth.py"
→
waiting...
idle
idle

      TURN 1
PROMPT
    
waiting for response...

        Build prompt
      
        1. Load system prompt (16K tok)

        2. Append user message

        3. Inject tool definitions

        4. Tokenize (BPE encode)
      
~5-13ms CPU
→
waiting for tokens...
idle

      TURN 1
INFERENCE
    
streaming tokens...

        wait for GPU...

        sampling each token

        ~0.1ms/tok CPU
      
        Prefill + Decode
      
        Prefill: 16K tokens

        TTFT: ~55ms (w/ cache)

        Decode: 128 tokens

        TPOT: ~13ms/tok
      
~1.7s GPU
idle

      TURN 1
PARSE
    
waiting...
←

        Parse → tool_call detected!
      
        Detokenize output

        Extract: read_file("auth.py")

        Validate function + args
      
~1ms CPU
→

        idle

        KV cache retained
      
preparing...

      TURN 1
TOOL Z
    
        sees: "Reading auth.py..."
      
        wait for tool...

        can schedule other sessions
      
        GPU IDLE
      
        KV cache: 5.1GB held

        waste = 1−ρ
      
        Execute: read_file
      
        Path: Direct Call

        Read auth.py from disk

        Return: 2000 tokens
      
Z ~ 0.1s

      TURN 1
RESULT
    
waiting...
←

        Format result → inject context
      
        Truncate if needed

        Append to history[]: tool_result

        Context: 16K → 18.1K tokens
      
~2ms CPU • then loop ↓
idle
done

      TURN 2
PROMPT
    
waiting...

        Build prompt (Turn 2)
      
        system + user + turn1_output

        + tool_result(auth.py)

        Tokenize ΔL = 2.1K new tokens

        prefix cache: reuse 16K KV
      
~3ms CPU
→
waiting...
idle

      TURN 2
INFER+TOOL
    
streaming...
"Editing auth.py..."

        sampling →
        parse tool_call →
        dispatch →
        format result
      
~6ms CPU total

        Incr. Prefill ΔL=2.1K
      
        TTFT: ~38ms (cache hit!)

        Decode: 128 tok → edit_file()
      
~1.7s GPU

        edit_file(auth.py, ...)
      
        Path: Direct Call

        Apply code patch
      
Z ~ 0.3s
context: 20.3K
inject tool_result → rebuild prompt ↓

      TURN 3
FINAL
    
streaming final answer...

        Build prompt (Turn 3)
      
        Reuse 18.1K prefix KV

        New ΔL: 2.2K tokens
      
→

        Incr. Prefill + Decode
      
        TTFT: ~40ms

        Decode: 256 tok

        No tool_call → final answer
      
~3.4s GPU
not invoked

      TASK DONE
    
←

        Receive final answer
      
        "Fixed the auth bug by..."

        Display to user
      
        Detokenize → stream to client
      
        Cleanup session state

        Signal: release KV cache
      
        KV cache freed

        20.3K × 320KB = 6.5GB released
      
idle

TURNS

3

CPU TOTAL

~30ms

GPU TOTAL

~6.8s

TOOL TOTAL

~0.4s

T_TASK E2E

~7.2s

Key observations from the flow:
• Orchestrator 是每轮必经的 serial path — prompt build + tokenize + parse + dispatch + format，约 8-15ms/轮 CPU 开销
• GPU 在 tool 执行期间完全空闲 — 但 KV cache 仍占显存，Orchestrator 可调度其他 session 填充
• Prefix cache 让 Turn 2+ 的 TTFT 从 ~580ms 降到 ~38ms — 只处理增量 ΔL 而非完整 context
• tool_call 检测是分支点 — 有 tool_call 则进入 dispatch→execute→format→loop；无则直接返回用户
• Context 单调增长 — 16K → 18.1K → 20.3K tokens，KV cache 从 5.1GB 增长到 6.5GB

Hierarchical Architecture — Full Stack Expansion

从用户请求到 GPU kernel / 具体工具的完整分层展开。左侧: LLM 推理栈（Router → PD 分离 → GPU）。右侧: Tool 执行栈（Dispatch → 路径 → 具体工具）。

CLIENT
User request • Result display • Session UI

↓ task request ↑ final answer

ORCHESTRATOR (CPU)

        ReAct Loop
        Prompt Build
        Tokenizer
        Parse & Route
        Session Mgmt
      

↙ token_ids + attention_mask

tool_call(name, args) ↘

          LLM INFERENCE STACK
        

API Gateway / Router CPU

Load balancing, rate limiting, auth, model routing (选择 model variant / 精度)

↓

Serving Engine CPU

vLLM / SGLang / TRT-LLM
Request scheduler • Continuous batching • Prefix cache index
KV cache manager • Chunked prefill • Preemption policy

↓ PD disaggregated?

            Prefill-Decode Disaggregation
          

PREFILL NODES

Compute-bound
• 处理 L(j) 或 ΔL input tokens
• Self-Attention O(L²) or O(ΔL×L)
• MLP / MoE expert routing
• 生成 KV cache

GPU Kernels:
FlashAttention-2/3 • GEMM (FP16/FP8)
RoPE • LayerNorm • SwiGLU
MoE all-to-all (if MoE)

Utilization: η_p ≈ 65% (compute-bound)

DECODE NODES

Memory-bound
• Auto-regressive, 1 token/step
• Load weights: T_weight
• Load KV cache: T_kv
• TP all-reduce per layer

GPU Kernels:
PagedAttention • GEMV (weight load)
GQA/MLA KV read • Top-p sampling
TP all-reduce (NVLink/IF)

Utilization: η_d ≈ 40% (memory-bound)

KV Cache Transfer: Prefill → Decode | Network (RDMA/NVLink) or shared HBM | DualPath: storage BW + network BW 双通道

↓

GPU Hardware HW

Compute
Tensor Cores (FP16/FP8/FP4)
SM/CU × 132-304

Memory
HBM3e: 3.35-8.0 TB/s
80-288 GB capacity

Interconnect
NVLink/Infinity Fabric
TP all-reduce, EP all-to-all

KV Cache (HBM)
GQA: ~320 KB/tok
MLA: ~69 KB/tok

          TOOL EXECUTION STACK
        

Tool Router / Dispatcher CPU

function_name → 路由到对应 dispatch 路径
Validate args schema • Permission check • Rate limit

↓ which path?

            Dispatch Paths
          

                Direct Call (~0.1ms dispatch)
              

File I/O
read_file • write_file
grep • glob • list_dir
Z: 0.05-0.5s

Shell / Terminal
bash cmd • git ops
npm/pip install • build
Z: 0.1-30s

Code Analysis
AST parse • lint check
symbol lookup • LSP
Z: 0.1-2s

Code Sandbox
Python exec • test run
Container spawn
Z: 0.5-60s

                MCP Server (~2-50ms dispatch, JSON-RPC)
              

Browser Automation
navigate • click • type
screenshot • extract
Z: 1-15s

Database
SQL query • schema inspect
Postgres / SQLite / Redis
Z: 0.05-5s

RAG / Vector DB
embed query • similarity search
re-rank • chunk retrieve
Z: 0.2-3s

Custom Plugins
Slack • Jira • Calendar
Domain-specific MCP
Z: 0.5-10s

                External API (~5-100ms dispatch, HTTP/gRPC)
              

Web Search
Google / Bing / Tavily API
Parse SERP • extract content
Z: 2-10s (network)

Cloud Services
AWS/GCP/Azure APIs
Deploy • Monitor • Scale
Z: 1-30s

3rd Party SaaS
GitHub API • Stripe • Twilio
OAuth + rate limit
Z: 0.5-5s

Sub-Agent LLM
Call another LLM for subtask
Translation / Summary / Judge
Z: 1-60s

↓ raw result

Result Formatter CPU

Truncate to max_tokens • Error wrapping • Structured output • ΔL tokens → Orchestrator

        ↗ output token_ids → Orchestrator
      

        ↖ tool_result (ΔL tokens) → Orchestrator
      

      ↻
      Orchestrator: if tool_call → inject result → rebuild prompt → LLM again  |  if no tool_call → stream to Client
    

■ CPU HOST — Orchestration & Preprocessing

Agent Orchestrator

ReAct loop, planning, decision routing, multi-agent coordination, state machine

~1-5ms per decision step

Prompt Construction

System prompt (16K+), history assembly, tool result injection, context window management

~2-10ms, string concat intensive

Tokenizer / Detokenizer

BPE/SentencePiece encode → token IDs; decode output IDs → text. Pure CPU.

~0.5-3ms per 2K tokens

Sampling & Output Parsing

Top-p/top-k/temperature sampling on logits; structured output parsing (JSON tool_call, code blocks)

~0.1-1ms per output token

Session & Memory Mgmt

Conversation state, KV cache metadata & eviction policy, prefix cache index, session lifecycle

O(C) sessions tracked in DRAM

Request Scheduler

Batch formation, priority queuing, preemption, continuous batching, KV budget allocation

~0.5-2ms scheduling overhead

CPU bottleneck: prompt construction scales with context length; at high throughput, tokenization & scheduling overhead can reach 15-40% of per-turn time (TaxBreak, 2603.12465)

token_ids + attention_mask + position_ids ▼ PCIe/NVLink → GPU HBM

■ GPU DEVICE — LLM Inference Engine

Prefill (Compute-bound)

Process all input tokens in parallel. Self-attention O(L²) + MLP. Determines TTFT.

TTFT = 2×P_active×L / (G×F) / η_p

⚠ O(L²) without prefix cache

Decode (Memory-bound)

Auto-regressive generation, 1 token/step. Weight + KV-cache loading from HBM dominates.

TPOT = max(T_weight+T_kv, T_compute) / η_d

⚠ HBM bandwidth-limited

KV Cache (HBM)

Per-session KV tensors. Grows with L(j) × C. Eviction needed when memory full.

GQA: ~320 KB/tok • MLA: ~69 KB/tok

⚠ memory wall: C_max shrinks per turn

Prefix Cache

Reuse KV from prior turns. Reduces prefill to incremental ΔL only. Hit rate h(Z).

cache hit → 21× TTFT speedup

Attention Kernels

FlashAttention / PagedAttention. GQA or MLA. TP all-reduce per layer.

~30μs all-reduce × 2/layer × 80 layers

MLP / MoE Experts

Dense FFN or routed MoE. EP across GPUs. Small batch = few active experts.

E_active = min(B×K, E_total)

GPU idle during tool execution pauses (Z). Active ratio ρ = R/(R+Z). Need C ≥ B_max/ρ concurrent sessions to keep GPU saturated.

output logits / token IDs ▼ CPU: detokenize + parse tool_call

■ CPU: parse_tool_call(output) → extract function_name + arguments → ▼ dispatch to Tool Environment

■ TOOL EXECUTION — External Environment (CPU / I/O / Network bound)

Code Sandbox

Python/shell in isolated container. Process spawn + execution. CPU-bound compute.

Z ~ 0.5-5s typical

File I/O

Read/write/search files. Grep, glob, AST parsing. Disk I/O + CPU string ops.

Z ~ 0.1-2s typical

Web Search / Browse

HTTP requests, page rendering, content extraction. Network latency dominant.

Z ~ 2-30s typical

API Calls

Database queries, REST/gRPC, external service invocations. Network I/O bound.

Z ~ 0.1-10s typical

RAG / Retrieval

Vector DB search, embedding, document chunking, re-ranking. CPU + optional GPU.

Z ~ 0.2-3s typical

Result Formatting

Truncation, summarization, structured output. Prepare ΔL tokens for next prompt.

ΔL ~ 500-3000 tokens/turn

Tool results feed back to CPU for next-turn prompt construction. GPU is completely IDLE during this phase. Waste ratio = 1−ρ.

Orchestrator Placement — Where Does the Brain Live?

Orchestrator 是 Agent 系统的控制中枢，向上对接用户请求，向下驱动 LLM 推理和工具执行。
它可以部署在 Client、Server、或两者之间，产生截然不同的系统特性。

Orchestrator = 三向路由中枢

        User / Client — task request
      
↓ ↑
ORCHESTRATOR

          • 接收用户请求，维护会话状态

          • 构建 prompt（system + history + tool results）

          • 驱动 ReAct 循环（Think → Act → Observe）

          • 解析 LLM 输出，检测 tool_call

          • 路由 tool dispatch，格式化 result

          • 调度决策（GPU 空闲期塞其他 session）
        
↙

            LLM (GPU)
prefill + decode
          
↘

            Tools
MCP / API / sandbox

Three Deployment Modes

        A: Client-Heavy
      

Cursor, Claude Code

CLIENT

            Orchestrator
Prompt build
Tool dispatch
JSON parse
Context mgmt
          

          — network (1 RTT/turn) —
        
SERVER
LLM inference only

+ 本地工具（真实环境）
+ 隐私（数据不离开本地）
+ 实时可见中间过程

− N轮 × RTT 延迟叠加
− Client CPU 成为瓶颈
− 受限于用户设备性能

        B: Split (Hybrid)
      

Manus, Devin

CLIENT
Session UI
Result render

          — network (stream) —
        
SERVER

            Orchestrator
Prompt build
Tool dispatch
LLM inference
Cloud sandbox
          

+ 内部闭环，无 RTT 叠加
+ 可水平扩展
+ 强计算资源可用

− 工具在云端沙盒（非真实环境）
− 系统复杂度高
− 隐私：数据上云

        C: Server-Heavy
      

ChatGPT, Gemini, Cloud Agent

CLIENT
Pure UI
Send request, wait

          — network (final result) —
        
SERVER

            Orchestrator
Prompt build
Tool dispatch
LLM inference
Tools (sandbox)
Context mgmt
          

+ 零 RTT 内部闭环
+ 全部资源可控
+ 统一调度优化

− GPU idle during Z, KV cache 占显存
− 隐私最低（全上云）
− 无法访问用户本地环境

Dimension	A: Client-Heavy	B: Split	C: Server-Heavy
代表产品	Cursor, Claude Code	Manus, Devin	ChatGPT, Gemini
CPU 开销位置	用户设备	服务端	服务端
网络调用/轮	1 RTT (LLM API)	0 (内部闭环)	0 (内部闭环)
8轮 task 额外延迟	0.8-3.2s (RTT×N)	~0	~0
工具执行环境	本地真实环境	云端沙盒	云端沙盒
隐私	高（数据不离开本地）	中	低（全上云）
可扩展性	受限于用户设备	水平扩展	水平扩展
GPU idle 问题	Server 可服务其他用户	Z 期间 GPU idle + KV 占显存	Z 期间 GPU idle + KV 占显存
核心 trade-off	RTT 换隐私+本地工具	复杂度换灵活性	GPU 空闲换低延迟闭环

Orchestrator ↔ Tool Dispatch

Orchestrator 通过路由层选择 dispatch 路径，不同路径的 CPU 开销和 Z 延迟差异显著。

ReAct Loop Control Flow — Orchestrator 每轮决策

1. Build prompt
~2-10ms
→
2. Tokenize
~0.5-3ms
→
3. GPU infer
TTFT+decode
→
4. Parse output
~0.1-1ms
→

        tool_call?

        YES ↓   NO → return
      
↓
5. Validate &
dispatch
~0.2-0.5ms
→
6. Tool exec
Z = 0.1-30s
→
7. Format &
inject result
~1-3ms
↻

Three Dispatch Paths — Tool 路由层

        Path 1: Direct Call
      

本进程内直接调用函数，零网络开销。
例: Cursor Read/Write/Shell/Grep
dispatch: ~0.1ms
序列化: 无
适用: 高频 / 低延迟内置工具

        Path 2: MCP Server
      

通过 MCP 协议调用外部 tool server。
例: Cursor browser, 自定义 MCP
dispatch: ~2-50ms (stdio/HTTP)
序列化: JSON-RPC
适用: 标准化 / 可插拔工具

        Path 3: Direct API
      

不走 MCP，直接 HTTP 调用外部服务。
例: web search, DB query, SaaS
dispatch: ~5-100ms (network RTT)
序列化: HTTP + JSON
适用: 第三方外部服务

Tool Call Execution Modes

Sequential

        LLM → tool_1 → LLM → tool_2 → LLM

        Z_total = Z_1 + Z_2 + ...

一次一个 tool call，等结果再决定下一步。最常见模式（Cursor/Claude Code 默认）。
GPU 利用率最低

Parallel

        LLM → [tool_1 ‖ tool_2 ‖ tool_3] → LLM

        Z_total = max(Z_1, Z_2, Z_3)

一轮输出多个 tool_calls[]，并发执行。OpenAI Agents SDK 支持。
Z 取 max 而非 sum

Speculative

        LLM + [predict → pre-exec tool] → verify

        Z_eff ≈ 0 (if prediction correct)

预测可能的 tool call，提前执行。前沿研究 (2512.15834)。
CPU 开销最高（预测+验证+可能丢弃）

Orchestrator Scheduling During Tool Pause (Z)

工具执行期间 GPU 完全空闲，Orchestrator 面临调度决策：

Option (a) 空闲等待

简单但浪费 GPU

ρ 直接下降

Option (b) 调度其他 session

提高利用率，但增加 KV 内存压力

ρ ↑ 但可能导致 cache eviction

Option (c) Speculative prefill

预计算下轮可能的 prefix

AgentOpt: speculative context assembly

Orchestrator 需要维护全局状态：所有 session 的 KV cache 位置/大小、当前阶段（推理/暂停）、GPU batch 容量、内存预算。这些全部是 CPU 上的工作，是 Agent serving 相对于标准 serving 独有的复杂性。

Agent System Metrics

Agent 系统的评价指标体系，覆盖延迟、吞吐、效率、成本四个维度。每个指标标注其测量位置（CPU / GPU / Tool / End-to-End）。

LATENCY — 延迟指标

TTFT GPU

Time To First Token — 用户发出请求到收到第一个 output token 的时间。由 prefill 计算主导。
公式: TTFT = 2 × P_active × L_prefill / (G × F) / η_p
有 prefix cache 时仅处理 ΔL（~2K tokens），无 cache 时处理完整 L(j)（可达 50K+）。
典型值: 38-200ms (w/ cache) | 580-6200ms (w/o cache)

TPOT GPU

Time Per Output Token — decode 阶段每生成一个 token 的时间。受 HBM 带宽限制（memory-bound）。
公式: TPOT = max(T_weight + T_kv, T_compute) / η_d
随 batch size 和 context 长度增长。GQA/MLA 影响 KV 带宽瓶颈。
典型值: 13-18ms (70B, 8×H100)

R (Per-Turn Latency) E2E

单轮端到端延迟 — 一次 LLM 推理的完整时间 = TTFT + TPOT × OSL。
公式: R(j) = TTFT(j) + TPOT(j) × OSL
Agent 的核心响应速度指标。影响用户感知的交互流畅度。
典型值: Code 1.7s | Research 1.1s | Reasoning 74s

Z (Tool Pause) Tool

工具执行暂停时间 — GPU 完全空闲等待工具返回的时间。Agent 独有的延迟成分。
决定 GPU 活跃比 ρ = R/(R+Z)。直接影响 Pareto 曲线位置。
典型值: code 0.5s | file 2s | web 10-30s

T_task E2E

Task Completion Time — 完成一个 agent task 的总时间 = Σ(R_j + Z_j)。
公式: T_task = Σ_{j=1}^{N} [R(j) + Z(j)]
最终用户关心的指标。包含所有 N 轮推理 + 工具执行。
典型值: 十几秒 ~ 数分钟（取决于轮数 N 和工具速度）

CPU Overhead CPU

Host-side 开销 — tokenization + prompt construction + sampling + scheduling + kernel launch。
TaxBreak 分解为 7 类：launch, queue, tokenize, sample, schedule, transfer, misc。
典型值: 15-40% of per-turn time（小 batch 时可达 40%）

THROUGHPUT — 吞吐指标

X_turn (turns/s) System

Turn Throughput — 系统每秒完成的 LLM 推理轮数。
公式: X_turn = C_eff / (R + Z) [Little's Law]
Agent serving 的核心吞吐指标。受 GPU 计算 + 工具暂停双重约束。

X_task (tasks/s) System

Task Throughput — 系统每秒完成的完整 agent task 数。
公式: X_task = X_turn / N
对业务更有意义的指标。每个 task 包含 N 轮，N 越大 X_task 越低。

Token Throughput GPU

tokens/s/GPU — 标准 serving 的吞吐指标，在 agent 场景中需乘以活跃比 ρ。
有效吞吐 = raw throughput × ρ
典型值: Code 155 | Research 7.5 | Reasoning 36 tok/s/GPU

Useful Token Ratio System

有效 token 比 — 实际产出有用内容的 token 占总生成 token 的比例。
Agent 会生成大量 function_call JSON、重复 system prompt 等"overhead tokens"。
公式: useful_ratio = useful_tokens / total_generated_tokens

EFFICIENCY — 效率指标

ρ (GPU Active Ratio) GPU

GPU 活跃比 — GPU 实际在做推理计算的时间占比。Agent 独有的核心效率指标。
公式: ρ = R / (R + Z)
低 ρ 意味着 GPU 大量空闲，需要更多并发 session 填满。
典型值: Research 12% | Code 67% | Reasoning 82%

Prefix Cache Hit Rate h(Z) GPU

前缀缓存命中率 — 跨轮 KV cache 复用的成功率。命中时 prefill 从 L(j) 降到 ΔL。
是暂停时间 Z 和并发 C 的函数。形成正反馈环：Z↑ → h↓ → R↑ → ρ↓。
典型值: Code ~95% | Reasoning ~85% | Research ~70%

KV Cache Utilization GPU

KV 缓存显存占用率 — 当前 KV cache 占可用 GPU 显存的比例。
M_kv = C × L̄ × κ (κ: bytes/token)
随轮次增长而单调增加。GQA ~320KB/tok, MLA ~69KB/tok。
内存墙: C_max = ⌊M_avail / M_kv_session⌋ 随 task 进行持续下降

C_max (Max Concurrency) GPU

最大并发 session 数 — 受 KV cache 显存约束的并发上限。
Agent 独有的动态约束：随 context 增长 C_max 持续缩减。
70B 8×H100: Turn 1: 98 sessions → Turn 20: 27 sessions

B_eff (Effective Batch) CPU+GPU

有效 batch size — 稳态下 GPU 实际处理的平均并发请求数。
公式: B_eff = C_eff × ρ = C_eff × R / (R + Z)
B_eff 与 R 互相依赖（TPOT 取决于 B_eff），需迭代求解收敛。

Tool Call Success Rate Tool

工具调用成功率 — 工具执行成功并返回有效结果的比例。
失败的工具调用浪费 Z 时间且不产出有用 context，导致额外重试轮次。
影响: 低成功率 → N 增大 → T_task 增大 → 成本上升

COST & QUALITY — 成本与质量指标

$/task E2E

单 task 成本 — 完成一个 agent task 的 GPU 计算成本。
$/task = GPU_hours/task × $/GPU_hour
Agent 成本 = standard_serving_cost × N × (1/ρ)。慢工具 ρ 低但 GPU 空闲可共享。

Tokens/task E2E

Task 总 token 消耗 — input + output tokens across all N turns。
Input tokens 随轮次累积增长（context window stuffing），是 API 成本的主要来源。
典型: Code agent ~100K tokens/task | Deep reasoning ~500K+

Task Success Rate Quality

任务成功率 — Agent 成功完成目标任务的比例。
标准 benchmark: SWE-bench verified (coding), WebArena (browsing), GAIA (general)。
注意: 成功率与 latency/cost 存在 trade-off（更多轮次 → 更高成功率 → 更高成本）

Turns/task (N) Quality

平均轮数 — 完成一个 task 需要的 LLM 推理轮数。反映 agent 的推理效率。
N 越大 → T_task 越大, tokens/task 越多, 成本越高。
典型: Code 8-15 | Research 15-30 | Deep Reasoning 20-64

Metric Dependency Graph — 指标间的因果关系

        Z (tool speed)
        →
        h (cache hit)
        →
        TTFT
        →
        R (latency)
        →
        ρ (active ratio)
        →
        B_eff
        →
        TPOT
        ↻ R
      

        R + Z
        →
        X_turn
        →
        X_task = X_turn/N
        C_max
        ↓
        $/task = f(N, ρ, token_price)
      

Agent System Architecture