大模型LLM到底在做什么一句话理解大模型当你在输入法里打“今天天气真”它会自动建议“好”——大模型做的事情本质上一样只不过它看的不是前面几个字而是前面几千甚至几十万个字且每次只“补”一个 Token文本碎片然后把刚补的内容也加入上下文再预测下一个如此循环直到生成完整回答。这个过程叫做自回归生成Autoregressive Generation。理解了这一点后面所有概念都有了根基Token模型每一步“补”的那个文本碎片就是一个 Token。上下文窗口模型在“补”之前能看到的最大文本量。Temperature / Top-p模型在多个候选碎片中“选哪个”的策略。Max Tokens你允许模型最多“补”多少步。有了这个心智模型我们再逐一展开。全局概念地图在深入每个概念之前先看一张完整的调用流程图帮你在 30 秒内建立全局认知用户输入 ↓ [Tokenizer] → Token 序列 ↓ 塞入上下文窗口System Prompt User Prompt 历史 RAG 片段 ↓ ↑ 模型推理自注意力机制 [Embedding 向量检索] ↓ 从知识库召回相关片段 logits → [Temperature/Top-p/Top-k] → 采样出下一个 Token ↓ 重复直到 EOS 或 Max Tokens ↓ 结构化输出解析 校验 ↓ 业务消费后续每个小节都能在这张图上找到对应位置。Token模型的“阅读单位”你可以把 Token 理解为“模型的阅读单位”。我们人类读中文是一个字一个字地看读英文是一个词一个词地看但模型既不按字、也不按词——它用一套自己的“拆字规则”叫 Tokenizer把文本切成大小不等的碎片每个碎片就是一个 Token。为什么不直接按字或按词切因为模型需要在“词表大小”和“序列长度”之间取平衡如果每个汉字都是一个 Token词表小、但序列长模型要“补”更多步如果每个词都是一个 Token序列短、但词表会爆炸中文词组太多了。所以实际使用的是一种折中方案——子词切分算法如 BPE、Unigram它会把高频词保留为整体把低频词拆成更小的片段。 一个直觉你可以把 Token 想象成乐高积木——常用的“积木块”比较大比如“你好”可能是一个 Token不常用的词会被拆成更小的基础块拼起来。Token 不是“一个字”或“一个词”的严格等价物英文可能一个单词被拆成多个 Token中文可能一个词被拆成多个 Token也可能多个字合并成一个 Token取决于词频与词表。因此工程上通常只用经验估算做容量规划而用实际 API 返回的 usage若供应商提供做精确计费与监控。经验估算仅用于粗略规划英文1 Token 大约对应 3~4 个字符与文本类型相关。中文1 Token 常见在 1~2 个汉字上下波动与混排比例强相关。以 DeepSeek 官方数据为例1 个英文字符约消耗 0.3 Token1 个中文字符约消耗 0.6 Token。换算过来1 个 Token 约等于 3.3 个英文字符或 1.7 个中文字符与上述经验值吻合。 成本趋势提示Token 成本与编码器Tokenizer版本强相关。早期模型如 GPT-3.5中文压缩率较低约 1 字 1.5~2 Token。GPT-4o 使用 o200k_base Tokenizer词表约 20 万相比前代 cl100k_base 对中文的压缩率有进一步提升Qwen2.5 词表约 15 万对中文常用词同样有优化。实测数据因文本类型而异新闻类文本约 1.5 字/Token技术文档约 1.2 字/Token。“趋近 1 字 1 Token”仅适用于高频词汇不建议作为成本估算基准。在做成本预算时请务必查阅当前模型版本的官方 Tokenizer 演示勿沿用旧模型经验。Token 划分的精细度会直接影响模型的理解能力。特别是在中文处理时分词歧义同一字符序列的多种切分方式和生僻字/低频专业术语的切分粒度会直接影响模型的语义理解效果。Token 化过程示例原文你好我是 Guide。切分[你好][][我是][Guide][。]统计原文 12 字符 → Token 数 5 个 → 压缩比约 2.4 倍Token 化过程示例⚠️ 注意实际的 Token 切分由模型供应商的 Tokenizer 实现不同供应商对相同文本可能产生不同的 Token 序列。生产环境中应使用对应供应商的 Tokenizer 工具进行精确计数。特殊 Token除了文本内容对应的 Token模型内部还会使用一些特殊标记这些也会计入 Token 总数特殊 Token用途示例BOSBeginning of Sequence标记序列开始sEOSEnd of Sequence标记序列结束/sPADPadding批处理时填充短序列pad工具调用标记Function Calling 场景的边界标记tool_call/这些特殊 Token 通常对用户不可见但会占用上下文窗口。在精确计数时建议使用官方 Tokenizer 工具而非手动估算。多模态 Token图片也会消耗 TokenGPT-4o、Claude 3.5、Gemini 等模型已支持图片输入。图片不是“零成本”的——它会被转换成一批 Token同样占用上下文窗口。粗略估算规则模型图片 Token 计算方式一张 1024×1024 图片约等于GPT-4o按分辨率 细节模式低细节 ~85 tokens高细节 ~1105~765 tokens取决于裁剪Claude 3.5固定 ~5 tokens缩略图或 ~85 tokens全图取决于图片模式Gemini按分辨率计算~258 tokens标准工程启示做多模态 RAG 时要把图片 Token 也纳入预算批量处理图片时注意首字延迟TTFT会显著增加如果只需要 OCR考虑先用专门的 OCR 服务提取文字再以纯文本形式送入模型上下文窗口Context Window上下文窗口或称“上下文长度”是 LLM 的“工作记忆”Working Memory。它决定了模型在任何时刻可以处理或“记住”的文本量以 Token 为单位。对话连续性它决定了模型能进行多长的多轮对话而不遗忘早期细节。单次处理能力它决定了模型一次性能够处理的最大文档、代码库或数据样本的大小。“模型支持 128K/200K/1M”指的是一次调用里能放进模型的总 Token 上限。大多数模型的上下文窗口包含输入与输出的总和但部分供应商如 Google Gemini对输入和输出分别设限请查阅具体 API 文档。此外上下文窗口往往被隐形成本占用上下文窗口Context Window LLM 的「工作记忆」System Prompt调节模型行为的系统指令通常对用户隐藏但占用窗口。User Prompt业务数据与指令。多轮对话历史过往的消息记录。RAG 检索片段从外部知识库检索到的补充信息。工具调用 Schema函数定义与参数结构。格式开销特殊字符、换行符、Markdown 标记等。模型生成的输出 Token关键输出也占用上下文窗口。因此你真正能塞进 Prompt 的“有效业务内容”往往远小于标称上限。⚠️ 注意输出硬限制上下文窗口Context Window≠ 最大生成长度。许多模型支持 128K 甚至 1M 输入但单次输出上限因 API 而异OpenAI Chat Completions API 使用max_tokens参数GPT-4o 最大 16K 输出部分新模型支持max_completion_tokens如 o1 系列DeepSeek V3 最大输出 8K。使用前需查阅具体模型的 API 文档。思维链模式的多轮对话处理在多轮对话场景中思维链模型如 DeepSeek-R1的reasoning_content思考过程通常不会被自动包含在下一轮对话的上下文中。只有content最终回答会参与后续对话。这意味着你无需为思考过程额外占用上下文窗口。但如果后续对话需要参考之前的推理过程需要手动将reasoning_content拼接到消息历史中。部分供应商的 SDK 会自动处理这一差异建议查阅具体文档确认行为。上下文窗口为什么会有上限上下文窗口并非越大越好它受限于 Transformer 架构的自注意力机制Self-Attention计算成本平方级增长计算需求与序列长度呈平方级关系O(N²)。输入 Token 翻倍处理能力需求可能变为 4 倍。这意味着更长的上下文 更高的成本 更慢的推理速度。推理延迟增加随着上下文变长模型生成每个新 Token 时需要关注的所有历史 Token 变多导致输出速度逐渐变慢尤其是首字延迟 TTFT 会显著增加。安全风险增加更长的上下文意味着更大的攻击面模型可能更容易受到对抗性提示“越狱”攻击的影响。工程优化手段实践中FlashAttentionIO-aware 精确注意力、GQA/MQA分组/多查询注意力、Sliding Window Attention如 Mistral、Ring Attention 等技术已显著降低长上下文的实际计算和显存开销。但 O(N²) 的理论复杂度仍是上限扩展的根本瓶颈。上下文溢出的真实表现当上下文接近上限或内容过长时常见现象包括模型忽略早期约束System Prompt 里要求“必须输出 JSON”但因距离生成点太远注意力不足导致被忽略。缓解策略将关键约束在 User Prompt 末尾重复强调或使用 Structured Outputs 的 Strict Mode 从解码层面强制约束。“中间丢失”现象Lost in the MiddleLiu et al., 2023即使在 1M 窗口模型中模型对开头和结尾的信息最敏感对中间部分的信息召回率显著下降。回答漂移前半段还围绕问题后半段开始总结/扩写/跑题。RAG 失效检索文档过多关键信息被稀释或被截断导致证据链断裂。成本与延迟激增1M 上下文会导致首字延迟TTFT显著增加且 Token 成本呈线性增长。在本项目里你能看到两个典型的“上下文控制”手段智能截断不要简单粗暴地截断字符串。例如把简历内容做摘要提取或关键信息抽取避免把长文本原封不动塞进评估 prompt。分批处理和二次汇总长面试评估按 batch 分段评估再做二次汇总避免单次调用 Token 过大。即使拥有 1M 窗口也建议设置软性预算上限如 128K。除非必要否则不要全量输入以平衡成本、延迟与准确性。计费差异输入 Token ≠ 输出 Token大多数供应商对输入 Token和输出 Token采用不同的计费标准通常输出价格是输入的2~4 倍模型输入价格/1M Tokens输出价格/1M Tokens输出/输入比GPT-4o$2.50$10.004xClaude 3.5 Sonnet$3.00$15.005xDeepSeek V3¥0.5¥2.04xDeepSeek-R1¥4.0¥16.04x工程启示长 Prompt 短输出 更经济的调用方式RAG 场景要控制检索片段数量避免输入 Token 激增思维链模型的 reasoning tokens 通常按输出价格计费成本更高Prompt Caching重复前缀的成本救星当你的请求中存在大量重复的固定前缀如 System Prompt、长 RAG Context可以用Prompt Caching提示词缓存显著降低成本。原理供应商会缓存你请求中“可复用的前缀部分”。下次请求如果前缀相同这部分就不重新计费只收“缓存读取”的费用通常是正常价格的 10%~50%。典型适用场景多轮对话System Prompt 历史 Message 不变RAG 应用检索片段重复率高批量评估同一份 System Prompt不同的简历/文章各供应商支持情况供应商功能名称缓存时长缓存命中折扣OpenAIPrompt Caching5~10 分钟输入价格约 50%AnthropicPrompt Caching5 分钟输入价格约 10%DeepSeekContext Caching10~30 分钟输入价格约 25%工程建议把不变的内容放前面System Prompt、工具定义、RAG Context把变化的内容放后面User Prompt监控cache_read_tokens和cache_creation_tokens指标验证缓存命中率批量任务尽量在缓存时间窗口内完成即使拥有 1M 窗口也建议设置软性预算上限如 128K。除非必要否则不要全量输入以平衡成本、延迟与准确性。一次调用的 Token 预算怎么做把“上下文窗口”当成一个固定容量的桶下图展示了一个典型调用的 Token 预算分配pie title 16K 上下文窗口典型分配结构化输出场景 System Prompt含 Schema : 1500 User Prompt业务数据 : 6000 历史消息多轮对话 : 2000 安全边际供应商开销 : 1500 输出预留Max Tokens : 5000此分配仅为示意实际比例需根据业务场景动态调整。最实用的预算方式是window ≥ input_tokens max_output_tokens对于思维链模型公式应调整为window ≥ input_tokens reasoning_tokens max_output_tokens其中reasoning_tokens思考链 Token 数难以精确预估建议按max_output_tokens的 2~3 倍预留。其中input_tokens至少包含system prompt含 schema / 工具定义user prompt含变量替换后的实际文本历史消息如果你做多轮对话RAG context如果你拼进来了工程上建议你反过来做预算因为输出经常更可控先定max_output_tokens结构化输出通常不需要很长再为输入预留安全边际例如再留 10%~20% 给“供应商额外开销”工具调用包装、隐藏 tokens、编码差异等超预算时用可解释的策略“减输入”而不是“赌模型会自我约束”优先减少 RAG 的 Top-K 或做片段去重对长字段做摘要/截断如简历、长回答多段任务拆成多次调用分批评估、两阶段生成解码Decoding与采样参数先理解“选词”过程模型每一步会给词表中的每个候选 Token 打一个分数内部叫logits分数越高说明模型越觉得这个词应该出现在这里。举个例子假设模型正在补全“今天天气真__”它可能给出这样的分数候选 Token原始分数logit好5.0不错3.2棒2.1糟糕0.5紫色-8.0但原始分数不是概率——需要经过一次数学变换softmax才能变成“每个候选被选中的概率”。变换后大致是候选 Token概率好62%不错20%棒10%糟糕5%紫色≈ 0%最后模型按这个概率分布“抽签”采样决定输出哪个 Token。解码参数Temperature、Top-p、Top-k 等就是在这个“打分 → 概率 → 抽签”的过程中施加控制。它们的作用可以这样理解Temperature调整概率分布的“形状”——让高分选项更突出或者让各选项更均匀Top-p / Top-k直接砍掉不靠谱的候选项缩小“抽签池”Penalty 系列对已经出现过的词降分防止“复读机”下面逐一展开。Temperature控制模型的“冒险程度”Temperature 参数控制模型输出的随机性Temperature 的工作原理很简单在 softmax 之前先把所有分数除以温度值 T。p(t) softmax(z_t / T)(T ≈ 1)保持原始分布。(T 1)分布更尖锐更倾向选择高概率 Token更“稳”、更少发散。(T 1)分布更平坦低概率 Token 更容易被采样到更“灵感”、也更容易偏离约束。那除以 T 之后会发生什么还是用“今天天气真__”的例子T 0.2低温——“保守模式”分数差距被放大都除以 0.2等于乘以 5原本就领先的“好”概率飙升到 ~98%几乎每次都选它。T 1.0默认温度保持原始分布不变“好”62%、“不错”20%...按正常概率采样。T 1.5高温——“冒险模式”分数差距被缩小都除以 1.5“好”概率降到 ~35%“棒”、“不错”甚至“糟糕”都有更大机会被选中。一句话总结温度越低输出越确定、越“稳”温度越高输出越随机、越“野”。工程建议经验值非硬规则场景推荐温度说明结构化提取 / JSON 输出0 ~ 0.3配合严格 schema 解析失败重试策略评估 / 分析 / 代码评审0.4 ~ 0.8平衡确定性与表达多样性创作类内容文案、头脑风暴0.8 ~ 1.2增加多样性但要承担格式一致性风险追求确定性若需单元测试幂等或结果复现仅设Temperature0不够GPU 浮点误差仍可能导致非确定性。建议同时配置seed参数如 OpenAI/DeepSeek 支持。固定 seed 低温可最大程度减少波动。需注意即使配置seed以下情况仍可能导致结果不一致模型版本更新底层权重变化跨区域调用不同集群可能部署不同版本Top-p 采样即使 T0若 Top-p1 仍有随机性建议在 CI/CD 中仅将 LLM 调用用于冒烟测试核心逻辑仍依赖 Mock。Top-pNucleus Sampling与 Top-k缩小“抽签池”Temperature 调整的是概率分布的形状但不管怎么调词表里所有 Token 理论上都有被选中的可能哪怕概率极低。Top-p 和 Top-k 则更直接——把不靠谱的候选直接踢出抽签池。还是用“今天天气真__”的例子候选 Token概率累计概率好62%62%不错20%82%棒10%92%糟糕5%97%紫色≈0%≈100%Top-k 3只保留概率最高的 3 个候选好、不错、棒在这 3 个里重新分配概率后采样。“糟糕”和“紫色”直接出局。Top-p 0.9从高到低累加概率保留累计刚好达到 90% 的最小集合。这里“好 不错 棒 92% ≥ 90%”所以保留这 3 个。如果某个场景下头部更集中比如第一名就占了 95%Top-p 会自动只保留 1 个——这就是它比 Top-k 更灵活的地方。两者的区别Top-k 固定保留 k 个不管概率分布长什么样Top-p 根据概率自适应调整候选数量。实践中Top-p 更常用因为它能自动适应不同的概率分布。常见组合组合效果适用场景T0贪婪解码永远选最高分完全确定结构化输出、可复现场景低温 Top-p0.9相对稳定但允许措辞上有些变化分析报告、摘要中高温 Top-p0.95多样性较高但排除了极端离谱选项创意写作、对话⚠️ 注意贪婪解码虽然最稳定但可能更容易陷入重复循环比如反复输出同一段话。Max Tokens / Stop Sequences控制输出何时停止工程上需要意识到两点Max Tokens 是硬上限到上限会被强制截断——模型正写到一半也会被“掐断”。常见后果JSON 缺右括号、列表缺最后几项、句子写了一半。Stop Sequences停止词是软切断你可以指定一些字符串如\n\n或模型生成到这些内容时会自动停止。但如果 stop 设计不当可能提前截断关键字段。因此结构化输出场景要把“截断风险”当成一类失败路径来设计缓解策略。思维链模式的 Token 计算差异对于支持思维链的模型如 DeepSeek-R1max_tokens的值通常包含思考过程 最终回答两部分。例如设置max_tokens8192模型可能在思考链上消耗 5000 tokens最终回答只剩 3192 tokens 的预算。因此思维链场景需要为思考过程预留更大的 buffer。不同供应商的默认值和上限差异较大DeepSeek-R1 默认 32K、最大 64KOpenAI o1 系列的输出上限也高于普通模型。使用前务必查阅具体模型的 API 文档。Repetition / Presence / Frequency Penalty防止“复读机”你可能遇到过模型反复输出同一句话或者在长回答里不断重复相同的观点。Penalty 参数就是用来缓解这类问题的它们在解码时降低已出现 Token 的分数参数作用通俗理解Repetition Penalty降低所有已出现 Token 的概率“说过的词再说就扣分”Presence Penalty只要 Token 出现过就扣分不看次数“鼓励聊新话题”Frequency PenaltyToken 出现次数越多扣分越重“同一个词说了三遍重罚”⚠️ 工程陷阱结构化输出别乱加 PenaltyJSON 里字段名如name、score需要反复出现加了 Repetition Penalty 可能把必须出现的字段名也“惩罚掉”导致输出残缺。RAG 问答别加 Presence Penalty它会鼓励模型“说点新东西”反而降低对检索内容的忠实度faithfulness增加幻觉风险。保守建议如果你不确定这些参数的精确语义不同供应商定义可能不同建议保持默认值。用低温 更强 Prompt 约束 更短输出来获得稳定性比调 Penalty 更可控。思维链模式的参数限制部分模型如 DeepSeek-R1、OpenAI o1支持“思维链模式”Thinking Mode在生成最终回答前会先输出一段内部推理过程。这类模型有特殊的参数约束不支持的采样参数思维链模式下以下参数通常被忽略temperature、top_p采样控制参数presence_penalty、frequency_penalty惩罚参数原因思维链模式的设计目标是让模型“自由思考”采用模型内部固定的采样策略具体实现因供应商而异用户传入的采样参数会被忽略。工程建议调用思维链模型时不要依赖上述参数控制输出风格若需要更稳定的输出格式应通过 Prompt 约束而非采样参数关注模型返回的reasoning_content字段思考过程与content字段最终回答的区别流式输出Streaming默认情况下API 会等模型生成完所有内容后一次性返回。流式输出则是边生成边返回——模型每生成一个或几个Token就立刻推送给客户端用户更早看到内容开始出现。核心价值改善用户体验降低首字延迟TTFTTime-To-First-Token。常见误解澄清❌ “流式输出更快”——总耗时E2E latency不一定下降模型生成的总 Token 量相同❌ “流式输出更省钱”——Token 计费不变仍然受限流/配额影响⚠️ 如果你需要结构化输出如 JSON流式场景要考虑“半成品 JSON”在前端/网关层的处理——拿到的可能是{name: 张你需要等流结束后再解析或使用流式 JSON 解析器Logprobs对数概率部分 API如 OpenAI支持返回每个生成 Token 的对数概率logprobs可以理解为模型对该 Token 的“确信程度”logprob 越接近 0模型越确信值越小如 -5.0说明模型越“犹豫”。工程应用场景置信度评估提取“金额: 1000”时若对应 Token 的 logprob 很低说明模型不太确定可能需要人工复核。异常检测监控生产环境中模型输出的平均 logprob若突然下降可能提示 Prompt 漂移或输入数据异常。多候选对比获取 Top-N 候选 Token 及其概率用于纠错或二次排序。注意事项logprobs 会增加响应体积且并非所有供应商都支持。使用前请查阅 API 文档。参数速查表最后整理一张速查表方便你根据场景快速选择参数组合场景TemperatureTop-pPenalty其他建议JSON / 结构化输出0 ~ 0.31.0保持默认配合 Strict Mode 重试策略代码评审 / 技术分析0.4 ~ 0.70.9保持默认结合 CoT Prompt多轮对话0.6 ~ 0.80.9适度开启控制历史消息长度创意写作 / 头脑风暴0.8 ~ 1.20.95按需开启接受输出多样性做好后处理思维链模型—不支持——通过 Prompt 控制非采样参数总结当我们把大模型作为一个核心组件接入业务系统时第一步就是要抛弃拟人化的业务直觉建立起工程师的客观视角。回顾这篇扫盲内容核心其实就是处理好三个维度的工程权衡Token 是成本与性能的物理标尺它不仅决定了你的计费账单和推理延迟更决定了模型对文本的理解粒度。做容量规划时必须按 Token 算账而不是按字数算账。上下文窗口是极其稀缺的资源哪怕模型宣称支持 1M 上下文也不意味着可以毫无节制地堆砌数据。为 Prompt、RAG 检索片段、历史对话和输出预留做好严格的 Token 预算分配是走向生产环境的必修课。采样参数是业务场景的调音台如果追求稳定的 JSON 输出就果断压低 Temperature 并配合严格的 Schema如果需要创意与头脑风暴再适度放开 Temperature 和 Top-p。不要迷信默认参数要根据业务的容错率来定制。打好这层参数与原理的地基再去回顾我们之前讲过的 Agent 编排、RAG 检索或是 MCP 工具调用你会发现那些高阶架构的本质无非是在更好地调度这些底层 Token更精准地管理这个上下文窗口。
面试官：“你一天烧几十个token也好意思面AI应用开发？”我镇定自若：“我烧的不是token，是我的热情。”面试官：“明天二面。”
发布时间：2026/5/19 17:16:11
大模型LLM到底在做什么一句话理解大模型当你在输入法里打“今天天气真”它会自动建议“好”——大模型做的事情本质上一样只不过它看的不是前面几个字而是前面几千甚至几十万个字且每次只“补”一个 Token文本碎片然后把刚补的内容也加入上下文再预测下一个如此循环直到生成完整回答。这个过程叫做自回归生成Autoregressive Generation。理解了这一点后面所有概念都有了根基Token模型每一步“补”的那个文本碎片就是一个 Token。上下文窗口模型在“补”之前能看到的最大文本量。Temperature / Top-p模型在多个候选碎片中“选哪个”的策略。Max Tokens你允许模型最多“补”多少步。有了这个心智模型我们再逐一展开。全局概念地图在深入每个概念之前先看一张完整的调用流程图帮你在 30 秒内建立全局认知用户输入 ↓ [Tokenizer] → Token 序列 ↓ 塞入上下文窗口System Prompt User Prompt 历史 RAG 片段 ↓ ↑ 模型推理自注意力机制 [Embedding 向量检索] ↓ 从知识库召回相关片段 logits → [Temperature/Top-p/Top-k] → 采样出下一个 Token ↓ 重复直到 EOS 或 Max Tokens ↓ 结构化输出解析 校验 ↓ 业务消费后续每个小节都能在这张图上找到对应位置。Token模型的“阅读单位”你可以把 Token 理解为“模型的阅读单位”。我们人类读中文是一个字一个字地看读英文是一个词一个词地看但模型既不按字、也不按词——它用一套自己的“拆字规则”叫 Tokenizer把文本切成大小不等的碎片每个碎片就是一个 Token。为什么不直接按字或按词切因为模型需要在“词表大小”和“序列长度”之间取平衡如果每个汉字都是一个 Token词表小、但序列长模型要“补”更多步如果每个词都是一个 Token序列短、但词表会爆炸中文词组太多了。所以实际使用的是一种折中方案——子词切分算法如 BPE、Unigram它会把高频词保留为整体把低频词拆成更小的片段。 一个直觉你可以把 Token 想象成乐高积木——常用的“积木块”比较大比如“你好”可能是一个 Token不常用的词会被拆成更小的基础块拼起来。Token 不是“一个字”或“一个词”的严格等价物英文可能一个单词被拆成多个 Token中文可能一个词被拆成多个 Token也可能多个字合并成一个 Token取决于词频与词表。因此工程上通常只用经验估算做容量规划而用实际 API 返回的 usage若供应商提供做精确计费与监控。经验估算仅用于粗略规划英文1 Token 大约对应 3~4 个字符与文本类型相关。中文1 Token 常见在 1~2 个汉字上下波动与混排比例强相关。以 DeepSeek 官方数据为例1 个英文字符约消耗 0.3 Token1 个中文字符约消耗 0.6 Token。换算过来1 个 Token 约等于 3.3 个英文字符或 1.7 个中文字符与上述经验值吻合。 成本趋势提示Token 成本与编码器Tokenizer版本强相关。早期模型如 GPT-3.5中文压缩率较低约 1 字 1.5~2 Token。GPT-4o 使用 o200k_base Tokenizer词表约 20 万相比前代 cl100k_base 对中文的压缩率有进一步提升Qwen2.5 词表约 15 万对中文常用词同样有优化。实测数据因文本类型而异新闻类文本约 1.5 字/Token技术文档约 1.2 字/Token。“趋近 1 字 1 Token”仅适用于高频词汇不建议作为成本估算基准。在做成本预算时请务必查阅当前模型版本的官方 Tokenizer 演示勿沿用旧模型经验。Token 划分的精细度会直接影响模型的理解能力。特别是在中文处理时分词歧义同一字符序列的多种切分方式和生僻字/低频专业术语的切分粒度会直接影响模型的语义理解效果。Token 化过程示例原文你好我是 Guide。切分[你好][][我是][Guide][。]统计原文 12 字符 → Token 数 5 个 → 压缩比约 2.4 倍Token 化过程示例⚠️ 注意实际的 Token 切分由模型供应商的 Tokenizer 实现不同供应商对相同文本可能产生不同的 Token 序列。生产环境中应使用对应供应商的 Tokenizer 工具进行精确计数。特殊 Token除了文本内容对应的 Token模型内部还会使用一些特殊标记这些也会计入 Token 总数特殊 Token用途示例BOSBeginning of Sequence标记序列开始sEOSEnd of Sequence标记序列结束/sPADPadding批处理时填充短序列pad工具调用标记Function Calling 场景的边界标记tool_call/这些特殊 Token 通常对用户不可见但会占用上下文窗口。在精确计数时建议使用官方 Tokenizer 工具而非手动估算。多模态 Token图片也会消耗 TokenGPT-4o、Claude 3.5、Gemini 等模型已支持图片输入。图片不是“零成本”的——它会被转换成一批 Token同样占用上下文窗口。粗略估算规则模型图片 Token 计算方式一张 1024×1024 图片约等于GPT-4o按分辨率 细节模式低细节 ~85 tokens高细节 ~1105~765 tokens取决于裁剪Claude 3.5固定 ~5 tokens缩略图或 ~85 tokens全图取决于图片模式Gemini按分辨率计算~258 tokens标准工程启示做多模态 RAG 时要把图片 Token 也纳入预算批量处理图片时注意首字延迟TTFT会显著增加如果只需要 OCR考虑先用专门的 OCR 服务提取文字再以纯文本形式送入模型上下文窗口Context Window上下文窗口或称“上下文长度”是 LLM 的“工作记忆”Working Memory。它决定了模型在任何时刻可以处理或“记住”的文本量以 Token 为单位。对话连续性它决定了模型能进行多长的多轮对话而不遗忘早期细节。单次处理能力它决定了模型一次性能够处理的最大文档、代码库或数据样本的大小。“模型支持 128K/200K/1M”指的是一次调用里能放进模型的总 Token 上限。大多数模型的上下文窗口包含输入与输出的总和但部分供应商如 Google Gemini对输入和输出分别设限请查阅具体 API 文档。此外上下文窗口往往被隐形成本占用上下文窗口Context Window LLM 的「工作记忆」System Prompt调节模型行为的系统指令通常对用户隐藏但占用窗口。User Prompt业务数据与指令。多轮对话历史过往的消息记录。RAG 检索片段从外部知识库检索到的补充信息。工具调用 Schema函数定义与参数结构。格式开销特殊字符、换行符、Markdown 标记等。模型生成的输出 Token关键输出也占用上下文窗口。因此你真正能塞进 Prompt 的“有效业务内容”往往远小于标称上限。⚠️ 注意输出硬限制上下文窗口Context Window≠ 最大生成长度。许多模型支持 128K 甚至 1M 输入但单次输出上限因 API 而异OpenAI Chat Completions API 使用max_tokens参数GPT-4o 最大 16K 输出部分新模型支持max_completion_tokens如 o1 系列DeepSeek V3 最大输出 8K。使用前需查阅具体模型的 API 文档。思维链模式的多轮对话处理在多轮对话场景中思维链模型如 DeepSeek-R1的reasoning_content思考过程通常不会被自动包含在下一轮对话的上下文中。只有content最终回答会参与后续对话。这意味着你无需为思考过程额外占用上下文窗口。但如果后续对话需要参考之前的推理过程需要手动将reasoning_content拼接到消息历史中。部分供应商的 SDK 会自动处理这一差异建议查阅具体文档确认行为。上下文窗口为什么会有上限上下文窗口并非越大越好它受限于 Transformer 架构的自注意力机制Self-Attention计算成本平方级增长计算需求与序列长度呈平方级关系O(N²)。输入 Token 翻倍处理能力需求可能变为 4 倍。这意味着更长的上下文 更高的成本 更慢的推理速度。推理延迟增加随着上下文变长模型生成每个新 Token 时需要关注的所有历史 Token 变多导致输出速度逐渐变慢尤其是首字延迟 TTFT 会显著增加。安全风险增加更长的上下文意味着更大的攻击面模型可能更容易受到对抗性提示“越狱”攻击的影响。工程优化手段实践中FlashAttentionIO-aware 精确注意力、GQA/MQA分组/多查询注意力、Sliding Window Attention如 Mistral、Ring Attention 等技术已显著降低长上下文的实际计算和显存开销。但 O(N²) 的理论复杂度仍是上限扩展的根本瓶颈。上下文溢出的真实表现当上下文接近上限或内容过长时常见现象包括模型忽略早期约束System Prompt 里要求“必须输出 JSON”但因距离生成点太远注意力不足导致被忽略。缓解策略将关键约束在 User Prompt 末尾重复强调或使用 Structured Outputs 的 Strict Mode 从解码层面强制约束。“中间丢失”现象Lost in the MiddleLiu et al., 2023即使在 1M 窗口模型中模型对开头和结尾的信息最敏感对中间部分的信息召回率显著下降。回答漂移前半段还围绕问题后半段开始总结/扩写/跑题。RAG 失效检索文档过多关键信息被稀释或被截断导致证据链断裂。成本与延迟激增1M 上下文会导致首字延迟TTFT显著增加且 Token 成本呈线性增长。在本项目里你能看到两个典型的“上下文控制”手段智能截断不要简单粗暴地截断字符串。例如把简历内容做摘要提取或关键信息抽取避免把长文本原封不动塞进评估 prompt。分批处理和二次汇总长面试评估按 batch 分段评估再做二次汇总避免单次调用 Token 过大。即使拥有 1M 窗口也建议设置软性预算上限如 128K。除非必要否则不要全量输入以平衡成本、延迟与准确性。计费差异输入 Token ≠ 输出 Token大多数供应商对输入 Token和输出 Token采用不同的计费标准通常输出价格是输入的2~4 倍模型输入价格/1M Tokens输出价格/1M Tokens输出/输入比GPT-4o$2.50$10.004xClaude 3.5 Sonnet$3.00$15.005xDeepSeek V3¥0.5¥2.04xDeepSeek-R1¥4.0¥16.04x工程启示长 Prompt 短输出 更经济的调用方式RAG 场景要控制检索片段数量避免输入 Token 激增思维链模型的 reasoning tokens 通常按输出价格计费成本更高Prompt Caching重复前缀的成本救星当你的请求中存在大量重复的固定前缀如 System Prompt、长 RAG Context可以用Prompt Caching提示词缓存显著降低成本。原理供应商会缓存你请求中“可复用的前缀部分”。下次请求如果前缀相同这部分就不重新计费只收“缓存读取”的费用通常是正常价格的 10%~50%。典型适用场景多轮对话System Prompt 历史 Message 不变RAG 应用检索片段重复率高批量评估同一份 System Prompt不同的简历/文章各供应商支持情况供应商功能名称缓存时长缓存命中折扣OpenAIPrompt Caching5~10 分钟输入价格约 50%AnthropicPrompt Caching5 分钟输入价格约 10%DeepSeekContext Caching10~30 分钟输入价格约 25%工程建议把不变的内容放前面System Prompt、工具定义、RAG Context把变化的内容放后面User Prompt监控cache_read_tokens和cache_creation_tokens指标验证缓存命中率批量任务尽量在缓存时间窗口内完成即使拥有 1M 窗口也建议设置软性预算上限如 128K。除非必要否则不要全量输入以平衡成本、延迟与准确性。一次调用的 Token 预算怎么做把“上下文窗口”当成一个固定容量的桶下图展示了一个典型调用的 Token 预算分配pie title 16K 上下文窗口典型分配结构化输出场景 System Prompt含 Schema : 1500 User Prompt业务数据 : 6000 历史消息多轮对话 : 2000 安全边际供应商开销 : 1500 输出预留Max Tokens : 5000此分配仅为示意实际比例需根据业务场景动态调整。最实用的预算方式是window ≥ input_tokens max_output_tokens对于思维链模型公式应调整为window ≥ input_tokens reasoning_tokens max_output_tokens其中reasoning_tokens思考链 Token 数难以精确预估建议按max_output_tokens的 2~3 倍预留。其中input_tokens至少包含system prompt含 schema / 工具定义user prompt含变量替换后的实际文本历史消息如果你做多轮对话RAG context如果你拼进来了工程上建议你反过来做预算因为输出经常更可控先定max_output_tokens结构化输出通常不需要很长再为输入预留安全边际例如再留 10%~20% 给“供应商额外开销”工具调用包装、隐藏 tokens、编码差异等超预算时用可解释的策略“减输入”而不是“赌模型会自我约束”优先减少 RAG 的 Top-K 或做片段去重对长字段做摘要/截断如简历、长回答多段任务拆成多次调用分批评估、两阶段生成解码Decoding与采样参数先理解“选词”过程模型每一步会给词表中的每个候选 Token 打一个分数内部叫logits分数越高说明模型越觉得这个词应该出现在这里。举个例子假设模型正在补全“今天天气真__”它可能给出这样的分数候选 Token原始分数logit好5.0不错3.2棒2.1糟糕0.5紫色-8.0但原始分数不是概率——需要经过一次数学变换softmax才能变成“每个候选被选中的概率”。变换后大致是候选 Token概率好62%不错20%棒10%糟糕5%紫色≈ 0%最后模型按这个概率分布“抽签”采样决定输出哪个 Token。解码参数Temperature、Top-p、Top-k 等就是在这个“打分 → 概率 → 抽签”的过程中施加控制。它们的作用可以这样理解Temperature调整概率分布的“形状”——让高分选项更突出或者让各选项更均匀Top-p / Top-k直接砍掉不靠谱的候选项缩小“抽签池”Penalty 系列对已经出现过的词降分防止“复读机”下面逐一展开。Temperature控制模型的“冒险程度”Temperature 参数控制模型输出的随机性Temperature 的工作原理很简单在 softmax 之前先把所有分数除以温度值 T。p(t) softmax(z_t / T)(T ≈ 1)保持原始分布。(T 1)分布更尖锐更倾向选择高概率 Token更“稳”、更少发散。(T 1)分布更平坦低概率 Token 更容易被采样到更“灵感”、也更容易偏离约束。那除以 T 之后会发生什么还是用“今天天气真__”的例子T 0.2低温——“保守模式”分数差距被放大都除以 0.2等于乘以 5原本就领先的“好”概率飙升到 ~98%几乎每次都选它。T 1.0默认温度保持原始分布不变“好”62%、“不错”20%...按正常概率采样。T 1.5高温——“冒险模式”分数差距被缩小都除以 1.5“好”概率降到 ~35%“棒”、“不错”甚至“糟糕”都有更大机会被选中。一句话总结温度越低输出越确定、越“稳”温度越高输出越随机、越“野”。工程建议经验值非硬规则场景推荐温度说明结构化提取 / JSON 输出0 ~ 0.3配合严格 schema 解析失败重试策略评估 / 分析 / 代码评审0.4 ~ 0.8平衡确定性与表达多样性创作类内容文案、头脑风暴0.8 ~ 1.2增加多样性但要承担格式一致性风险追求确定性若需单元测试幂等或结果复现仅设Temperature0不够GPU 浮点误差仍可能导致非确定性。建议同时配置seed参数如 OpenAI/DeepSeek 支持。固定 seed 低温可最大程度减少波动。需注意即使配置seed以下情况仍可能导致结果不一致模型版本更新底层权重变化跨区域调用不同集群可能部署不同版本Top-p 采样即使 T0若 Top-p1 仍有随机性建议在 CI/CD 中仅将 LLM 调用用于冒烟测试核心逻辑仍依赖 Mock。Top-pNucleus Sampling与 Top-k缩小“抽签池”Temperature 调整的是概率分布的形状但不管怎么调词表里所有 Token 理论上都有被选中的可能哪怕概率极低。Top-p 和 Top-k 则更直接——把不靠谱的候选直接踢出抽签池。还是用“今天天气真__”的例子候选 Token概率累计概率好62%62%不错20%82%棒10%92%糟糕5%97%紫色≈0%≈100%Top-k 3只保留概率最高的 3 个候选好、不错、棒在这 3 个里重新分配概率后采样。“糟糕”和“紫色”直接出局。Top-p 0.9从高到低累加概率保留累计刚好达到 90% 的最小集合。这里“好 不错 棒 92% ≥ 90%”所以保留这 3 个。如果某个场景下头部更集中比如第一名就占了 95%Top-p 会自动只保留 1 个——这就是它比 Top-k 更灵活的地方。两者的区别Top-k 固定保留 k 个不管概率分布长什么样Top-p 根据概率自适应调整候选数量。实践中Top-p 更常用因为它能自动适应不同的概率分布。常见组合组合效果适用场景T0贪婪解码永远选最高分完全确定结构化输出、可复现场景低温 Top-p0.9相对稳定但允许措辞上有些变化分析报告、摘要中高温 Top-p0.95多样性较高但排除了极端离谱选项创意写作、对话⚠️ 注意贪婪解码虽然最稳定但可能更容易陷入重复循环比如反复输出同一段话。Max Tokens / Stop Sequences控制输出何时停止工程上需要意识到两点Max Tokens 是硬上限到上限会被强制截断——模型正写到一半也会被“掐断”。常见后果JSON 缺右括号、列表缺最后几项、句子写了一半。Stop Sequences停止词是软切断你可以指定一些字符串如\n\n或模型生成到这些内容时会自动停止。但如果 stop 设计不当可能提前截断关键字段。因此结构化输出场景要把“截断风险”当成一类失败路径来设计缓解策略。思维链模式的 Token 计算差异对于支持思维链的模型如 DeepSeek-R1max_tokens的值通常包含思考过程 最终回答两部分。例如设置max_tokens8192模型可能在思考链上消耗 5000 tokens最终回答只剩 3192 tokens 的预算。因此思维链场景需要为思考过程预留更大的 buffer。不同供应商的默认值和上限差异较大DeepSeek-R1 默认 32K、最大 64KOpenAI o1 系列的输出上限也高于普通模型。使用前务必查阅具体模型的 API 文档。Repetition / Presence / Frequency Penalty防止“复读机”你可能遇到过模型反复输出同一句话或者在长回答里不断重复相同的观点。Penalty 参数就是用来缓解这类问题的它们在解码时降低已出现 Token 的分数参数作用通俗理解Repetition Penalty降低所有已出现 Token 的概率“说过的词再说就扣分”Presence Penalty只要 Token 出现过就扣分不看次数“鼓励聊新话题”Frequency PenaltyToken 出现次数越多扣分越重“同一个词说了三遍重罚”⚠️ 工程陷阱结构化输出别乱加 PenaltyJSON 里字段名如name、score需要反复出现加了 Repetition Penalty 可能把必须出现的字段名也“惩罚掉”导致输出残缺。RAG 问答别加 Presence Penalty它会鼓励模型“说点新东西”反而降低对检索内容的忠实度faithfulness增加幻觉风险。保守建议如果你不确定这些参数的精确语义不同供应商定义可能不同建议保持默认值。用低温 更强 Prompt 约束 更短输出来获得稳定性比调 Penalty 更可控。思维链模式的参数限制部分模型如 DeepSeek-R1、OpenAI o1支持“思维链模式”Thinking Mode在生成最终回答前会先输出一段内部推理过程。这类模型有特殊的参数约束不支持的采样参数思维链模式下以下参数通常被忽略temperature、top_p采样控制参数presence_penalty、frequency_penalty惩罚参数原因思维链模式的设计目标是让模型“自由思考”采用模型内部固定的采样策略具体实现因供应商而异用户传入的采样参数会被忽略。工程建议调用思维链模型时不要依赖上述参数控制输出风格若需要更稳定的输出格式应通过 Prompt 约束而非采样参数关注模型返回的reasoning_content字段思考过程与content字段最终回答的区别流式输出Streaming默认情况下API 会等模型生成完所有内容后一次性返回。流式输出则是边生成边返回——模型每生成一个或几个Token就立刻推送给客户端用户更早看到内容开始出现。核心价值改善用户体验降低首字延迟TTFTTime-To-First-Token。常见误解澄清❌ “流式输出更快”——总耗时E2E latency不一定下降模型生成的总 Token 量相同❌ “流式输出更省钱”——Token 计费不变仍然受限流/配额影响⚠️ 如果你需要结构化输出如 JSON流式场景要考虑“半成品 JSON”在前端/网关层的处理——拿到的可能是{name: 张你需要等流结束后再解析或使用流式 JSON 解析器Logprobs对数概率部分 API如 OpenAI支持返回每个生成 Token 的对数概率logprobs可以理解为模型对该 Token 的“确信程度”logprob 越接近 0模型越确信值越小如 -5.0说明模型越“犹豫”。工程应用场景置信度评估提取“金额: 1000”时若对应 Token 的 logprob 很低说明模型不太确定可能需要人工复核。异常检测监控生产环境中模型输出的平均 logprob若突然下降可能提示 Prompt 漂移或输入数据异常。多候选对比获取 Top-N 候选 Token 及其概率用于纠错或二次排序。注意事项logprobs 会增加响应体积且并非所有供应商都支持。使用前请查阅 API 文档。参数速查表最后整理一张速查表方便你根据场景快速选择参数组合场景TemperatureTop-pPenalty其他建议JSON / 结构化输出0 ~ 0.31.0保持默认配合 Strict Mode 重试策略代码评审 / 技术分析0.4 ~ 0.70.9保持默认结合 CoT Prompt多轮对话0.6 ~ 0.80.9适度开启控制历史消息长度创意写作 / 头脑风暴0.8 ~ 1.20.95按需开启接受输出多样性做好后处理思维链模型—不支持——通过 Prompt 控制非采样参数总结当我们把大模型作为一个核心组件接入业务系统时第一步就是要抛弃拟人化的业务直觉建立起工程师的客观视角。回顾这篇扫盲内容核心其实就是处理好三个维度的工程权衡Token 是成本与性能的物理标尺它不仅决定了你的计费账单和推理延迟更决定了模型对文本的理解粒度。做容量规划时必须按 Token 算账而不是按字数算账。上下文窗口是极其稀缺的资源哪怕模型宣称支持 1M 上下文也不意味着可以毫无节制地堆砌数据。为 Prompt、RAG 检索片段、历史对话和输出预留做好严格的 Token 预算分配是走向生产环境的必修课。采样参数是业务场景的调音台如果追求稳定的 JSON 输出就果断压低 Temperature 并配合严格的 Schema如果需要创意与头脑风暴再适度放开 Temperature 和 Top-p。不要迷信默认参数要根据业务的容错率来定制。打好这层参数与原理的地基再去回顾我们之前讲过的 Agent 编排、RAG 检索或是 MCP 工具调用你会发现那些高阶架构的本质无非是在更好地调度这些底层 Token更精准地管理这个上下文窗口。
