模型卡里的上下文长度，和实际可用长度不是一回事

[小高]

长上下文模型在不同位置找信息的能力会波动，尤其多文档混杂时。LongBench 这类评测就是提醒大家别只看窗口数字。

[陈一]

还有输出 token 要留空间。你塞满输入，模型没地方回答。

[rootless]

本地部署还受显存、KV cache、推理框架限制。模型理论窗口和你实际能跑的窗口可能不同。

[leaf_1997]

API 文档里的限制也要看输入输出合计、单次请求限制、模型版本。别用旧博客数字。

[普通网友A]

那产品宣传能写“支持 128K 文档问答”吗？

[葡萄冰]

如果真实体验没测过，别这么写。可以写“支持长文档处理”，但验收要看准确率和延迟。

[小周]

怎么测实际可用长度？

[zeroOne]

做位置敏感测试：关键答案放开头、中间、末尾；单文档、多文档；有干扰段落；看引用是否正确。

[林小北]

还要测随着长度增加的成本和延迟。用户不只要答对，还要等得起。

[小满]

我们之前把政策合集按月份拼一起，模型总引用旧政策。后来按生效日期过滤，效果才好。

[小傅]

所以窗口大不代表上下文管理可以摆烂。

[nora]

对。窗口越大，越需要整理输入。

[小高]

长上下文是能力，不是清洁工。