模型上下文长度怎么调

本地跑模型时想让它一次吃下整份文档，就把上下文长度往上调，结果要么启动报显存不足，要么速度掉到没法用。这篇按「先确认上限、再算显存、再调参、最后判断该不该调」的顺序讲一遍，给你能直接照做的动作和判断标准。

本地跑模型时想让模型一次吃下整份文档，就把上下文长度往上调，结果要么启动就报显存不足，要么速度掉到没法用。这事儿的坑在于：调长度不是一个动作，而是一串动作——先确认上限、再算显存、再动手改、最后判断到底该不该调。

下面按这个顺序讲一遍，每个环节都给你能直接照做的动作和判断标准。看数字的地方统一去站内对应页面核对当时的数值，别拿记忆里的旧数字做决策。

先搞清楚你能调的其实是三个不同的数

模型位置上限

模型训练时定死的最大位置数，属于能力的硬天花板，超过它要么直接报错，要么输出开始变乱。

框架上下文长度

推理框架启动参数里那个长度，是你在软件层面实际设的值，通常默认远小于模型上限。

请求级缓存分配

服务端按每次请求真正预留的那块 KV 缓存，跟前两个是不同层级的东西。

三者不是一回事。很多人以为自己「把上下文调到多少」，实际改的只是框架参数，而真正吃显存的是第三项。先去 /models 查目标模型的规格页，确认它标注的最大输入是多少，心里有个天花板；再去看框架的默认值，那个才是你真正要改的数。

顺带把概念对齐一下：Token、上下文、温度这几个词很容易被混成一个参数。到 /ai-dict/category/basics 把它们各自的定义对一遍，尤其是把「上下文长度」和「回答长度」分开——前者是输入侧能吃多少，后者是输出侧生成多少，改错参数会让人怀疑人生。

在哪改、改完怎么验证

1. 短请求打底先用一条很短的请求确认服务本身正常，排除是部署坏了而不是长度问题。
2. 逐步加长输入一点一点把输入加长，同时盯日志里的显存占用和首 token 延迟，别一次拉到顶。
3. 设成业务真实最长值按「最长的合同全文 + 提示词 + 预留输出」来定，多留一截余量就够了，不需要为了保险留一大截。

验证的时候有个容易忽略的点：长输入下最先崩的往往不是显存，而是并发。你按单请求测通了，不代表两个人同时用还能跑起来。所以验证要分两步——先单请求测通，再加一点并发看日志。

长度翻倍，显存不是翻倍那么简单

除了权重本身，长上下文主要吃两块：一块是 KV 缓存，随长度和并发数往上走；另一块是注意力计算的开销，增长比线性更快。所以显存曲线是往上翘的，不是一条直线——长度翻一倍，占用可能翻不止一倍。

• KV 缓存的量级跟层数、注意力头维度、精度、序列长度、并发数都相关，不是只看长度一个变量
• 具体到你的模型和量化档位，用 /models/deploy 和 /tools 里的换算工具跑一遍，别凭感觉估
• 显存不够时的取舍顺序：先降并发，再看量化档位（到 /ai-dict/category/tech 与量化相关页面对齐口径），最后才考虑换卡
• 把长度砍半通常比换卡便宜得多，也更立竿见影，先把这一刀砍到位再谈硬件

判断标准很朴素：如果单请求能跑、并发一上来就 OOM，那问题在并发不在长度；如果单请求就跑不动，才轮到长度和量化档位出场。别一上来就怀疑显卡不够。

什么时候不该继续加长

第一，注意力会被稀释。塞进去的内容越多，模型对中间段落的关注往往越弱，「全文喂进去」不一定比「只给相关几段」答得准。第二，成本和延迟双重上升：按量计费的接口，输入越长单价越高，实际单价去 /official-api 和 /tools/token-price-calculator 核对当时的数字；本地部署则是延迟和并发一起掉。

判断标准：如果任务本质是「找几条」，检索通常更划算；只有需要跨段落整体推理、通篇改写这类任务，硬堆长度才有意义。