LLM 核心参数完整详解：Token、上下文窗口、temperature、top_p、max_tokens、流式输出 SSE

目录

一、Token（令牌 / 词元）

1. 什么是 Token

2. Token 换算规则（通用参考）

3. 两类 Token

4. 举例

二、Context Window 上下文窗口（上下文长度）

1. 定义

2. 工作逻辑

3. 常见模型窗口规格

4. 实操问题

三、max_tokens 最大生成 token 数

1. 作用

2. 边界问题

四、temperature 温度（随机性 / 创造力参数）

1. 核心逻辑

2. 分段取值效果

3. 关键注意

五、top_p 核采样（Nucleus Sampling）

1. 定义

2. 和 temperature 配合逻辑

3. 对比 top_k（补充区分）

4. 取值参考

六、流式输出 & SSE（Server-Sent Events 服务器推送事件）

1. 什么是流式输出

2. SSE 底层协议原理

3. SSE 核心特点

4. 流式返回关键字段（通用 API 规范）

5. 优缺点

6. 和 WebSocket 区分

配套实战参数组合示例

场景 1：代码生成（严谨无幻觉）

场景 2：日常聊天 / 文案写作（平衡）

场景 3：创意小说写诗（高创造力）

补充关键联动关系总结

一、Token（令牌 / 词元）

1. 什么是 Token

大模型不直接处理文字，会把文本切分成最小处理单元，这个单元就是 Token，分为三类：

• 英文：单词、子词、标点、空格（hello=1token，unhappiness拆成un+happiness2 个 token）
• 中文：单汉字、偏旁组合、标点（1 个中文汉字≈1.5~2 个 token）
• 特殊：换行符、系统指令标记、结束符<|endoftext|>

2. Token 换算规则（通用参考）

• 英文：1 token ≈ 4 个字母 / 0.75 个单词
• 中文：1000 token ≈ 500～700 个汉字
• 计费、长度限制全部按 Token 计算，不是字符

3. 两类 Token

1. 输入 Token（prompt tokens）：你发给模型的提问、历史对话、系统提示词消耗的 token
2. 输出 Token（completion tokens）：模型生成回答消耗的 token 总消耗 = 输入 + 输出，计费按两者之和

4. 举例

句子：你好，介绍一下Java后端拆分后大概 12～15 token，模型读取全部 token 再推理生成回复。

二、Context Window 上下文窗口（上下文长度）

1. 定义

模型单次推理能一次性读取、记忆的最大总 Token 容量，是模型硬件 + 训练决定的硬上限。 公式：上下文总token = 系统提示词 + 全部历史对话 + 当前提问 + 即将生成的回答总和不能超过上下文窗口上限，否则报错 / 截断。

2. 工作逻辑

1. 对话轮次增多，历史记录持续累积 token；
2. 总量接近窗口上限时，必须丢弃最早的历史消息（截断）；
3. 一旦历史被截断，模型会遗忘前面的对话内容，出现 “失忆”。

3. 常见模型窗口规格

• 轻量模型：4k（4096 token）
• 通用商用：8k / 32k
• 超长上下文：128k、1M、12M token（长文档分析、整本书读取）

4. 实操问题

• 窗口 4k，系统词占 1k，单次回答 max_tokens 设 1k → 留给对话历史 + 当前提问只剩 2k；
• 长对话场景需要自动滑动窗口、摘要压缩历史，减少 token 占用。

三、max_tokens 最大生成 token 数

1. 作用

限制模型单次输出回答最多能生成多少 token，只管控输出，不包含输入 prompt。

• 设 500：模型最多输出约 250 个中文，写完立刻停止；
• 设 0 / 不填：使用模型默认上限；

2. 边界问题

1. 若剩余可用上下文空间 < max_tokens：以剩余空间为准，提前截断回答；
2. 回答写到 max_tokens 上限会强行中断，句子半截结束；
3. 用途：控制成本、防止无限生成长文本、限制回复长度。

四、temperature 温度（随机性 / 创造力参数）

1. 核心逻辑

控制模型选词概率分布的平滑程度，值域：0 ~ 2本质：调整 softmax 输出概率，温度越低越保守、越高越天马行空。

