GPT 上下文与 Token 计数：如何在撞墙之前算清楚用量

把「字符数」当成「token 数」是用 LLM API 烧钱最快的方式。 模型按 token（子词片段）计费与截断，它和单词、标点、代码块的长度没有线性关系。你把 1.2 万字符的提示词发给标称 8k 上下文的模型，不是「差不多」，而是已经超限。

本文说明 token 是什么、不同模型的上下文如何分配、多语言与代码提示词为何容易超预期，以及如何用 Safe Local Tools 在浏览器本地计数——密钥与客户文本不必上传到第三方。

Token 到底是什么（为什么不是「一个字」）

大模型推理时不会直接吞整段 Unicode，而是先用 分词器（tokenizer） 切成整数序列。每个整数对应一个片段：可能是完整词、词根，也可能是和标点粘在一起的符号。

OpenAI 等厂商会为不同模型世代使用不同编码（如 cl100k_base 及后续版本）。同一句话，两套分词表可能差几个百分点——产品若写「剩余 token」，应标明是精确值还是估算。

上下文窗口：输入、输出与「预留」

宣传里的 32k、128k、200k 是总容量，实际要拆成：

占用部分	典型来源
系统 / 开发者指令	每次请求固定开销
RAG 检索片段	往往最大头
用户多轮对话	历史会累积
工具 / 函数定义	JSON Schema 很吃 token
模型回复	你设置的 max_tokens

很多提供商里，输出 token 也占同一窗口。标 120k 的模型若预留 8k 给回答，提示词侧实际只剩约 112k。

还要留余量：停止符、推理模型的内部链、失败重试导致的历史重复发送。

为什么字数、词数都不靠谱

1. 代码：缩进与大括号会成簇出现。
2. JSON / YAML：重复键名与引号各自占 token。
3. 非拉丁文字：字符少不等于 token 少。
4. 日志堆栈：视觉上冗长，计费上更冗长。

客服场景里，用户粘贴的 Base64 或十六进制 дамп 是经典「看起来不长、账单很长」案例。

不同模型族：计数不能混用

• OpenAI GPT‑4 系列：文档与社区工具较全。
• Anthropic Claude：独立分词；「约 3.5 字符 / token」只是英文粗估。
• 开源模型（Llama、Mistral 等）：各自 SentencePiece / BPE。
• Embedding 模型：窗口常与对话模型不同。

UI 可展示估算，财务对账要靠 API 返回的 usage.prompt_tokens 与本地计数定期比对。

上线前检查清单

1. 统计 完整请求体（系统 + 工具 + 全部消息），不是最后一条用户话。
2. 尽量用 目标模型对应的分词器。
3. 从标称窗口减去计划中的 完成 token。
4. RAG 场景先控制检索块大小，再塞进提示词。
5. 每周对比本地估算与账单差异，查 schema 变长、多语言文案等异常。

超窗后的裁剪策略

避免对字符串盲目 slice(0, N)：

• 摘要较早轮对话，写入滚动记忆。
• 丢弃中间历史（保留最初目标 + 最近 k 轮）。
• 缩小工具输出——日志应进对象存储，不应整段进聊天。
• 重切块文档，控制重叠，而不是整份 PDF 原文硬塞。

成本、延迟与失败率同源

token 多 → 钱多花、首 token 更慢、context_length_exceeded 更常见。本地计数是廉价熔断器：按钮点下去之前 UI 先变红，比排队失败省得多。

隐私：为何强调本地计数

第三方演示站方便，但不适合：

• 病历、合同、事故日志里的密钥
• 未发布文案
• 安全事件原始载荷

Safe Local Tools 在客户端分词，应急排障时少一个「又把数据交给 SaaS」的合规项。

2026 年仍常见的团队误区

1. 只数用户最后一句话，忽略线程已膨胀。
2. 忽略每次请求都带上的 工具定义。
3. 用英文 heuristic 估中文 prompt。
4. 换模型后不重新校验缓存的 token 数。
5. 营销写「无限对话」，API 硬 cap。

本周可加的观测

• 每次调用打点 prompt_tokens、completion_tokens、model。
• p95 提示词超过默认模型窗口 70% 时告警。
• 看板：本地估算 vs 账单差异。
• Feature flag：本地超阈值则禁止发送。

示例：客服 copilot 如何算账

16k 窗口、预留 2k 给回答。已有：系统策略 1.5k、检索知识库 6k、工单线程 3k、工具 schema 1k → 合计 11.5k，用户新问题尚未写入。应在调用 API 之前 先压缩线程或减少检索，而不是等报错再处理。

多模型网关下的计数

若抽象了 OpenAI、Anthropic、自建模型，应在网关透传上游返回的 usage，而不是在网关用另一套分词器重算——否则财务对账与限流都会漂移。

流式输出与中途停止

流式回复的 completion token 会持续累加，直到流结束。UI 应实时显示已用 token，便于用户在费用失控前点击停止。

收尾

Token 算术枯燥，直到账单教会你。习惯用对的分词器测全量出站载荷、给完成留余量、把检索算进 prompt。

要在不上传的前提下对照多种模型编码试算草稿，试用 AI Token 计数器 →