LLM 运行机制：Token、上下文窗口与采样参数怎么影响输出
原文：JavaGuide - LLM 运行机制 作者：Guide 字数：约 6173 字
一、核心主线
本文围绕 LLM 底层运行机制展开，解决两个核心问题：
- Token 与上下文窗口 → 决定成本与效果的上限
- 采样参数 → 决定输出稳定性与多样性的调节手段
底层逻辑：自回归生成（Autoregressive Generation） —— 每次只预测下一个 Token，将其加入上下文，循环往复。
二、Token：模型的"阅读单位"
2.1 Token 的本质
| 对比维度 | 人类阅读 | LLM 处理 |
|---|---|---|
| 中文 | 逐字阅读 | 子词碎片（不固定字数） |
| 英文 | 逐词阅读 | 子词碎片（可能拆词） |
Tokenizer 采用折中方案：高频词保留整体，低频词拆成片段（BPE、Unigram 等子词切分算法）
类比：Token 如同乐高积木，常用词是大块，生僻词用小零件拼
2.2 中英文 Token 消耗差异（关键成本因素）
| 语言 | 经验估算 | DeepSeek 官方数据 |
|---|---|---|
| 英文 | 1 Token ≈ 3~4 字符 | 1 字符 ≈ 0.3 Token → 1 Token ≈ 3.3 字符 |
| 中文 | 1 Token ≈ 1~2 汉字 | 1 字符 ≈ 0.6 Token → 1 Token ≈ 1.7 字符 |
成本趋势：新模型词表扩大，中文压缩率提升
- GPT-4o（o200k_base，~20万词表）
- Qwen2.5（~15万词表）
- 但"趋近 1 字 1 Token"仅适用于高频词，不可作为成本估算基准
2.3 实际 Token 化示例
原文：你好，我是 Guide。
切分：[你好] [，] [我是] [Guide] [。]
统计：12 字符 → 5 Token → 压缩比 2.4x2.4 特殊 Token（隐藏开销）
| 特殊 Token | 用途 | 示例 |
|---|---|---|
| BOS | 序列开始标记 | <s> |
| EOS | 序列结束标记 | </s> |
| PAD | 批处理填充 | <pad> |
| 工具调用标记 | Function Calling 边界 | <tool_call/> |
⚠️ 这些对用户不可见，但计入上下文窗口和计费
三、多模态输入的 Token 开销
图片并非"零成本"，会被转换为 Token 矩阵：
| 模型 | 计算方式 | 1024×1024 图片估算 |
|---|---|---|
| GPT-4o | 分辨率 + 细节模式 | 低细节 ~85 tokens / 高细节 ~1105~765 tokens |
| Claude 3.5 | 缩略图 ~5 / 全图 ~85 | 取决于模式 |
| Gemini | 按分辨率计算 | ~258 tokens（标准） |
工程启示：
- 多模态 RAG 必须纳入图片 Token 预算
- 仅需 OCR 时，先用专用服务提取文本更经济
四、上下文窗口：极其稀缺的"工作记忆"
4.1 基本概念
- 标称上限：128K / 200K / 1M 指的是输入+输出的总 Token 上限
- 实际有效内容远小于标称值（存在大量隐形成本）
4.2 上下文窗口的"隐形占用"
| 占用项 | 说明 |
|---|---|
| System Prompt | 调节模型行为的隐藏指令 |
| User Prompt | 业务数据与指令 |
| 多轮对话历史 | 过往消息记录 |
| RAG 检索片段 | 外部知识库补充 |
| 工具调用 Schema | 函数定义与参数结构 |
| 格式开销 | 特殊字符、换行、Markdown |
| 模型输出 Token | 输出也占用窗口！ |
典型分配示例（16K 结构化输出场景）：System 38% | User 31% | 历史 13% | 安全边距 9% | 输出预留 9%
4.3 关键区分
| 概念 | 含义 |
|---|---|
| 上下文窗口（Context Window） | 输入+输出的总容量 |
| 最大生成长度 | 单次输出上限（通常远小于窗口） |
- GPT-4o: max_tokens 最大 16K
- DeepSeek V3: 最大输出 8K
- o1 系列: 支持 max_completion_tokens
4.4 思维链模型的特殊处理
DeepSeek-R1 等模型的 reasoning_content（思考过程）默认不进入下一轮上下文，仅 content（最终回答）参与后续对话。
| 影响 | 说明 |
|---|---|
| ✅ 节省窗口 | 无需为思考过程额外占用 |
| ⚠️ 需手动处理 | 若后续需参考推理过程，要手动拼接 |
| 📋 SDK 差异 | 部分供应商自动处理，需查文档 |
4.5 长上下文的技术瓶颈
自注意力机制的 O(N²) 复杂度：
- 序列长度翻倍 → 计算需求变为 4 倍
- TTFT（首字延迟）显著增加
- 攻击面扩大
优化技术：FlashAttention、GQA/MQA、Sliding Window Attention、Ring Attention（降低开销但未改变理论复杂度）
4.6 上下文溢出的真实表现
| 现象 | 原因 |
|---|---|
| 忽略早期约束 | System Prompt 距离生成点太远，注意力衰减 |
| "中间丢失" | 对开头结尾敏感，中间信息召回率低 |
| 回答漂移 | 前半段切题，后半段跑题 |
| RAG 失效 | 检索文档过多，关键信息稀释或证据链断裂 |
| 成本延迟激增 | 1M 上下文导致 TTFT 和费用大幅上升 |
五、计费机制与成本优化
5.1 输入/输出 Token 计费差异
输出价格通常是输入的 2~4 倍：
| 模型 | 输入 /1M | 输出 /1M | 输出/输入比 |
|---|---|---|---|
| GPT-4o | $2.50 | $10.00 | 4x |
| Claude 3.5 Sonnet | $3.00 | $15.00 | 5x |
| DeepSeek V3 | ¥0.5 | ¥2.0 | 4x |
| DeepSeek-R1 | ¥4.0 | ¥16.0 | 4x |
思维链模型的 reasoning tokens 按输出价格计费，成本更高
5.2 Prompt Caching：降低重复成本
原理：缓存可复用的前缀部分，下次请求相同前缀时按"缓存读取"计费（10%~50% 正常价格）
| 供应商 | 功能名 | 缓存时长 | 折扣 |
|---|---|---|---|
| OpenAI | Prompt Caching | 5~10 分钟 | ~50% |
| Anthropic | Prompt Caching | 5 分钟 | ~10% |
| DeepSeek | Context Caching | 10~30 分钟 | ~25% |
工程建议：
- 不变内容放前（System Prompt、工具定义、RAG Context）
- 变化内容放后（User Prompt）
- 监控
cache_read_tokens和cache_creation_tokens
5.3 Token 预算公式
基础公式：
window ≥ input_tokens + max_output_tokens思维链模型调整：
window ≥ input_tokens + reasoning_tokens + max_output_tokensreasoning_tokens 建议按 max_output_tokens 的 2~3 倍预留
反向预算策略（更实用）：
- 先定
max_output_tokens（结构化输出通常较短） - 输入预留 10%~20% 安全边距
- 超预算时"减输入"而非赌模型自我约束：
- 减少 RAG Top-K 或片段去重
- 长字段摘要/截断
- 多段任务拆多次调用
六、采样参数：从 logits 到输出
6.1 核心流程
模型打分（logits）→ softmax 变概率 → 按概率分布采样 → 输出 Token
↑___________________________________________|
解码参数在此干预6.2 Temperature：控制"冒险程度"
公式：p(t) = softmax(z_t / T)
| T 值 | 效果 | 场景 |
|---|---|---|
| T → 0 | 趋近贪婪解码，最高分概率→100% | 结构化输出 |
| T < 1 | 分布更尖锐，倾向高概率 Token | 分析、评审 |
| T = 1 | 保持原始分布 | 默认 |
| T > 1 | 分布更平坦，低概率 Token 易入选 | 创意写作 |
工程经验值：
| 场景 | 推荐温度 | 备注 |
|---|---|---|
| 结构化提取 / JSON | 0 ~ 0.3 | 配合 strict schema + 重试 |
| 评估 / 分析 / 代码评审 | 0.4 ~ 0.8 | 平衡确定性与多样性 |
| 创作类（文案、头脑风暴） | 0.8 ~ 1.2+ | 承担格式一致性风险 |
追求确定性的完整配置：
Temperature=0+seed参数（OpenAI/DeepSeek 支持）- ⚠️ 但仍可能不一致：模型版本更新、跨区域调用、Top-p < 1
6.3 Top-p vs Top-k：缩小"抽签池"
| 参数 | 机制 | 特点 |
|---|---|---|
| Top-k | 固定保留概率最高的 k 个 | 死板，不随分布自适应 |
| Top-p | 保留累计概率达 p 的最小集合 | 更常用，自适应调整 |
示例（"今天天气真__"）：
| 候选 | 概率 | 累计 |
|---|---|---|
| 好 | 62% | 62% |
| 不错 | 20% | 82% |
| 棒 | 10% | 92% |
| 糟糕 | 5% | 97% |
- Top-k=3：保留"好、不错、棒"（固定 3 个）
- Top-p=0.9：保留"好、不错、棒"（累计 92% ≥ 90%，自动 3 个）
- 若头部更集中（如"好"占 95%），Top-p 自动只保留 1 个
常见组合：
| 组合 | 效果 | 场景 |
|---|---|---|
| T=0 | 贪婪解码，完全确定 | 结构化输出、可复现 |
| 低温 + Top-p=0.9 | 相对稳定，允许措辞变化 | 分析报告、摘要 |
| 中高温 + Top-p=0.95 | 多样性较高，排除极端离谱 | 创意写作、对话 |
⚠️ 贪婪解码最稳定，但可能更容易陷入重复循环
6.4 停止条件与截断风险
| 机制 | 性质 | 风险 |
|---|---|---|
| Max Tokens | 硬上限 | 强制截断，JSON 缺括号、句子写一半 |
| Stop Sequences | 软切断 | 设计不当可能提前截断关键字段 |
思维链模型的特殊注意：
max_tokens包含 reasoning + 最终回答- 例：max_tokens=8192，思考用 5000，最终回答仅剩 3192
6.5 Penalty 参数：对抗复读
| 参数 | 机制 | 通俗理解 |
|---|---|---|
| Repetition Penalty | 降低所有已出现 Token 概率 | "说过的词，再说扣分" |
| Presence Penalty | 出现过就扣分（不计次数） | "鼓励聊新话题" |
| Frequency Penalty | 出现次数越多扣分越重 | "同词说三遍，重罚" |
工程陷阱：
- ❌ 结构化输出别加 Penalty：会惩罚必须重复的字段名（如
"name"、"score"） - ❌ RAG 问答别加 Presence Penalty：降低对检索内容的忠实度，增加幻觉
- ✅ 保守建议：不确定时保持默认，用低温+强 Prompt+短输出换稳定性
6.6 思维链模型的参数限制
DeepSeek-R1 / OpenAI o1 等模型：
- ❌ 忽略
temperature、top_p - ❌ 忽略
presence_penalty、frequency_penalty - 原因：设计目标为"自由思考"，采用内部固定采样策略
工程建议：通过 Prompt 约束 而非采样参数控制输出格式
6.7 流式输出与首字延迟（TTFT）
| 维度 | 说明 |
|---|---|
| 核心价值 | 改善用户体验，降低 TTFT |
| 常见误解① | "更快" → 总耗时不一定下降 |
| 常见误解② | "更省钱" → Token 计费不变 |
| 结构化注意 | 需处理"半成品 JSON"的前端/网关层 |
6.8 Logprobs：置信度排查
定义：每个生成 Token 的对数概率，越接近 0 越确信
| 应用场景 | 说明 |
|---|---|
| 置信度评估 | logprob 低的提取结果需人工复核 |
| 异常检测 | 监控平均 logprob 突降，提示 Prompt 漂移或数据异常 |
| 多候选对比 | Top-N 候选用于纠错或二次排序 |
注意：增加响应体积，非所有供应商支持
七、采样参数配置速查表
| 场景 | Temperature | Top-p | Penalty | 其他建议 |
|---|---|---|---|---|
| JSON / 结构化输出 | 0 ~ 0.3 | 1.0 | 默认 | Strict Mode + 重试策略 |
| 代码评审 / 技术分析 | 0.4 ~ 0.7 | 0.9 | 默认 | 结合 CoT Prompt |
| 多轮对话 | 0.6 ~ 0.8 | 0.9 | 适度开启 | 控制历史消息长度 |
| 创意写作 / 头脑风暴 | 0.8 ~ 1.2 | 0.95 | 按需开启 | 接受多样性，做好后处理 |
| 思维链模型 | —（不支持） | — | — | 通过 Prompt 控制 |
八、核心总结：三个维度的工程权衡
| 维度 | 核心认知 | 行动要点 |
|---|---|---|
| Token | 成本与性能的物理标尺 | 按 Token 算账，非按字数；容量规划用经验估算，精确计费用 API 返回的 usage |
| 上下文窗口 | 极其稀缺的资源 | 严格预算分配：Prompt + RAG + 历史 + 输出预留；超预算时"减输入" |
| 采样参数 | 业务场景的调音台 | 根据容错率定制：JSON 压低温，创意放高温；不迷信默认参数 |
高阶架构的本质：更好地调度底层 Token，更精准地管理上下文窗口
九、关键工具链接
- OpenAI Tokenizer — 官方 Token 计算工具