官方直连价怎么读：四要素
一手例子（核对日 2026-10-07）：阿里百炼 qwen3.8-max 北京在线 12 元/百万输入、36 元/百万输出；qwen3.8-flash 0.8/2.7 元。火山方舟 doubao-seed-2.1-pro 6/30 元、缓存命中 1.2 元、缓存存储 0.017 元/百万 token/小时。读任何价页都要记四件事：币种（同页可能混报不同地区价）、单位（每百万 token）、上下文阶梯（百炼 qwen3.7-plus 在 256K 与 1M 档差三倍；方舟 mini 按 32/128/256k 分档）、Batch 与缓存条件（两家 Batch 都约为在线价 50%，百炼明文 Batch 与上下文缓存折扣“两者不能同时生效”）。
中转站倍率不是价格
new-api 系站点公开的 model_ratio / group_ratio / cache_ratio 只是计费乘数，换算基准是 quota_per_unit 与站点显示币种——2026-10-07 核验，4Router 与 PackyAPI 的 quota_per_unit 均为 500000，4Router 显示 CNY、PackyAPI 显示 USD。未经换算的“model_ratio=1”没有可比性；把倍率直接当“每百万 token 单价”引用是常见的比较错误。
换算前必须核明的变量（当前未知）
把倍率换算成每百万 token 单价，需要知道站点确切的结算公式——包括分组倍率与按模型覆盖值（如 PackyAPI 公开的 model_group_ratio）在生效时是“替代 group_ratio”还是“再次相乘”。两家站点都没有在公开页面说明这一点，本轮核验也未实测确认，所以本文不给出任何换算单价算例：用一个未经核实的公式算出“看起来精确”的价格，比承认未知更危险。
核明公式的唯一可靠方法是用你自己的账号做锚点：以小额真实调用为准，用响应里的 usage tokens 和后台实际扣费反推单价。反推确认后写进台账，注明反推日期与样本量；站点改版后重测。
# 单价核对维度清单（不给“倍率→单价”算例：站点计算式未核明）
# 1) 显示币种与换算基准：两家公开 quota_per_unit=500000；显示币种一家 CNY、一家 USD
# 2) 三列倍率：model_ratio（输入）、completion_ratio（输出乘数）、cache_ratio（缓存）
# 3) 分组倍率 group_ratio 与按模型覆盖值 model_group_ratio
# ——覆盖值生效时是“替代”分组倍率还是“再次相乘”，站点未说明，不能默认任何一种
# 4) 条件项：上下文分档、高峰/空闲分时、Batch 与缓存折扣是否互斥
# 5) 复核锚点：usage.tokens × 你最终确认的单价，对照后台账单用 usage 字段复核账单
抽 3–5 次真实调用做复核：估算与服务商账单的误差要能归因——缓存命中（输入按 cache 折算）、阶梯跳档（长上下文换档）、币种汇率（显示 USD 的站点）。归因不了的误差就是需要向客服追问的账单问题。
# 每次响应的 usage 是计费凭据：
# 本次成本 = prompt_tokens/1e6 × 输入单价 + completion_tokens/1e6 × 输出单价
in_tok, out_tok = 12500, 780 # 取自响应 JSON 的 usage 字段
in_price, out_price = 12, 36 # 例：qwen3.8-max 华北2（北京）在线价（元/百万 token）
print(f"本次成本 ≈ {in_tok/1e6*in_price + out_tok/1e6*out_price:.4f} 元")验收条件
(1) 每个在用模型有一行台账：币种、输入/输出/缓存单价、适用阶梯、来源 URL 与核对日期；(2) usage 复核误差可解释；(3) 比较两个渠道时用同一阶梯、同一币种、同一工作负载——不同阶梯下“谁便宜”会反转（例如短上下文便宜的模型在 1M 档可能更贵）。