大模型上下文窗口、Token 与成本开发者必须理解的三个概念码海寻道 · 大模型、智能体与 RAG 工程组件系列第 9 篇很多大模型应用的成本和稳定性问题最后都会落到三个词上上下文窗口、Token 和成本。用户说“我只是问了一句话”系统却可能把几十轮历史消息、十几个检索片段、工具返回结果和一大段系统提示词一起发送给模型。真正消耗资源的不是用户输入框里看到的那一句话而是一次请求的完整上下文。理解这三个概念才能解释为什么短问题也会超限为什么增加 RAG 片段后回答反而变差以及为什么同一个功能的账单会不断上涨。一、Token 是什么Token 是模型处理文本时使用的基本片段。它不完全等于汉字、单词或字节。一段中文可能按字符、子词或其他内部规则切分英文单词可能被拆成多个片段标点、空格、数字和代码也会占用 Token。可以先用这个近似理解文本 → Token 序列 → 模型处理 → Token 序列 → 文本实际 Token 数量取决于具体模型和分词器不能只按“一个汉字一个 Token”或“一个英文单词一个 Token”简单估算。因此应用不要用字符串长度直接代替 Token 数量。对于本地模型或需要精确截断的服务应使用目标模型对应的 Tokenizer并明确max_length、padding 和 truncation 策略。不同模型的分词结果可能不同同一段中文、代码或表格文本不能跨模型复用固定估算值。二、一次请求的 Token 由哪些部分组成大模型请求通常不只有用户问题输入 Token 系统提示词 对话历史 当前问题 RAG 检索内容 工具定义 工具返回结果 输出 Token 模型生成的回答总消耗可以近似表示为总 Token 输入 Token 输出 Token在很多应用中输入上下文的增长比用户问题本身更快。尤其是多轮对话、RAG 和 Agent 任务都会不断增加输入内容。三、上下文窗口是什么上下文窗口是模型一次请求能够处理的输入与输出总范围。它限制了模型在当前请求中可以“看到”和“生成”的内容量。可以把它想象成模型当前工作的桌面系统提示词 历史消息 检索片段 工具结果 当前问题 新回答 ≤ 上下文窗口不同模型、不同版本的上下文窗口不同。不能只根据模型名称推测也不能把宣传页中的最大值直接等同于你的业务请求一定能稳定使用的长度。工程实现时应把上下文窗口看成一个预算而不是一个可以随意填满的容器上下文总预算 系统提示词 用户问题 历史消息 RAG 片段 工具结果 预留输出空间应用应在发送请求前完成预算检查并为输出、工具调用和异常重试预留空间。不要等到 API 返回超限错误后才被动截断。当上下文超过限制可能出现API 直接返回超限错误应用被迫截断历史或检索内容输出空间变小回答被截断延迟和成本明显上升模型难以关注真正重要的信息。四、上下文窗口大不代表应该塞满内容“模型能装下更多文本”与“应该把所有文本都发进去”是两回事。上下文过长可能导致信息噪声增加无关片段越多模型越难识别关键依据。成本增加输入 Token 通常会影响费用重复发送历史消息尤其浪费。延迟增加模型需要处理更多输入首字节时间和总生成时间可能增加。重要信息被淹没即使内容在窗口内模型也不一定能同等关注每一段内容。上下文管理仍然是应用设计问题。因此RAG 的目标不是把检索到的内容全部塞进 Prompt而是筛选少量真正相关、权限正确、来源清晰的片段。五、Token 成本如何估算一次调用成本可以粗略表示为单次成本 ≈ 输入 Token / 计费单位 × 输入单价 输出 Token / 计费单位 × 输出单价如果模型服务还对缓存命中、批量处理、推理级别或工具调用有单独计费实际公式还需要继续拆分。一个简单的月度估算可以写成月成本 ≈ 日请求数 × 平均单次成本 × 计费天数 Embedding 建库成本 Reranker 成本 向量数据库与对象存储成本 日志、监控和计算资源成本不要只计算大模型 API 费用。企业知识库里Embedding、Reranker、Milvus、PostgreSQL、Redis、对象存储、队列和日志系统也会产生实际成本。六、为什么 RAG 会让 Token 很快增长假设用户问题只有 20 个 Token但系统召回了 8 个文档片段每个片段 500 个 Token用户问题20 检索内容8 × 500 4,000 历史与提示词1,000 输入总量约 5,020 Token真正占大头的不是问题而是上下文。如果每个片段还重复包含标题、页眉、页脚、相邻 Chunk 和相同的元数据实际输入会更大。优化方法包括减少无关候选使用 Reranker合并重复片段压缩或摘要长文档只保留回答所需字段让引用信息简洁但可追溯为不同任务设置不同的 Top K。七、多轮对话为什么会越来越贵很多聊天应用每一轮都会把完整历史重新发送给模型第 1 轮消息 1 第 2 轮消息 1 消息 2 第 3 轮消息 1 消息 2 消息 3 ...如果对话很长输入 Token 会不断累积。常见的控制策略包括滑动窗口只保留最近若干轮消息适合上下文主要依赖近期对话的场景。历史摘要把早期对话压缩成结构化摘要再与近期原始消息一起发送。重要事实提取单独保存用户明确提供的偏好、约束和任务状态避免每轮都携带完整聊天记录。按需召回历史把历史消息存入数据库或向量库根据当前问题检索最相关的历史而不是全部发送。这些策略各有信息损失需要用真实对话评测效果不能只看 Token 降低了多少。八、Agent 为什么更容易增加 TokenAgent 可能经历多轮“模型 → 工具 → 模型”的循环第 1 次模型调用分析目标 第 1 次工具结果返回数据 第 2 次模型调用解释数据并决定下一步 第 2 次工具结果返回更多数据 第 3 次模型调用组织最终答案每一轮都可能携带之前的消息、工具定义和工具结果。工具返回的原始 JSON 如果没有裁剪Token 会迅速增长。Agent 需要设置最大循环次数最大执行时间最大输入和输出 Token工具结果大小限制大结果分页或摘要策略失败与超限时的降级路径。九、Token 限制与业务逻辑如何联动不要等 API 报超限错误后再处理。应用应该在调用前估算上下文defbuild_context(history,retrieved_docs,max_input_tokens):context[]foriteminhistory:ifestimate_tokens(context[item])max_input_tokens:breakcontext.append(item)fordocinretrieved_docs:ifestimate_tokens(context[doc])max_input_tokens:breakcontext.append(doc)returncontext生产实现需要使用与目标模型匹配的 Token 计算方式并为输出预留空间输入上限 最大输出预留 ≤ 模型上下文窗口不能把整个窗口都分配给输入否则模型没有足够空间生成完整答案。十、如何降低成本而不明显损失效果1. 先减少无效输入这是通常最值得优先做的优化。减少重复历史、无关检索片段和过大的工具结果往往比直接更换模型更有效。2. 任务分层使用模型意图分类、格式提取和简单摘要可以使用成本较低的模型复杂推理和最终生成再使用能力更强的模型。3. 缓存稳定结果对于重复问题、相同文档摘要和相同 Embedding可以使用 Redis 或应用缓存避免重复调用。4. 批量处理离线任务文档建库、批量 Embedding 和离线评测不一定要与用户在线请求使用同一套低延迟策略。5. 设置预算和限额按用户、租户、应用和日期统计 Token超过阈值时降级、限流或转人工。6. 在模型调用前做 Token 预算可以采用一个保守的预算函数deffit_context(parts:list[str],tokenizer,input_budget:int)-list[str]:selected[]used0forpartinparts:sizelen(tokenizer.encode(part,add_special_tokensFalse))ifusedsizeinput_budget:breakselected.append(part)usedsizereturnselected真实系统还要为系统提示词、历史消息、工具调用和输出预留空间。这个函数只是说明预算边界不能替代按相关性、权限和来源进行的上下文筛选。十一、Token 优化不能破坏可追溯性压缩上下文时要保留必要的来源信息{content:员工年休假……,document_id:doc_123,page:8,version:2026-03}最终答案可以只展示简洁引用但系统日志应保留完整的文档 ID、页码、版本和检索分数便于审计和问题排查。成本优化不能变成“把上下文随便删掉”。如果删掉了限定条件、文档版本或权限信息回答可能更便宜却不再可靠。十二、监控哪些 Token 指标建议至少记录每次请求的输入 Token每次请求的输出 Token缓存命中率每个模型的调用次数平均、P95 和 P99 延迟单用户、单租户和单功能成本RAG 片段数量和总 TokenAgent 循环次数超限、截断和重试次数。这些指标要与回答质量一起看。单纯追求 Token 越少可能导致召回不足和回答质量下降。十三、上下文工程的检查清单确认目标模型的上下文窗口和输出限制输入和输出 Token 分开统计为输出预留足够空间历史消息有截断、摘要或按需召回策略RAG 结果经过去重和重排序工具返回结果有字段和大小限制Agent 有循环次数和执行时间上限记录超限、截断、重试和降级费用按模型、功能、用户和租户拆分成本优化后重新评估回答质量。使用目标模型 Tokenizer 进行预算和截断为系统提示词、工具结果和输出保留固定预算结语上下文不是越多越好而是越相关越有价值Token 是模型处理文本的基本计量单位上下文窗口是一次请求能够容纳的输入与输出范围成本则是这些 Token 和基础设施资源最终形成的工程账单。三者互相联系更多历史、检索片段和工具结果 ↓ 更多输入 Token ↓ 更高成本、更大延迟和更高超限风险好的 LLM 应用不会把所有内容都交给模型而会先判断哪些信息真正有用再把它们以合适的长度、结构和优先级放进上下文。至此第二篇章“模型与向量基础”全部完成。下一篇章将进入 PostgreSQL 与业务数据从大模型项目中 PostgreSQL 到底负责什么开始。参考资料Milvus DocumentationSimilarity MetricsMilvus DocumentationEmbedding Function OverviewHugging Face DocumentationTokenizerOpenAI Platform Documentation本文为“码海寻道”原创技术文章。模型上下文窗口、Token 计算方式、价格和限制会随版本变化正式使用时请以对应模型和平台的最新文档为准。 9.大模型上下文窗口、Token 与成本：开发者必须理解的三个概念
大模型上下文窗口、Token 与成本开发者必须理解的三个概念码海寻道 · 大模型、智能体与 RAG 工程组件系列第 9 篇很多大模型应用的成本和稳定性问题最后都会落到三个词上上下文窗口、Token 和成本。用户说“我只是问了一句话”系统却可能把几十轮历史消息、十几个检索片段、工具返回结果和一大段系统提示词一起发送给模型。真正消耗资源的不是用户输入框里看到的那一句话而是一次请求的完整上下文。理解这三个概念才能解释为什么短问题也会超限为什么增加 RAG 片段后回答反而变差以及为什么同一个功能的账单会不断上涨。一、Token 是什么Token 是模型处理文本时使用的基本片段。它不完全等于汉字、单词或字节。一段中文可能按字符、子词或其他内部规则切分英文单词可能被拆成多个片段标点、空格、数字和代码也会占用 Token。可以先用这个近似理解文本 → Token 序列 → 模型处理 → Token 序列 → 文本实际 Token 数量取决于具体模型和分词器不能只按“一个汉字一个 Token”或“一个英文单词一个 Token”简单估算。因此应用不要用字符串长度直接代替 Token 数量。对于本地模型或需要精确截断的服务应使用目标模型对应的 Tokenizer并明确max_length、padding 和 truncation 策略。不同模型的分词结果可能不同同一段中文、代码或表格文本不能跨模型复用固定估算值。二、一次请求的 Token 由哪些部分组成大模型请求通常不只有用户问题输入 Token 系统提示词 对话历史 当前问题 RAG 检索内容 工具定义 工具返回结果 输出 Token 模型生成的回答总消耗可以近似表示为总 Token 输入 Token 输出 Token在很多应用中输入上下文的增长比用户问题本身更快。尤其是多轮对话、RAG 和 Agent 任务都会不断增加输入内容。三、上下文窗口是什么上下文窗口是模型一次请求能够处理的输入与输出总范围。它限制了模型在当前请求中可以“看到”和“生成”的内容量。可以把它想象成模型当前工作的桌面系统提示词 历史消息 检索片段 工具结果 当前问题 新回答 ≤ 上下文窗口不同模型、不同版本的上下文窗口不同。不能只根据模型名称推测也不能把宣传页中的最大值直接等同于你的业务请求一定能稳定使用的长度。工程实现时应把上下文窗口看成一个预算而不是一个可以随意填满的容器上下文总预算 系统提示词 用户问题 历史消息 RAG 片段 工具结果 预留输出空间应用应在发送请求前完成预算检查并为输出、工具调用和异常重试预留空间。不要等到 API 返回超限错误后才被动截断。当上下文超过限制可能出现API 直接返回超限错误应用被迫截断历史或检索内容输出空间变小回答被截断延迟和成本明显上升模型难以关注真正重要的信息。四、上下文窗口大不代表应该塞满内容“模型能装下更多文本”与“应该把所有文本都发进去”是两回事。上下文过长可能导致信息噪声增加无关片段越多模型越难识别关键依据。成本增加输入 Token 通常会影响费用重复发送历史消息尤其浪费。延迟增加模型需要处理更多输入首字节时间和总生成时间可能增加。重要信息被淹没即使内容在窗口内模型也不一定能同等关注每一段内容。上下文管理仍然是应用设计问题。因此RAG 的目标不是把检索到的内容全部塞进 Prompt而是筛选少量真正相关、权限正确、来源清晰的片段。五、Token 成本如何估算一次调用成本可以粗略表示为单次成本 ≈ 输入 Token / 计费单位 × 输入单价 输出 Token / 计费单位 × 输出单价如果模型服务还对缓存命中、批量处理、推理级别或工具调用有单独计费实际公式还需要继续拆分。一个简单的月度估算可以写成月成本 ≈ 日请求数 × 平均单次成本 × 计费天数 Embedding 建库成本 Reranker 成本 向量数据库与对象存储成本 日志、监控和计算资源成本不要只计算大模型 API 费用。企业知识库里Embedding、Reranker、Milvus、PostgreSQL、Redis、对象存储、队列和日志系统也会产生实际成本。六、为什么 RAG 会让 Token 很快增长假设用户问题只有 20 个 Token但系统召回了 8 个文档片段每个片段 500 个 Token用户问题20 检索内容8 × 500 4,000 历史与提示词1,000 输入总量约 5,020 Token真正占大头的不是问题而是上下文。如果每个片段还重复包含标题、页眉、页脚、相邻 Chunk 和相同的元数据实际输入会更大。优化方法包括减少无关候选使用 Reranker合并重复片段压缩或摘要长文档只保留回答所需字段让引用信息简洁但可追溯为不同任务设置不同的 Top K。七、多轮对话为什么会越来越贵很多聊天应用每一轮都会把完整历史重新发送给模型第 1 轮消息 1 第 2 轮消息 1 消息 2 第 3 轮消息 1 消息 2 消息 3 ...如果对话很长输入 Token 会不断累积。常见的控制策略包括滑动窗口只保留最近若干轮消息适合上下文主要依赖近期对话的场景。历史摘要把早期对话压缩成结构化摘要再与近期原始消息一起发送。重要事实提取单独保存用户明确提供的偏好、约束和任务状态避免每轮都携带完整聊天记录。按需召回历史把历史消息存入数据库或向量库根据当前问题检索最相关的历史而不是全部发送。这些策略各有信息损失需要用真实对话评测效果不能只看 Token 降低了多少。八、Agent 为什么更容易增加 TokenAgent 可能经历多轮“模型 → 工具 → 模型”的循环第 1 次模型调用分析目标 第 1 次工具结果返回数据 第 2 次模型调用解释数据并决定下一步 第 2 次工具结果返回更多数据 第 3 次模型调用组织最终答案每一轮都可能携带之前的消息、工具定义和工具结果。工具返回的原始 JSON 如果没有裁剪Token 会迅速增长。Agent 需要设置最大循环次数最大执行时间最大输入和输出 Token工具结果大小限制大结果分页或摘要策略失败与超限时的降级路径。九、Token 限制与业务逻辑如何联动不要等 API 报超限错误后再处理。应用应该在调用前估算上下文defbuild_context(history,retrieved_docs,max_input_tokens):context[]foriteminhistory:ifestimate_tokens(context[item])max_input_tokens:breakcontext.append(item)fordocinretrieved_docs:ifestimate_tokens(context[doc])max_input_tokens:breakcontext.append(doc)returncontext生产实现需要使用与目标模型匹配的 Token 计算方式并为输出预留空间输入上限 最大输出预留 ≤ 模型上下文窗口不能把整个窗口都分配给输入否则模型没有足够空间生成完整答案。十、如何降低成本而不明显损失效果1. 先减少无效输入这是通常最值得优先做的优化。减少重复历史、无关检索片段和过大的工具结果往往比直接更换模型更有效。2. 任务分层使用模型意图分类、格式提取和简单摘要可以使用成本较低的模型复杂推理和最终生成再使用能力更强的模型。3. 缓存稳定结果对于重复问题、相同文档摘要和相同 Embedding可以使用 Redis 或应用缓存避免重复调用。4. 批量处理离线任务文档建库、批量 Embedding 和离线评测不一定要与用户在线请求使用同一套低延迟策略。5. 设置预算和限额按用户、租户、应用和日期统计 Token超过阈值时降级、限流或转人工。6. 在模型调用前做 Token 预算可以采用一个保守的预算函数deffit_context(parts:list[str],tokenizer,input_budget:int)-list[str]:selected[]used0forpartinparts:sizelen(tokenizer.encode(part,add_special_tokensFalse))ifusedsizeinput_budget:breakselected.append(part)usedsizereturnselected真实系统还要为系统提示词、历史消息、工具调用和输出预留空间。这个函数只是说明预算边界不能替代按相关性、权限和来源进行的上下文筛选。十一、Token 优化不能破坏可追溯性压缩上下文时要保留必要的来源信息{content:员工年休假……,document_id:doc_123,page:8,version:2026-03}最终答案可以只展示简洁引用但系统日志应保留完整的文档 ID、页码、版本和检索分数便于审计和问题排查。成本优化不能变成“把上下文随便删掉”。如果删掉了限定条件、文档版本或权限信息回答可能更便宜却不再可靠。十二、监控哪些 Token 指标建议至少记录每次请求的输入 Token每次请求的输出 Token缓存命中率每个模型的调用次数平均、P95 和 P99 延迟单用户、单租户和单功能成本RAG 片段数量和总 TokenAgent 循环次数超限、截断和重试次数。这些指标要与回答质量一起看。单纯追求 Token 越少可能导致召回不足和回答质量下降。十三、上下文工程的检查清单确认目标模型的上下文窗口和输出限制输入和输出 Token 分开统计为输出预留足够空间历史消息有截断、摘要或按需召回策略RAG 结果经过去重和重排序工具返回结果有字段和大小限制Agent 有循环次数和执行时间上限记录超限、截断、重试和降级费用按模型、功能、用户和租户拆分成本优化后重新评估回答质量。使用目标模型 Tokenizer 进行预算和截断为系统提示词、工具结果和输出保留固定预算结语上下文不是越多越好而是越相关越有价值Token 是模型处理文本的基本计量单位上下文窗口是一次请求能够容纳的输入与输出范围成本则是这些 Token 和基础设施资源最终形成的工程账单。三者互相联系更多历史、检索片段和工具结果 ↓ 更多输入 Token ↓ 更高成本、更大延迟和更高超限风险好的 LLM 应用不会把所有内容都交给模型而会先判断哪些信息真正有用再把它们以合适的长度、结构和优先级放进上下文。至此第二篇章“模型与向量基础”全部完成。下一篇章将进入 PostgreSQL 与业务数据从大模型项目中 PostgreSQL 到底负责什么开始。参考资料Milvus DocumentationSimilarity MetricsMilvus DocumentationEmbedding Function OverviewHugging Face DocumentationTokenizerOpenAI Platform Documentation本文为“码海寻道”原创技术文章。模型上下文窗口、Token 计算方式、价格和限制会随版本变化正式使用时请以对应模型和平台的最新文档为准。