一、前言
想象你走进一家餐厅，菜单上写着"按食材重量计费"。你点了一碗面，但结账时发现：面条、汤底、葱花全都算重量，而且不同食材单价不同。大模型的 Token 计费，本质上就是这么回事。
大模型 （Large Language Model, LLM）是经过海量文本训练的 AI 系统，能理解和生成人类语言。GPT、Claude、Gemini、DeepSeek 都属于此类。Token 则是大模型处理文本的最小单位------不是字，不是词，而是介于两者之间的一种"语言积木"。模型读取你的输入、生成回复，都是以 Token 为单位来计算和计费的。
为什么理解这些概念很重要？因为它直接影响三件事：
- 成本 --- 不同模型的 Token 单价差距可达 60 倍以上
- 选型 --- 上下文窗口大小决定了模型能"记住"多少内容
- 使用体验 --- 理解对话本质，才能更高效地使用 AI 工具
本文将从四个维度展开：对话的本质是什么 、上下文有什么限制 、Token 怎么计费 、主流编程模型怎么选。无论你是刚接触 AI 的新手，还是正在做技术选型的开发者，都能找到需要的答案。
二、模型的对话指的是什么
2.1 对话的本质
和大模型"聊天"看起来像跟真人对话，但底层机制完全不同。每一轮对话的本质是一次单向的请求-响应：
你发送一段文本（Prompt） → 模型处理 → 模型返回一段文本（Response）
就像发邮件一样，模型没有"持续思考"的状态。它每次都是拿到你的完整输入，从头开始理解，然后一次性生成回复。这意味着每一轮对话都是一次独立的 API 调用，模型本身并不会"记住"之前聊了什么。
2.2 Token 是什么
Token 是模型处理文本的基本单位。你可以把它理解为语言积木------模型把文本拆成一块块积木来处理，而不是一个字一个字地读。
不同语言的切分方式不同：
- 英文 ：大致 1 个单词 ≈ 1-2 个 Token。
"Hello world"→["Hello", " world"]= 2 Token - 中文 ：大致 1 个汉字 ≈ 1.5-2.5 个 Token。
"你好世界"→["你", "好", "世", "界"]约 4-8 Token
关键认知：中文消耗的 Token 显著多于英文。 同样的语义内容，中文输入可能比英文多消耗 50%-100% 的 Token，这直接影响使用成本。
想亲自体验？可以用 OpenAI 的 Tokenizer 可视化工具 试试，把中英文分别粘贴进去对比。
2.3 对话 vs 会话（Session）
日常使用中，你在 Claude 或 GPT 里的一个"聊天窗口"就是一个会话（Session） 。每发送一条消息就是一轮对话。
关键问题在于：每一轮对话，模型都要重新读取整个会话历史。
举个例子：
| 轮次 | 你发送的内容 | 模型实际处理的 Token |
|---|---|---|
| 第 1 轮 | "帮我写个排序函数" | 你的消息（约 20 Token） |
| 第 2 轮 | "改成降序" | 第 1 轮完整对话 + 你的新消息（约 300 Token） |
| 第 3 轮 | "加上注释" | 前 2 轮完整对话 + 你的新消息（约 600 Token） |
| 第 10 轮 | "还有问题吗？" | 前 9 轮完整对话 + 你的新消息（可能几千 Token） |
这就是为什么聊得越久花费越高------Token 是累积计费的。每一轮对话的成本都包含了之前所有历史消息的 Token。
三、模型的对话上下文限制
3.1 什么是上下文窗口（Context Window）
上下文窗口是模型的**"工作记忆"容量**------它能同时处理的 Token 总量上限。这个上限包含输入和输出的所有 Token。
打个比方：上下文窗口就像一张书桌。桌子越大，能同时摊开的资料越多。128K 上下文约等于一本 300 页的书，1M 上下文则约等于 7-8 本书。
3.2 主流模型上下文对比
| 模型 | 标准上下文 | 扩展上下文 | 备注 |
|---|---|---|---|
| Claude Opus/Sonnet 4.6 | 1M | - | 原生支持，无需额外配置（2026.3.13 GA） |
| GPT-5.4 | 272K | 1.05M | 需显式开启扩展窗口 |
| GPT-5.2 | 400K | - | |
| Gemini 3 Pro | 1M | - | 原生支持，长上下文最强 |
| DeepSeek V3 | 128K | - | |
| Kimi K2.5 | 256K | - | 长上下文特长 |
| GLM-5 | 200K | - | |
| MiniMax M2.5 | 200K | 架构支持 1M | |
| Qwen 3.5 | 256K | 1M（Plus 版本） |
注：Claude 4.6 的 1M 上下文于 2026 年 3 月 13 日正式 GA（General Availability），公告链接。
3.3 上下文满了会怎样？
当对话 Token 累积接近或超过上下文窗口时，模型需要某种策略来处理。以下是常见的 6 种方式：
| 处理方式 | 说明 | 适用场景 |
|---|---|---|
| 自动截断 | 丢弃最早的消息，保留最近的 | 简单聊天场景 |
| Auto-compact | 自动压缩/总结历史对话 | Claude Code 等开发工具 |
| 滑动窗口 | 保留最近 N 轮对话，丢弃更早的 | API 调用常见策略 |
| 摘要压缩 | 将历史对话总结为摘要，替换原文 | 长对话场景 |
| 手动分段 | 用户主动开启新会话，手动传递上下文 | 复杂任务、精确控制 |
| RAG 检索 | 历史存入向量库，按需检索相关内容 | 企业级应用 |
不同产品和 API 采用的策略不同。以开发者常用的 Claude Code 为例，它采用了一套多层递进压缩策略 （参考 learn-claude-code 项目的解析）：
- 微压缩（Micro Compact） --- 每一轮自动静默执行，将超过 3 轮的旧工具调用结果替换为简短占位符（如
[Previous: used read_file]），不需要调用模型，纯规则替换 - 自动压缩（Auto Compact） --- 当 Token 数接近上下文窗口上限时触发（Claude Code 在约 92% 时触发），由模型对整段对话生成结构化摘要，替换掉旧的完整历史
- 手动压缩（/compact 命令） --- 用户主动触发，不必等到自动阈值，适合在关键节点主动释放空间
这套"先规则替换、再模型摘要"的递进设计，在不丢失关键信息的前提下尽可能延长了可用的对话长度。对于 API 开发者来说，滑动窗口和摘要压缩是最常用的两种方案，可以根据业务场景灵活选择。
四、Token 的计费
4.1 计费模型解析
大模型 API 的计费很直接：按 Token 数量收费，输入和输出分开计价。
- 输入 Token（Input）：你发给模型的内容，包括系统提示词、历史消息、当前问题
- 输出 Token（Output）：模型生成的回复内容
为什么输出比输入贵？因为输入阶段是并行处理（模型一次性读取所有 Token），而输出阶段是逐个 Token 生成，每一步都需要独立的推理计算。通常输出价格是输入的 3-5 倍。
计费单位统一为每百万 Token（$/MTok 或 ¥/MTok）。
4.2 主流编程模型价格对比
| 模型 | 输入 ($/MTok) | 输出 ($/MTok) | 上下文 | 特点 |
|---|---|---|---|---|
| Claude Opus 4.6 | $5 | $25 | 1M | 最强能力，全窗口统一价 |
| Claude Sonnet 4.6 | $3 | $15 | 1M | 平衡之选，全窗口统一价 |
| GPT-5.4 | $1.75 | $14 | 272K / 1.05M | >272K 加价 2x / 1.5x |
| GLM-5 | 参见官方定价 | - | 128K | 近期涨价 30%+ |
| Kimi K2.5 | $0.45 | $2.20 | 256K | 缓存命中率高达 90% |
| MiniMax M2.5 | $0.30 | $1.20 | 1M | 仅 Claude Opus 的 1/63 |
| DeepSeek V3 | $0.28 | $0.42 | 128K | 极致性价比 |
数据来源：Anthropic 定价、OpenAI 定价、Gemini 定价、GLM 定价、Kimi K2.5 (OpenRouter)、MiniMax 定价
差距有多大？用 Claude Opus 处理 100 万 Token 输出需要 <math xmlns="http://www.w3.org/1998/Math/MathML"> 25 ，换成 D e e p S e e k V 3 只要 25，换成 DeepSeek V3 只要 </math>25，换成DeepSeekV3只要0.42------相差近 60 倍。当然，能力和价格往往成正比，选型要看具体场景。
4.3 省钱技巧
Prompt Caching（提示缓存）
大部分平台支持缓存重复的输入内容（如系统提示词）。缓存命中时，该部分 Token 可享受最高 90% 折扣。如果你的应用有固定的系统提示词，这是最直接的省钱方式。
Batch API（批量接口）
对于不需要实时返回的任务（如批量翻译、数据标注），使用 Batch API 可享受 50% 折扣。代价是响应时间从秒级变为分钟到小时级。
选择合适的模型层级
不是所有任务都需要最强的模型：
- 简单任务（格式转换、摘要、分类）→ Haiku / Flash / 小模型
- 复杂任务（代码生成、推理、创作）→ Opus / Pro / 大模型
Auto Router（智能路由）
Auto Router 根据任务复杂度自动选择模型层级，让简单任务走便宜模型、复杂任务走强模型。Claude Code 社区有一个热门项目 claude-code-router（26.4k+ Star），可实现最高 80% 成本节省。
但 Auto Router 也有明显的缺点需要注意：
- 路由误判 --- 复杂任务可能被分配到弱模型，导致质量下降
- 响应一致性差 --- 同一轮对话中可能切换模型，风格/质量不统一
- 额外延迟 --- 路由决策本身需要时间
- 调试困难 --- 出了问题不确定是模型的问题还是路由的问题
适合场景：对成本敏感、能接受偶尔质量波动的个人开发者或非关键业务。
4.4 长上下文的额外成本
使用大上下文窗口时，部分厂商会收取溢价：
| 厂商 | 阈值 | 超出后定价 |
|---|---|---|
| Anthropic (Claude 4.6) | 无阈值 | 全窗口统一价格（2026.3.13 起） |
| OpenAI (GPT-5.4) | >272K | 输入 2x，输出 1.5x |
| Google (Gemini) | >200K | 2x |
Claude 4.6 取消长上下文加价是一个重要变化。 此前使用超长上下文往往意味着额外的成本，现在 Claude 的 1M 全窗口统一定价，意味着你用 10K Token 和用 900K Token 的单价完全一样。对于需要处理大量代码、长文档的开发者来说，这是实实在在的成本优势。
五、模型的优劣势对比
5.1 如何评估模型
选模型不能只看厂商宣传。以下是值得参考的权威评测资源：
什么是 Benchmark？
Benchmark 是标准化的测试集，用来量化模型在特定任务上的能力。常见的有：
- SWE-Bench --- 软件工程能力评测，给模型真实的 GitHub Issue，看它能不能修好 Bug
- MMLU --- 多学科知识考试，覆盖数学、科学、人文等 57 个学科
- GPQA --- 研究生难度的科学推理题
推荐的评测站点：
| 类型 | 站点 | 说明 |
|---|---|---|
| 综合评测 | Artificial Analysis | 综合评分、价格、速度、延迟一站式对比 |
| 综合评测 | LM Council | 多维度 Benchmark 对比 |
| 综合评测 | LLM Stats | 排行榜汇总 |
| 代码能力 | Vellum | 代码能力专项评测 |
| 代码能力 | SWE-Bench | 软件工程能力评测（官方） |
为什么需要第三方评测？厂商的自有评测往往在自己擅长的任务上做文章，第三方的统一标准更能反映真实水平。
5.2 编程能力对比
对于开发者最关心的编程能力，以下是 SWE-Bench 榜单的关键数据：
| 模型 | SWE-Bench Verified | 编程特点 |
|---|---|---|
| Claude Opus 4.6 | 80.8% | 代码质量高，Agent 能力强，擅长复杂重构 |
| MiniMax M2.5 | 80.2% | 性价比极高，性能接近顶级但价格仅为 1/60 |
| GPT-5.4 | 77.2%* | 生态成熟，IDE 插件丰富，Computer Use 能力强 |
| GLM-5 | 77.8% | 逻辑推理强，中文编程场景友好 |
| Kimi K2.5 | 76.8% | 多模态能力突出，可根据截图生成代码 |
| DeepSeek V3.2 | 73.0% | 开源标杆，可本地部署 |
数据来源：SWE-Bench 排行榜、vals.ai 独立评测。*GPT-5.4 分数来自 vals.ai 独立测试，OpenAI 已转向 SWE-Bench Pro 指标（57.7%）。
数字只是一部分。在实际使用中，Claude 在长上下文代码理解 和 Agent 工作流 方面表现突出；GPT-5.4 的核心升级在 Computer Use 和工具调用 方向，编码能力较 5.2 有小幅提升；DeepSeek 作为开源模型可以本地部署，适合对数据隐私有要求的场景。
5.3 如何选型
不要问"哪个模型最好"，要问"哪个模型最适合我的场景"。以下是一些常见场景的选型思路供参考：
编程场景
- 追求质量 → 例如 Claude Opus 4.6（SWE-Bench 80.8%）、GPT-5.4（生态成熟）
- 追求性价比 → 例如 MiniMax M2.5（80.2%， <math xmlns="http://www.w3.org/1998/Math/MathML"> 0.30 / 0.30/ </math>0.30/1.20）、DeepSeek V3.2（ <math xmlns="http://www.w3.org/1998/Math/MathML"> 0.28 / 0.28/ </math>0.28/0.42）
- 需要本地部署 → 例如 DeepSeek V3.2、GLM-5（均开源，GLM-5 编程分数 77.8%）
长文本处理
- 处理超大代码库 → 例如 Claude 4.6（1M 窗口，无加价）、Gemini 3 Pro（1M 窗口）
- 预算有限 → 例如 MiniMax M2.5（200K， <math xmlns="http://www.w3.org/1998/Math/MathML"> 0.30 / 0.30/ </math>0.30/1.20）、Kimi K2.5（256K， <math xmlns="http://www.w3.org/1998/Math/MathML"> 0.45 / 0.45/ </math>0.45/2.20）
极致性价比
- API 调用量大 → 例如 DeepSeek V3.2（ <math xmlns="http://www.w3.org/1998/Math/MathML"> 0.28 / 0.28/ </math>0.28/0.42）、MiniMax M2.5（ <math xmlns="http://www.w3.org/1998/Math/MathML"> 0.30 / 0.30/ </math>0.30/1.20）
- 固定提示词多 → 开启 Prompt Caching 可再省 90%
以上仅为示例，模型迭代速度很快，建议结合前文的评测站点查看最新排名，再做决策。
六、结语
没有"最好"的大模型，只有"最适合"的。
选型的思路是三步走：先明确场景 （编程、对话、翻译、图像？），再看 Benchmark （用第三方评测站验证能力），最后算成本（Token 单价 × 预估用量）。
AI 领域的竞争正在让模型更强、价格更低。保持关注，定期重新评估你的选型------今天的最优选择，明天可能就不是了。
附录：权威资源汇总
评测排行榜
| 类型 | 站点 | 链接 |
|---|---|---|
| 综合评测 | Artificial Analysis | artificialanalysis.ai/leaderboard... |
| 综合评测 | LM Council | lmcouncil.ai/benchmarks |
| 综合评测 | LLM Stats | llm-stats.com/leaderboard... |
| 代码能力 | Vellum | www.vellum.ai/best-llm-fo... |
| 代码能力 | SWE-Bench | www.swebench.com/ |
官方定价页面
| 厂商 | 链接 |
|---|---|
| Anthropic (Claude) | platform.claude.com/docs/en/abo... |
| OpenAI (GPT) | openai.com/api/pricing... |
| Google (Gemini) | ai.google.dev/gemini-api/... |
| 智谱 (GLM) | open.bigmodel.cn/pricing |
| 月之暗面 (Kimi) | platform.moonshot.cn/docs/pricin... |
| MiniMax | www.minimaxi.com/pricing |
| 阿里云百炼 (Qwen) | help.aliyun.com/zh/model-st... |
| 硅基流动 (国产聚合) | siliconflow.cn/pricing |
价格对比聚合站
| 站点 | 链接 |
|---|---|
| AIGCRank | aigcrank.cn/llmprice |
| 硅基流动 | siliconflow.cn/pricing |
省钱工具
| 工具 | 说明 | 链接 |
|---|---|---|
| claude-code-router | Claude Code 智能路由，多 Provider 支持 | github.com/musistudio/... |