同样一次请求，把 20 万汉字的长文档交给模型、再让它输出 500 个 token，按量计费（输入约 ¥3/百万 token、输出约 ¥15/百万 token，以各家模型官方页面的标价为准，本文仅作换算参考）是 0.7275 元；换到小鱼API 用 grok-4.1 按次计费，这一次固定 0.05 元，相差 14.6 倍。一次省 0.68 元，每天 500 次就是每天省约 340 元，一个月省约 10200 元。
Grok 系列是三档价：grok-4.1 每次 0.05 元，grok-4.5 和 grok-4.6 每次 0.09 元。中间差 0.04 元，但它等于在 0.05 元基础上涨了 80%。每天 500 次，升级一个月多花 600 元；每天 2000 次，多花 2400 元。要不要升，是一道能算出来的算术题。
另一面也讲清楚：每天只发短请求（输入 800 token、输出 300 token），按量只要 0.0069 元，比按次便宜。请求越短按量越划算，输入越长按次越划算，超过约 1.2 万汉字后按次开始明显省钱。
| 模型 | 每次价格 | 每天 500 次 | 每月 30 天 |
|---|---|---|---|
| grok-4.1 | 0.05 元 | 25 元 | 750 元 |
| grok-4.5 | 0.09 元 | 45 元 | 1350 元 |
| grok-4.6 | 0.09 元 | 45 元 | 1350 元 |
4.5 和 4.6 同价，选哪个看任务对推理深度和实时信息的要求。真正需要认真选的，是 4.1 和 4.5 之间那 0.04 元。
| 模型 | 每次价格 | 定位 |
|---|---|---|
| gemini-2.5-pro | 0.031 元 | 便宜档 |
| grok-4.1 | 0.05 元 | 便宜档偏上 |
| claude-sonnet-4-5-thinking | 0.09 元 | 中档 |
| gemini-3.1-pro-preview | 0.09 元 | 中档 |
| gpt-5.5 | 0.20 元 | 中高档 |
| claude-opus-4-6-thinking | 0.25 元 | 高价位 |
按次计费是「一次请求固定价」，所以这张表能直接换算成预算：每天 500 次，grok-4.1 是 25 元一天，gpt-5.5 是 100 元一天，claude-opus-4-6-thinking 是 125 元一天。
| 计费方式 | 算式 | 这次请求花多少 |
|---|---|---|
| 按量计费 | 输入 20 万汉字 ≈ 24 万 token：24 万 ÷ 100 万 × 3 = 0.72 元；输出 500 token：500 ÷ 100 万 × 15 = 0.0075 元 | 0.7275 元 |
| 按次（grok-4.1） | 固定 0.05 元，输入多长都同价 | 0.05 元 |
差距全来自输入长度。20 万汉字的输入在按量里要实付 0.72 元，在按次里一分钱不用多付。
按次计费就是一次请求一个固定价。你发「你好」是 0.05 元；把 20 万字产品手册整篇贴进去问一个问题，还是 0.05 元。价格只跟「这次调哪一档模型」有关，跟塞进去多少内容无关。
这带来一个实用结果：提示词可以放心写长。不少人为了省 token 把 system prompt 压到几十个字，结果输出飘、格式老不对。按次计费下，你把 3000 字的规范、示例、格式要求全写进 prompt，价格依然是 0.05 元。
按量的算法只有一行：
钱 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价
代入具体数字：一次请求输入 5 万 token、输出 800 token，按输入 ¥3/百万、输出 ¥15/百万 算，输入部分 5 万 ÷ 100 万 × 3 = 0.15 元，输出部分 800 ÷ 100 万 × 15 = 0.012 元，合计 0.162 元。同一次请求走 grok-4.1 按次是 0.05 元，省 0.112 元，相当于 3.24 倍。
口径先说透，你才能自己复算：本文统一按 1 个汉字 ≈ 1.2 个 token。中文分词器不同，实际倍数落在 1~1.5 之间；英文单词和标点另算，一个英文单词往往比一个汉字略贵。
按 1.2 算：2 万汉字 ≈ 2.4 万 token，20 万汉字 ≈ 24 万 token。你若按 1.5 重算，按量成本会往上走 25% 左右，但「输入越长、按次越划算」的方向不变。
| 对比项 | 按次计费（小鱼API） | 按量计费（官方） |
|---|---|---|
| 计价单位 | 元/次 | 元/百万 token |
| 输入长度影响 | 完全不影响 | 线性增加 |
| 短请求（输入 800 token） | 0.05 元 | 约 0.0069 元 |
| 长请求（输入 20 万汉字） | 0.05 元 | 约 0.7275 元 |
| 账单可预测性 | 高，次数 × 单价 | 低，看每次输入多长 |
| 适合任务 | 长文档、长 prompt、批量处理 | 短问答、低频调用 |
盈亏平衡点能算出来：输出按 500 token 计，占掉 0.0075 元，剩 0.0425 元留给输入，0.0425 ÷ 3 × 100 万 ≈ 1.42 万 token ≈ 1.2 万汉字。单次输入超过约 1.2 万汉字，按次就开始更便宜；到 3 万汉字，按量要 0.108 元，按次 0.05 元，省掉一半以上。
4.1 是这一系列的日常主力：分类打标、字段抽取、文本改写、结构化输出都能稳定完成。每天 2000 次是 100 元一天，很多小项目就跑在这个预算里。
判断标准很简单：答案有明确对错的任务（抽金额、判情绪、转 JSON），4.1 够用，没必要付 0.09 元。
0.09 元换来的是更深的推理链路和更强的长上下文把握能力，具体差别有四处：
0.04 元很小，问题是它等于 0.05 元的 80%。一天 500 次就是 20 元，一个月 600 元。这 600 元是你为「可能更好」付出的确定成本，而好处是概率性的。所以决策逻辑应该是：先证明它确实更好，再决定长期付费。
拿合同审阅举例：5 万字合同走按量计费，5 万汉字 ≈ 6 万 token，输入部分 6 万 ÷ 100 万 × 3 = 0.18 元，比 4.1 的 0.05 元贵 3.6 倍。输入天然很长的任务，按次计费的优势体现得充分。
多轮推理要换个算法。一次任务平均 6 轮，4.1 一个任务 0.30 元，4.5 一个任务 0.54 元。若 4.1 有 20% 任务需重跑，实际成本 0.30 × 1.2 = 0.36 元；4.5 重跑率降到 5%，成本 0.54 × 1.05 = 0.567 元。4.5 仍更贵，除非把人工重跑的成本算进去。
实时信息类任务的成本结构不一样：价值衰减快，答晚了等于答错。这类任务优先用 4.6，你付的不是「更聪明」的钱，而是「更少出错、更少人工复核」的钱。如果这类请求占比很小，比如每天 200 次，升级成本是 0.04 × 200 × 30 = 240 元一个月，属于可接受的试错预算。
单价差 0.04 元，每天 500 次就是 20 元一天，一个月 600 元。总账单从 750 元涨到 1350 元，涨幅 80%。这个数接近很多个人项目的服务器成本，不能靠感觉决定。
同样是那 0.04 元，规模上来就变得刺眼：
到每天 10000 次这个量级，全量升级基本不成立，合理做法是分级路由：简单任务留在 4.1，只有难任务走 4.5 / 4.6。
| 每天请求数 | 4.1 月成本 | 4.5 / 4.6 月成本 | 月度差价 | 建议 |
|---|---|---|---|---|
| 100 次 | 150 元 | 270 元 | 120 元 | 试错成本低，可直接升 |
| 500 次 | 750 元 | 1350 元 | 600 元 | 先跑 A/B 再定 |
| 2000 次 | 3000 元 | 5400 元 | 2400 元 | 必须 A/B 后再决定 |
| 10000 次 | 15000 元 | 27000 元 | 12000 元 | 分级路由，不要全量升 |
下面这段脚本把单价、日调用量、token 口径都做成变量，换成你的真实数字跑一次，几秒出结果：
# grok_price.py —— 按次 vs 按量的成本对比
PER_CALL = {"grok-4.1": 0.05, "grok-4.5": 0.09, "grok-4.6": 0.09}
IN_PRICE = 3.0 / 1_000_000 # 元/token，输入参考价
OUT_PRICE = 15.0 / 1_000_000 # 元/token，输出参考价
DAYS = 30
def meter_cost(zh_chars, out_tokens, tokens_per_char=1.2):
"""按量计费：输入字数 + 输出 token"""
return zh_chars * tokens_per_char * IN_PRICE + out_tokens * OUT_PRICE
def month_cost(model, calls_per_day, days=DAYS):
"""按次计费：次数 × 单价 × 天数"""
return PER_CALL[model] * calls_per_day * days
calls = 500
metered = meter_cost(zh_chars=200000, out_tokens=500)
print("长请求按量：%.4f 元/次" % metered) # 0.7275
for m in PER_CALL:
print("%s 按次：%.2f 元/次，月 %d 次 = %.0f 元"
% (m, PER_CALL[m], calls * DAYS, month_cost(m, calls)))
delta = (PER_CALL["grok-4.5"] - PER_CALL["grok-4.1"]) * calls * DAYS
print("升级 4.5 的月度差价：%.0f 元" % delta) # 600 元跑出来是：按量 0.7275 元一次，4.1 月账单 750 元，4.5 / 4.6 是 1350 元，差价 600 元，和前面手算一致。
接入方式和官方接口一致，只把 base_url 指向小鱼API：主线路 https://xyuapi.top/v1，备用线路 https://xyuai.cc/v1。模型名填短名即可：grok-4.1、grok-4.5、grok-4.6，不带任何前缀或版本后缀。
已写了 OpenAI 兼容代码的项目，改动量就是一行字符串；切换档位只需换 model 字段。
curl https://xyuapi.top/v1/chat/completions \
-H "Authorization: Bearer $XYU_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "grok-4.1",
"messages": [
{"role": "user", "content": "用一句话说明按次计费和按量计费的区别"}
],
"temperature": 0.7
}'把 grok-4.1 换成 grok-4.5 或 grok-4.6，其他一个字不用改，就能直接对比三档输出。
起步充值 7 元就够用：7 ÷ 0.05 = 140 次 grok-4.1，或 7 ÷ 0.09 ≈ 77 次 grok-4.5，足够把 A/B 对比跑好几轮。
预算按「先小额验证、再放量」走：先用 7 元把接入和 A/B 跑通，确认选型稳定后，再按上表估出的月度成本充值，留 20% 余量应对重跑。
从真实流量里挑 100 条，不要用自己编的测试题：
| 评测维度 | 权重 | 差距达到多少才值得升级 |
|---|---|---|
| 答案正确性 | 40% | 明显更高即可，这是硬指标 |
| 格式稳定性 | 20% | 需要能省掉一次返工 |
| 长输入表现 | 20% | 长任务上的差距要明显 |
| 响应时延 | 20% | 不能明显变慢 |
门槛建议定成：正确性和格式稳定性必须有可见提升，否则不升。只是「感觉回答更漂亮」而正确率没变化，那 0.04 元差价就是纯支出。
先给 10% 流量走高价位模型，观察一周再决定放量：
# ab_router.py —— 10% 流量走 grok-4.5，其余走 grok-4.1
import hashlib
HIGH_END = "grok-4.5"
BASE = "grok-4.1"
def pick_model(user_id: str, high_end_ratio: float = 0.10) -> str:
bucket = int(hashlib.md5(user_id.encode()).hexdigest()[:8], 16) % 100
return HIGH_END if bucket < high_end_ratio * 100 else BASE
# 同一个 user_id 永远落到同一档，避免同一用户体验来回跳
print(pick_model("user-10086"))好处是：不用全量压测就能拿到真实对比数据，同一用户始终落在同一档，出问题也容易回溯。
grok-4.1 是不是比 4.5 慢很多？ 延时要自己测：在 A/B 的 100 条样本里同时记录首字时间，用实测数据决定能否接受。
三档之间要全量升级吗？ 不需要。多数项目的合理状态是：八成流量走 grok-4.1，两成难任务走 grok-4.5 / 4.6，既保住成本，又让难任务拿到更好结果。