Benchmarking

Die adk-bench-Crate und der Befehl cargo adk bench ermöglichen Echtzeit-LLM-Benchmarking für ADK-Rust-Agenten. Im Gegensatz zu synthetischen Mikrobenchmarks misst adk-bench die tatsächliche End-to-End-Leistung mit Live-Modellaufrufen und trennt den Overhead des Frameworks von der Latenz des Anbieters.

Was wird gemessen

Schnellstart

# Run all benchmarks with default settings
cargo adk bench

# Run a specific workload
cargo adk bench --workload simple_tool_call

# Dry run (no LLM calls, validates config only)
cargo adk bench --dry-run

Referenz für CLI

cargo adk bench [OPTIONS]

OPTIONS:
    --workload <NAME>          Run a specific workload (simple_tool_call,
                               multi_step_reasoning, parallel_tool_invocation)
    --iterations <N>           Number of iterations per workload [default: 10]
    --warmup <N>               Warmup iterations before measurement [default: 2]
    --provider <NAME>          LLM provider to benchmark [default: gemini]
    --model <MODEL>            Model ID to use [default: gemini-3.5-flash-lite]
    --output <FORMAT>          Output format: table, json, csv [default: table]
    --output-file <PATH>       Write results to file instead of stdout

    # Cost control
    --dry-run                  Validate configuration without making LLM calls
    --max-cost-usd <AMOUNT>    Abort if estimated cost exceeds this amount
    --confirm-cost             Prompt for confirmation before running

    # Regression detection
    --save-baseline <NAME>     Save results as a named baseline
    --check-regression <NAME>  Compare against a saved baseline
    --tolerance <PERCENT>      Regression threshold percentage [default: 10]

    # External comparison
    --ebp                      Enable External Benchmark Protocol output
    --harness <PATH>           Path to external framework harness config

Kostenkontrolle

Benchmarks führen echte LLM-Aufrufe aus. Verwenden Sie diese Flags, um unerwartete Kosten zu vermeiden:

# Preview what would run without spending anything
cargo adk bench --dry-run

# Set a hard cost ceiling
cargo adk bench --max-cost-usd 5.00

# Require manual confirmation after cost estimate
cargo adk bench --confirm-cost

Der Kostenschätzer verwendet Tokenanzahlen aus vorherigen Ausführungen (oder Schätzungen aus der Workload-Definition), multipliziert mit den veröffentlichten Preisen des Anbieters pro Token.

Regressionserkennung

Verfolgen Sie die Leistung über verschiedene Versionen hinweg:

# Establish a baseline after a release
cargo adk bench --save-baseline v1.0.0

# On the next change, check for regressions
cargo adk bench --check-regression v1.0.0 --tolerance 10

# Tighter tolerance for critical paths
cargo adk bench --workload simple_tool_call --check-regression v1.0.0 --tolerance 5

Exit-Codes:

• 0 — keine Regressionen erkannt
• 1 — mindestens eine Metrik hat sich über die Toleranzgrenze hinaus verschlechtert
• 2 — Konfigurations- oder Laufzeitfehler

Baselines werden in .adk-bench/baselines/ als JSON-Dateien gespeichert.

Vergleich mit externen Frameworks (EBP)

Das External Benchmark Protocol (EBP) ermöglicht einen direkten Vergleich mit anderen Agent-Frameworks. EBP definiert ein standardisiertes Workload-Format und Messprotokoll, damit Ergebnisse über verschiedene Implementierungen hinweg vergleichbar sind.

# Output EBP-compatible results
cargo adk bench --ebp --output json > results.json

# Run against an external harness (e.g., LangGraph, Python SDK)
cargo adk bench --harness harnesses/langraph.toml

Harness-Konfigurationsdateien legen fest, wie externe Frameworks mit denselben Workloads aufgerufen und ihre Ergebnisse anhand derselben Methodik gemessen werden.

Benchmark-Ergebnisse

Veröffentlichte Ergebnisse zum Vergleich von ADK-Rust mit anderen Frameworks (deterministische Konfiguration, dasselbe Modell, derselbe Workload):

Methodik:

• Echte Gemini 3.5 Flash-Lite-Aufrufe (nicht simuliert)
• Deterministische Konfiguration: temperature=0, fester Seed
• 10 Iterationen nach 2 Aufwärmläufen
• Isolierung des Overheads: Gesamtzeit minus gemessene LLM-Latenz
• Dieselben Tool-Definitionen und Prompts in allen Frameworks

Workloads

simple_tool_call

Eine einzelne Benutzernachricht → ein Tool-Aufruf → eine Antwort. Misst den minimalen Round-Trip-Overhead.

multi_step_reasoning

Eine mehrteilige Konversation, die 3–5 sequenzielle Tool-Aufrufe mit dazwischenliegendem Reasoning erfordert. Misst die anhaltende Schleifenleistung.

parallel_tool_invocation

Eine einzelne Benutzernachricht, die 3 parallele Tool-Aufrufe auslöst. Misst den Overhead der gleichzeitigen Weiterleitung.

Programmatische Verwendung

use adk_bench::{BenchmarkSuite, BenchConfig, Workload};

let config = BenchConfig::builder()
    .iterations(10)
    .warmup(2)
    .provider("gemini")
    .model("gemini-3.5-flash-lite")
    .build()?;

let suite = BenchmarkSuite::new(config);
let results = suite.run_all().await?;

for result in &results {
    println!("{}: cold_start={}ms overhead={}μs",
        result.workload,
        result.cold_start_ms,
        result.loop_overhead_us,
    );
}

Weiterführende Lektüre

Siehe adk-bench/README.md für:

• Benutzerdefinierte Workload-Definitionen
• Leitfaden zur Erstellung des Harness
• Muster für die CI-Integration
• Nachverfolgung historischer Ergebnisse

---

Zurück: ← Codeausführung | Weiter: ACP Werkzeuge →