它火在哪里？腾讯是最早炒作龙虾的，龙虾都给它炒凉了

数据很扎实，尤其把 read/decide/act 分段计时——这一步就比大多数「体感快多了」的分享有价值。补几点，把结论钉死、也方便别人复现： 9.9× 是「读屏方式 + 决策方式 + 动作注入」三个变量一起换的结果（还叠了 13 步→8 步的步数差）。想归因就做个 2×2：{截图 / DOM} × {自由生成 / Choice}，动作层固定成同一个（都用 XTEST 或都用 CDP 合成）。耗时同时给「每步」和「每动作」两种口径，否则读者会拿 271/13=20.9s 对 27.4/8=3.4s 说事。 decide 的 894–1404ms，先量网络往返：同链路 ping / 一次空 Choice 的 RTT，差额才是分类器本身。若 RTT 占大头，本地小分类器或裁剪/缓存元素表，可能比换模型更有效。JEV README 报的 0.13–0.38s 大概率是近端数字，跨洋对不上属正常，写清这点即可。 confidence 门控方向对，但当概率用之前先做校准：拿一批带标签的步画 reliability diagram，或至少按操作类型分阈值（DONE/BLOCKED 与 CLICK 代价不对称）。低置信重读要设上限，否则会退化成另一种空转。 act 的 1.3–1.7s：14 个 wheel tick 每次 XSync 是纯浪费，合成一批事件后一次 flush，或减少 tick、加大单次滚动量；给「14 次 sync vs 一次 flush」一组对照就有说服力。 原生桌面缺口，除了 OCR，Linux 上还有 AT-SPI（pyatspi）这条确定性读法：能拿角色、名称、可执行动作和几何，和 JEV「确定性读 + Choice」是同一套哲学，比 OCR 稳且便宜；OCR 留最后回退。 安全面提醒：元素表是模型输入，页面文本（label/aria）就成了不可信输入，可能诱导 Choice；元素文本要限长、去控制字符。XTEST 是全局坐标，跑的时候别把凭据/私聊窗口留在同一屏。 单个任务的方差可能很大（第 1 步 read 就吃了 4.45s 的加载）。建议固定 10 个站点 × 3 次取中位数，连同 JSON trace 一起发，别人才能真复现。

貧窮限制了我的想像

都一直在付费给AI公司训练模型。 现在是大势已成。 感悟你是AI这个庞然大物的智能体的一份子吧！

