免费Token额度不等于真实算力：五个被误解的假象

模型排行榜泛滥，人人都看腻了。与其争论哪个榜单更权威，不如换一种方式：用一份可对照的账本（ledger），把「免费额度」拆开看。

MonkeyCode 是一个开源项目，提供免费模型访问和免费服务器选项，运营方声明有 1000 万 token 的免费额度（声明：本文为 MonkeyCode 产品外联内容）。下面不谈未公开的模型名、硬件规格或吞吐数字——那些没有来源就不编。可以给的是一个探针脚本，以及它能戳破的五个假象。

为什么账本比仪表盘更可信

仪表盘只给你一个数字，而数字不是证据。你真正需要的是数字背后的原始请求和响应：状态码、token 计数、重试次数、哈希值。这些才是完整的凭证。

探针：一个文件、三条提示、九次调用

ledger_probe.py 是一个示意性脚手架，本文不报告任何实测结果。它做三件事：向 OpenAI 兼容端点发三次提问，每次最多重试三次（指数退避），温度固定为 0，每条记录写入 ledger.jsonl。

**OpenAI 兼容端点**指的是遵循 OpenAI Chat Completions API 请求/响应格式的 HTTP 接口。它通常以 `/chat/completions` 为路径，接受 `model`、`messages`、`temperature` 等字段，并在成功时返回 `choices` 数组和 `usage` 计数（`prompt_tokens`、`completion_tokens`）。许多自建推理框架（如 vLLM、Ollama、LM Studio）和云厂商都会提供这一兼容层，以便现有客户端无需改动即可切换。对本文的方法论而言，这个兼容层很关键：只要端点行为一致，同一份探针脚本就能在任意提供商之间复用来做对账，而不会被专有 SDK 或私有协议绑定。

**温度（temperature）** 是采样参数，用于调节输出分布的随机程度。数值越低，模型越倾向选择概率最高的 token；设为 0 通常表示贪心解码，即在每一步取最大概率项。但“温度为 0”并不等价于“结果唯一”：批处理调度、浮点非确定性、混合专家路由、量化误差以及提供商后台的重新部署，都可能让相同输入产生不同输出。正因如此，探针把温度固定为 0 只是减少一个变量，真正判断确定性还得靠对补全结果做哈希比对，而不是依赖这个参数本身。
# ledger_probe.py — 示意性脚手架，本文不报告实测结果
import json, os, time, uuid, hashlib
from pathlib import Path
import httpx

BASE  = os.environ["LLM_BASE_URL"]   # 任意 OpenAI 兼容端点
KEY   = os.environ["LLM_API_KEY"]
MODEL = os.environ["MODEL_ID"]       # 从项目自己的列表里取

LEDGER = Path("ledger.jsonl")

PROMPTS = [
    "Reply with the single word: ok",
    "Count the letters in 'strawberry'. Show only the number.",
    "Return strict JSON: {\"n\": 1, \"unit\": \"token\"}",
]

def call(prompt, attempt):
    body = {"model": MODEL, "temperature": 0,
            "messages": [{"role": "user", "content": prompt}]}
    started = time.perf_counter()
    r = httpx.post(f"{BASE}/chat/completions", json=body, timeout=60,
                   headers={"Authorization": f"Bearer {KEY}"})
    elapsed = (time.perf_counter() - started) * 1000

    rec = {
        "probe_id": str(uuid.uuid4()),
        "attempt": attempt,
        "status": r.status_code,
        "latency_ms": round(elapsed, 1),
        "prompt_sha256": hashlib.sha256(prompt.encode()).hexdigest()[:12],
    }

    if r.status_code == 200:
        data = r.json()
        usage = data.get("usage") or {}
        rec["prompt_tokens"] = usage.get("prompt_tokens")
        rec["completion_tokens"] = usage.get("completion_tokens")
        text = data["choices"][0]["message"]["content"]
        rec["completion_sha256"] = hashlib.sha256(text.encode()).hexdigest()[:12]

    with LEDGER.open("a") as fh:
        fh.write(json.dumps(rec) + "\n")
    return rec

for prompt in PROMPTS:
    for attempt in range(1, 4):
        rec = call(prompt, attempt)
        if rec["status"] == 200:
            break
        time.sleep(2 ** attempt)   # 免费层会限流，要提前规划

为什么用哈希？因为「能用」不是一种度量。哈希要么重复，要么不重复。

对账步骤

reconcile.py 读取属于你自己的账本，而不是厂商租给你的仪表盘：

# reconcile.py — 读你自己的账本，不是租来的仪表盘
import json, collections

rows = [json.loads(line) for line in open("ledger.jsonl")]
ok   = [r for r in rows if r["status"] == 200]

print("requests:", len(rows), "ok:", len(ok), "retries:", len(rows) - len(ok))
print("prompt_tokens:    ", sum(r.get("prompt_tokens", 0) for r in ok))
print("completion_tokens:", sum(r.get("completion_tokens", 0) for r in ok))

