# 端到端测试指南 ## 前置条件 ```bash # 设置环境变量 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 推荐配置: ```yaml 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 连通性验证 ```bash 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 连通性验证: ```bash 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 匀速发送,观察成功率。 ```bash # 基线: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 模式 — 瞬时并发 一次性发出所有请求,测试瞬时容量。 ```bash # 测试 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 耗尽桶容量,再观察补充速率。 ```bash 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 模式 — 滑动窗口 测试请求在滑动时间窗口内的恢复行为。 ```bash 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 模式 — 固定窗口边界 在分钟边界前后发送请求,测试窗口重置行为。 ```bash cargo run -- rpm --provider anthropic --mode window-boundary --burst 100 --prompt "Hi" ``` 关注:边界后成功率是否突然恢复(固定窗口特征)。 ### 1.7 Diagnose 模式 — 综合诊断 组合多种探针,自动推断限流器类型。 ```bash 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 拉取数据集 ```bash cargo run -- dataset fetch ``` 数据存储在 `data/benchmarks/` 目录。 ### 2.2 AIME 2026(数学竞赛题) ```bash # 快速验证(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: 393`、`Answer: 393`、`The answer is 393` 这类明确 final-answer 格式;解释文本末尾的普通数字不会再被当成答案,会记为 `no_answer`。 ### 2.3 GPQA Diamond(研究生级别多选题) ```bash # 快速验证(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`,其中 `LETTER` 是 `A`、`B`、`C` 或 `D`。评分只按这个严格 `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` 参数: ```bash # 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 覆盖: ```bash # 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_tokens` 和 `effort`,两个字段都会发送。为了减少后端或中转站兼容性问题,建议 Gemini 3 只配 `effort`,Gemini 2.5 只配 `budget_tokens`。 如果只配置 `enabled: true`,但不配置 `budget_tokens`、`effort`、`display`,当前实现不会发送 `thinkingConfig`。如果想显式请求或关闭 thought summary,至少加上 `display: summarized` 或 `display: omitted`。 ## 错误请求/响应 Debug 当上游返回 400、429、504 等非成功 HTTP 状态时,`check`、`bench`、`rpm` 会自动在 `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`: ```bash 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.json` 的 `raw_output` 中出现 ``,可以查看 debug 文件判断它来自 `text_delta`,还是上游返回了其他 thinking 事件。 --- ## 故障排查 | 现象 | 可能原因 | |------|----------| | 连接超时 | base_url 不可达,检查网络/DNS | | 401 Unauthorized | api_token 环境变量未设置或已过期 | | 全部 429 | RPM 设置过高,降低后重试 | | accuracy 为 0 | 模型输出格式不匹配 judge 规则,检查 wrong_cases | | ttft_ms 全部 None | 未启用流式模式 |