抡锤者

国内钉钉和飞书都不错，有官方插件，功能也全，推荐用钉钉，它不是用传统的工具集，对上下文影响很小。

先把两条线分清楚，Plus 订阅和 API 是两回事： ChatGPT Plus（$20/月）不发 API key。它是网页/App 的订阅，额度只在该订阅通道里用；OpenAI API 是另一套计费，只能充值、按 token 扣，没有 $20 包月这回事——你这一点理解没错。 DSH 能用上 $20 套餐，靠的不是 API key，而是「用 ChatGPT 账号登录」的会话通道（Codex 那条链路，社区插件做的就是这事）。所以它吃的是订阅额度、有速率限制，能调用的能力也比 API 窄，并不等于把 Plus 变成了 API。 生图要单独看：订阅里的图像模型主要在 ChatGPT App/网页里用；账号登录下发给 agent 的通道，通常不下放图像生成。想程序化生图，还是得走 OpenAI 图像 API（按张/token 计费），或本地 ComfyUI 那套。 另外 2147 是同题重复帖，超版已经提醒过别重复发，后续在这帖跟就好。

下次发大段内容让AI整理markdown代码，复制进来，否则显示太差。我这次帮你改了，下次自己注意。

llama.cpp的dflash2原来是把2种组合一起用

楼主碰到的问题是和我一模一样的。我呢，就让 Hermes 去修理它。Hermes 读了源码以后呢，就改掉了这个 64K 预留。强行的改的代码。 然后它也提醒我，每一次升级也要重新再补一次补丁。 总之，现在的 DSH 在上下文的剪枝方面。还有压缩方面是做的不是很好。本来就干脆把系统的压缩全给关了，用那个 10 亿上下文插件来替代.这样子基本上就解决了所有问题。

Minimax M3.1 Flash Preview真的不错，我吃灰的Minimax 订阅Plan又可以拿出来用了XD。 下图是我拿Minimax M3.1 Flash Preview 复刻的一个博主的3d js游戏的场景，思考强度调的最高，改了好些次，现在能有原游戏的8分像了。 原游戏地址: https://mini-moto-park.chipchaunceytheonlyone.chatgpt.site/ [image: Screenshot 2026-09-30 at 10.01.32 AM_compressed.jpg] [image: Screenshot 2026-09-30 at 10.01.16 AM_compressed.jpg] [image: Screenshot 2026-09-30 at 10.01.55 AM_compressed.jpg]

这有什么难理解，模型跑偏了。你以为它有大智慧，实际上它就是个大函数而已，它不管你那么多三七二十一！ 真的，它就只是一大堆数字，只不过有一定的纠偏能力而已。

这个问题DSH 自己就能修复。 只要你的要求告诉它就行了

在吗 我用dsh 0.2rc 也发现了和你一样的问题，我运行本地qwen27B 很多任务都做不下来，dsh一边压缩信息，一边大规模阅读我本地信息，导致很长时间上下文都被占满，再压缩。但是我换成codex 或者hermes就正常了。

那个 23206 tok/s 不是生成速度，是整轮聚合吞吐（prompt + decode 一起算），而且你这组数据缓存命中 0% → 几乎每个 step 都在全量重算 prefill，数字被 prefill 拉高了。 拆开看： 9 轮 50 步、6.5M tok：平均每步约 13 万 token，说明每步都把整段长上下文重新喂了一遍（0% 缓存命中），而不是只算增量。 prefill 是 compute-bound，A3B 这种小激活 MoE 在 5090 上跑几万 tok/s 很正常；真正决定体感的是 decode（单 token 生成），那是 bandwidth-bound，通常只有几十到一两百 tok/s。 对照你 V4.1 Flash 那组：1264M tok、缓存命中 97% → 绝大多数 token 走了缓存、只算 decode 增量，所以显示 278 tok/s 反而"慢"，但这更接近真实出字速度。 0% 命中的排查顺序： 每轮是不是新会话 / system prompt 前缀变了（工具 schema、日期等一变，前缀全 miss）； --hicache-size 24 对 1M 上下文 + 长对话可能偏小，放不下就被淘汰； Qwen3.6-35B-A3B 是混合线性注意力（含 Mamba 层），部分层未必支持前缀复用，--mamba-full-memory-ratio 0.4 也会影响可缓存量； 确认没传 --disable-radix-cache，并拿 SGLang 日志里的 radix/hicache hit rate 与面板对一下。 量真实速度：单开一个长输出请求，用 generated_tokens / 生成耗时 算；或用 python -m sglang.bench_serving --dataset-name random --random-input-len 1000 --random-output-len 512 看 output token throughput。要感知长上下文，就看第二次同前缀请求的命中率有没有上来。

@imbiplaza-ASUS 好吧，我弟你处于另一个层次，老夫唐突了。

@xiaote 帮我看看

@williamlouis 说: 它准确率不是100% 应用到财务流程中？ 也不算严格用在财务流程里吧，我想做的其实就是一个自动化创建、提交报销单的应用，输入出差时长，或者报销类目的简单自然语言的描述，以及发票，水单之类的文件，然后这个应用自动化分析，审核，最终提交报销单，达到减少员工的报销工时的目的。我们现在报销攒的多了，至少花一下午，甚至花一天去做提交 只要报销单正确率能到90%左右就好，这个应该可以实测多轮以后加一些自动化审核流程做到。最终提交的报销单有些小错误也不要紧，有外包的人员来审核报销单的错误，打回来再由人来改就好了。

整体判断：方向对，「少而按需」这个原则是对的——本地 27B-int4 的真实瓶颈就是工具 schema 膨胀 + 每回合多次调模型，不是插件数量。几处批注： prefix caching 别当万能。vLLM 的 APC 只在「前缀逐字节一致」时命中；插件如果每次按配置动态拼/重排工具列表，或系统提示里带时间戳、随机 id，前缀就断了，等于白开。要吃到 APC，得保证工具段顺序和内容稳定。这也反过来支持你「office 三选一」的结论。 真正决定工具能不能用的是 vLLM 启动参数，不是插件本身：必须带 --enable-auto-tool-choice --tool-call-parser hermes（Qwen 系用 hermes 或 qwen 解析器），否则不会返回结构化 tool_calls，插件装了也白装。建议把这条放在清单第 0 位。 dsh-model-manager 的「VRAM 校验」要注意口径：vLLM 按 --gpu-memory-utilization 预分配，nvidia-smi 看到的高占用是正常的，不能拿它反推「还能装多大模型」。换量化前的显存估算，按「权重 + KV(层数×头数×ctx×dtype) + 激活/图」手算更靠谱。 autofork 排第一我同意，但它会把并发拉起来：单卡跑 27B 时，分叉的新会话和后台会话共享同一实例的 KV 池，32G 卡要盯 gpu_cache_usage，别把 max-num-seqs / max-model-len 开太大导致抢占回退，否则「自动分叉」反而更慢。装在吞吐有余量的时候。 避开 telemetry 那条最关键，本地部署的隐私价值就在这，同意；MCP 限 1–2 个也对。 一句话：清单可以按这个装，但先把 vLLM 的 tool-call 参数和 prefix caching 的稳定性搞定，再谈插件——插件是乘法，底座是加法。