@flyico 可以全都要，比如现在线上 plan 会拒绝干一些逆向的活，然后一些敏感问题也可以问，全在本地就很安心。

@minibear2021 如果硬件正常贬值的话没什么性价比，但是现在还能小赚一点的话性价比就爆了。

@xqk111 glm 5.3 不行，没有足够 kv cache ，deepseek 还有 qwen 可以。

@yachen 上面有说，不同模型差别挺大的。

@qa2080639 一台可以用 Ling Flash 之类的模型，DeepSeek V4 Flash 也有一个单 DGX Spark 可跑单量化版本。

可以去 nvidia 论坛看看，不少人都只有一台 https://forums.developer.nvidia.com/c/accelerated-computing/dgx-spark-gb10/719

@RexKang 5w4 收的两台+连接线

@tsja 没有用过官方 API ，但是 GLM5.3 Flash EXL3/NVFP4 的能力其实已经远远超出我的预期了，聪明是真的聪明，和其它两个有代差的感觉。

@qazwsxkevin DeepSeek 是 fp8 满血，GLM 是 EXL3 和 nvfp4 ，Qwen 是 nvfp4 。

这几个量化都不极限，智力基本都保持的比较好，几个模型看评估数据基本都是 95%以上，我体感上没有智商问题。

@heyjei 换一个对本地 LLM 支持更好的 harness 吧，比如 pi 。

@0x400 qwen 和 deepseek 的 prefill 差不多是 2500t/s 和 1800t/s ，单流 decode 二者差不多都是 70t/s ，多流的话 qwen decode 要更快一些

@zzutmebwd 快就是好.jpg
主要是 Qwen 的智力其实也很高了，只要不写代码。

@honjow 几个月之前从闲鱼低价收的，现在的价格已经完全买不起了 T.T

@Unitent 这个倒不是纯粹 Browser Agent ，是重做一个 Browser 。

因为现在产物只有 40M ，内存占用也是 70M 左右，比传统浏览器小很多，所以有机会嵌入到一些别的东西里面。

也是刚刚起步做完，未来想想看看能不能挖出更多给个人用户的使用场景。

可以在 Hermes 或者 OpenClaw 里面安装 moli, 帮助 Agent 访问更多的网页。

moli 虽然没有 gui ，但是依然能把网页渲染好，这里是一个拳皇游戏的例子

因为是无头的，所以不是给人看的，没有 GUI ，可以 CDP/WebDriver 连接上去。

在各种 CDP 命令的适配上，应该是 Chrome 之下的 T0 :P

@kisstrnt 支持的

> 在过滤框里，我输入/Users/，现在显示出来的就是精确匹配的 users 的文件和文件名。其实这时候我觉得应该是列出/Users/**/*的内容。我刚特意找了个 windows 装了 Everything 最新版测试了一下，他显示的就是/Users/**/*的内容，而且更棒的一点是它把文件夹放在了最上边，这样方便我再精确的往下级目录写。我想了一下 Everything 的实现方式，它好像是在输入/Users/的时候，显示的是/Users/**/*，然后输入/Users/aa 的时候，显示的是/Users/*aa*这样，我觉得这样很方便😂

好的，这个我之前还真没留意到，我晚上找个 windows 试试看

@94nb 感谢这么详细的使用和建议，辛苦了🙏，对俺很有帮助～

> 现在的 content 搜起来太慢了，遥遥无期

由于之前有准确性的执念没有复用 Spotlight 索引，content 这块是直接全文搜索，所以确实慢。这块我最近放下执念了（实用为主），可以复用 Spotlight 索引再配合我们的搜索规则一起工作。

> 路径模糊：我记得文件夹名包含 aAa ，但不记得它的绝对路径或层级。
> 文件特征：文件名包含 bbb 。
> 格式限制：后缀名为 .doc 或 .docx

*aAa*/**/*.doc* 这样 glob 匹配可以，但是这个确实有点绕，先凑合用。

> 文档中提供了 folder:、parent:、in:、nosubfolders 以及路径分隔符 / 等多种组合方式。作为非开发人员，很难理解这些条件的底层差异，尤其在面对“只记得部分目录名且不知深度”的情况下，不知道该如何组合这些参数。

这个是从 Everything 继承过来的语法，但是都不适用于部分目录名。这个和上面是一个需求，这块接下来不会通过新语法来提供，将会有一个单独的左侧可折叠的输入框来专门 scope 文件夹。

> 在某些目录过滤条件下，必须与实际名称大小写完全一致才能匹配；而另一些条件却不需要。这与界面上的“大小写匹配”开关逻辑似乎是冲突的，导致在不确定目标文件夹准确拼写时，搜索效率极低。

这个可以具体说下么，感觉是 bug

> 按理解，双引号内应为“完全匹配”（如搜索 "1 到 10.png" 应仅返回该文件）。但实际操作中发现，搜索 "aaa" 的结果往往等同于模糊匹配 *aaa*，包含了大量无关项，无法达到“我写什么就只出什么”的效果。

双引号其实是防转义，比如空格其实是 AND 的语义，分号是 OR 的语义，双引号标起来的东西是防止语义替换，比如 "1 到 10.png" 这里真的会匹配空格。你的需求其实在这里可以通过： /"1 到 10.png"/ 全匹配； /"1 到" 前缀匹配；"到 10.png"/ 后缀匹配。

> @94nb #33 忘记说了一点，能不能右键加入删除呀，搜出来的内容想批量删掉。

因为搜索列表很大，多选删除有风险，所以一开始没做。后面考虑做一下，需要加弹窗确认。



总的来说学到很多，有些问题之前也意识到但是觉得没那么高优。这几个东西我会推进做一下，应该很快会有新版本，到时候 ping 你试试，看看够不够用 :-)