api模型检测
Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

11 KiB

端到端测试指南

前置条件

# 设置环境变量
export ANTHROPIC_RELAY_TOKEN="your-token-here"
export OPENAI_RELAY_TOKEN="your-token-here"
export GOOGLE_API_KEY="your-token-here"

# 构建
cargo build --release

确认 config.yaml 中 provider 配置正确(base_url、protocol、default_model)。

Google Gemini provider 推荐配置:

providers:
  google:
    protocol: google
    base_url: "https://generativelanguage.googleapis.com/v1beta"
    api_token: "${GOOGLE_API_KEY}"
    default_model: "gemini-3-pro-preview"
    stream: true
    thinking:
      enabled: true
      effort: high
      display: summarized

如果走中转站,把 base_url 改成中转站提供的 Gemini base url。


阶段 1:RPM 限流测试(Anthropic 协议)

目标:验证中转站实际 RPM 限制,推断限流器类型。

1.1 连通性验证

cargo run -- check --provider anthropic --prompt "Reply with pong."

# 流式模式(应输出 first_token_ms)
cargo run -- check --provider anthropic --stream --prompt "Reply with pong."

验证要点:

  • 非流式:返回文本 + elapsed_ms
  • 流式:额外输出 first_token_ms,且 first_token_ms < elapsed_ms

Google Gemini 连通性验证:

cargo run -- check --provider google --prompt "Reply with pong."
cargo run -- check --provider google --stream --prompt "Reply with pong."

验证要点相同。Google 流式请求会走 streamGenerateContent,非流式请求会走 generateContent

1.2 Sustained 模式 — 持续发送

以目标 RPM 匀速发送,观察成功率。

# 基线:100 RPM,预期全部成功
cargo run -- rpm --provider anthropic --mode sustained --rpm 100 --duration 60s --prompt "Hi"

# 目标:200 RPM,观察是否有 429
cargo run -- rpm --provider anthropic --mode sustained --rpm 200 --duration 60s --prompt "Hi"

# 超限:250 RPM,预期出现限流
cargo run -- rpm --provider anthropic --mode sustained --rpm 250 --duration 30s --prompt "Hi"

1.3 Burst 模式 — 瞬时并发

一次性发出所有请求,测试瞬时容量。

# 测试 burst 容量
cargo run -- rpm --provider anthropic --mode burst --burst 50 --prompt "Hi"
cargo run -- rpm --provider anthropic --mode burst --burst 100 --prompt "Hi"
cargo run -- rpm --provider anthropic --mode burst --burst 200 --prompt "Hi"

1.4 Token Bucket 模式 — 令牌桶

先 burst 耗尽桶容量,再观察补充速率。

cargo run -- rpm --provider anthropic --mode token-bucket --rpm 200 --burst 50 --prompt "Hi"

关注:burst 阶段成功数 ≈ burst 值,refill 阶段恢复速率 ≈ rpm/60 req/s。

1.5 Sliding Window 模式 — 滑动窗口

测试请求在滑动时间窗口内的恢复行为。

cargo run -- rpm --provider anthropic --mode sliding-window --burst 200 --prompt "Hi"
cargo run -- rpm --provider anthropic --mode sliding-window --burst 200 --probe-seconds 120 --prompt "Hi"

关注:60s 后成功率是否明显回升(滑动窗口特征)。

1.6 Window Boundary 模式 — 固定窗口边界

在分钟边界前后发送请求,测试窗口重置行为。

cargo run -- rpm --provider anthropic --mode window-boundary --burst 100 --prompt "Hi"

关注:边界后成功率是否突然恢复(固定窗口特征)。

1.7 Diagnose 模式 — 综合诊断

组合多种探针,自动推断限流器类型。

cargo run -- rpm --provider anthropic --mode diagnose --rpm 200 --burst 50 --prompt "Hi"

