Skip to main content

​
总结

  • LLM 的输入是模型能看到的文本上下文，
  • LLM 的输出是模型一个 Token 一个 Token 生成的回答，
  • LLM 的缓存是为了复用已计算内容、加速生成和降低成本而保存的中间结果

​
1. LLM 输入是什么？

LLM 输入就是模型在回答前能看到的内容。 它不只是用户当前说的一句话，还可能包括很多部分： 
系统设定：
你是一个专业的编程助手。

历史对话：
用户：什么是 Token？
助手：Token 是模型处理文本的基本单位。

当前问题：
用户：什么是 LLM 输入/输出/缓存？
这些内容会一起组成模型的输入。

​
输入通常包括哪些？

​
1. 用户问题

也就是你真正问模型的话： 
什么是 LLM 输入/输出/缓存？

​
2. 系统提示词

系统提示词通常用于规定模型的身份、风格和边界，比如： 
你是一个 helpful coding assistant。
请用中文回答。
不要输出违法内容。
你平时不一定看得到，但它会影响模型的回答方式。

​
3. 历史对话

如果是多轮聊天，模型需要看到前面的对话，才能理解上下文。 例如： 
用户：我刚才说的那个概念是什么意思？
如果没有历史上下文，模型不知道“那个概念”指什么。

​
4. 工具或外部信息

有些 LLM 应用会把搜索结果、数据库内容、文档片段也塞进输入里。 例如： 
根据以下文档回答用户问题：
文档内容：……
用户问题：……
这类方式常见于 RAG，也就是“检索增强生成”。

​
2. 输入会被变成 Token

LLM 不直接处理文字，而是先把文字切成 Token。 比如： 
我喜欢人工智能
可能会被切成： 
我 / 喜欢 / 人工智能
英文也可能按词或词片段切： 
transformer
可能切成： 
trans / former
模型真正接收的是这些 Token 对应的数字。 所以很多 LLM API 会按 Token 计费，而不是按字数计费。

​
3. 什么是上下文窗口？

LLM 能看到的输入不是无限长的，而是有长度限制，叫 上下文窗口。 比如一个模型支持： 
128K tokens 上下文
意思是它最多能同时处理大约 128K 个 Token 的内容。 如果输入太长，可能会发生：
  • 超过限制，直接报错
  • 系统自动截断较早内容
  • 模型忘掉很久以前的对话
  • 需要做摘要或检索来压缩上下文

​
4. LLM 输出是什么？

LLM 输出就是模型生成的回答。 例如你输入： 
请解释一下黑洞。
模型输出： 
黑洞是一种引力极强的天体，连光也无法逃脱……
从技术上看，输出也是一个个 Token 生成出来的。

​
模型不是一次性写完整答案

LLM 通常是这样生成的： 
黑
黑洞
黑洞是
黑洞是一种
黑洞是一种引力
黑洞是一种引力极强
……
它每一步都在做一件事：
根据当前已经看到的内容，预测下一个最可能的 Token。
然后把新生成的 Token 加回上下文，再继续预测下一个。

​
5. 输出也有长度限制

输出通常也有最大长度限制，例如： 
max_tokens = 1000
意思是最多生成 1000 个 Token。 如果限制太小，回答可能会突然结束。 比如： 
Transformer 的核心机制是自注意力，它可以
然后就没了。 这不是模型不会了，而是输出长度达到限制了。

​
6. 什么是 LLM 缓存？

LLM 里的“缓存”可以有几种意思，最常见的是：
  1. KV Cache
  2. Prompt Cache / 前缀缓存
  3. 应用层缓存
它们目的都差不多：
避免重复计算，提高速度，降低成本。
这里主要讲述KV Cache

​
7. KV Cache 是什么？

KV Cache 是 Transformer 推理时最重要的一种缓存。 在生成回答时，模型需要不断参考前面已经出现过的 Token。 如果每生成一个新 Token，都把前面所有内容重新计算一遍，会非常浪费。 所以模型会把前面 Token 的一些中间计算结果保存起来，这些中间结果通常叫： 
Key / Value
也就是 KV Cache。

​
用类比理解 KV Cache

假设模型已经读过一句话： 
太阳系是由太阳和围绕它运行的天体组成的。
接下来要继续生成。 如果没有缓存，模型每写一个字，都要重新“读一遍”整句话。 有了 KV Cache，就像模型做了读书笔记： 
我已经读过前面的内容了，关键关系我都记下来了。
下一步生成时，它只需要处理最新生成的 Token，并结合之前保存的缓存。

​
KV Cache 的作用

KV Cache 主要带来几个好处：
  • 生成速度更快
  • 避免重复计算
  • 长文本生成时尤其重要
但它也有代价：
  • 会占用显存/内存
  • 上下文越长，缓存越大
  • 并发用户越多，缓存压力越大

​
8. 输入、输出、缓存之间的关系

可以用一个简化流程表示： 
用户输入
  ↓
文本切成 Token
  ↓
模型读取输入
  ↓
生成中间计算结果
  ↓
写入 KV Cache
  ↓
预测下一个 Token
  ↓
输出 Token
  ↓
新 Token 又加入上下文
  ↓
继续生成
生成时，模型会不断重复： 
看上下文 → 用缓存 → 预测下一个 Token → 输出 → 更新缓存

​
9. 一个简单比喻

可以把 LLM 想象成一个学生在做阅读理解。

​
输入

老师给学生看的材料： 
题目、背景资料、历史对话、要求

​
输出

学生写下来的答案： 
这篇文章主要讲了……

​
缓存

学生边读边做的笔记： 
前文说主角是小明
这里的“他”指小明
这段讲的是原因
有了笔记，学生不用每写一句答案都从头重读全文。

​
11. 常见误区

​
误区一：LLM 真的“永久记住”了所有聊天内容？

通常不是。 在一次对话里，历史消息会作为输入再次发给模型。
模型看起来像记得，是因为系统把历史对话放进了上下文。 如果历史内容没有被传进去，模型通常就不知道了。

​
误区二：缓存等于记忆？

不完全是。 KV Cache 主要是推理过程中的临时缓存，通常只在当前请求或当前会话生成过程中有效。 它不是长期记忆。 长期记忆一般需要额外系统支持，比如：
  • 数据库
  • 向量库
  • 用户画像
  • 历史摘要
  • RAG 检索系统

​
误区三：输入越长越好？

不一定。 输入太长会带来：
  • 成本更高
  • 延迟更高
  • 重要信息被淹没
  • 可能超过上下文窗口
  • 模型注意力被无关内容分散
所以实际应用中，经常需要筛选、摘要、检索最相关的信息。