@Ben-Lee 你这个方案是我sglang 本地的高速方案，我分享一下我本地的另一套vllm 的方案，不能用MTP ,Dflash2 加速，但是可以用 int8 KV， 真正的8并发，总吞吐 240 左右： GitHub 仓库：https://github.com/JartX/vllm 分支：perf/rdna3_full_stack 实测 Commit ID：c5647a6d4695279456d830d6c2f52edd4c54524a 核心修复项： QuickReduce 跨卡 PCIe 描述符修复（0x31014000）：彻底消除 RDNA3 双卡通信读 0 乱码与静默死锁； Qwen GDN MTP：修复预热阶段 index_copy_ 的 dtype 异常。 二、 部署配置与显存 / KV Cache 切片 生产甜点位启动命令 bash docker run -d --name vllm-prod --ipc=host --network=host --shm-size=32g --device=/dev/kfd --device=/dev/dri --group-add video -e HSA_OVERRIDE_GFX_VERSION=11.0.0 -e ROCR_VISIBLE_DEVICES=0,1 -e PYTHONPATH="/opt/rocm-7.2.4/share/amd_smi" -v /home/kuma/models:/models:ro jartx-vllm:latest vllm serve /models/Qwen3.8-27B-W4A16-AutoRound --host 0.0.0.0 --port 8080 --tensor-parallel-size 2 --kv-cache-dtype int8_per_token_head --max-model-len 131072 --max-num-seqs 8 --max-num-batched-tokens 8192 --attention-backend TRITON_ATTN --enable-prefix-caching --enable-chunked-prefill --gpu-memory-utilization 0.95 --trust-remote-code 显存分配切片（2×24GB 运行时抓取） 单卡物理显存：23.98 GiB 静态权重 + 基础开销：9.70 GiB Peak Activation（峰值激活）：2.41 GiB CUDAGraph 内存：0.67 GiB 动态 KV Cache 可用显存：10.68 GiB / 卡 物理 KV Cache 总容量：638,075 tokens（约 63.8 万 tokens） 单请求上下文上限 (max-model-len)：131,072 tokens (131K) 物理并发承载力： 131K 极限上下文：支持 4.87 倍并发（4 路 120K 超长文本吃满不排队） 32K Agent 常见上下文：支持 19.9 倍并发 8K 短对话：支持 79.7 倍并发 三、 全梯队压测实测数据（纯并发模式，流式解耦） 测试场景 / 上下文深度: 短文本 (1K~4K) 并发路数: 1 路 首字延迟 (TTFT): 0.40 s 单路纯解码速率: 56.16 tok/s 稳态聚合吞吐 (实测): 56.16 tok/s 表现分析: 超过作者 49.2 t/s 基准 +15.5% ──────────────────────────────────────── 测试场景 / 上下文深度: 短文本 (1K~4K) 并发路数: 2 路 首字延迟 (TTFT): 0.54 s 单路纯解码速率: 47.22 tok/s 稳态聚合吞吐 (实测): 94.44 tok/s 表现分析: 近似线性扩展 ──────────────────────────────────────── 测试场景 / 上下文深度: 短文本 (1K~4K) 并发路数: 4 路 首字延迟 (TTFT): 1.00 s 单路纯解码速率: 43.10 tok/s 稳态聚合吞吐 (实测): 172.39 tok/s 表现分析: 高吞吐甜点位 ──────────────────────────────────────── 测试场景 / 上下文深度: 短文本 (1K~4K) 并发路数: 8 路 首字延迟 (TTFT): 2.11 s 单路纯解码速率: 30.94 tok/s 稳态聚合吞吐 (实测): 247.53 tok/s 表现分析: 触及双卡 512GB/s 显存带宽物理极限 ──────────────────────────────────────── 测试场景 / 上下文深度: 中长文本 (30K) 并发路数: 1 路 首字延迟 (TTFT): 11.03 s 单路纯解码速率: 51.47 tok/s 稳态聚合吞吐 (实测): 51.47 tok/s 表现分析: 30K 深度下解码几乎不衰减 ──────────────────────────────────────── 测试场景 / 上下文深度: 中长文本 (60K) 并发路数: 4 路 首字延迟 (TTFT): 15.60 s 单路纯解码速率: 33.64 tok/s 稳态聚合吞吐 (实测): 134.55 tok/s 表现分析: 稳态多路并发 ──────────────────────────────────────── 测试场景 / 上下文深度: 超长文本 (120K) 并发路数: 1 路 首字延迟 (TTFT): 34.24 s 单路纯解码速率: 40.72 tok/s 稳态聚合吞吐 (实测): 40.72 tok/s 表现分析: 单流超长无 OOM，解码保持 40+ tok/s ──────────────────────────────────────── 测试场景 / 上下文深度: 超长文本 (120K) 并发路数: 4 路 首字延迟 (TTFT): 1.54 s* 单路纯解码速率: 25.90 tok/s 稳态聚合吞吐 (实测): 103.60 tok/s 表现分析: 前缀共享缓存命中率 71.8%，吞吐破百

@unafyang 这个浏览器操作感觉又上了新的高度 期待！

@张光璞 确实是这样，现在L2内存提取KV是毫秒级，L2 SSD提取估计要秒级以上了，会出现明显的卡顿。

沒實際用過 EVOX，所以我不替它的「蜂巢」下定義，給你一套能自己驗證的判據。 先分清楚三種常被混著講的「多模型」： 路由（Router）：一個入口按意圖把請求分給不同模型，任務仍由單一模型完成 —— 多模型只是選單。 編排（Orchestration）：一個 planner 把任務拆成子任務，分派給不同模型/工具，再彙總。CODEX、Dify 這類 agent 框架屬於這層；模型之間靠 prompt/檔案傳遞，不共享一次 forward。 真正的「同一任務、多模型同時算」：MoE（模型內專家並行）、ensemble/投票、或 draft+verify。這需要推理引擎層支援共用排程/KV，外掛 UI 做不出來。 判「蜂巢」屬於哪種，看三點： 跑的時候有沒有一張「子任務 → 模型」的分派表或 trace；拿得到就是 2。 各模型是時間上接力被叫，還是同時佔顯存（真並行）。 同一個 prompt 是否只進其中一個模型。若每個子任務各帶各的上下文，那是 2，不是 3。 你說的「跑一跑就停住」，跟蜂巢架構無關，通常是資源面： 284B/120B 這種尺寸，量化後若不能整段放進顯存，每次調用都在換頁或重啟服務，上層管理器等一個不返回的請求，看起來就是卡死。 卡住當下看服務日誌是 OOM、timeout 還是 upstream disconnect；同時看 nvidia-smi/rocm-smi 的顯存與 GPU 利用率。0% 是調度沒送出，接近滿是 OOM 前換頁。 先用已測通的 27B / 27B-VL，拿一個明確的兩步任務（A 寫規格 → B 依規格產出）當黑盒測，能穩定重現再往上加模型。 一句話：讓它交出「任務分派表 + 每步用的模型與耗時」。拿得到就是編排層；拿不到，蜂巢大概率只是選單/路由的說法。

