抡锤者

@wml-ai 对啊，27b干一些小活脚本之类的还是很不错的，到flash next就是真的可以放心做很多事情了，肉眼可见的提升！ 我的pt账户好久不登录，然后被封了。昨天让flash next给我手搓了一个，嗯，当然不是从零开始，而是说它给我配置了各种docker compose，还有一个集成的操作的界面之类的。吭哧吭哧干了几个小时，虽然最后还是不能用，但是整个流程是跑下来跑通了一点问题没有。不能用，是因为现在已经公网的BT种子已经几乎绝迹了，这个是大环境的问题，不是他模型能力的问题。

@applejuice 這版沒裝過，感謝分享，裝來試試看。

@909 架子支持定做尺寸，买完架子后，自己加个尼龙纱网 40目的就可以了 [image: image.jpeg] [image: image.jpeg]

@Tony-Wang 卖豆浆的看到开奔驰的，也要涨点价格，

@stxpnet 说: 我反而想让CPU高点都不行。 你的是四卡 异构啊，怎么没试一下tabby api? 我只用buun 跑过双卡 张量并行。 SB了，我是跑的Qwen3.8-flash . 现在准备跑Swift1.5

请教vllm以下方案是否合理： [image: image.jpeg] 或者把Qwen3.8-27B改成Qwen3.6-27B是不是更稳定。

牛逼，这卡马上就要进博物馆了。

@Kenneth-Wu 可以. 我四卡v100 32G x 4 的qwen 3.8 flash next是跑SGLang, 雙卡V100 32G x 2 qwen 3.8 27B是跑llama.cpp

哦，这样的啊，我的AI抓的是65K,然后自己改成200K了。

[image: Screenshot 2026-09-23 at 17.52.36.png] [image: Screenshot 2026-09-23 at 17.52.55.png] 以上问了两轮，速度比较稳定。思考比较长，聪明的代价

前提已经点到了（两边不同模型），所以结论最好只落在「引擎」这一层，别被模型规模污染： 想比引擎就得等模型：8B BF16 两边各跑一次，或在两边都能加载的档位上跑同一个 27B（SGLang 若在 gfx1201 确实没有 int4 kernel，就退到能加载的 FP8/AWQ），否则「vLLM 快」永远分不清是引擎、量化还是投机。 你已经算出的 28/31≈90% 其实是最重要的一条：SGLang 在这张卡上没跑慢，是被 494 GB/s 带宽锁死。27B int4 的 54–62 要拆成两笔账——量化把权重从 54GB 压到 18GB（带宽瓶颈 54→27 t/s），DFlash2 再把有效吞吐抬 ~2×——别整笔记到引擎头上。prefill 6800 vs 1700 ≈4×、参数 3.4×，两边 prefill 效率其实同级。 agent 负载另看前缀缓存命中率与 TTFT p95：vLLM 有 78.8% 生产实据，SGLang 的 RadixCache 只是启用未测。用同一条 agent trace 对打命中率 + p95，比单流 decode 更能说明「服务端谁更好」。

@terry 好的，抱歉添麻烦了，以后我会注意检查格式再发，感谢修复！

@johnnybegood 长链任务看的是否有radix缓存树这种增量prefill，比如halogen，比如ninfer都有这样的能力，其它的优化只是锦上添花。

整体判断：方向对，「少而按需」这个原则是对的——本地 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 的稳定性搞定，再谈插件——插件是乘法，底座是加法。