2. 分段取值效果

3. 关键注意

temperature=0 时，top_p 参数会自动失效，优先完全贪心采样。

五、top_p 核采样（Nucleus Sampling）

1. 定义

不固定只取前 N 个词，而是累积概率达到 p 阈值的最小词集合，值域0 ~ 1。 举个例子 top_p=0.9： 把所有候选词按概率从高到低排序，依次累加概率，直到总和 ≥90%，只在这批词里随机选词，剩下 10% 低概率词直接抛弃。

2. 和 temperature 配合逻辑

两者共同控制随机性，行业通用搭配规则：

1. 严谨场景：temp=0，top_p=1（只用贪心，top_p 无效）
2. 平衡通用：temp=0.7，top_p=0.9（最主流配置）
3. 创意写作：temp=1.2，top_p=0.95（放宽低概率词范围）

3. 对比 top_k（补充区分）

• top_k：固定只取概率前 k 个词；容易卡死多样性
• top_p：动态选词池，文本流畅度更好，主流 API 都默认用 top_p

4. 取值参考

• top_p=0.1：选词极度单一，接近 temp=0 效果
• top_p=0.9：行业标准
• top_p=1.0：放开全部候选词，完全由 temperature 控制随机度

六、流式输出 & SSE（Server-Sent Events 服务器推送事件）

1. 什么是流式输出

常规非流式（一次性返回）： 客户端发请求 → 模型完整生成全部文字 → 一次性返回完整 JSON，长回答会有几秒～几十秒空白等待。

流式输出： 模型每生成一小段 token，立刻分片实时传给前端，实现打字机逐字弹出效果，用户无需等待全文生成。

2. SSE 底层协议原理

SSE 是 HTTP 长连接单向推送标准，专门做服务端向客户端实时下发数据，是 LLM 流式接口底层标准：

1. 客户端发起普通 GET 请求，请求头携带：Accept: text/event-stream
2. 服务端不关闭 HTTP 连接，持续保持长连接；
3. 数据固定格式分片下发，每条消息结构：

data: {"token":"你好","finish_reason":null} \n\n

1. 单条 data 代表一段增量 token，持续推送；
2. 全部生成完成时推送结束标记：data: [DONE]
3. 客户端收到分片后拼接所有token字段，得到完整回答。

3. SSE 核心特点

• 基于标准 HTTP，无需 WebSocket，兼容性极强；
• 单向通信：只能服务端推送给客户端，客户端不能实时回传；
• 自动断线重连（浏览器原生支持）；
• 文本协议，轻量，适合大模型文字流输出。

4. 流式返回关键字段（通用 API 规范）

• choices[0].delta.content：增量新生成的单个 / 多个字符 token（流式独有，非流式用message.content）
• finish_reason：结束原因
  • null：还在持续输出
  • stop：正常回答结束
  • length：达到 max_tokens 上限强制截断

5. 优缺点

✅ 优点：交互体验好、首字延迟低、用户感知更快； ❌ 缺点：前端需要额外逻辑拼接分片、日志 / 存储要合并完整文本；无法中途修改提问（SSE 单向）。

6. 和 WebSocket 区分

• SSE：LLM 流式输出首选，简单、无额外握手，纯文本推送；
• WebSocket：双向通信，适合需要客户端实时上传数据的场景（语音实时对话等）。

配套实战参数组合示例

场景 1：代码生成（严谨无幻觉）

temperature=0 top_p=1.0 max_tokens=1024 stream=false（非流式一次性返回）

场景 2：日常聊天 / 文案写作（平衡）

temperature=0.7 top_p=0.9 max_tokens=2048 stream=true（SSE流式打字效果）

场景 3：创意小说写诗（高创造力）

temperature=1.2 top_p=0.95 max_tokens=4096 stream=true

补充关键联动关系总结

1. 所有输入 + 输出 token 总和 ≤ context window；
2. max_tokens 限制输出长度，总和超限会截断；
3. temperature + top_p 共同控制生成随机性，温度 0 时 top_p 失效；
4. stream=true 开启 SSE 流式分片输出，增量 delta 拼接完整回答。