hashes = collections.Counter(r["completion_sha256"] for r in ok)
print("distinct completions:", len(hashes))
print("most common:", hashes.most_common(3))

跑一遍，你就握有了一张收据。

假象一：1000 万免费 token 就是 1000 万有效 token

不对。你的提示词开销会先一步吃掉这笔赠额。每次重试都会重新发送输入——系统提示、工具 schema、检索到的上下文，全都按输入计费。一个臃肿的提示上做三次重试，输入开销可以翻三倍。在固定额度下，重试并不免费。

正确的模型是：有效输出只是赠额的一部分。在规划容量之前，先测你的重试率。

假象二：回答过一次，它就具有确定性

单次样本几乎说明不了不方差问题。同一个问题问五次，对每次补全做哈希，数一数有多少个不同的哈希。

即便温度设为 0，你也可能看到漂移——来自重新部署、量化构建或路由切换。

正确的模型是：锁定一个模型版本，记录哈希，并在每次提供商变动后重新跑探针。

假象三：免费就等于无限并发

免费层会限流。这很正常，也没问题。真正危险的是静默失败：一个 429 被记成「error」，然后在循环里无限重试。

要记录状态码，撞到限流就停，别去砸一扇刚关上的门。

• 200：记录 token 和哈希
• 429：记录、退避、限制尝试次数
• 5xx：记录、退避、限制尝试次数
• 其他 4xx：大声失败，不要重试

正确的模型是：免费访问是一份带调速器的预算，不是一根无限管道。

指数退避（exponential backoff） 是一种重试节奏：每次失败后等待时间按倍数增长，例如 2、4、8 秒，并可加入随机抖动以避免多个客户端同时重试造成拥塞。它适合应对 429（限流）和 5xx（服务端临时故障），因为这些错误往往随时间自愈。但退避不是万能药：对 4xx 中的鉴权失败、请求非法等错误重试只会浪费额度并掩盖问题，所以探针脚本对重试次数设了上限，并把每次尝试都写入账本，让“重试”本身成为可计量的成本，而不是隐藏的开销。

假象四：免费服务器上的运行等于你本地的运行

那是另一台机器、另一个时钟，也可能另一个镜像。环境漂移是最安静的 bug。你的笔记本跑 Python 3.12，那台机器未必。

所以要固定你能控制的东西：lockfile、容器 digest，以及导出的环境块。把那个环境块写进同一份账本，就放在 token 旁边。

正确的模型是：免费服务器是一个复现结果的地方，不是一个假定结果成立的地方。

假象五：厂商计数器就是收据

厂商统计的是它网关看到的东西，你统计的是你的客户端真正发出的东西。当代理重试、流中断、或请求根本没落地时，这两个数字就会分叉。

两边都要对账。如果差距超过几个百分点，就去查清楚为什么。

正确的模型是：两个独立计数器、一个刻意无聊的脚本，再加上一段关于差值的书面说明。

双计数器对账之所以必要，是因为计费口径和客户端观测口径存在系统性差异。厂商统计的是请求到达其网关之后的 token 数，而客户端统计的是自己发出的内容。中间的代理、SDK 重试、流式响应中断、连接超时、负载均衡重放，都可能让两边分叉：一次请求可能在客户端只记录为一次，却在网关侧被计为多次；反之流式传输中断时，厂商可能已按部分输出计费而客户端只看到错误。定期对比两边的 token 总量并记录差值说明，是发现这类静默偏差最直接的手段。

一个决策表

问题	免费层够用	迁出免费层
原型、低量级	是	—
固定提示集的夜间 CI	是，需限制尝试次数	如果重试超过上限
面向客户的延迟承诺	否	是
数据驻留要求	否	是
长上下文批处理任务	先测，再量	如果输入成本占主导
任何你无法重跑的东西	否	是

谁不该用这套方法

开始之前先对自己诚实。

• 今天就需要延迟 SLA 的人。免费层不是 SLA。
• 有数据驻留或保留规则约束的团队。先读那些规则。
• 不会去读提供商限制页面的人。你会猜错。
• 把免费赠额当成永久容量的人。它只是一个起点。

免费额度是一个了解成本形状的地方，不是一份容量规划。

我不会掩饰的局限

本文没有核实当前额度、模型列表或服务器规格，请以项目自身文档当天的数字为准。配额会变，上个月写的账本不知道今天的限制。上面的脚手架是示意性的，本文不报告基准测试结果，因为作者没有运行过已发布的基准。

先测试，再信任

先写账本，再争模型。

如果你想不绑卡就试这套脚手架，免费模型访问和免费服务器选项是相关的入口。在规划任何事之前，先读项目自己的页面上的当前限制。

然后跑三条提示，数哈希，对 token。哪一个假象最先在你面前倒下？