词元Token

发送这条消息前，模型会收到多少词元

先看真实聊天输入和本轮请求票据：文字会被切成编号词元，System、历史和草稿一起占用同一个窗口，也一起进入输入账单。

从票据里记住四件事

面板已经把关系画在同一张请求票据上，这里只给它们命名。

• 模型读词元，不直接读字或单词：票据上的每张编号小票就是一个输入词元；长英文可能拆成子词，中文常按单字或短片段切。
• 切法取决于 tokenizer：同一段文字在不同模型上可能得到不同数量，最终应以目标模型的官方计数器或 API 为准。
• 整次请求一起计数：System、工具结果、历史对话和本轮草稿都会占窗口；“带上上一轮”会让历史行与合计同时增加。
• 账单和窗口都看词元：输入词元乘单价得到输入成本，并与上下文上限比较；输出词元通常另计。

什么时候先数词元

看到这些信号时，不要再凭字数猜。

• 准备发送长文档、多轮聊天或大段工具结果，担心撞到上下文上限。
• 同样的请求换成中文、代码或罕见术语后，账单和延迟突然上涨。
• 要比较删历史、做摘要或压缩 prompt 到底省了多少预算。
• 不适合只看词元：回答是否正确仍要靠评测，词元少不等于质量高。

怎么估一轮请求

从真实载荷走到可发送判断，只要四步。

1. 拿目标模型的 tokenizer 统计 System、历史、工具结果和本轮输入，不只数文本框。
2. 把输入合计与上下文上限比较，同时给预期输出留出余量。
3. 输入词元 × 输入单价，预估输出词元 × 输出单价，两项相加才是整轮成本。
4. 超预算时先删噪音、摘要历史或分块；重新计数后再发送。

同一条发布说明，只差有没有数完整请求

目标不变，只改变计数范围。