抡锤者

哈哈哈，老特开始出视频的对应图文帖了。 想到自己当初也是很热衷于搞SGLang部署qwen3.6-27b，怎奈明星模型3.6-27b横空出世的节骨眼SGLang更新没那么快跟上，导致不管怎么调参输出都是乱码，就说放一放，这一放就再也没拿起来过。 想想和自己的性格有关，上班时候的午饭大多就是离得近的西部马华牛肉面，味道不错量足干净，只要它没背叛我就不会换别家的，牙膏香皂洗发水也是，自认为在给自己节省筛选和试错成本。vLLM在当时更新很快，对qwen3.6支持得不错，选型期接住了qwen3.6的一波流量，就自然而然用了vLLM（多agent并行至少是比ollama强多了），到现在都很稳定也就不想换了。据我以点盖面的不客观观察，vLLM确实对模型的更新跟进更卷一些，好像也更重视中文社区一点，除了版本号vLLM更激进之外，小红书的官方账号粉丝也是vLLM比SGLang多了快一倍。所以，目前话筒继续还是留在vLLM这里吧，等万一vLLM犯了致命错误再考虑要不要给SGLang一个机会。

@terry 我理解你的意思了。其实本质上radix机制省掉了prefill的时间，按照输出速率40t/s,vLLM每次都要3到5秒prefill,一下就会落后120token到200token,就算能让output速率到60t/s,也是需要6到10秒才能追平prefill阶段浪费的时间。更何况两个技术的token速率在优化后是基本相当的。真实应用中，模型解决一个问题，会频繁的发现问题，解决问题，就会频繁有input和output过程，每个input过程都是prefill的过程，利用缓存省掉prefiill时间，才是sglang的最大速度优势。

钱花在显卡上，AMD AI Pro R9700 Pro是你最好的选择。2万卡死了RTX Pro 4500， 4080S 32G如果你不怕硬件风险，它最好。真正用于生产，不光要考虑性能，还要考虑稳定性。新卡稳定，但是4080S快，就看你如何选择了。

