udtrokia

最理想的情况下，肯定是希望用户对 compact 没有任何感知的，包括我可以并行 compact ，这个豆包真的是感觉体验上绝了跟别的产品比

@Hilong 如果是 apple chip 现在的 metal batch prefill 应该是和 Nivia 不相上下的吧，其次应该就是 memory 设计和 compaction 设计的问题：

1. memory 的问题我用 graph memory 解决了，每次 compact 不仅 summary 还会 vector db 索引相关的记忆
2. compaction 这个我昨天还在思考，如果是子任务的话，有没有可能使用 leader 来 compact members ，结果会更精准一些
3. 第三个效率补充就是，在思考如果长时间没有对话，后台其实也可以周期性的自动 compact 一下，我感觉豆包的处理应该就是这样的

https://openwalrus.xyz/blog/context-compaction

@hewitt29 你不需要搭大模型，binary 跑起来大模型自动就帮你跑起来了，你不需要任何操作

不过感觉应用场景这个确实，有个具体的东西才好讲，不然太抽象了就很飘了，我目前打算的最先开发的几个用途：

1. 用 openwalrus 运营 discord channel ，记录群里面的人的问题，因为 walrus 支持 graph memory ，所以直接把用户碰到的问题记录并且分类好
2. openwalrus 运营 twitter ，通过 browser 帮忙自动发帖运营，绕过 twitter 的 API call ，包括可以通过 browser 调用 grok 来去优化检索
3. 周期性的行业 research ，比如我现在做的这些 blogs ，https://openwalrus.xyz/blog?tag=research ，agent 去检索总结效率是非常大的

我目前主要是运营需求，@Eddiegaao 老哥你有啥需求我看看我的架构能不能解决？

用的最多的 kimi ，如果机器允许的话，也是可以本地跑的，其实没差的，openclaw 能做的 openwalrus 都可以做

其实大部分的日常场景都可以处理的，机器好的话也可以跑 35B, 122B ，所有的开源大模型都可以跑，远程的也是可以支持的

在做一个 rust 写的，优先跑本地大模型的 claw

https://openwalrus.xyz/

机器具体啥配置啊，看看能不能跑我的 alternative 😂

@fallshuang memory model 和 solidity 的设计不一样，后面动态的参数会有一些调整，不过目前的所有 demo 同样的函数和 solidity & vyper 比，都是字节码又短 gas 开销又低，可以看 https://docs.zink-lang.org