抡锤者

看起来KVCache相当省啊。可惜在速度上NInfer对40系提升不像5090那么大

很难赞同。炒作是一定有的，但不代表它没有价值。

就拿我之前看到的一个举例：
https://form-jev-scene-lab.op7418.chatgpt.site/

毫秒级切换场景布局。恕我孤陋寡闻，我不知道在此之前应该用什么模型实现同等的效果。

它的判断力确实还相当有限；但是给很多场景加上一个几乎无感知的前置决策，我觉得是有用的。

laya 零样本 似乎达不到可用水准；

openjev 似乎质量还行，但不够快。想试下这个。

step plan 官网是售罄状态。

看不懂。我只说说我作为外行的想法：

1. 魔改显卡+二手拆机配件？
2. qwen3.8-27B 当豆包用？小模型知识量少，也许是接入你们的知识库？
3. 硬件都没买的情况下，你说你做好了软件。。最好别到时候发现数不清的问题。
4. 20并发不需要太大显存，关键是你需要多大的上下文、响应/吐字速度、精度。
5. 建议就是对他们的需求摸个底，尽量压低配置，没提到的东西统统不要上；选质量有保障的硬件，降低风险。总之就是砍上限保下限。

PD分离么，有点意思。但是GB10算力一般；通信带宽也许足够了，但延迟可能会很糟糕。

看不懂。量化权重+draft权重+视觉塔算30G吧，这还剩60G VRAM；qwen3.8 在KVCache FP8量化下，262K context约12G；5并发各262K上下文，完全是足够的，在纠结什么？

我入坑本地部署得到的最大教训就是不要本地部署。先建立你完整的AI工作流，跑一段时间后分析成本，再决定要不要做本地部署，否则真的就只是在“玩”。

为什么要换呢？没钱不换；有钱直接买套新的。加/换内存即可

Artificial Analysis

qwen3.6 ⇨ qwen3.8，分数 38 ⇨ 52，都撞到ds4p了

@用户名违规 怎么会全量 prefill 呢？把三级缓存都打开试下？

export SGLANG_HICACHE_FILE_BACKEND_STORAGE_DIR="/path/to/kvcache/folder"

  --mamba-radix-cache-strategy extra_buffer \
  --enable-hierarchical-cache \
  --hicache-size 16 \
  --hicache-storage-backend file \
  --schedule-policy lpm \
  --enable-session-radix-cache \
  --enable-metrics \

hicache-size 根据内存大小设置，或者用 hicache-ratio

@stxpnet 挺奇怪，只占显存不推理应该是没功耗的

@johnnybegood 直接上个空调机柜会不会好点？

我的也是16GB。魔改厂商不太可能帮你把BAR1开到32GB。想改内核开P2P的话，风险很大。参考：https://duanyll.com/2026/7/13/4090-48G-P2P/

这很奇怪吧，32G 显存开不起 22G 权重？不要用 --gpu-memory-utilization，改 --kv-cache-memory-bytes 4G 试试，MTP 也先去掉。

TurboQuant 好处是 KVCache 容量比 FP8 大了将近1倍（仅以我的设备为例；vLLM）：

FP8：

GPU KV cache size: 1,006,391 tokens

TurboQuant：

GPU KV cache size: 1,900,544 tokens

---

官方声称 TurboQuant 吞吐量比 FP8 低很多，我还不以为意；接入 harness 实战后，降速凸显：

FP8，多并发：

Avg generation throughput: 443.6 tokens/s, Running: 12 reqs, Waiting: 0 reqs, GPU KV cache usage: 18.0%

TurboQuant，多并发：

Avg generation throughput: 264.0 tokens/s, Running: 12 reqs, Waiting: 0 reqs, GPU KV cache usage: 9.2%

FP8，单并发，约 72k 时：

Avg generation throughput: 56.0 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 7.3%

TurboQuant，单并发，约 72k 时：

Avg generation throughput: 22.0 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 3.8%

可见 TurboQuant 比 FP8 至少慢了 40%，而且越长越慢。真的是没有白捡的 KVCache

并发数用 --max-mamba-cache-size 控制比 --mamba-full-memory-ratio 更好。

--mamba-radix-cache-strategy extra_buffer_lazy 时，--max-mamba-cache-size = 并发数 x 4

另外，--speculative-num-steps 对 MTP 的影响可能比 --speculative-num-draft-tokens 更大。

再来个黑洞：

89ad3a80-3411-4807-806f-4be6e1b55bea-standalone.html

花了挺长时间。加上subagent，差不多2M tokens

提示词来自L站：

在当前目录下，使用web技术制作一个图形化预览黑洞效果的网页，要求外观和样式要类似于电影《星际穿越》里面的黑洞卡冈图雅。黑洞背景要有其他星星，黑洞要有跟电影里类似的吸积盘效果和引力透镜效应。用户可以用鼠标旋转观察，并且在侧边栏可以调整相关参数体现不同参数黑洞的不同效果。你可以使用你认为必要的技术来实现这个网页，既要保证性能也要完成必要的效果。可以引入你觉得必要的第三方图形库比如three.js等等之类。

补充两个挡位的思考强度

思考强度：低



和无思考几乎没有差别，很快，成果也很糟糕。

---

思考强度：高
pelican-ride.html

似乎比思考强度中略好，但是思考花了28k，并且调用工具失败1次，两次代码生成分别为 3.2k 和 7.7k，耗时长了很多。

dc133d52-4854-488d-b642-ab00fc37ba7f-pelican-bike.html

(APIServer pid=120761) INFO 08-18 10:53:17 [loggers.py:310] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 38.0 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 1.5%, Prefix cache hit rate: 39.9%, MM cache hit rate: 0.0%

(APIServer pid=120761) INFO 08-18 11:07:15 [loggers.py:310] Engine 000: Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 26.0 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 2.7%, Prefix cache hit rate: 67.8%, MM cache hit rate: 0.0%

模型	cyankiwi/Qwen3.8-27B-AWQ-INT4
聊天模板	froggeric/Qwen-Fixed-Chat-Templates
思考强度	中（模板默认）
框架	vllm 0.27
KV量化	turboquant_4bit_nc
harness	ClaudeCode
tokens	约 26k
总用时	14m

说明

• tokens 构成：思考 16k + 代码 10k + ClaudeCode 内置工具+系统提示词 21k ≈ 49k（如图）
• 速度及用时因设备而异。无MTP

超绝大思考。。知道的以为它在干活，不知道的还以为它似了呢