Back to Feed
Agents / Benchmarks & Evals

Benchmarking Resource Aware LLM Tool Agents

Original: PeakBench: Benchmarking Resource-Aware Tool Invocation in LLM Agents

Listen to the summary

Uses a voice available on your device

Audio options
On this page 5 sections
Related concepts 3 concepts

Key Takeaways

  • PeakBench uses 1.2K tools across 130 servers to benchmark LLM agent scheduling capabilities.
  • Dependency extraction success is not a strong indicator of an agent's ability to schedule tasks safely under resource constraints.
  • Models without resource-aware context rely on conservative delays, which increases latency to avoid capacity violations.
  • The Resource-Aware Scheduling Context (RASC) baseline reduces scheduling latency and improves resource utilization for most tested models.

Summary & Methodology Analysis

PeakBench addresses the gap in agent evaluation by moving beyond serial task success to examine physical scheduling under resource constraints. The benchmark includes 1.2K MCP-compatible tools aggregated from sources such as LiveMCPBench, MCP-Atlas, MCP-Bench, MCP-Universe, and MCPMark. It evaluates agents based on two dimensions: logical planning (recovering prerequisite relationships) and physical scheduling (managing resource capacity budgets). The researchers tested eight frontier API models, including DeepSeek-V4-Flash, DeepSeek-V4-Pro, GLM-5, Kimi-K2.5, Claude Sonnet 4.6, GPT-4.1, GPT-5, and o3.

Interactive System Flowchart

Click diagram to expand and zoom

Illustrative Implementation

A short sketch of the paper's core idea, not the authors' own code.

# Illustrative sketch (not from the paper)
import json, torch

# Load tool catalog with resource footprints (CPU, MEM, GPU, NET, DISK)
with open('tool_catalog.json') as f:
    catalog = json.load(f)  # {tool_id: [cpu, mem, gpu, net, disk]}

# Load a synthetic workflow (list of tool ids and declared edges)
with open('workflow.json') as f:
    wf = json.load(f)  # {"tools": [...], "edges": [(src, dst), ...]}

# ---------- Dimension I: Logical Planning ----------
# Assume we have a model-predicted edge set `pred_edges`
# Placeholder: use ground‑truth edges as prediction for illustration
pred_edges = wf['edges']

def graph_edit_distance(true, pred):
    # simple symmetric difference size as a proxy
    return len(set(true) ^ set(pred))

def edge_f1(true, pred):
    true_set, pred_set = set(true), set(pred)
    tp = len(true_set & pred_set)
    fp = len(pred_set - true_set)
    fn = len(true_set - pred_set)
    precision = tp / (tp + fp) if tp + fp else 0
    recall = tp / (tp + fn) if tp + fn else 0
    return 2 * precision * recall / (precision + recall) if precision + recall else 0

ged = graph_edit_distance(wf['edges'], pred_edges)
edge_f1_score = edge_f1(wf['edges'], pred_edges)
print('GED:', ged, 'Edge F1:', edge_f1_score)

# ---------- Dimension II: Physical Scheduling ----------
# Convert resource footprints to torch tensors for vectorized ops
resource_matrix = torch.tensor([catalog[t] for t in wf['tools']], dtype=torch.float)
# Example capacity budget (CPU, MEM, GPU, NET, DISK)
capacity = torch.tensor([100.0, 200.0, 8.0, 1000.0, 500.0])

# Simple scheduler that respects prerequisites and caps resources per timestep
schedule = []  # list of (timestep, [tool_indices])
remaining = set(range(len(wf['tools'])))
prereq = {dst: {src for src, d in wf['edges'] if d == dst} for dst in range(len(wf['tools']))}
current_time = 0
while remaining:
    ready = [i for i in remaining if prereq.get(i, set()).issubset(set(t for _, ts in schedule for t in ts))]
    # pack as many ready tools as capacity allows
    batch = []
    usage = torch.zeros(5)
    for i in ready:
        if torch.all(usage + resource_matrix[i] <= capacity):
            batch.append(i)
            usage += resource_matrix[i]
    schedule.append((current_time, batch))
    remaining.difference_update(batch)
    current_time += 1

# Compute metrics (placeholders)
scheduling_latency = len(schedule)
# Capacity Violation Area (CVA) = 0 because we enforced capacity
cva = 0.0
# Strict Mean Resource Utilization (MRU) = average usage / capacity
mru = torch.stack([torch.sum(resource_matrix[batch], dim=0) for _, batch in schedule if batch])
strict_mru = torch.mean(mru / capacity).item()
print('Latency:', scheduling_latency, 'CVA:', cva, 'Strict MRU:', strict_mru)

# ---------- RASC baseline (resource‑aware prompt) ----------
# In practice we would prepend resource metadata to the scheduling prompt
rasc_prompt = f"Capacity:{capacity.tolist()}\nTools:{resource_matrix.tolist()}\nSchedule the workflow safely."
print('RASC prompt snippet:', rasc_prompt[:80], '...')

Cross-Examination & FAQs

A deeper dive clarifying mechanics, constraints, and baseline evaluations.

Q1. What is the core purpose of PeakBench?

It is a benchmark of executable multi-tool workflows with execution-grounded dependency annotations and measured resource profiles to evaluate agent resource-aware orchestration.

Q2. Which models did the researchers test?

They evaluated DeepSeek-V4-Flash, DeepSeek-V4-Pro, GLM-5, Kimi-K2.5, Claude Sonnet 4.6, GPT-4.1, GPT-5, and o3.

Q3. Does being good at identifying task dependencies make an agent a better scheduler?

No. The research found that dependency-extraction success only weakly predicts the safety or efficiency of physical scheduling for the same workflow.

Q4. What strategy do models typically use when they lack resource telemetry?

They primarily rely on adding conservative delays, which increases scheduling latency to reduce capacity violations.

Q5. How does the RASC baseline improve agent performance?

For most models, it reduces scheduling latency while lowering capacity violation area and improving strict mean resource utilization by replacing conservative delays with targeted staggering.

Q6. What is the scale of the tools used in this benchmark?

PeakBench builds on approximately 1.2K MCP-compatible tools spanning about 130 servers.

Q7. Are there limitations to the workflows used in the study?

Yes, the benchmark uses synthetic workflows and the authors do not claim that the workflow set reproduces the full distribution of real user requests.

Q8. Is resource-aware orchestration an automatic capability in frontier models?

No, the benefit remains model-dependent, showing that resource-aware orchestration is a distinct capability rather than an automatic consequence of simply exposing resource metadata.

Q9. What specific metrics are used to evaluate physical scheduling?

The paper measures scheduling latency, capacity violation area, and strict mean resource utilization.

Flag an issue

What is wrong with this summary?

What is wrong?