Wisdom SSH：使用AI助手对话中tokens用量的计算方式

在使用AI助手（包括ChatGPT、Claude、Wisdom SSH等）时，理解tokens的计算方式对于成本控制和效率优化至关重要。本文将深入探讨tokens的基本概念、对话上下文的记忆机制，以及如何通过合理选择上下文长度来实现成本效益的最大化，这些原理适用于所有基于大语言模型的AI应用。

一、大模型的tokens单位

什么是 token？

token 是模型眼里最小语义切片，既非字母也非单词，而是分词器按概率切出的“原子”。同一段文本，在不同模型下可能长出完全不同的 token 序列——这就是计费差异的根源。

估算方式（含空格与标点）

• 英文：1 字符 ≈ 0.3 token
• 中文：1 汉字 ≈ 0.6 token
• 混合代码：看关键词密度，长变量名可被拆成 3-5 token

简单理解：同样 1 000 汉字≈600 token，而 1 000 英文字符≈300 token；写英文提示词天然省一半。

Tokens与成本的关系

大模型服务的计费通常基于一次请求中实际产生的“输入”与“输出”两部分tokens。
“输入”指用户端发给模型的全部内容（系统提示、历史对话、当前提问、文档、代码等）经分词后的总量；“输出”指模型返回的完整回复经分词后的总量。两者相加即为总tokens，直接决定本次API调用的成本。

• 输入tokens：用户发送给模型的文本占用的tokens
• 输出tokens：模型生成回复占用的tokens
• 总tokens：输入+输出，决定了API调用的成本

二、大模型的记忆：对话上下文

对话上下文的工作原理

AI 助手的“记忆”并不是像人类那样把信息写进长期记忆，而是每一次请求都把前面所有对话内容重新打包发给模型，让模型在“这一次”里重新“看到”完整上下文。换句话说，所谓“记住”只是把历史对话一次性塞进新的输入，模型本身不会在两轮请求之间保留任何状态。
因此，对话越长，每次请求要携带的文本就越多，占用的 tokens 也线性累加；一旦上下文长度超过模型上限，最早的那部分就会被截断或丢弃，表现为“忘记”。

上下文累积机制：

• 第1轮：用户提问 → 模型回复（上下文=第1轮）
• 第2轮：用户提问 → 模型回复（上下文=第1轮+第2轮）
• 第3轮：用户提问 → 模型回复（上下文=第1轮+第2轮+第3轮）
• 第n轮：包含前面所有轮次的完整对话历史

技术实现：

• 每次对话请求都会发送完整的对话历史
• 模型基于完整上下文理解当前问题
• 回复质量随着上下文增加而提升
• tokens用量随着对话轮次线性增长

上下文对tokens的影响

对话越长，tokens线性叠加；早期内容被反复计费，5轮即可翻5倍。

关键影响：

• 早期轮次的对话会被重复计算多次
• 长对话的tokens成本呈线性增长
• 上下文管理是成本控制的关键

三、节省tokens：选择合适的上下文长度

上下文长度选项

大模型自身的上下文容量是有限制的，目前主流的模型基本都已支持到128K。Wisdom SSH的AI助手在使用这些模型时，为用户提供了多个上下文长度选项：

32K上下文：

• 最大tokens数：约32,000
• 适用场景：简短对话、单一任务
• 成本效益：最高，单位tokens成本最低
• 优势：响应速度快，成本低
• 限制：长对话需要频繁截断

64K上下文：

• 最大tokens数：约64,000
• 适用场景：中等复杂度任务、多轮对话
• 成本效益：平衡，适中的单位成本
• 优势：支持较长对话，性价比好
• 限制：极长对话仍需管理

128K上下文：

• 最大tokens数：约128,000
• 适用场景：复杂任务、长文档分析
• 成本效益：较低，单位tokens成本较高
• 优势：支持超长对话和复杂分析
• 限制：成本高，需要谨慎使用

上下文管理策略

智能截断机制：

• 当对话接近上下文限制时，Wisdom SSH会采用智能压缩策略，保护任务流畅执行
• Wisdom SSH使用可追溯的压缩策略，必要时可追回
• Wisdom SSH智能压缩分为一级压缩与二级压缩，榨干可以上下文空间

三、总结

不同用户在使用AI助手时形成了各自的偏好模式。有的倾向于从较小上下文开始，逐步扩展；有的发现分段处理长文档比一次性发送更加高效；还有的在实践中观察到，对话累积到一定程度后，新开对话重新梳理往往能获得更清晰的回应。这些使用模式反映出，理解tokens计算机制后，用户能够根据自身需求和习惯，找到最适合的使用节奏。