<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Gateway on </title>
    <link>/tags/gateway/</link>
    <description>Recent content in Gateway on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Fri, 17 Apr 2026 18:00:00 +0800</lastBuildDate><atom:link href="/tags/gateway/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>两台 DGX Spark 跑 Qwen3.6-35B-A3B：直连 vLLM vs 经过 Gateway 的吞吐对比</title>
      <link>/posts/qwen36-vllm-gateway-benchmark/</link>
      <pubDate>Fri, 17 Apr 2026 18:00:00 +0800</pubDate>
      
      <guid>/posts/qwen36-vllm-gateway-benchmark/</guid>
      <description>TL;DR 两台 DGX Spark 各自独立运行 vLLM 推理 Qwen3.6-35B-A3B-FP8，前置一层 FastAPI 写的 LLM Gateway 做路由/负载均衡，实测结果：
单请求解码吞吐：机器本地 curl 稳定在 ~50 tok/s，客户端经 Tailscale 访问约 ~45 tok/s（差的是网络往返时间） Gateway 代理开销：serial 场景下相对直连差异 &amp;lt;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.</description>
    </item>
    
  </channel>
</rss>
