Context window

百科 · 模型与对话 · 账本会撑爆

Messages 那篇：历史要整份再寄。System prompt 那篇：人设每一轮都要带着。两件事加在一起，请求只会越来越胖。

模型一次能吞下的量叫上下文窗口（context window）。单位是 token，不是字数，也不是「能贴多少页」。窗口是这次请求的上限，不是服务端给你开的仓库。

历史一长，账单就涨

Chatbot 第一篇的响应里已经有 usage。只问「你是谁」时，入口很短：

"usage": {
  "prompt_tokens": 8,
  "completion_tokens": 42,
  "total_tokens": 50
}

把改名历史贴回去再问，入口就变长：

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-chat",
    "messages": [
      {"role": "user", "content": "你以后称呼自己为小K"},
      {"role": "assistant", "content": "好的，我以后称呼自己为小K！有什么可以帮你的？"},
      {"role": "user", "content": "你是谁"}
    ],
    "stream": false
  }'

回来的 usage 会变成类似：

"usage": {
  "prompt_tokens": 52,
  "completion_tokens": 18,
  "total_tokens": 70
}

翻译成人话：

  • prompt_tokens：你寄进去的量（system + 历史 + 新问题）
  • completion_tokens：它吐出来的量
  • 多贴一句，入口就多一截。Chatbot 不会自己删旧账

窗口满了，不是模型「忘了」，是这次塞不下。怎么裁、怎么摘要，是后面 Compaction 的事。

max_tokens 不是窗口

容易混在一起：max_tokens 管的是这一轮回答最多吐多长，不是历史能塞多深。

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-chat",
    "max_tokens": 8,
    "messages": [
      {"role": "user", "content": "介绍一下你自己"}
    ],
    "stream": false
  }'

回来：

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "我是 DeepSeek，由深度求"
      },
      "finish_reason": "length"
    }
  ]
}

翻译成人话：

  • 窗口：入口多大，这次 messages 还能不能装下
  • max_tokens：这张嘴一次张多大
  • finish_reason 为 length：话没说完就被砍断；为 stop 才是它自己停的

窗口会出什么问题

还没满，也会出事。常见几条：

  • 塞不下：超过窗口，这次请求装不下。不是忘了，是门太窄。
  • 更贵、更慢：prompt_tokens 按整份历史计。多轮越聊越胖，钱和等待一起涨。
  • 注意力被摊薄：字都在 messages 里，不等于它都看见。上下文越长，每一句分到的注意力越薄，推理更容易漂。
  • 位置会影响准头：开头和结尾更被盯住，中间那段最容易被滑过去。人设在最前、最新问题在最后，还算占了好位置；二十轮闲聊中间随口说的「以后别用代码块」，常常等于没说。重要约束不要只埋在对话腰上。
  • 旧账互相打架：前一轮说叫小K，后一轮又改口。历史全贴回去时，它可能听新的、听旧的，或和稀泥——和两条 system 冲突一样，协议没有裁判。

所以「窗口很大」不等于「可以无限往里倒」。倒得越多，越贵，也越容易在中间把关键句弄丢。怎么裁、把哪一段留在头尾，是后面 Compaction 的事。

总结

  • 上下文窗口 = 一次请求里 messages 能装多少
  • 多轮和 system 都会把 prompt_tokens 推高；Chatbot 不会自己瘦身
  • max_tokens 只限制这一口答多长，不是窗口本身
  • 没满也会出事：更贵、更慢、注意力被摊薄；头尾比中间更吃得住
  • 到这里，对话底板的账本规则也齐了：能聊、能带历史、能划框，也知道会撑爆、会看走眼

参见