/tags/qwen/ Recent content in Qwen on Hugo -- gohugo.io en Mon, 20 Apr 2026 12:15:00 +0800 /posts/vllm-qwen36-preserve-thinking/ Mon, 20 Apr 2026 12:15:00 +0800 /posts/vllm-qwen36-preserve-thinking/ TL;DR Qwen3.6 的 preserve_thinking 是写在模型 chat template 里的 Jinja 变量，不是 vLLM CLI 标志。 正确启用方式：--default-chat-template-kwargs '{"preserve_thinking": true}'。 在双机 DGX Spark 集群上用一台开、一台关做 A/B 对照：同样输入下 prompt tokens 55 vs 51（差 4 tokens 就是保留下来的历史 <think> 块），completion tokens 355 vs 382（关掉后模型重新"想"一遍）。 起因 Reddit 的一篇文章提到 Qwen3.6 随 KV cache 修复一起 “ships preserve_thinking flag”（原文链接）。集群里跑的正好是 Qwen3.6-35B-A3B-FP8（reasoning parser qwen3），想在两台 DGX Spark 上把这个开关打开。 参数归属：chat template 而非 vLLM CLI 这里"flag"是个容易误导的措辞。Qwen3.6 的 chat_template.jinja 里写着： {%- if (preserve_thinking is defined and preserve_thinking is true) or (loop. /posts/qwen36-vllm-gateway-benchmark/ Fri, 17 Apr 2026 18:00:00 +0800 /posts/qwen36-vllm-gateway-benchmark/ TL;DR 两台 DGX Spark 各自独立运行 vLLM 推理 Qwen3.6-35B-A3B-FP8，前置一层 FastAPI 写的 LLM Gateway 做路由/负载均衡，实测结果： 单请求解码吞吐：机器本地 curl 稳定在 ~50 tok/s，客户端经 Tailscale 访问约 ~45 tok/s（差的是网络往返时间） Gateway 代理开销：serial 场景下相对直连差异 <5%，几乎无额外开销 单机并发饱和点：N≈8 时单机聚合吞吐 ~300 tok/s（6× 单流） 双机聚合上限：经 Gateway round-robin 在 N=16 下 ~485 tok/s，接近这组测试里两台机器各自饱和时的合计 结论：在这组测试里，如果想更充分地利用两台机器，还是要走 Gateway，且客户端并发度也要跟上；低并发时 Gateway 与直连差异不大。 环境背景 两台机器都是 NVIDIA DGX Spark，GB10 Grace Blackwell Superchip + 128GB LPDDR5X 统一内存。通过 Tailscale 组网，内部 200-subnet 做机器间低延迟直连： ┌──────────────────────────────────────────────────────────┐ │ DGX Spark 集群 │ │ │ │ Server 1 (100.