1 长上下文与高效注意力要回答什么
把 1 份短文本交给模型分类，输入通常很容易放下。把 1 个项目的实验记录、论文摘要和多轮讨论放在同次请求里，问题就变了：模型能否接收这些材料，能否找到真正有关的证据，系统又能否承受同时到来的请求？长上下文讨论的是可处理的信息范围，高效注意力讨论的是处理这些信息时，怎样减少计算和内存负担。两者有关，却不能互相替代。
上下文是模型在当前请求中可使用的输入及相关历史，长度通常按 token 计算。token 是分词后的单位，不等于汉字、单词或字节。相同的汉字数，遇到代码、表格、特殊符号和不同分词器，token 数可能不同。产品界面允许粘贴多少字，也不等于模型实际收到了多少 token。讨论长度之前，应先记录分词器、输入模板，以及输出预留空间。
本课围绕公开的 20 Newsgroups 新闻组文本分类材料展开。可以从公开训练部分划出训练集和验证集，保留公开测试部分用于最终评价；例如在训练部分做分层的 80% 与 20% 划分。分类目标是新闻组主题，输入可包含正文、标题和引用段。用短片段做基线，再把更长正文或有关背景加入上下文，观察 macro-F1 是否改善。macro-F1 是各类别 F1 的平均值，能帮助我们看到样本较少的类别有没有被忽视。
这个任务也会揭露“更多文字”带来的混杂因素。发件人、邮件地址和固定签名可能泄露主题；引用段可能重复训练材料；某些类别的文章天然更长。若长输入的分数更高，原因可能是读到了标签线索，而不是更会整合证据。必须保持清洗规则和划分固定，检查重复内容，并按类别、长度分别报告表现。若删除标题，就对所有方案采用相同规则。
另一项受控任务是在允许使用的公开文本中插入明确的日期或实验编号，要求模型找出答案并指出来源段落。它能测试位置和长度带来的影响，但不能代替真实分类。分类关心语义判断，定位任务关心特定证据是否可取回。把这 2 类证据放在一起，我们才能区分“读得到”“找得到”和“用得对”。
本课要回答的核心问题是：在固定任务与质量要求下，需要多长的有效上下文，以及用什么代价维持它。所谓有效，是指关键证据位于不同位置时，模型仍能稳定完成任务。接口标注的最大长度只是接收边界；稳定质量、响应时间和可服务并发构成了另外的边界。后续每项技术都要回到这几条边界检验。
2 复杂度、内存与精度
注意力可以先理解为“每个位置根据当前需求，从其他位置的信息中分配关注”。查询 Q 表达想找什么，键 K 帮助匹配，值 V 提供可汇总的内容。标准全注意力让长度为 n 的输入产生约 n² 规模的位置配对。忽略维度和层数等固定因素，长度从 4096 增加到 8192，配对规模约增加到 4 倍。这里描述的是主要交互规模，不代表整次请求的耗时一定恰好增加 4 倍。
计算量与峰值内存也应分开。朴素实现可能保存很大的注意力分数矩阵；更高效的精确实现可分块计算，减少中间结果的读写和驻留空间。它们可以显著改善实际速度与内存，却仍可能保留标准注意力的平方计算增长。看到“没有显式保存完整矩阵”，不能就宣布算法变成线性；看到理论复杂度相同，也不能断言工程速度相同。
生成式推理通常分为预填充和解码。预填充处理已知输入前缀，建立供后续生成使用的信息；解码每次生成后续 token，并利用此前的 K、V。KV 缓存避免重复计算历史位置的这些表示，但新位置仍要读取相关历史。首 token 延迟受预填充、排队等因素影响；逐 token 延迟更能反映解码阶段的持续开销。最终用户感知的总时长还包含输出长度。
缓存的简单估算为：KV 字节数约等于 2 × 层数 × KV 头数 × 每头维度 × 每元素字节数 × 已缓存 token 数 × 活动请求数。开头的 2 代表 K 和 V。假设有 32 层、8 个 KV 头、每头 128 维、每元素 2 字节，每个 token 约需 128 KiB；每请求缓存 16384 个 token，就约需 2 GiB。该式不包含权重、临时张量、分配碎片等，也不适用于所有特殊缓存策略。
这里的 KV 头数不一定等于查询头数，有些模型会共享 K、V 以减少缓存。我们暂不展开结构推导，只记住估算必须使用真实模型配置。训练还涉及梯度、优化器状态和激活保存，不能用推理缓存公式推算完整训练显存。即使只研究推理，也要把模型权重占用与随请求增长的缓存占用分别列出。
“精度”还有 2 种容易混淆的意思：数值精度指每个数使用多少位表示，任务质量指预测是否正确。减小缓存元素字节数可能节省内存，但质量是否下降要实测；权重量化也不意味着 KV 自动量化。分类用 precision、recall、F1 等任务指标评价；容量用 GiB、活动 token 和失败率评价。不能把某个内存数字变好，直接当作模型效果变好。
3 稀疏、窗口与线性近似
既然任意位置之间都建立联系很贵，能否只保留部分联系？局部窗口给出最直观的做法：每个位置直接关注附近 w 个位置。固定窗口大小时，交互规模约为 n × w。对于局部线索密集的文本，这可能足够；对于开头定义规则、末尾要求应用规则的任务，关键联系却可能跨出窗口。经过多层传播，有些远处信息仍能间接到达，但不应把这种可能性当作可靠保证。
稀疏注意力进一步选择特定连接，例如局部联系配合少量全局位置，或在分块之间保留指定通路。它像在信息地图上修路：道路少了，建造成本下降，但必须检查重要地点是否仍可到达。若关键实验条件在前部、结果在后部，只有其中 1 段进入全局位置，模型可能无法正确比较。连接图的设计必须与任务结构相容。
线性近似尝试改变汇总方式，避免显式处理所有位置配对。在某些假设与实现下，它能让主要计算随长度近似线性增长。但“线性”不是无条件的质量保证，也不是所有部分都没有额外成本。压缩汇总可能丢掉对精确检索有用的区别；需要逐字核对编号、否定词或例外条件时，平均语义接近远远不够。入门阶段只需掌握这种取舍，不必推导核函数或递推状态。
还要区分“改算法”和“改执行方式”。分块执行精确注意力可以保持原来的数学计算目标；删去部分连接或采用近似汇总则改变了信息交互方式。两种改进可能叠加，但验证重点不同：前者主要比较数值容差和运行性能，后者还必须检验任务质量是否受损。不能只凭技术名称推断节省比例，更不能假定换个开关就能把现有模型改成另一种结构。
对于产品团队，另有输入层面的办法：检索相关段落、先做分段整理、去掉重复引用，再把有依据的材料交给模型。这些办法减少进入模型的 token，不属于注意力内部算法。它们同样需要评价，因为检索漏掉关键句，后面的模型再强也无法补回。若分段摘要删除了“除非”“不包含”等限定，最终结论可能方向相反。
回到新闻组分类：局部窗口可能足以捕捉显著主题词，但对引用与作者反驳的区分未必可靠。可以比较含完整正文、固定窗口截取、按段检索 3 种输入策略，并检查相同测试样本上的错误变化。若只挑模型容易识别的长文章，任何方法都可能看起来很好。高效方法的价值在于同等质量下节省资源，或在同等资源下解决更大的问题；评价必须明确是哪种目标。
4 动手：对照一次长上下文代价
这次实验不要求训练新的注意力结构。选择可在现有设备运行、已声明支持目标长度的开放模型，固定其权重版本、分词器、推理实现和数值格式。设备无法承担较长输入时，就缩小长度档位并说明限制。先研究同个模型在不同输入长度下的行为，再比较输入策略；同时更换模型与输入方式，会让性能差异难以解释。
先整理实验表。记录模型标识、设备可用显存、最大生成 token、并发、输入实际 token、是否截断及随机种子。把长度设为 2048、4096、8192，具体档位须落在模型支持范围内。所有计时都使用同样的运行条件，先做预热，再执行固定样本集合；同时保留每条请求的结果，不能只留平均值。计时若不包含排队，应在报告中明确注明。
质量实验使用 2 组材料。真实任务组从冻结的测试集中按类别和长度抽样，要求输出固定类别标签，格式错误也计入失败；分别报告 macro-F1、每类 precision 和 recall。长度截取必须按同样规则执行，并报告每档包含多少完整样本。若样本本来只有 1000 token，把上限从 2048 调到 8192 不会真的增加输入长度，不能据此比较长输入代价。
受控定位组则构造实际达到目标长度的文本，将需要回答的事实分别放在前部、中部、后部。尽量保持词汇、答案形式和干扰材料一致，使用多份基础材料轮换位置。加入“没有给出答案”的负例，防止模型总是猜出某个编号。报告答案完全匹配率、证据段命中率，以及无答案时的拒答正确率。构造材料不得混入真实任务的训练样本或最终测试标签。
性能实验先固定输出长度上限和并发为 1，比较不同长度的首 token 延迟、逐 token 延迟、峰值显存与实际输出 token 数。随后使用同组长度分布增加并发，例如 1、2、4。报告中位数和 P95 延迟；P95 表示约 95% 请求的延迟不超过该值。样本太少时高分位数不稳定，应保留样本量，避免把偶然值写成容量承诺。
对照结果表应把“长度档位、实际长度分布、质量、首 token 延迟、峰值显存、失败率”并列。假如显存增长近似线性、首 token 延迟增长更快，这与缓存和预填充的不同机制相符；若显存突然跳升，则进一步考虑批处理、分配策略或实现切换。这里只提出解释线索，不能仅凭曲线形状认定原因。最后用验证集确定策略，最终测试集只用于确认结论，避免反复调到测试集上。
5 上下文长度与成本取舍
上下文预算应由有效证据决定。假设主题分类中，正文前 2048 token 已覆盖大部分有用线索，继续增加长度只带来很小的 macro-F1 改善，而 P95 延迟明显上升，那么默认使用最长输入就缺乏依据。但若特定类别的关键反驳常出现在末尾，总体平均分可能掩盖它们的 recall 下降。预算选择要同时看总体收益和受影响样本，不能只追求单个汇总分数。
把输入拆成固定开销、用户内容和参考证据更容易管理。固定开销包括任务说明、输出格式和必要约束；用户内容包括当前问题及必须保留的历史；参考证据包括检索段落或原文。若总预算为 8192 token，预留输出 2048，就不能把剩余输入额度全部交给原文，还要扣除提示模板和其他内容。真实可用额度以接口和模型的长度定义为准，并在分词后检查。
输出预算也会影响容量。用户要求短标签时，允许生成数千 token 通常没有必要；分析报告则需要更长的输出空间。若运行时按最大输出预留资源，过大的上限可能压低可接收并发；若按实际增长分配，仍需避免所有请求同时增长时越界。缩小输出上限必须经过任务检查，不能为了降低开销把证据解释截断到无法使用。
交互中的缓存公式揭示了直接取舍：在固定结构与缓存格式下，输入加输出的总长度翻倍，单请求缓存也约翻倍；活动请求数翻倍，总缓存再翻倍。标准全注意力的预填充交互规模则对输入长度更敏感。滑块没有预测准确率，因为数据决定质量曲线，不能从 token 数直接算出 F1。预算工具适合排除明显不可行的配置，压测与任务评测才能确认可行配置。
成本也不只指单请求耗时。较长请求可能占用缓存更久，降低吞吐，使短请求等待；分段整理会增加调用次数；检索需要维护索引并承担漏检风险。比较方案时应覆盖完整流程，包括检索、整理、生成和失败重试。若系统使用按 token 收费的服务，就记录实际计费规则；若自行部署，就记录设备占用时间和目标吞吐，无须把两者强行换成同种价格。
建议先选择满足质量底线的较短默认预算，再为需要更多证据的请求提供扩展路径。例如主题分类先处理正文，证据不足时加入选出的背景段，并单独统计升级比例。升级条件需要在验证集上制定，模型自述“有信心”不能自动充当可靠概率。最终方案可能是多个长度档位配合准入策略，而不是所有请求共享同个最大长度。
6 常见坑：宣称支持却未测中间迷失
“支持 32768 token”通常只能说明某种配置接受这个长度，不能证明其中任意位置的事实都能被稳定使用。中间迷失描述的是关键证据位于较长上下文中部时，表现可能差于位于前后位置的情况。它不是每个模型、每项任务都必然出现的定律；我们需要把位置作为实验变量，而不是只测开头或结尾后就宣称全范围可靠。
位置评测必须避免答案本身变化造成干扰。可准备 30 份不同基础材料，每份分别生成前、中、后 3 个版本，在多个长度档位重复。位置按实际 token 比例定义，例如约 10%、50%、90%，不能按网页滚动位置定义。记录每次答案和引用段，按基础材料配对比较。若模型只在某个编号上失败，先排查分词、歧义或重复编号，再解释为位置效应。
另个常见问题是静默截断。应用层可能先按字符裁剪，推理端再按 token 限制截断，导致显示上传成功但中部或尾部未进入模型。要保存实际输入长度、截断方向及证据是否仍在输入中。若关键段已被删掉，错误属于输入管线；若段落完整却未被使用，才有理由继续研究注意力、提示或任务难度。两种故障的修复方法不同。
质量污染也会制造虚假的长上下文收益。在新闻组数据中，重复引文、签名和主题字段可能让分类过于容易；把测试标签做成示例放入提示，更是直接泄漏。若用于客户流失预测的表格描述进入上下文，取消服务后才产生的字段同样可能泄漏结局。长上下文让更多字段进入模型，也扩大了泄漏面，不能因为输入是自然语言就忽略数据时间边界。
类别不平衡和分布变化则会制造虚假的稳定。高频类别的正确预测可能撑住 accuracy，少数类别的 recall 却持续下降；较长的新文章可能来自不同年代、不同写作风格，而不是单纯多了 token。应固定样本比较长度策略，再用独立的时间段或新来源测试分布变化。AUC 适合有连续评分的相应分类设置，但它不能代替实际决策阈值下的 precision、recall，也不能评价证据引用是否正确。
最后，不要用单次成功截图证明长上下文能力。至少覆盖无答案、冲突证据、跨段条件和无关材料增加等情形。若原文中“实验 A 有效”后来被“复核后撤回”修正，模型必须遵循任务规定处理最新结论，而不是挑到任意匹配句就算正确。评测应明确事实时间、引用规则和冲突处理方式，让失败能被定位到具体要求。
7 案例：KV 增长挤爆推理池
某研究团队搭建公开论文材料的主题分类与证据说明工具。原先大多数请求只有 2048 token，单请求测试表现正常。后来用户开始上传完整材料，输入增至 16384 token，还要求输出较长说明。系统仍按“同时最多 8 个请求”准入，短请求延迟突然升高，偶尔出现内存分配失败。以下数字是教学估算，用来解释排查路径，并非公开测量结果。
团队先把显存占用分为权重、运行时临时空间、KV 缓存和余量。在固定模型与缓存格式下，每个 token 的 KV 约为 128 KiB；每请求输入 16384 token，约需 2 GiB。再预留 4096 个输出 token，每请求最终约需 2.5 GiB。若给 KV 的预算只有 16 GiB，8 个请求理论上就要 20 GiB，还没有考虑额外分配余量。单请求能运行，无法证明该并发也能运行。
排查日志发现，失败并不总出现在上传后立即发生。有的请求已经开始生成，后续缓存继续增长才触及边界；有的运行时选择排队或暂停部分工作，表现为尾延迟变差。较长预填充还可能与其他请求竞争计算资源。因此团队分别记录排队时间、首 token 延迟、逐 token 延迟及活动缓存总量，用时间轴核对增长发生在哪个阶段。
修复先从准入开始：按预计输入加输出 token 占用设置总额度，超过额度的请求排队；同时限制单请求长度，给未知输出增长留余量。接着把长材料请求与短分类请求的调度需求纳入评估，避免少量长任务拖慢全部交互。是否需要独立队列或不同服务池，取决于混合负载压测，不能从理论公式直接指定最佳部署形态。
团队也尝试通过去重和检索缩短输入。这里必须回到质量验证：关键证据召回率下降时，显存节省可能换来错误解释；只保留前部则可能放大中间迷失与末尾信息丢失。每项候选策略都使用同份冻结测试集，比较 macro-F1、证据命中率和位置分组结果。容量改善与质量达标都成立，才把策略纳入默认路径。
上线前的验收不再是“最长输入跑通 1 次”，而是固定长度分布、输出长度分布和到达模式的持续压测。报告包含可维持吞吐、P95 延迟、失败率、缓存峰值及质量回归结果。若运行时、模型或缓存格式变化，就重做相关测试。这个案例的关键教训是：容量是所有活动请求共同消耗的资源，最大上下文长度只是单请求条件的一部分。
8 把上下文策略写进产品方案
产品方案首先描述任务与证据边界。例如“对公开新闻文本进行主题分类，并返回支持判断的原文段落”，比“支持超长文档”更容易验证。说明输入允许哪些来源、是否保留引用和标题、如何处理重复文本、何时认定证据不足。涉及表格时还要说明字段出现的时间点；涉及图像时，文本 token 预算不能直接代替图像编码后的实际资源预算。
随后写出预算规则与质量门槛。默认输入档位、最大输入、输出预留、超限处理和并发准入应能从请求日志核对。质量门槛应来自业务损失与验证结果，例如关注少数类别的 recall，并同时约束 precision，防止靠大量误报抬高召回。不要凭空承诺所有长度都达到同个 F1；应按长度和位置给出已验证范围及样本数。
超限后的用户行为也要明确。系统可以提示缩小范围、先检索相关段落或转入较慢的处理队列；若采用摘要，应让用户知道答案基于整理后的证据，并保留回到原文的路径。不能静默丢掉末尾内容后仍声称已分析全文。证据不足时应返回可理解的状态，而不是用流畅措辞掩盖遗漏。
验收表应把离线质量和在线容量连起来。固定测试集回答“方法是否正确”，混合负载压测回答“系统能否持续提供该方法”。监控至少包含实际输入长度分布、输出长度、截断比例、检索空结果比例、延迟与失败率。位置鲁棒性难以直接从在线日志判断，可以维护不含敏感内容的固定探针，定期覆盖前、中、后位置，检查版本变化是否引入退化。
最后为变更规定证据要求。换模型、改提示、换分词器、启用新注意力实现，可能影响不同边界；应记录变更版本及关联评测。若只调整输入清洗，也要检查是否删掉否定词、来源时间或标签线索。方案的价值是让团队知道何时需要重测，以及出现问题时可以退回哪个已验证配置，而不是堆砌最大长度和理论加速比例。
9 从长上下文与高效注意力走向模型压缩（A48）
到这里，我们已经看到资源消耗来自不同部分。模型权重通常与请求长度无关，KV 缓存随活动历史增长，预填充临时空间又与具体实现和批处理有关。若主要瓶颈是长请求的 KV，单纯压缩权重未必解除并发限制；若设备连权重都放不下，缩短上下文也不能解决全部问题。进入模型压缩之前，先画出资源构成，比先挑压缩方法更有意义。
模型压缩会讨论用更少的存储、计算或参数维持可接受的任务质量。量化、剪枝、蒸馏是常见方向，具体原理留到 A48。本课只建立接口：压缩改变了哪个资源项，是否改变数值误差或模型行为，原有长上下文验证是否仍然成立。即使短文本分类分数基本不变，长文本中的精确编号检索或冲突证据处理也可能出现不同退化，需要单独覆盖。
为下一课准备的实验记录应保留未压缩基线：相同测试划分、清洗方式、提示模板、长度档位和输出约束。以后比较压缩版本时，使用相同输入并记录实际数值格式，才能解释质量和内存差异。若新版本同时更改注意力结构，就不要把所有收益归因于量化。能解释改动来源，才能把资源节省转成可信的产品收益。
长上下文、高效注意力、输入检索与模型压缩可以协作，但每种方法解决的环节不同。先确定关键证据，再限制无用输入；识别运行瓶颈，再评估对应技术；最后在真实任务与混合负载下验证。这条顺序让我们把“可以装下更多文字”的演示，推进为“在质量与容量约束下稳定完成任务”的工程判断。
放进方案里
本项目面向公开新闻文本的主题分类与证据说明。训练、验证、测试沿用固定划分，清洗发件人、重复引文等可能造成泄漏的内容，并保存清洗版本。默认只纳入当前任务有关的正文与参考段落，所有长度均以固定分词器计算。输入模板、用户文本和参考证据共享输入预算，输出另行预留；超限时采用已验证的检索或分段路径，明确提示处理范围。
上线前比较多个长度档位，分别报告 macro-F1、每类 precision 与 recall、证据命中率和无答案处理表现。受控材料将关键证据放在前部、中部、后部，覆盖重复编号、冲突结论与无关材料增加。验收附件逐档列出各位置的样本数、通过门槛与实测结果，并保存实际送入模型的证据段标识；任一位置未达标，就缩小承诺范围或调整策略后重测。最终测试集仅用于确认方案，不参与预算和提示调参。对于更长或来源变化的输入，单独报告结果，不把短文本结论直接外推。
容量按输入加预留输出的活动 token 估算，再以混合负载压测确定准入额度，保留权重、临时空间和缓存分配余量。验收同时检查首 token 延迟、逐 token 延迟、P95 总延迟、峰值显存和失败率。预算不足时排队或引导缩小范围，禁止静默截断后宣称完成全文分析。记录实际输入、输出、截断原因和策略版本，以便追溯错误。
模型、分词器、注意力实现、数值格式或清洗策略变更后，运行相关质量回归与容量测试。若证据位置表现、少数类别 recall 或延迟越过已约定门槛，恢复已验证配置，并依据日志判断是证据缺失、模型误用还是资源不足。只有质量和容量同时达标的长度范围，才写入对外服务承诺。
10 小结：下一步模型压缩（A48）
长上下文需要同时回答能否接收、能否利用、能否持续服务。标准全注意力的配对规模随长度平方增长，常见推理 KV 缓存则随历史长度与活动请求数近似线性增长。高效实现、稀疏连接、窗口与线性近似的作用不同，都要回到真实任务检验。
自测时可以解释这 3 个问题：为何长度翻倍不代表延迟必定翻倍？为何单请求成功不能证明并发安全？为何前后证据都能找到，仍不足以证明全文可靠？如果能分别用预填充、缓存预算和中间位置评测回答，就已经具备进入 A48 的基础。下一课将继续讨论模型压缩，学习在更小的资源预算下保留可验证的任务能力。