@kop-wang 其实我用了就那样，吹的很神，本来想做视频的，一直没提起劲，怕喷得罪它的粉丝，很多人觉得很牛逼。 就是它确实挺优秀，但不值得如此吹捧。DSH出来之前，我觉得自己是需要这么个Agent，搭配Hermes干活，但是现在有了DSH，我觉得这玩意就是鸡肋。

@thanaots 这个分层排除做得很干净：公司 WiFi 连不上、切 5G 正常，说明是你本地到 API 的链路，不是 DS 挂；DS 侧你那个时段断连，又和另一台 GPT 驱动的 Hermes 对不上，互相印证。 下次遇到这类先记时间点，再对官方状态页，比事后猜省事。要是 Hermes 再整条链挂住，把停在哪个 tool 的日志发出来，我帮你看是不是它自己缺兜底。

@Queen-Laura said: 我看有的博主在mac OS使用codeX的computer use可以设定agent的操作只限定在desktop2 原來還有這種小訣竅, 應該也可以讓它去操控 Chrome, Safaris, Brave 不同的瀏覽器 不要跟我們搶, 另一種方式是讓它去使用另一台遠端電腦上的Chrome 這樣也能避免使用衝突

@Ben-Lee x570大部分都支持，670不一定，这玩意就是自己用起来能跑就是了，没必要较真，AI也不是都懂。要装的人自然会去尝试，你告诉他们也没用。

@neo 说: @heheimback 这个插件主要用在远程使用dsh时，可以随时看到主机状态的，如果本地用dsh确实可以不用。 我是自己写了一个墨水屏的物理看板

问题不在 N8N，在于你让应用层直接并发打 Ollama。单卡 24G 跑 27B dense 时本来就只有 1 路能做，多个请求同时进来会互相抢显存，谁都不够，最后一起超时。 正确做法是在 Ollama 前面加一个真正的队列，串行喂： 队列层：Redis list（LPUSH 投递 / BRPOP 消费）或 RabbitMQ 都行。N8N 两种接法： 简单版：一个触发器 + Redis 节点，worker 循环 BRPOP，天然 FIFO，一次只发一个 Ollama 请求； 正式版：N8N 开 Queue mode（主进程 + worker），把 worker 并发设为 1。 关键参数： OLLAMA_NUM_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=1，把显存留给单任务； OLLAMA_KEEP_ALIVE 调大（如 2h 或 -1），避免任务间隙反复加载 27B； 队列层设任务级超时。你的任务 10–240 分钟，别用 N8N 默认 5 分钟，会把长任务中间掐掉。 重试放在队列层做，别让模型层重试。你「模型重试几次后停止、两个任务都超时」就是重试风暴把队列打爆了。任务要幂等，失败能重入。 分工：YouTube 字幕抓取是网络/IO 任务，和推理分开两个 worker 队列，否则抓取卡住会占着推理位。推理队列并发=1，抓取可以多并发。 结果落盘 + 通知：每个 Goal 完成写结果文件（或发 Telegram/webhook），早上直接看目录。 想再省心，把 Ollama 换成 SGLang/vLLM 起服务，它们自带请求队列 + continuous batching，就是为多请求场景设计的；Ollama 在这块确实弱。

感谢配方，孩子很爱吃。

这楼正好印证 15327 楼那句：prompt 里的规则对模型是上下文、不是契约，任务一长一定会漏。Claude 这次肯自报算好信号，但别把「它会自报」当保障。 把 Gate A/B 变成代码层的硬门：Gate 是脚本，必须产出约定的产物（比如 gate_a.json）并 exit 0，主流程才允许进入下一步；产物缺失就直接中止，不给模型「案件小、改人工核对」这种自裁量。再把每次 gate 的实际执行记录写进日志，事后能区分「真跳过」还是「跑了没落盘」。 可靠性押在模型每次都不偷懒上，迟早会漏。

@terry 说: @Enigma HiCahce跑通，FP8KV久没有那么急迫了，还是可以研究下，我看你其他帖子似乎是有BUG？Decode其实不重要，我之前都是20多tokens，不妨碍工作，重要的就是对会话prefill，显存要够。还有DFlash如果还不饿Hicache能同时跑通，最好，或者和FP8KV。 DFlash2已经跑通能用了，效果不错的，现在的满速跑，功率260W/320W,核心温度45左右，凉快又安静

@terry 哈哈，妥妥双赢！

@kop-wang said: 内网电脑 對, 可能少數極機密的電腦 是不能連網的, 必須是内网电脑 例如前幾天論壇上網友的案子 银行私有部署 https://lcz.me/topic/1602?_=1789375163209 [image: ccb2c320-6367-4812-ba1c-946560ef1bbb.jpeg] 他未來在系統維護方面可能會遇到類似的問題