# SGLang 支援 Qwen3.8-27B 本機部署，RTX 5090 單卡達 206.1 tok/s

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：SGLang (@sgl_project) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥🔥 · 日期：2026-08-15

> 原始來源：https://x.com/sgl_project/status/2088281320422322413

## 證據與延伸閱讀

- [SGLang 支援 Qwen3.8-27B 本機部署，RTX 5090 單卡達 206.1 tok/s。](https://x.com/sgl_project/status/2088281320422322413)
- [Alibaba_Qwen 確認單卡效能與支援](https://x.com/alibaba_qwen/status/2088293486995087461)
- [模型共有 64 layers 與詳細架構設定](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B) — 官方文件

## 中文摘要

SGLang 支援 Qwen3.8-27B 本機部署，RTX 5090 單卡達 206.1 tok/s。

**分享重點** SGLang（`@sgl_project`）在 2026 年 8 月 14 日分享 Qwen3.8-27B 已開放原始碼，並宣布 SGLang 已提供 Day-0 支援。貼文的核心主張是：這款 27B 模型不只適合一般推論，也在 agentic planning 與 long-horizon tasks 上再次提高小型模型的能力門檻；SGLang 希望使用者直接在本機執行它。Alibaba_Qwen 隨後回應，確認單張 RTX 5090 可達約 206 tok/s，並肯定 SGLang 團隊的即時支援。

這次分享也延續 Qwen3.8-27B 開放權重後的部署脈絡。本站先前策展過〈[Qwen3.8-27B 開放權重]( /curated/2967)〉——該模型具備 262K tokens 的多模態上下文；本次 SGLang 貼文則把焦點放在實際 serving、硬體配置與可重現的部署命令上。

**效能結果** 貼文列出兩個明確的 decode throughput：

- 單張 RTX 5090：206.1 tok/s，使用 SGLang 的 NVFP4 與 DSpark。
- DGX Spark：38.28 tok/s。

這些數字是貼文用來支撐「小型模型之王回歸」的主要證據，但不代表所有硬體、量化格式或工作負載都能得到相同結果。來源文件提供的是不同硬體與 serving recipe 的配置表，而非一組涵蓋所有條件的統一 benchmark；因此，實際速度仍會受到量化格式、批次大小、並發數、預填區塊大小、推測解碼與記憶體配置影響。

**模型與權重** Qwen3.8-27B 被文件描述為 dense hybrid GDN vision-language model，也就是把 Gated Delta Networks（GDN）與完整 attention 混合使用的視覺語言模型。它支援圖像、影片與文字理解，並透過 Qwen3-VL path 提供 vision serving。模型共有 64 layers，結構為 16 次重複的 `3 × (Gated DeltaNet → FFN)`，再加上 `1 × (Gated Attention → FFN)`：

- 48 個 linear-attention layers 與 16 個 full-attention layers。
- Gated DeltaNet 使用 48 個 value heads、16 個 QK heads，head dimension 為 128。
- Gated Attention 採 GQA 24/4，head dimension 為 256，包含 64-dim rotary slice。
- hidden size 為 5120，FFN 維度為 17,408。
- checkpoint 內建 multiple-step training 的 MTP head。
- native context 為 262,144 tokens，可延伸至 1,000,000。
- Thinking mode 預設開啟，但可以逐 request 關閉；`reasoning_effort` 可調整 reasoning depth，`preserve_thinking` 可保留先前 messages 的 reasoning context。

目前文件列出三種主要權重：

- BF16：[`Qwen/Qwen3.8-27B`](https://huggingface.co/Qwen/Qwen3.8-27B)
- FP8 blockwise：[`Qwen/Qwen3.8-27B-FP8`](https://huggingface.co/Qwen/Qwen3.8-27B-FP8)
- NVFP4 W4A4 加 FP8 projections：[`RadixArk/Qwen3.8-27B-NVFP4`](https://huggingface.co/RadixArk/Qwen3.8-27B-NVFP4)

SGLang 的 cookbook 對應模型為 `Qwen/Qwen3.8-27B`，模型名稱會依硬體、variant 與 quantization 解析。解析順序包含 `hw|variant|quant`、`variant|quant`、`hw|quant`、`quant`、`hw` 與 `default`，再將 `{{MODEL_NAME}}` 等 placeholder 插入產生的 command。

**硬體與量化** Cookbook 配置支援 `h200`、`rtx6000`、`rtx5090`、`dgx-spark` 與 `gb300`；variant 只有 `default`，quantization 包含 `BF16`、`FP8` 與 `NVFP4`，`strategy` 則有 `Balanced` 與 `High-Throughput`。這些 cell 目前以 Single Node 為主，文件明確列出下列模型 mapping：

- BF16：`Qwen/Qwen3.8-27B`
- FP8：`Qwen/Qwen3.8-27B-FP8`
- NVFP4：`RadixArk/Qwen3.8-27B-NVFP4`

硬體支援範圍不等於每個硬體都支援每種 quantization。H200 是 SM90，沒有 FP4 tensor cores，因此 NVFP4 cell 會被停用；其 MLP 會退回 Marlin W4A16 weight-only path。RTX PRO 6000、RTX 5090 與 DGX Spark 屬於 Blackwell 相關平台，其中 RTX PRO 6000 有 96GB VRAM、RTX 5090 有 32GB VRAM；DGX Spark 則是 128GB、與 host CPU 共用的 unified memory，三種 checkpoint 都能放入，但來源仍指出其 SM121 recipe 尚未完成該平台驗證。

NVFP4 checkpoint 宣告 `kv_cache_quant_algo: FP8`。在 SGLang 中，預設的 `--kv-cache-dtype auto` 會採用 checkpoint 設定，讓 KV pool 使用 `fp8_e4m3` 與對應 calibration scales。SM120／SM121 平台應使用 `--attention-backend flashinfer`，因為 `trtllm_mha` 僅支援 SM100。若要使用 MTP，FlashInfer 的 prefill `plan` 必須支援 `uniform_q_len`，版本需新於 `0.6.15.post1`；否則應改用 `--attention-backend triton`。

**已列出的部署狀態** 文件刻意區分「verified」「Final Verification In Progress」與「Not Verified」，未把未驗證配置當成已確認結果：

- H200 的 BF16、FP8 Balanced 單節點配置已 verified，使用 `--mem-fraction-static 0.85`、FlashInfer、`--chunked-prefill-size 32768` 與 `--max-prefill-tokens 32768`。
- RTX PRO 6000（文件內部 ID 為 `rtx6000`）的 BF16、FP8、NVFP4 Balanced 已 verified，`--chunked-prefill-size` 為 `2048`。
- RTX 5090 目前列出已 verified 的 NVFP4 Balanced，static memory fraction 為 `0.85`，chunked prefill 為 `2048`。
- DGX Spark 的 NVFP4、FP8、BF16 Balanced 使用 `--mem-fraction-static 0.95`、`--chunked-prefill-size 8192` 與 `--disable-prefill-cuda-graph`，但來源沒有將這三項標為 verified。
- GB300 的 NVFP4、FP8、BF16 Balanced 均已 verified，使用 `0.85` static memory fraction 與 `2048` chunked prefill。
- GB300 另有三種 quantization 的 High-Throughput verified 配置，加入 EAGLE speculative decoding。

GB300 High-Throughput 配置使用以下 flags：

```bash
--speculative-algorithm EAGLE
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4
```

文件也說明，原先有些文件使用 `NEXTN`，但它只是 EAGLE 的 alias，演算法相同。DSpark 則使用獨立的 draft model：

```bash
--speculative-algorithm DSPARK
--speculative-draft-model-path RadixArk/Qwen3.8-27B-DSpark
```

FP8 權重約 28.5GB，在 32GB 顯示卡上除了 batch size 小於或等於 2 的情境外，不適合 serving；NVFP4 約 16.5GB，較適合 RTX 5090 等級的 GPU。

**部署介面與 command generator** 官方 cookbook 為 [Qwen3.8-27B](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B)，完整文件索引則位於 [SGLang Documentation Index](https://docs.sglang.io/llms.txt)。介面由 Deployment 與 Playground 組成：

- Deployment 只輸出模型已文件化的 launch recipes。
- Playground 可在目前 Deployment cell 上增加注意力機制、推測解碼、PD disaggregation、HiCache、MoE 與其他 knobs。
- 輸出模式支援 Python 與 Docker，可複製 command、查看 cURL 與 Env placeholders。
- `CURL_HOST`、`CURL_PORT` 等環境值會保存至 `localStorage`，之後造訪其他 cookbook 時重用。
- selection 會同步至 URL hash，並透過 `sglang-deploy-sel` CustomEvent 在 Deployment 與 Playground 間同步。
- 沒有 verified base cell 時，介面會顯示：
  ```text
  # No verified base cell at the current Deployment selection.
  # Pick a supported hardware/variant in the Deployment panel to populate the playground base.
  ```

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f02eea16ee964e2e.png)
> Qwen3.8-27B 的部署介紹介面，左上方帶有橘色 SGLang 的 logo 文字與標誌，中央顯示模型名稱「Qwen3.8-27B」與其下方關於 dense hybrid GDN 視覺語言模型部署的英文說明文字，背景為深色漸層。

Python 安裝路徑是先更新 `pip`、安裝 `uv`，再安裝 SGLang：

```bash
pip install --upgrade pip
pip install uv
uv pip install sglang
```

Docker 路徑使用 `lmsysorg/sglang:qwen38-27b`：

```bash
docker pull lmsysorg/sglang:qwen38-27b
```

來源也提到一般 Docker fallback image 為 `lmsysorg/sglang:dev`。Docker command 會使用 `--gpus all`、`--shm-size 32g`、`--ipc=host`，並掛載：

```text
-v ~/.cache/huggingface:/root/.cache/huggingface
--env "HF_TOKEN={{HF_TOKEN}}"
```

需要 host network 時會使用 `--network host`，否則以 `-p ${servePort}:${servePort}` 映射服務連接埠。DGX Spark 的 multi-node Docker 還需要：

```bash
--ulimit memlock=-1:-1
--cap-add IPC_LOCK
--device /dev/infiniband
```

這些設定涉及解除 memlock 限制、增加 `IPC_LOCK` capability 與掛載 Infiniband 裝置，應依部署環境與權限需求人工核對，不宜在不了解主機安全設定時直接套用。

**基本 serving 參數** 預設 placeholder 為 `HOST_IP=0.0.0.0`、`PORT=30000`、Docker 使用的 `HF_TOKEN=<your-hf-token>`、`CURL_HOST=localhost` 與 `CURL_PORT=30000`。一般服務 command 會包含：

```text
--model-path {{MODEL_NAME}}
--host {{HOST_IP}}
--port {{PORT}}
--trust-remote-code
--reasoning-parser qwen3
--tool-call-parser qwen3_coder
```

其中兩個 parser 對 Agent 使用相當重要。缺少 `--tool-call-parser qwen3_coder` 時，tool call 可能以 raw text 而不是結構化 `tool_calls` 傳出；`qwen3_coder` 會解析 `<tool_call></tool_call>` 內的 `<function=…>` 與 `<parameter=…>`，而 Hermes parser 預期的是 `<tool_call>` 內的 bare JSON，格式不符時可能無法解析。`qwen3` 則對應預設啟用的 thinking 行為。

OpenAI-compatible 請求範例如下：

```bash
curl http://{{CURL_HOST}}:{{CURL_PORT}}/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{ "model": "{{MODEL_NAME}}", "messages": [{"role":"user","content":"Hello"}] }'
```

速度與準確度測試命令也由 cookbook 提供。speed benchmark 使用 `sglang.bench_serving` 與 `sglang-oai` backend，參數包含 `DATASET`、`ISL`、`OSL`、`NUM_PROMPTS` 與 `MAX_CONCURRENCY`：

```bash
python3 -m sglang.bench_serving \
  --backend sglang-oai \
  --host {{CURL_HOST}} --port {{CURL_PORT}} \
  --model {{MODEL_NAME}} \
  --dataset-name {{DATASET}} \
  --random-input-len {{ISL}} --random-output-len {{OSL}} --random-range-ratio 1 \
  --num-prompts {{NUM_PROMPTS}} --max-concurrency {{MAX_CONCURRENCY}} \
  --request-rate inf \
  --flush-cache
```

GSM8K accuracy 測試使用 1319 個 examples：

```bash
python3 -m sglang.test.run_eval \
  --host http://{{CURL_HOST}} --port {{CURL_PORT}} \
  --model {{MODEL_NAME}} \
  --eval-name gsm8k \
  --num-examples 1319
```

Benchmark 介面將 throughput 定義為 `(input+output tokens)/elapsed/GPU`，interactivity 則為 `1000/TPOT(ms)`，單位是 `tokens/s/user`。缺少數值時顯示 `—`，未有資料的組合不會渲染成空的 Accuracy 或 Speed 表格。

**GDN 記憶體與 concurrency** 對這個 hybrid GDN model 而言，文件特別強調 `--mamba-full-memory-ratio` 是影響吞吐量與 concurrency 的關鍵 sizing flag。預設值 `0.9` 會過度配置 KV pool，並靜默壓低 concurrency；使用者應在 `#mamba-ratio-calculator` 設定 average request length，由 calculator 把計算結果寫入 command。

核心公式為：

```text
ratio = (S + D) x state_bytes / (L x kv_bytes_per_token)
```

其中：

- `L` 是 input 加 output 的 average total request length。
- `S` 是每個 running request 的 state slots：`extra_buffer=5`、`extra_buffer_lazy=4`、`no_buffer=3`，停用 radix cache 時為 `1`。
- `D` 是 speculative decoding 的 verify intermediate states；EAGLE 3/1/4 recipe 使用 `4` 個 draft tokens，未啟用時為 `0`。
- 固定 geometry 下，fp32 state 約 153.9 MB，bf16 state 約 78.4 MB。
- KV 每 token 約為 fp8 的 32.8 KB 或 bf16 的 65.5 KB。

calculator 會產生：

```bash
--mamba-full-memory-ratio <ratio>
```

也可以改用明確 cache 上限：

```bash
--max-mamba-cache-size = target_concurrency x (S + D)
```

來源建議啟動後檢查 log 中的 `max_running_requests`，確認沒有低於目標 concurrency。若開啟 speculative decoding 卻沒有設定 `--max-running-requests`，SGLang 會將 serving concurrency 重設為 **48**；因此要依目標並發數明確加入：

```bash
--max-running-requests <N>
```

RTX 5090 等 32GB 小 VRAM 平台上，state pool 可能早於 KV pool 限制 concurrency。此時可使用：

```bash
--mamba-radix-cache-strategy extra_buffer_lazy
```

把每 request state cost 從 5 slots 降為 4；若仍受限，也可使用：

```bash
--disable-radix-cache
```

將 `S` 設為 1。這些選擇會改變記憶體與 concurrency 的取捨，不應只根據單一 throughput 數字決定。

**Prefill、MTP 與服務延遲** 混合 GDN 模型的 decode 會受到每個 prefill chunk 阻塞。來源指出，8192-token chunk 每次可能造成約 600ms stall；將 `--chunked-prefill-size` 調成 `2048`，可讓 mixed load 的 decode inter-token latency 更平滑，也能改善 single-wave TTFT，但 DGX Spark 的 recipe 例外使用 `8192`。

Speculative decoding 也有部署前提。Playground 會在存在 `--speculative-algorithm`、但沒有 `--max-running-requests` 時顯示警告，因為 SGLang 會把 concurrency 設為 48。另一方面，`prefill-CP` 與 `DP-Attention` 目前不能同時使用 interleave layout；現行 SGLang releases 會要求 `dp_size == 1`，否則 command 可能在 startup 失敗。Combined CP + DP-Attention support 已規劃於 upstream，在功能完成前必須關閉其中一項。

若使用 PD Disaggregation，系統固定使用：

```text
prefill.serve = 30000
prefill.dist = 30335
decode.serve = 30100
decode.dist = 30435
```

Prefill 與 decode 兩個 role 都啟動後，Router 才能提供 client 入口；client 的 cURL 不應直接打 role server，而應打 Router。Router 預設 port 為 `8000`，若設定檔提供 `pdRouter.port` 則採用該值。多節點部署時，command 會要求同一份命令在每個 node 執行，head node 的 rank 為 `0`，其他 node 為 `1..${nnodes - 1}`，並使用可互相連線的 head node IP：

```text
--nnodes ${nnodes}
--node-rank {{NODE_RANK}}
--dist-init-addr {{NODE0_IP}}:${distPort}
```

<video src="https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1786766429076-f44zq233.mp4" poster="https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/957fb846be7f9398.jpg" controls playsinline preload="metadata" style="max-width:100%;height:auto;display:block;margin:1rem 0"></video>
> Qwen3.8 27B 搭配 NVFP4 與 DSpark 的效能跑分數據對比

**Agent 工具相容性** Qwen3.8-27B 可透過 OpenAI-compatible endpoint 連接 Agent harnesses，也可透過 SGLang 的 Anthropic-compatible endpoint 連接 Claude Code。OpenAI-compatible base URL 為：

```text
http://<host>:30000/v1
```

harness 的 `model` 必須等於 server 的 `--model-path`；`/v1/models` 預設名稱也是該路徑，可用 `--served-model-name` 縮短設定。SGLang 另提供 `/v1/messages`，在 Anthropic 與 OpenAI 的 request／response 形狀間轉換，前述 parser flags 仍適用。

OpenCode 的文件位於 [OpenCode provider docs](https://opencode.ai/docs/providers/)，流程先執行：

```bash
opencode
/connect
```

`opencode.json` 使用 `@ai-sdk/openai-compatible`、`baseURL: "http://localhost:30000/v1"`，model id 可設定為 `RadixArk/Qwen3.8-27B-NVFP4`；`models` key 必須與 served model name 相同，也可以透過 `/models` 確認。

Pi 可使用 extension provider，參考 [Pi custom provider](https://pi.dev/docs/latest/custom-provider)，設定 `api: "openai-completions"`、`contextWindow: 262144`、`maxTokens: 32768`，並將輸入、輸出、快取讀取與快取寫入成本全部設為 0（對應 `input/output/cacheRead/cacheWrite`）；可用下列命令確認模型：

```bash
pi --list-models
```

Hermes Agent（Nous Research，MIT）文件位於 [Hermes Agent](https://github.com/NousResearch/hermes-agent)，可先執行：

```bash
hermes model
```

或在 `~/.hermes/config.yaml` 設定 provider `custom`、`base_url: http://localhost:30000/v1`、`api_key: ""`、`context_length: 262144`，並將預設模型設為 `RadixArk/Qwen3.8-27B-NVFP4`；多 endpoint 可透過 `providers:` 管理，再以 `/model custom:<name>` 切換。

Claude Code 的相容性則需要保留限制條件：Anthropic 明確表示，透過 gateway 將 Claude Code 路由至非-Claude models 不受支援。雖然 SGLang 實作 Anthropic message format，實際上可能運作，但不在 Claude Code 的測試範圍內，未來功能可能 degrade 或 fail。設定時 `ANTHROPIC_BASE_URL` 不可加 `/v1`：

```bash
export ANTHROPIC_BASE_URL=http://localhost:30000
export ANTHROPIC_AUTH_TOKEN=placeholder
```

`ANTHROPIC_AUTH_TOKEN` 使用 `Authorization: Bearer`，`ANTHROPIC_API_KEY` 則使用 `x-api-key`；可透過 `/status` 確認 session 使用的 base URL 與 credential source。來源也指出，SGLang 的 `--api-key` 預設未設定，因此 endpoint 預設允許 unauthenticated requests；若服務超出 localhost，應人工核對網路暴露範圍並設定 `--api-key`，不可把未驗證的公開 endpoint 當成安全預設。

**實際意義** 這篇貼文不是只宣傳一個新模型的參數規模，而是以 SGLang 的立即支援與可重現 recipe，主張 27B 級模型已能在消費級或工作站級 GPU 上承擔更長的 Agent 工作流程。206.1 tok/s 的 RTX 5090 結果、DGX Spark 的 38.28 tok/s，以及 NVFP4、MTP、DSpark、GDN state pool 與 parser 整合，顯示小型模型的競爭焦點已從「能否執行」轉向「能否在特定硬體上以合理延遲、並發與工具呼叫品質長時間運作」。

不過，來源同時揭示這項進展的前提：效能數字依賴精確的量化格式、注意力後端、預填區塊、快取策略與 concurrency 設定；部分 DGX Spark 配置尚未 verified，H200 不能使用 NVFP4，PD-Disaggregation 需要 Router，speculative decoding 需要手動固定 `--max-running-requests`，而 Claude Code 對非-Claude models 的路由也不在 Anthropic 支援範圍內。換言之，SGLang 宣稱的「小模型之王」更準確地說，是一組已開始成熟、但仍必須依硬體與工作負載仔細調校的本機 Agent serving 路徑。

## 標籤

開源專案, 功能更新, LLM, Qwen, Alibaba