抡锤者

@williamlouis 好的 谢谢大佬推荐

3年前的硬件能驱动世界知名车企的电车满街跑的水平。 但是人家顶尖的调优团队，并且是专用硬件和软件

@Che 0.0% 大概率不是故障，而是「没有可命中的公共前缀」。vLLM 的 prefix cache 只在请求开头有完全相同的 token 序列时才命中，按这个顺序排查： 先确认开关。老版本（0.6 之前）要显式加 --enable-prefix-caching 才开缓存，新版本默认开。跑一下 vllm serve --help | grep prefix 看你的版本；如果是从别处抄的启动参数，注意有没有 --disable-prefix-caching。另外极老版本还要配合 --enable-chunked-prefill 才生效。 自测方法：同一个 prompt 原样连发两次，第二次 hit rate 应该明显大于 0。如果第二次上去了，说明缓存本身是好的，你平时看到 0% 只是因为每次请求前缀都不同——这是正常现象，不是 bug。如果连发两次还是 0，才需要怀疑开关或配置。 最隐蔽的杀手：前缀「看着一样、token 不一样」。Chat UI 如果每次在 prompt 最前面注入时间戳、随机 request id、或者带变化的系统提示词，哪怕只差一个 token，整个前缀全部失配，命中率直接归零。系统提示词要保证字节级一致，别用动态拼接。 长上下文会把缓存挤爆。你这种双 3090 场景如果 max-model-len 开很大，KV cache 预算被长序列占满，LRU 淘汰非常激进，缓存条目很快被换出去，命中率自然上不去。max-model-len 按实际需要设，别贪大，给缓存留空间。 /metrics 里的 hit rate 是服务启动以来的累计均值，不是最近一分钟的实时值。刚起服务、前面全是独立请求时，均值就是 0.x%，别被吓到。想验证就看 vllm:num_prefix_cache_hits 这个计数器的增量，而不是看百分比。 补充一句：TP=2 下 prefix cache 按层分片正常生效，不需要特殊处理。真正要盯的是你的请求模式——如果每个用户会话都是独立历史、没有共享的 system prompt 前缀，那这个指标低是预期行为，省下的显存留给 KV cache 更实在。

@YDM 这个和SG-lang无关，和模型有关，Qwen也不是每次都能答对。训练过的就100%能答对。

我选方案2，但要说清楚：这不是"改善体验"的锦上添花，而是必要的信息可见性——你那个C盘例子恰恰证明了这一点。 两小时没清出垃圾，大概率不是 thinking 的锅，而是工具循环卡死：模型在反复尝试同一个失败的命令（权限不足的删除、被占用的文件、路径写错），thinking 只是它"心里的话"，真正卡住的是你看不见的工具调用过程。不把思考过程和工具调用都流式显示出来，你根本分不清它是"在想"还是"卡死了"——这才是你说的体验问题的根源。 怎么让 thinking 可见：Qwen3.6 走 OpenAI 兼容接口时，思考内容在 reasoning_content 字段里，Hermes/codex 这类前端透传这个字段就会流式显示出来。你本地跑 qwen3.6:27B，Ollama 的兼容接口对 Qwen3 系也会把 thinking 透传出来，前端能看到就不存在"以为卡死"的问题了。实在不想折腾的话，llama.cpp 有 --no-thinking 可以直接关。 我的建议是按任务分流，别全局开关： 简单任务（清理磁盘、改配置、跑固定流程）：关 thinking，快和稳优先； 复杂任务（写代码、排错、方案设计）：开 thinking，但配一个能显示思考过程的前端，至少能看出它卡在哪一步、重试了几次。 至于"本地模型 thinking 没区别"——27B 这种规模的模型 thinking 收益确实比云端大模型小，但"看不出区别"很多时候是因为你压根看不见思考过程才下的结论。先把输出流式化，观察几天再决定关不关，比拍脑袋直接关掉更靠谱。

@kop-wang 说: 但是prefill速度也降了。总体上来讲，目前的重Agent场景，总体性能，prefill和decode速度各占一半。 agent得另算，我使用场景关注并发，不关注TTFT等延迟。这个log现在不优化直接开batch=4并发已经可以输出接近1000 tokens/s，还是在我把vllm的gpu利用率限制在0.55情况下，这要升级到0.92后续继续优化我都不敢想，没准直接上1800了

目前就是 使用qwen 3 6 27b吧 等 ornith 1.0 31b dense 出來 再討論這個問題比較有意義

哈哈哈，老特开始出视频的对应图文帖了。 想到自己当初也是很热衷于搞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的最大速度优势。

@terry 说: @applejuice 这个我可以参考下，抄作业，有空弄下。awq的还是值得玩的。你Hermes调度时，有思考过程吗？ [image: fd30c376-f764-46d4-847b-344e46cf5d9b.jpeg] 有的. 其实也不是我弄的 ai 全自动搞

如果是功能性任务，35b足够，它只是无法长期胜任全面Agent助手，幻觉严重。编程其实都不是事，因为大多数人写的小程序都不复杂。

看看这个项目，我实测qwen3.6-27b fp8 k8v4的kvcache 可以到230k的上下文，mtp 3支持多模态，prefill可以1800+ t/s decode 70+ t/s 我实测使用llamc.cpp 启用nccl的情况下跑qwen3.6-27b q6 q8的kvcahce 可以到400k的上下文池，np为2 mtp 3 prefiil可以到1000t/s , decode可以60t/s

不是有BUG，是使用了谷歌搜索，没有使用原生搜索，现在网站收录的内容还不够快，有很多页面没加入谷歌索引。但是开弓没有回头箭，现在既然已经切换了谷歌搜索，就只有等收录情况慢慢变好，大概要几个月时间，这是没办法的事。如果几个月后用户多了再切换，不适应的人更多。

反正后面都是要全力工作的了，待机功耗大无所谓拉

@stxpnet 具体外挂是什么原理呢

@topgun2000 有可能，但是我这块板现在实际跑起来，是现实pcie4.0的速度的。只不过还没想起来要测试一下实际能到多少。可以试试，回头发论坛看看

@AGI llama.cpp的架構只適合單人使用啊, 并發的請求處理是一個接一個

@kop-wang 我找了一下 说是比较偏向coding 但是不能调用工具查资料 coding 也废了一半 我的coding 比较多是商业逻辑 是有看到gemma比较差 但是没想到我完全用不了 我感觉QWEN3.6 27b 的智力有以前MINIMAX 2.7 的智力 MINIMAX3.0 没用过所以不知道 看了你的那个链接 感觉我上面的体验是对的

@stxpnet 说: @九龙杨生 参数，硬件各方面都有。我打算把我的HERMES配置来专门做调参师。 本地模型要玩起来要么升级硬件，要么不断优化参数。 大家差不多，我只是在调教我的越狱模型

@566656661 螺蛳壳里做道场，享受的只是乐趣，大公司在线版肯定蹍压我们。但，这是我们自己的，就像自己家一样。意义大抵在此吧，个人所见，难免偏颇。