主题
进阶技巧
接通是起点，把成本压下去 + 监控做起来 + 调用更稳，看本页。
1. 控成本：选对模型 + 看清是哪段烧 token
大体的"性价比"思路
不同模型每千 token 价格相差可达 100 倍以上。先用便宜模型把流程跑通，再切贵模型做实际生产——这是最省钱的姿势。
| 场景 | 建议起步模型 |
|---|---|
| 日常 chat / 简单问答 | gpt-5-mini / claude-haiku-4-5 / gemini-2.5-flash |
| 中等代码 / 中等推理 | gpt-5 / claude-sonnet-4-6-* |
| 长上下文 / 难推理 / Agent | claude-sonnet-4-* / gpt-5 / claude-opus-4-* |
具体可用模型 + 当下定价以 控制台模型页 为准。
看清调用日志：哪段烧了 token
控制台 → 「日志」可以看到每次调用的：
- prompt_tokens（输入）
- completion_tokens（输出）
- total_tokens
输出 token 的单价通常是输入的 3 倍以上——长输出比长输入更烧钱。常见浪费场景：
- 让模型"用 markdown 表格列出所有 XXX"——表格语法消耗大量 token
- 没设
max_tokens，模型放飞自我写一大段 - 同样的 system prompt 每次都重发（见下文 prompt caching）
Prompt caching（适用 OpenAI / Claude 路径）
OpenAI 和 Claude 都支持把 system prompt + 长上下文标记为"可缓存"——后续命中缓存的部分按更低价（通常打 1 折左右）计费。
python
# OpenAI prompt caching 在协议层是自动的：
# 同样开头的 prompt（>= 1024 token）后续命中缓存，无需特殊参数
# 控制台日志看返回的 cached_tokens 字段判断命中情况python
# Anthropic SDK 用 cache_control 标记
client.messages.create(
model="claude-sonnet-4-6-...",
system=[
{
"type": "text",
"text": "<很长的 system prompt 或文档>",
"cache_control": {"type": "ephemeral"}
}
],
messages=[...]
)TIP
具体哪个模型支持 caching、命中条件、价格折扣，以上游官方 OpenAI 文档 / Anthropic 文档 为准。本站作为协议网关透传该字段。
2. 监控用量
控制台「日志」按时段过滤
「日志」页支持按时间 / 模型 / 状态码 / Key 过滤，看：
- 某段时间总消耗：用于追溯"今天怎么烧了 ¥30"
- 某个 Key 消耗：用于多 Key 拆分项目的成本归属
- 失败调用：429 / 5xx 是不是集中在某个时段（可能是上游波动）
给 Key 设额度上限
创建 / 管理 API Key 时可以给单个令牌设额度上限——独立于账户余额。这样：
- 接给客户端 / 队友的 Key 设个 ¥50 顶额，跑飞最多损失 ¥50
- 给自动化脚本用的 Key 单独设额度，方便核算单业务成本
- 主 Key 不设上限留给自己用
接入告警（自建）
控制台暂不提供"余额低于 X 时邮件告警"。需要的话自己写一个 cron：
bash
# 每小时查余额，低于阈值发钉钉/Slack
# 假设有 GET /api/balance 端点（按实际控制台 API 文档调整）
BALANCE=$(curl -s -H "Authorization: Bearer $WHY01_API_KEY" \
https://s1.why01.top/api/balance | jq -r '.data.balance')
if (( $(echo "$BALANCE < 10" | bc -l) )); then
# 调你的告警通道
curl -X POST $WEBHOOK -d "{\"text\":\"why01 余额 $BALANCE\"}"
fi控制台 API 端点和返回结构以实际可见的为准；若控制台没暴露余额查询 API，直接定时人工看「钱包」也是一种办法。
3. 多 Key 管理
一个账户能建几个 Key
不限。建议按用途拆分：
dev-local— 开发机用，额度低、容易换prod-app-A— 生产 App A 用，独立额度归属prod-app-B— 生产 App B 用cli-claude-code— 自己 Claude Code 用，单独看消耗temp-debug-{date}— 临时调试，跑完即禁
Key 命名约定
{环境}-{业务}-{创建月} 之类，避免半年后看着一堆 mykey1/test/abc 不知谁是谁。
轮换节奏
生产 Key 建议每 90 天主动轮换：
- 控制台建新 Key，名称加上日期后缀
- 更新业务侧配置（
.env/ 配置中心 / CI 变量） - 灰度切换 → 观察 24 小时
- 把老 Key 禁用（不删，留作回滚）
- 7 天没问题 → 老 Key 真删
4. 调用更稳：重试 + 超时 + 限流
重试策略（核心）
5xx 几乎一定要重试；429 也重试但要有 backoff。不要重试 4xx 里的 400/401/402/404——那是你自己的 bug，重试只是浪费 token。
python
import time, random
from openai import OpenAI, APIError
client = OpenAI(base_url="https://s1.why01.top/v1", api_key="sk-...")
def chat_with_retry(messages, max_attempts=4):
for attempt in range(max_attempts):
try:
return client.chat.completions.create(
model="gpt-5-mini",
messages=messages,
timeout=300, # 5 分钟，长 prompt 必加
)
except APIError as e:
status = getattr(e, "status_code", 0)
# 不重试的 4xx
if status in (400, 401, 402, 403, 404, 422):
raise
# 5xx 和 429：指数退避 + 抖动
if attempt == max_attempts - 1:
raise
wait = (2 ** attempt) + random.uniform(0, 1)
time.sleep(min(wait, 30))客户端 timeout 设到多大
- 短对话 / 非流式：60 秒
- 长 prompt / agent 类：300 秒（5 分钟）
- 批量任务：900 秒（15 分钟）
短了的话长 prompt 处理中途就会被自己客户端断掉，看起来像"网关有问题"实则是自己 timeout 太短。
控制并发
不要并发打满。单 Key 同时进行的请求不超过 5 个是个稳妥的起点。需要更高并发先观察 429 日志，再 联系客服 评估升级用户组。
5. 流式 vs 非流式
| 维度 | 非流式 | 流式 |
|---|---|---|
| 实现复杂度 | 一次 request → response | 需要处理 SSE / async iterator |
| 用户体感 | 等几秒一次性出 | 边出边看，更流畅 |
| 中途出错 | 整次 fail | 已收到的 token 能保留 |
| 计费 | 按返回 token 算 | 同样按返回 token 算（不区分） |
面向人的对话：用流式（更好的 UX）。 机器调用机器（写代码生成、批量处理）：非流式更简单。
流式实现见 OpenAI 兼容 § 流式输出。
6. Agent 类应用的几个坑
Claude Code / Codex / 自写 agent 都属于这类。最大的成本来源是上下文不断膨胀。
- 每轮对话 = 把所有历史消息 + 工具调用结果都重发一次
- 长会话到 100k token 后单次调用就要 ¥几毛
- 文件越多 + 工具调用越频繁，token 消耗越快
应对：
- 及时
/clear清上下文——长会话超过 1 小时考虑重开 - 窄化项目目录——只
cd到相关子目录，避免读node_modules/ - 用
.claudeignore/.gitignore——把无关文件挡在外面 - 能用便宜模型完成的子任务用便宜模型——比如让 haiku 跑文件搜索 / 简单替换，sonnet 留给真的需要推理的部分
7. 多家上游切换
本站根据用户组路由到不同上游。同一个模型名调用过去可能跑在不同上游商，结果略有差异（特别是 token 计算 / 边缘情况输出）。
如果你需要严格"对齐 OpenAI 官方"或"对齐 Anthropic 官方"的输出，本站作为聚合网关不保证完全一致——这是渠道分发模型的固有性质。需要绝对一致请直接走官方账号。
对绝大多数应用场景（写代码、对话、翻译、总结），上游差异在可接受范围内。