输出中 likely_limiter 字段为推断结果:

  • TokenBucket — 令牌桶(refill 探针稳定恢复)
  • FixedWindow — 固定窗口(边界后突然恢复)
  • SlidingWindow — 滑动窗口(60s 后逐步恢复)
  • Unknown — 信号不足,无法判断

1.8 关注指标

指标 含义
success / failure 成功/失败请求数
429 错误计数 被限流的请求数
latency_ms p50/p95/p99 请求总延迟百分位
ttft_ms p50/p95/p99 首 token 延迟百分位(仅流式)
likely_limiter 推断的限流器类型(仅 diagnose)

1.9 建议测试策略

  1. 先用低 RPM(100)确认全部成功,建立基线
  2. 逐步提高 RPM(150 → 200 → 250),找到限流阈值
  3. 用 diagnose 模式推断限流器类型
  4. 根据推断结果,用对应的专项模式深入验证

阶段 2:数据集精度验证

目标:验证各模型在标准数据集上的准确率。

2.1 拉取数据集

cargo run -- dataset fetch

数据存储在 data/benchmarks/ 目录。

2.2 AIME 2026(数学竞赛题)

# 快速验证(10 题)
cargo run -- bench aime2026 --provider anthropic --limit 10

# 完整测试
cargo run -- bench aime2026 --provider anthropic

# 指定更强模型
cargo run -- bench aime2026 --provider anthropic --model anthropic/claude-sonnet-4-20250514

# Google Gemini 快速验证
cargo run -- bench aime2026 --provider google --model gemini-3-pro-preview --limit 10

AIME prompt 会要求模型把最终答案写进 \boxed{}。评分时优先提取最后一个 boxed integer,其次只接受 Final answer: 393Answer: 393The answer is 393 这类明确 final-answer 格式;解释文本末尾的普通数字不会再被当成答案,会记为 no_answer

2.3 GPQA Diamond(研究生级别多选题)

# 快速验证(10 题)
cargo run -- bench gpqa-diamond --provider anthropic --limit 10

# 完整测试
cargo run -- bench gpqa-diamond --provider anthropic

# 指定模型
cargo run -- bench gpqa-diamond --provider anthropic --model anthropic/claude-sonnet-4-20250514

# Google Gemini 快速验证
cargo run -- bench gpqa-diamond --provider google --model gemini-3-pro-preview --limit 10

GPQA-Diamond 的 prompt 和评分按 OpenAI simple-evals 风格处理:要求模型最后一行输出 Answer: $LETTER,其中 LETTERABCD。评分只按这个严格 Answer: 格式提取答案;如果模型只在最后单独输出 C,或输出 I choose C,会记为 no_answer

2.4 精度参考基线

数据集 claude-haiku-4.5 claude-sonnet-4 gpt-4o-mini
AIME 2026 ~15-25% ~40-60% ~20-30%
GPQA Diamond ~30-40% ~50-65% ~35-45%

注:实际精度受 prompt 模板、temperature 等因素影响,以上为近似参考值。

2.5 报告输出

报告自动写入 reports/ 目录,JSON 格式,包含:

  • 总体准确率(accuracy)
  • 真实发送给上游的协议参数摘要(params.request,不含 prompt/token)
  • 每道题的对错明细(wrong_cases)
  • 延迟百分位(latency_ms、ttft_ms)
  • 错误统计(errors)

流式模式补充说明

所有命令均支持 --stream 参数:

# RPM 测试 + 流式
cargo run -- rpm --provider anthropic --mode sustained --rpm 200 --duration 60s --stream --prompt "Hi"

# Benchmark + 流式
cargo run -- bench aime2026 --provider anthropic --stream

流式模式下报告额外包含 TTFT(Time To First Token)百分位数据。

如果 provider config 中已设置 stream: true,则默认使用流式,无需额外传参。CLI --stream 参数优先级高于 config。

Thinking 参数

如果需要测试 reasoning / thinking 能力,可以在配置中打开,也可以通过 CLI 覆盖:

# Anthropic thinking
cargo run -- bench aime2026 \
  --provider anthropic \
  --model anthropic/claude-opus-4.7 \
  --limit 5 \
  --thinking true \
  --thinking-type enabled \
  --thinking-budget-tokens 10000 \
  --thinking-display omitted

# OpenAI-compatible reasoning
cargo run -- bench aime2026 \
  --provider openai \
  --limit 5 \
  --thinking true \
  --reasoning-effort high \
  --reasoning-summary auto

# Google Gemini 3 thinkingLevel
cargo run -- bench aime2026 \
  --provider google \
  --model gemini-3-pro-preview \
  --limit 5 \
  --thinking true \
  --thinking-effort high \
  --thinking-display summarized

# Google Gemini 2.5 thinkingBudget
cargo run -- bench aime2026 \
  --provider google \
  --model gemini-2.5-pro \
  --limit 5 \
  --thinking true \
  --thinking-budget-tokens 5000 \
  --thinking-display summarized

Anthropic 开启 thinking 后,请求体不会发送 temperature。benchmark 和 RPM 的 JSON report 会记录本次 thinking 参数,方便复现实验。

Google Gemini 开启 thinking 后,请求体会按以下规则写入 generationConfig.thinkingConfig

  • budget_tokens 对应 thinkingBudget,推荐给 Gemini 2.5 使用。
  • effort 对应 thinkingLevel,推荐给 Gemini 3 使用。
  • display: summarized 会发送 includeThoughts: true
  • display: omitted 会发送 includeThoughts: false

如果同时配置 budget_tokenseffort,两个字段都会发送。为了减少后端或中转站兼容性问题,建议 Gemini 3 只配 effort,Gemini 2.5 只配 budget_tokens

如果只配置 enabled: true,但不配置 budget_tokenseffortdisplay,当前实现不会发送 thinkingConfig。如果想显式请求或关闭 thought summary,至少加上 display: summarizeddisplay: omitted

错误请求/响应 Debug

当上游返回 400、429、504 等非成功 HTTP 状态时,checkbenchrpm 会自动在 outputs/debug/ 写入一份请求/响应 debug JSON,不需要额外加参数。请求在拿到 HTTP 响应前失败时,例如连接超时、读取响应失败、流式响应中断并被统计成 request_error,也会写入 *-request-error debug JSON。

debug JSON 包含:

  • 完整请求 URL
  • 脱敏后的请求 headers
  • 完整请求 body,包括 prompt
  • 响应 status;request_error 场景为 null
  • 完整响应 headers;request_error 场景为空对象
  • 完整响应 body;request_error 场景为空字符串
  • request_error 场景额外包含 response.error_kind: "request_error" 和本地错误信息 response.error

API token 会被脱敏,但 prompt、题目内容和模型输出会原样保存,排查完后按需清理 outputs/debug/

原始成功响应 Debug 模式

排查中转站是否改写成功响应时,可以加 --debug-raw

cargo run -- check --provider anthropic --stream --debug-raw --prompt "Reply with pong."
cargo run -- bench aime2026 --provider anthropic --stream --debug-raw --limit 3
cargo run -- rpm --provider anthropic --rpm 60 --duration 30s --stream --debug-raw --prompt "Hi"

开启后,程序会把成功请求的上游原始响应也写到 outputs/debug/

  • 非流式成功请求保存完整 JSON body
  • 流式成功请求保存原始 SSE 行,包括 event:data:
  • 文件不包含 API token
  • 文件可能包含模型输出内容,outputs/ 不会提交到 git

如果 report.jsonraw_output 中出现 <think>,可以查看 debug 文件判断它来自 text_delta,还是上游返回了其他 thinking 事件。


故障排查

现象 可能原因
连接超时 base_url 不可达,检查网络/DNS
401 Unauthorized api_token 环境变量未设置或已过期
全部 429 RPM 设置过高,降低后重试
accuracy 为 0 模型输出格式不匹配 judge 规则,检查 wrong_cases
ttft_ms 全部 None 未启用流式模式