1m 上下文感觉面对 agent 还是少了？预测下接下来哪家会先出真*2m 上下文？

压缩一下呗，带着那么多垃圾历史信息没意义

@xiaomushen #1 自动压缩感觉会损失很多细节。期待真 2m 上下文模型

我觉得目前这个上下文大小已经比较甜点了，有用的信息提到项目文档或者个人知识库就好

1M 的时候不担心 token 消耗量么？ 2M 那更不敢想了

@ktyang #4 公司给买了

上下文太多 记忆力稀释怎么办

@hrapunzel #6 所以我说真*2m 上下文，不会因为长上下文稀释降低性能的

能不能引入一种上下文提炼组件，代替压缩呢？自动判断哪些有价值，哪些没有的那种 我觉得比光加要好

1M 上下文有些模型都丢信息。支持更大的上下文长度 价值不大，压缩要做好 能提取重要的信息，1M 往上 显存兜不住

@lynn1su 请教下现在真 1m 上下文的有哪些

稀释问题解决不了，再长也没用

@lynn1su #5 供应量无限嘛 羡慕啊

1m 都不好用现在。

1m 上下文相对于 512k 性能已经下降了，可以从一些基准测试里看出来

得了吧, 现在真 1M 且效果好的模型都没有, 还 2M

1M context 里有多少是有效 context 我不好说

我觉得还是需要人来控制，有的时候表现出来记忆里不够，有的时候又混杂了很多无关的东西。
但是这样会很累，希望以后模型对于上下文处理的更加合理。

还是研究研究压缩吧，真出了怕是没人用的起

大胆点 100M 上下文 就像当初宽带一样 512K ADSL,现在不也是家家都千八百 M 的

个人感觉并不是上下文窗口越大越好，太大了精度质量下降，tokens 消耗更快。

长任务还是拆分窗口进行吧。

我觉得恰恰相反，现在是 agent 肆无忌惮的的浪费上下文，上下文越长，信噪比越低。这样下去上下文边际能力收益会越来越低。
模型训练那边已经想明白后训练才是最有性价比的付出，agent 也会探索出让上下文更有价值的方法，我并不期待更大的上下文，我期待“Agent 仙人”

@xiaoz 没错。即使是支持 1M 上下文的模型，我也主动限制为 256K 上下文，尽早触发上下文压缩可以有效降低使用成本，特别是当 agent 们大部分时候都在自主工作时。超过 400k 每一次工具调用都变得异常昂贵，即使命中 cache 也是。

不只是压缩，还有总结。
压缩是从上下文中去掉一部分，总结是保存为文档，需要的时候再来读。
好比你写论文，记忆里只有一个大概 “XXX 说过一个什么意思的话”， 真要要引用的时候，你再去找原始资料再读一遍， 确认你没记错，确认更多细节。

我日常超过 256K 上下文使用的话，多轮对话下去成本会骤升，好多 Agent 工具在这个量级附近已经开始自动压缩模型上下文了，1M 以上的上下文需求目前占比应该非常小，但是潜力肯定还是有的，最大阻力是算力成本墙，要成为主流还是得给输入/输出上下文的单价进一步降下来，个人认为至少得目前市场价数倍的降幅，且模型能力还要保持不下降，否则这个短期内市场博弈下，大多数用户盯着消耗账单望而却步。

外面一堆 200 的都一样用

500K 是甜点，1M 上下文大部分用不到---因为上下文有效的，可能就最近几轮对话。再之前的，都是废话

这和人对话一样的道理：说话请说重点，别东拉西扯废话连篇