5 Likes
64K 的上下文就是 deepseek 目前最大的问题
6 Likes
deepseek的价格能打啊
1 Like
吓我一跳, 刚去官网查了一下, 啥时候是32k了, 64k好吧
3 Likes
ds上下文比claude好多了
这个价格这个速度 我觉得上下文短点也不是很大的缺陷 
DeepSeek 从 128K 降回到 64K 的说法是之前真正用到 128K 的太少，为了节省资源，调回了 64K。要想官方把上下文调上去，就要有更多用户（至少 75% 以上）真正迫切地需要 128K 上下文。注意是“真正迫切”，因为我也希望官方支持 128K，然而，我用到 128K 的实际可能性也就 5% 不到。换言之，谁都希望上下文越多越好，但官方要看真正“迫切需要”的用户占多少。但是呢，官方并没有在做这样的统计，而“迫切需要”的用户可能分散在不同的平台吐槽，再加上有的也懒得吐槽，最后的结果就是，即便“迫切需要”的用户占比达到了 75% 以上，官方也看不到。唉，这就很尴尬……
1 Like
我是属于那种不需要长上下文的。。
1 Like
猫猫还是水了 
是的……至少应该提供128k的选项
会单开吗
我一般新开一个 
1 Like
cline确实消耗上下文，但是在我们公司的场景里，确实不存在超过64k的情况，官方所言不一定不靠谱
建议用Claude opus, 1M上下文，分析代码项目很方便，但是很贵。
之前去中转站买过，发现实际上是掺水了的，扔个大项目只能回答一部分。
cline的token用的太多了，而且他的system prompt很长
64k上下文确实让人头疼
用来审查代码的话，经常能到 300K 的上下文
用gemini啊，2000k上下文够你用了
64K问不到几轮就满了
我觉得可以进行自动的二档付费，当上下文超过64k时自动启用二档价格，二档贵点上下文长度翻倍时可以接受的不然浪费的模型128k的上下文能力了，大家都忙着卷上下文长度的，它来个倒吸
1 Like