抡锤者

我觉得现在阻碍自动化生产的主要问题就是模型的审美还是不行。
没办法区分生成的是符合需求的视频/图片，还是废片。更没法梳理视频中的穿帮并自修正。

流程越长，这个误差累积的程度就越深，自动化生产的成功率就越低。
尤其是在Minimax H3这个速度并不快的模型场景中。

这个也是我目前好奇的，据之前坛友的测试，qwen3.8-flash的prefill和decode性能更慢。
我非常的不理解，规模和激活参数均砍半，但性能还更差。

等待其他有双机的坛友测试。

@johnnybegood 纯玩没问题，开心就可以了撒。但是代价就是玩是一种消费，所以不要去纠结性价比和成本。

纠结“玩的值不值”，我个人理解是一种非常内耗的行为。

恭喜，小特对于论坛的管理看来越来越深入了。

所以每个领域都有“装备党”、“器材党”，所谓差生文具多。
这并不是一种贬义的说法，对于一个事物，每个人有每个人的理解和解读，我认为只要你问心无愧就是对的。

但核心就是要认清自己的实际目的，不要披着实用之名，行装备党之实，就好。

我个人挑工具的习惯是从需求出发的。即我想达到目的A：
1、有哪些方案。
2、这些方案的价格如何，哪些我能承受。
3、买我能承受的最好的方案（90%的情境下也是最贵的）。

@imbiplaza-ASUS 目前我使用openCode go订阅的qwen3.8-flash模型作为日常LLM，比v4-flash-0731价格低，还没有峰谷。

这样显卡资源能腾出来。

@許托比 这样也解决了之前诟病的hermes自学习，自动修改memery、skill导致的自顾不暇，记忆混淆、思维混乱等问题。

最近一个月大家应该都沉浸在dsh（deepseek harness）等新生代harness，以及各种flash、27B级别模型的不停发布尝鲜中，俺也一样。

我最近一个月只主动发起了5个hermes的session。

这两天也是把hermes升级到了0.21最新版，和大家贫几句最新的feature与发现。

---

Bot机制

本质上hermes的bot，就是hermes的profile机制。只是在上层添加了一个能够@，能够群聊的chat接口。
这也就构成了hermes的bot的独特性。

其他harness的Agent团队、Agent蜂群都是一次性的。他们只持有不同的系统提示词。

hermes的bot互相之间有隔离的session历史，有隔离的memery，有隔离的message gateway。所以理论上讲，他们可以在hermes-desktop中，或者discord频道里吵起来。

我会把我的日程交给hermes主进程，孩子的课表、课外班、学习任务、既往成绩交给 Charlie's Study，home doctor负责监督我们的日程是否健康（他有我家庭所有成员的体检报告，孩子的视力检查报告，我家庭成员的每日体重、血压等），是否有充足的户外时间以及日间运动量，孩子的近距离用眼时间是否控制等等。然后他们每晚10点就会开会对账，发现我日程安排的不合理之处。以及讨论如何修改行程和学习任务最为合理。

---

CLI、TUI、GUI三侧的功能逐渐分离

cli tui越来越偏向于自动化、程序管理、服务器管理等功能优化，GUI则越来越偏向于用户侧功能优化。比如上文着重的bot群聊机制，就是GUI程序独有。

如果罗列更新的feature列表，GUI占60%，越来越多的独占GUI功能，逐渐证明了hermes从极客属性再向大众化转型。

版本	代号	信号
v2026.6.5 (6/5)	The Surface Release	原生桌面 app 发布（macOS/Linux/Windows）+ 浏览器管理面板
v2026.6.19	The Reach	Desktop 生产力套件、主题、远程网关改进
v0.21.0 (8/31)	The Pantheon	Bot Mode 内置桌面端、桌面内置浏览器、MCP 指挥中心、桌面会话控制/浏览器标注……

以上，欢迎指正讨论。

这个是个好思路，工具分享和经验分享，其实是平行的。
他们的检索、浏览逻辑不同。
对应的UI逻辑其实也不应该完全相同。

把工具和经验混在一起查看效率比较低，工具的曝光属性也稍差。

https://github.com/astropuzzo/ComfyUI-MiniMax-H3-Image-Studio
社区的利用Minimax H3 强悍的r2v能力实现的图片生成、编辑节点。

这个主要矛盾就是目前的图片编辑模型基本都不能选主体。也就是必须要主体鲜明才能正确替换。
其实Minimax H3能完美解决这个场景，但是用视频模型解决图片问题有点大炮打蚊子……

必须一口气换吗？我的想法是，是不是可以图片迭代换7次？
我指的是，把这七个小人切割成7张图，然后换脸，然后再合成。

这种问题很依赖harness环境。
楼主晒出自己的harness环境才好横比。

要考虑comfyUI和qwen的负载分别是什么。所以你需要先定义你的场景，你需要生图？生视频？需要LLM有多强的能力（类似线上API的能力，还是只需要能文字交互的能力）？
然后才能出比较合理的方案。

为何总参数、激活参数更小的qwen3.8-flash会更慢，这个很难理解。

@Che 说:

看不懂。量化权重+draft权重+视觉塔算30G吧，这还剩60G VRAM；qwen3.8 在KVCache FP8量化下，262K context约12G；5并发各262K上下文，完全是足够的，在纠结什么？

不够的，sglang环境下的session热切换不是只要满足 总context <显存余量就可以。还需要考虑memba层，也就是参数memba ratio对应的逻辑。

自动截断我遇到的是跟jinja表有关。
我改jinja表就是因为配了匹配codex和claude code。改完之后dsh就会自动截断了，而且sglang还没日志

后来发现claude code太依赖服务端API能力给他的tool_use，放弃了就还原了jinja表，就正常了

我体感也是tag其实更好，目前的BBS不像过去，过去更像是分区自治，每个板块的规则甚至都不同。目前节奏快了，没人关心这些，更多的偏向于信息沟通效率。这时候扁平+标签分类结构就比分区要有优势。

btw：我其实只用”最新“这个页面，所以我对于分区越来越不敏感……

@alex-wang-0 说:

我想把这套部署写成一键启动脚本（含模型下载、服务自启、OpenAI 兼容接口配置），应该怎么描述合适？

这个你得一步一步来，首先得先引导LLM装成功一次，且确认性能、能力都符合你的需求，然后再总结成脚本。否则只靠产出脚本来测试效率太低了

@alex-wang-0 hicache的性能肯定不如全显存，但是也比切换session反复重新prefill强得多。而且你的ram很充裕。

btw：你可以看下sglang官方的cookbook，你可以理解为你的配置就是RTX PRO 6000
https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B#hw=rtx6000&variant=default&quant=fp8&nodes=single&spec=none&tier=low-latency&ssmDtype=float32