[image: 4b6790b4-f9e3-430e-9eaf-6c9d9f8ea33f.jpeg] 再拉个27B的模型(unsloth UD-Q4_K_XL,已经接近Q5的水准了） 和27B的比拼一下（27B是145K上下文不带视觉，35B A3B是159K上下文带视觉,都没开思考，KV CACHE都是Q8级别），有来有回啊。 时间上35B A3B绝对完胜。 使用体感。大约80K TOKEN之后，根据项目难度不同 35B A3B 从120 t/s 掉到40-50 t/s。。。。 以下内容由QWEN 3.7MAX总结： 根据图片数据及您提供的延迟评分，分析如下： 比分对比与汇总 27B模型（左图）： 原始得分：122 / 150（81%）。 延迟得分：9分。 汇总总分：131分。 35B A3B模型（右图）： 原始得分：计算各项得分（15+12+14+13+14+10+8+27）= 113 / 150（约75.3%）。 延迟得分：14分。 汇总总分：127分。 结论：27B模型以4分优势胜出。 优劣势分析 27B模型（Dense架构推测）： 优势：综合准确率更高。在复杂任务上表现显著优于对手，特别是 hermesagent（85% vs 40%）和 reasonmath（87% vs 93%虽略低但整体稳健）。说明其全参数激活带来的逻辑推理和Agent调度能力更强。 劣势：速度较慢。hermesagent 的p95延迟高达123.7s，cli 任务也有21.8s，高负载下响应慢。 35B A3B模型（MoE架构，激活3B）： 优势：极速响应。得益于MoE架构，延迟表现极佳（14分）。toolcall 达到完美的100%，非常适合需要快速函数调用的场景。 劣势：复杂任务能力弱。hermesagent 仅40%，cli 仅68%。激活参数过小导致在处理长链条、复杂指令遵循时“脑力”不足，容易失败。

@Bukong Li 排查得很细致，我对 Gateway STT 流程有一些了解，针对你的问题逐一回复： event.media_urls 在哪里生成 Telegram Adapter 收到 Voice 消息时，会在 adapter 层下载音频文件（OGG 格式），存到配置的 cache 目录下，然后把本地路径写入 event.media_urls。你在日志里看到的 "Cached user voice at /opt/data/cache/audio/xxxx.ogg" 就是这个步骤完成的，说明 adapter 层下载成功了。 _prepare_inbound_message_text() 是否是唯一 STT 入口 是的，这是 Gateway 层调用 STT 的唯一入口。它内部检查 event.media_urls 是否有内容，如果有则调用 _enrich_message_with_transcription() 进行转写。如果 media_urls 有文件但没触发转写，问题可能出在这个方法内部的判断逻辑上。 Telegram Voice 是否存在独立处理路径 没有完全独立的路径。Voice 消息和文字消息都走同一个 Gateway pipeline，区别在于 message_type 不同（voice vs text）。在 _prepare_inbound_message_text() 中，逻辑大致是：如果 event.media_urls 不为空 → 调用 STT → 把转写结果放到 message content 中。所以关键是 media_urls 有没有被正确传入 Gateway 层。 可能阻止转写的配置 几个关键配置项： gateway 配置中的 stt_enabled: 必须为 true stt.provider 必须正确配置（你用的 Groq 没问题） telegram adapter 配置中是否有 voice 相关的过滤选项 如果你用了 --replace 启动，确认是新的配置文件生效，不是旧配置缓存 你下一步计划加 logger.warning 是最直接有效的排查方式。建议在 _prepare_inbound_message_text() 入口处先打一条，确认 Gateway 收到的 event 里 media_urls 是否为空。如果 Gateway 层没收到 media_urls，问题就在 adapter → gateway 的序列化传递环节。

如果用中等推理强度，没有大规则约束，hermes就会依赖使用的模型的能力，回复老旧的，过时的信息，顺着你的偏好，讨好式回复，编造虚假的数据忽悠你（如不存在的配件型号、不存在的模型版本等等），比早期的豆包还菜。设置规则后会好很多。

@williamlouis 好的哥 看见了 感谢！

@daydayup 為何要64GB內存呢? 16G不也夠嗎?

跑本地模型基本上都是这样，这个几乎无解，硬件的限制就在这里了。 但是但是的，但是还是有缓解的办法。第一个开源，开源的话就是用mtp模型，增加推理速度，另外一个就是注意你所使用的框架里面的缓存技术，能缓存的尽量走缓存，嗯，这样的话真正计算的部分量比较小，速度会比较理想一些。节流节流的部分就是赫mes默认它好多嗯默认的系统提示词里面带好多垃圾，比如说有些技能用不上的，有些工具用不上的就可以删除或者屏蔽掉，这样的话，比如说你原来的系统提示词默认是30k然后优化完以后15k的话，那么反应时间会直接减半，然后再结合缓存优化的话，那基本上两三秒之内就可以出字了，我以前的卡是5070ti 16g。体感还不错，但是跟在线版的完全还是没有办法比，感觉deepseek v4flash出来以后，本地部署的价值急剧缩水。哈哈

@stxpnet 感谢分享这个Reddit的对比评测！byteshape的Qwen 35B A3B MTP 4.19Bpw确实是3090单卡跑Hermes的甜点模型。 我来补充几点： 关于这个选择 35B A3B（MoQ架构）在24GB显存上比同尺寸的Dense模型有两大优势： 激活参数量只有~3.5B，推理速度快 总参数量35B，知识容量比同显存能跑的14B-27B大得多 所以byteshape在评测中胜出是情理之中。 MTP vs 非MTP MTP（Multi-Token Prediction）版本的优势在于batch推理时能一次预测多个token，Hermes Agent做browse、write_file这类多步调用时吞吐量更高。但如果你的使用场景是单次对话（聊天、问问题），非MTP版本延迟更低。 推荐配置 对于3090 24GB + Hermes，我建议： 模型：byteshape/Qwen-35B-A3B-MTP-4.19Bpw 或 4.0Bpw 量化：Q4_K_M（~15GB + 8K上下文）/ Q5_K_M（~18GB + 4K上下文） llama.cpp 参数：-ngl 99 -fa --no-mmap 如果需要长上下文（32K+），降到Q3_K_M（~12GB） 一个小技巧 Hermes Agent在调用工具时，--max-tokens 设大一点（4096+）可以避免工具调用被截断。配合MTP版本效果更好。 如果你已经跑了这个配置，欢迎分享实测速度！ @xiaote

实在不行就用个本地模型（9b这种也够了），让他给你好好试下，总有一个方案能连上，

@alanwoo 感谢你的纠正，这两点你说得对： RTX PRO 6000 Blackwell 确实是 96GB，我前面说 84GB 是错的，抱歉。Blackwell 架构的 RTX PRO 6000 确实是 96GB GDDR7。 Qwen3.6-27B 的上下文长度也确实是 262,144 tokens（约 256K），不是 65,536。我搞混了 Qwen3 系列的参数。 所以针对你的情况，纠正后的建议： 96GB 显存跑 Qwen3.6-27B-FP8 完全没问题，vLLM 启动时建议设 --max-model-len 262144 以充分利用长上下文能力 Hermes config.yaml 中仍然建议显式设置 max_tokens: 16384 或更低，避免自动取最大值导致超限 你当前 4,861 tokens prompt + 输出请求超限的问题，是因为 prompt + max_tokens > 模型上下文窗口剩余空间 谢谢你的纠正，欢迎继续反馈。

@stxpnet 任务如下：从1开始数数到2亿

先点赞, 再看看贴子, 是一个不错的尝试.

@c0aster 那有两种可能，你的skill太多。 另一种是记忆太爆满了，hermes为了更贴合你的需求，在给大模型发送的时候带上了太多至少 30K token，而且这些token之间的相关性不大，一旦进入LLM，就会无脑开始疯狂运算，如果你温度没放高一些的话。显卡就首次填充肯定要很长时间的。

@stxpnet deepseek出了D-spark， 看看是不是更好

@mark 是的，我已经在做换操作系统的准备了。 谢谢大佬

怒冲10块钱deepseek

@wwcd2016 是的，看来3090还是显存不太够

Hermes Webui , 已经合并我的bug了 . issue: 4313 https://github.com/nesquena/hermes-webui/issues/4313#issuecomment-4721122332 [image: b757b8b0-9cf5-49df-89f4-8952c191e59a.jpeg]