ranxianglei

ranxianglei

V2EX member #110457, joined on 2015-04-11 18:19:40 +08:00
Today's activity rank 3027
ranxianglei's recent replies
@fantasts 你提到的这个问题应该是 bug 或者设计问题,可以稍微修改源码就能解决。

另外会话消耗 token 10 亿可能和 acp 实际处理任务不在一个量级,acp 大多数情况下上下文在 10%左右 acp 10 亿 token 相对 mc 来说应该在 50 亿左右。或者反过来 mc10 亿 token 换算成 acp 大概 2 亿左右。

实际上 mc 不管用不用异步压缩用不用便宜模型 都没有省 token 。
另外站长 V2EX 本来就没有多少高质量帖子 好不容易来一个还给移动到推广区,还要充钱。
给 V2EX 带来高质量本身就付出了巨大成本,最后还需要自己花钱,花钱是不可能的
又深入研究了 mc 机制,本质上是异步的 acp 。acp 把上下文压缩即时化,充分利用了缓存,mc 相当于复制一份流量,用另外的模型压缩。
我理解 mc 把问题搞复杂了,即时压缩不但省 cache ,模型根据当前状态决定哪些重要,而异步搬出去压缩会丢掉这个决策信号,实际上会造成压缩质量下降。
最终 mc 会比 acp 费 5 到 10 倍 token ,做的事情未必有 acp 好
另外补充一点 推理质量 acp 更优,acp 基本上只用模型前百分之 10 的上下文,理论上模型在这个位置更聪明 。

综合来说,除了没有记忆共享,acp 更优。
@fantasts 从压缩效果和长上下文优势和省 token 来说 acp 是更好的选择。二者里面完全针锋相对。acp 认为基于当前状态下的压缩才是最好的,mc 恰恰相反,交给后台压缩。

省 token 来说,acp 是绝对优势,acp 哲学是当前用多少上下文就多大。

长上下文优势来说,这个我不能评判 mc ,仅 acp 来说一个窗口开数十亿 token 是没问题的,mc 我没有测过。

记忆共享,mc 的独特之处。和 acp 完全不一样的理念,acp 相反,记忆共享会影响模型效果。

总之,二者完全是两个极端。
分享为啥被搞成推广了 不理解呀 。个人开发者,打字 1 个小时
另外 https://github.com/ranxianglei/opencode-acp/issues/5 bug 已经修复。
dcp 的 bug 非常非常多,可能还需要修复一阵子。
@zzl22100048 dcp 固有的一些 bug ,我修复了一些 不太彻底。可以把具体场景提给我 ,我定位哪里的原因,也修复了。
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   999 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 22:23 · PVG 06:23 · LAX 15:23 · JFK 18:23
♥ Do have faith in what you're doing.