测试基准：本机 RTX PRO 4500 32GB，100K 上下文稳定档 / DSPARK 投机 / NVFP4 量化，agent 真实负载（开思考）稳态 decode 63-79 tok/s，no-spec 基线 49 tok/s。数据附实测方法，欢迎拉复验打脸。

目录

• 结论速查
• 名词白话解释
• 运行环境
• 最终配置
• 最重要的机制
• 实测数据
• 踩过的N个坑
• 不要做的事
• 复现附录
• 未测试项

结论速查

指标	数值	说明
Decode 吞吐	63-79 tok/s	agent 负载（开思考），DSPARK 投机
no-spec 基线	~49 tok/s	关投机对照（DSPARK 提速 ~29%）
关思考纯生成	~47 tok/s	短输出直答模式
TTFT	0.12-0.17s	短上下文；session radix 命中 <1s 免 prefill
上下文	100000 (100K)	稳定档；131072+DSPARK 在 32GB 上 6K 即 OOM（血案见坑1）
KV 池	107077 tokens	fp8_e4m3，每 token 仅 32KB（hybrid 架构红利）
可用显存	~1.57GB	余量（OOM 崩溃时仅 0.049GB，30 倍差距）
缓存命中上报	已开启	--enable-cache-report；agent（dsh）可显示真实命中率（实测 97% 前缀命中上报）
真实 agent 会话	90 tok/s · 首 token 3.1s · 缓存命中 84%	dsh 5 轮 31 步真实会话（2026-09-09，UI 累计口径；口径辨析见「实测数据 > 真实 agent 会话」节）
冷启（JIT 热后）	~45s	CUDA graph capture 完成
首请求	~90s 一次性	首次 lazy init
完整冷启（无 JIT 缓存）	16-18min	CUDA graph capture 阶段占大头，属正常非卡死

名词白话解释

运行环境

️ 权重必须 gittensor-model-hub 版（modelopt 格式，SGLang 兼容）；Unsloth NVFP4（compressed-tensors）SGLang 直接报不支持。

最终配置

systemd 服务路径：~/.config/systemd/user/sglang-qwen27b.service（全文如下，可直接复制）

[Unit]
Description=SGLang Qwen3.8-27B-NVFP4 (100K/DSPARK/无视觉, 2026-09-08 定案)
After=network.target

[Service]
Type=simple
WorkingDirectory=%h
ExecStart=%h/.sglang-venv/bin/python -m sglang.launch_server --model-path %h/models/Qwen3.8-27B-NVFP4-RTX5090 --served-model-name qwen3.8-27B-NVFP4 --host 127.0.0.1 --port 8000 --context-length 100000 --mem-fraction-static 0.88 --max-running-requests 4 --mamba-ssm-dtype bfloat16 --kv-cache-dtype fp8_e4m3 --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-session-radix-cache --enable-cache-report --speculative-algorithm DSPARK --speculative-draft-model-path %h/models/Qwen3.8-27B-DSpark-NVFP4 --speculative-dspark-block-size 7 --speculative-draft-model-quantization modelopt_fp4
# ⚠️ 环境三件套（缺一不可，见坑3）：PATH 前缀 cuda-cc（gcc-12 symlink）+ cu13 bin；CUDA_HOME=cu13；LD_LIBRARY_PATH=cu13/lib + cudnn/cusparselt/nccl/nvshmem
Environment=PATH=%h/.local/bin/cuda-cc:%h/.sglang-venv/lib/python3.11/site-packages/nvidia/cu13/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Environment=CUDA_HOME=%h/.sglang-venv/lib/python3.11/site-packages/nvidia/cu13
Environment=LD_LIBRARY_PATH=%h/.sglang-venv/lib/python3.11/site-packages/nvidia/cu13/lib:%h/.sglang-venv/lib/python3.11/site-packages/nvidia/cudnn/lib:%h/.sglang-venv/lib/python3.11/site-packages/nvidia/cusparselt/lib:%h/.sglang-venv/lib/python3.11/site-packages/nvidia/nccl/lib:%h/.sglang-venv/lib/python3.11/site-packages/nvidia/nvshmem/lib
Environment=CUDA_VISIBLE_DEVICES=0
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

️ 不要加 --mamba-radix-cache-strategy no_buffer（与 overlap schedule 不兼容直接 crash loop，用默认 auto）；不要加 --max-mamba-cache-size 20（intermediate 预占挤走 KV 池 ~2.8GB）。

启动 & 验证（长等待用 curl --retry，勿 shell 手写循环）：

systemctl --user daemon-reload
systemctl --user start sglang-qwen27b.service
curl -s -m 3 --retry 90 --retry-delay 10 --retry-all-errors http://127.0.0.1:8000/v1/models | head -c 300

llm-switch 集成：目标 1=sglang-qwen27b（echo 1 | llm-switch），与 sglang-a3b/ComfyUI 8000 端口互斥。

最重要的机制

1. 为什么是 100K 而不是 131072（OOM 血案实证）

ctx 131072 + mem-fraction 0.90 + DSPARK 时，6K 前缀请求即 CUDA OOM（free 仅 49MB）→ scheduler SIGQUIT → 服务崩溃。显存账本：

关键数字：每 token KV 仅 32KB（16/64 层 full-attn 才要传统 KV，48 层线性注意力走 state 池）——100K 满需求 ~3.2GB，131K 满需求 ~4.2GB，差距不大；真正的杀手是 DSPARK 的 draft 1.4GB + intermediate 2.25GB 预占。mem-fraction 0.90 时预分配过满，运行时 free≈0，任何请求峰值即爆。

100K + mem-fraction 0.88 = 甜点区：KV 池 107077（≥100K + radix 余量）+ available 1.57GB（30 倍余量）。实测 30K 上下文稳定、NRestarts=0。

若要回 131072：唯一路径是去掉 DSPARK（释放 draft+intermediate 共 ~3.65GB → 池 174681），但速度 63→49 tok/s，稳定性换速度，想清楚再动。

2. DSPARK 投机为什么值得（对本模型）

• draft 1.4GB 独立小模型，对 reasoning 思考链接受率高（agent 开思考负载 63-79 tok/s > no-spec 49）
• 必须 --speculative-draft-model-quantization modelopt_fp4（README 裸格式在部分环境报不兼容）
• ️ gittensor README 的 85.8/161.7 tok/s 是 RTX 5090（1792 GB/s 带宽）参考值，4500 带宽减半——本机实测约其一半（no-spec 49→DSpark 63），勿拿 README 数字当本机预期
• MTP（模型内嵌 head 投机）此权重已移除（gittensor 优化版），不要加 MTP 参数

3. 无视觉是特性不是 bug

SGLang 默认不加载 vision encoder；--language-model-only 对本模型架构会 ValueError。视觉任务走云端多模态 API（mimo-v2.5 等），本地只管文本——显存省 ~2GB。

实测数据

稳态 decode（开思考 agent 负载）

方法：连续请求看 SGLang 日志 gen throughput (token/s)；短输出直答另测。

实测区间：63-79 tok/s（DSPARK，思考链长短波动）
no-spec 对照：~49 tok/s
关思考纯生成：~47 tok/s

真实 agent 会话（dsh UI 口径，2026-09-09）

本配置 2026-09-08 起作为 dsh agent 日常现役模型（~/.dsh/settings.yaml → qwen3.8-27B-NVFP4），持续稳定运行（NRestarts=0）。真实 5 轮 31 步会话（本会话累计快照，随会话增长数值小幅漂移）：

LLM 合计 9分8秒 · 工具调用 30.7s
90 tok/s          UI 口径：Σ输出 tokens ÷ Σ纯 decode 时长（firstToken→completed，不含 prefill/排队/等待；4 轮快照 88，随会话增长小幅上浮）
首 token 平均 3.1s UI 口径：每请求 (firstTokenTime − stepStart) 全请求平均
缓存命中 84%      UI 口径：cacheReadTokens ÷ 输入 tokens（1.3M 输入中约 1.1M 免重复 prefill）
输入 1.3M tok · 输出 40.9K tok（5 轮累计；单请求上下文逐轮增长，末轮远超此前 30K 实测档）

️ 口径辨析（复验请以下列 SGLang 日志为准）：UI 的 90 tok/s ≠ SGLang 日志 gen throughput 63-79 tok/s。前者是客户端「纯 decode 窗口」（首 token 到完成，不含 prefill/排队/混合采样窗口），数值高于日志档属口径使然；后者是服务端采样窗口、复验基准。两口径不矛盾，勿互相打脸。首 token 平均 3.1s（4 轮快照 3.5s）被后轮长上下文 prefill 拉高（短上下文冷/热 0.107-0.17s 仍成立），属预期行为非劣化。

TTFT / radix

• 短上下文 TTFT：0.12-0.17s
• session radix 命中（同会话连续多轮）：<1s 免 prefill
• 缓存命中上报已打通（2026-09-08 晚）：服务端加 --enable-cache-report 后，响应 usage.prompt_tokens_details.cached_tokens 真实回填，agent（dsh）可显示真实命中率（实测 987 token 前缀第 2 轮起 cached=960，97%）。️ 该参数默认 False——不加时 ptd 恒 null，agent 显示「缓存命中 0%」是读不到字段的盲区不是 radix 失效（旧版文档的坑8 即此，现已由参数解决）。DSPARK 投机不影响上报（字段来自 radix 前缀命中统计，与 decode 侧投机无关）。验证法仍可用：同前缀两连发对比 TTFT（实测 25K 前缀：冷 5.7s → 命中 0.107s）。
• 真实 5 轮会话首 token 平均 3.1s（UI 口径，4 轮快照 3.5s）：短上下文 0.107-0.17s 仍成立，后轮长上下文 prefill 拉高均值，预期非劣化（口径辨析见「真实 agent 会话」节）。

冷启耗时

• JIT 缓存热后：~45s（含 CUDA graph capture）
• 首次请求：~90s 一次性 lazy init
• 完整冷启（清空 ~/.cache/sglang）：16-18min——进程 ALIVE + 显存稳定 + 日志停在 autotune/capture 无报错 = 在 capture 属正常，耐心等；进程退出 + traceback = 真失败

显存分布（稳态）

踩过的N个坑

坑1：ctx 131072 + DSPARK 直接 OOM 崩溃（最贵的坑）

6K 前缀请求即 CUDA OOM，scheduler SIGQUIT 服务崩。反复调参浪费数小时后定案：不是 ctx 大，是 mem-fraction 0.90 预分配过满 + DSPARK 三件套（draft 1.4GB + intermediate 2.25GB + graph 1.4GB）挤压。解法：100K + 0.88（见机制1）。教训：新参数先复刻历史验证基线跑通，再逐档上调，别一上来顶目标配置。

坑2：SGLang 冷启 16-18 分钟以为是卡死

首次部署无 JIT 缓存时 CUDA graph capture 阶段日志静默、GPU util 低波动——差点被 kill。判定：进程 ALIVE + 显存 ~29.7GB + 无 traceback = 正常。就绪探测用 curl --retry 90（见上），不要用 shell 手写循环 + 短超时误判 DOWN。

坑3：环境三件套缺失（JIT 编译全家桶）

SGLang JIT（flashinfer）依赖链全在 venv 的 site-packages/nvidia/cu13（nvcc 13.4.46rc1 全家桶），不是系统 CUDA：

1. gcc 版本：nvcc 不认 gcc 15 → ~/.local/bin/cuda-cc/ 放 gcc/g++ → gcc-12 symlink，PATH 前缀
2. CUDA_HOME：必须指向 site-packages/nvidia/cu13（含 nvcc + 头 + lib）；指向系统 /usr/local/cuda（12.9）会编译出链接 libcublasLt.so.12 的产物 → sm_120 fp8 初始化失败 bmm_fp8_internal_cublaslt failed
3. LD_LIBRARY_PATH：cu13/lib + cudnn/cusparselt/nccl/nvshmem 五个目录全列（见 unit 全文）
4. lib64 + 无版本 .so symlink：pip 布局是 cu13/lib（无 lib64、无 libcublasLt.so 无版本 symlink）→ JIT 找不到 -lcudart/-lcublasLt，需 ln -sfn lib lib64 + 补 5 个无版本 symlink；pip 重装 nvidia-cuda-* 后 symlink 会丢，需重补

坑4：CCCL 版本撕裂与 13.0 缺陷

• --prerelease=allow 装 SGLang 可能拉 nvcc 13.4.46rc1 + 头 13.0 → CUDA compiler and CUDA toolkit headers are incompatible。解法：nvcc/crt/runtime 全套统一 13.4.46rc1
• nvcc 13.0.88 有硬缺陷：对 compute_12x 生成 PTX 9.4 但自带 ptxas 只认 9.0 → Unsupported .version 9.4，13.0.x 全线不行，必须 13.4rc
• glibc ≥2.42 兼容：13.4 头自带 noexcept(true) 检测，Ubuntu 26.04（glibc 2.43）无需手 patch rsqrt（13.0.x 头无此机制需 patch 2 行）

坑5：权重厂商选错直接起不来

Unsloth NVFP4（compressed-tensors 混合精度）SGLang 报 No compressed-tensors compatible scheme was found；必须 gittensor-model-hub 版（modelopt 格式，含 No-MTP/LMHead4 变体可选）。下载 hf download 勿 | tail 吞退出码（假成功空目录血案）。

坑6：DSPARK 参数三件套缺一不可

--speculative-algorithm DSPARK + --speculative-draft-model-path + --speculative-draft-model-quantization modelopt_fp4 + --speculative-dspark-block-size 7。少 quantization 或 block-size 不对 → draft 加载失败或验证路径报错。draft 用 gittensor-model-hub/Qwen3.8-27B-DSpark-NVFP4，不是 MTP head 版。

坑7：--mamba-radix-cache-strategy 与 --max-mamba-cache-size 是负优化开关

• no_buffer：与 overlap schedule 不兼容 → AssertionError crash loop（需 --disable-overlap-schedule 才能用，别碰）
• --max-mamba-cache-size 20：intermediate 预占从 KV 池挤走 ~2.8GB（池 174681→99102），KV 不足
• 两个都不加，用 auto 默认

坑8：agent 显示缓存命中 0% —— 服务端默认不上报（已解决）

dsh 等 agent harness 显示「缓存命中 0%」——根因是 SGLang 启动参数 --enable-cache-report 默认 False：响应 usage.prompt_tokens_details 恒 null 不回填 cached_tokens，harness 读不到字段（pi-ai 解析链只认 ptd.cached_tokens / prompt_cache_hit_tokens / 顶层 cached_tokens）。不是 radix 失效，TTFT 验证法可确认缓存实际在工作。

修复（2026-09-08 实测闭环）：unit ExecStart 加 --enable-cache-report → 重启 → 第二轮起同前缀请求返回 cached_tokens: N（987 token 前缀实测 cached=960，97%），dsh UI 命中率显示真实值。DSPARK 投机不影响该字段。排查链：curl 直连看响应 ptd 是否 null → null 即未开上报。

坑9：dsh/agent 接入报 400 Unexpected message role.（developer role 坑）

dsh（DeepSeek 官方 harness）对配置了 reasoning 的模型把 system prompt 发成 role:"developer"（pi-ai 逻辑：useDeveloperRole = model.reasoning && compat.supportsDeveloperRole，DeepSeek API 认 developer，本地 Qwen3.6 模板不认直接 400）。症状：dsh 所有请求失败报 CONTEXT_WINDOW_EXCEEDED: 400 status code (no body)，但 curl 直连 SGLang 完全正常——tcpdump 抓包见响应体 Unexpected message role.。

修复：dsh ~/.dsh/settings.yaml 的 local-qwen 每个模型条目 compat 块加 supportsDeveloperRole: false（role 回落 system），重启 dsh.service 即恢复：

compat:
  supportsDeveloperRole: false   # 本地 Qwen 模板不认 developer role
  thinkingFormat: chat-template
  chatTemplateKwargs:
    enable_thinking: {$var: thinking.enabled}
    reasoning_effort: {$var: thinking.effort, omitWhenOff: true}
    preserve_thinking: true

坑10：reasoning_effort 别发 max

Qwen3.8 jinja 模板只认 xhigh/high/medium/low，max 直接 500。agent 配置 reasoning_effort 用 xhigh 封顶（本地 override 键大小写双套 low/medium 细调）。

不要做的事

复现附录

完整从零到跑通

# 1. 创建虚拟环境（python3.11）
python3.11 -m venv ~/.sglang-venv

# 2. 安装 SGLang 0.5.19 + flashinfer（自动依赖 cu130 wheel）
~/.sglang-venv/bin/pip install sglang==0.5.19 --prerelease=allow
#   验证：nvcc 13.4.46rc1 全家桶在 site-packages/nvidia/cu13（坑4）

# 3. 补 JIT 编译环境
#    gcc-12 symlink（nvcc 不认 gcc 15）
mkdir -p ~/.local/bin/cuda-cc && cd ~/.local/bin/cuda-cc
ln -sf "$(which gcc-12)" gcc && ln -sf "$(which g++-12)" g++
#    cu13/lib64 + 无版本 .so symlink（pip 布局缺这两个）
cd ~/.sglang-venv/lib/python3.11/site-packages/nvidia/cu13
ln -sfn lib lib64
cd lib && for f in libcudart.so.13 libcublas.so.13 libcublasLt.so.13 libnvrtc.so.13 libcuda.so; do
  ln -sfn "$f" "${f%.13}"; ln -sfn "$f" "${f%%.so*}.so" 2>/dev/null
done; cd -

# 4. 下载权重（gittensor 官方，勿 | tail 吞退出码）
hf download gittensor-model-hub/Qwen3.8-27B-NVFP4-RTX5090 --local-dir ~/models/Qwen3.8-27B-NVFP4-RTX5090
hf download gittensor-model-hub/Qwen3.8-27B-DSpark-NVFP4 --local-dir ~/models/Qwen3.8-27B-DSpark-NVFP4

# 5. 写入 systemd 服务（最终配置节全文）到 ~/.config/systemd/user/sglang-qwen27b.service
#    ⚠️ 环境三件套 Environment 行是启动成败关键（坑3），逐字复制

# 6. 启动（冷启 16-18min 属正常，见坑2）
systemctl --user daemon-reload
systemctl --user start sglang-qwen27b.service
curl -s -m 3 --retry 90 --retry-delay 10 --retry-all-errors http://127.0.0.1:8000/v1/models | head -c 300

# 7. 验证
curl -s http://127.0.0.1:8000/v1/models | python3 -m json.tool   # id=qwen3.8-27B-NVFP4, max_model_len=100000

# 8. 压测（纯文本 max_tokens 给足 ≥512，思考模型占 token）
curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3.8-27B-NVFP4","messages":[{"role":"user","content":"详细解释量子计算原理"}],"max_tokens":2048}' | python3 -m json.tool

客户端三处同步（ctx 改后必做）

1. Hermes ~/.hermes/config.yaml：providers.local-qwen.models[0].context_length = 100000
2. Hermes config.yaml.template 同步（缩进不同，行级替换）
3. dsh ~/.dsh/settings.yaml：llm-pi-ai.providers.local-qwen 模型条目 contextWindow = 100000（A3B 条目保持 131072），且每个模型条目 compat 块必须含 supportsDeveloperRole: false（见坑9——dsh 对 reasoning 模型默认发 developer role，本地 Qwen 模板不认会 400）

llm-switch 集成

# llm-switch.sh TARGETS 表已含：1=sglang-qwen27b / 2=sglang-a3b / 3=comfyui / 4=stop
echo 1 | llm-switch        # 切到 27B
echo 4 | llm-switch        # 停止全部

未测试项

本文档写于 2026-09-08，基于本机 RTX PRO 4500 32GB 实测（llama.cpp/vLLM 引擎同日退役后的 SGLang 终局配置）。硬件不同数据会有差异，仅供参考。方法论框架见 Hermes llm-serving 技能（M1-M8 全流程），本配置为 2026-09-08 深夜 OOM 实证后定案的稳定档。

2026-09-08 深夜更新：① ExecStart 加 --enable-cache-report（缓存命中真实上报打通，坑8 由"盲区无解"改"参数解决"）② 新增坑9（dsh developer role 400，settings.yaml compat 加 supportsDeveloperRole: false）③ 原坑9 顺延为坑10。

2026-09-09 更新：本配置现为 dsh agent 日常现役模型（settings.yaml → qwen3.8-27B-NVFP4，NRestarts=0 稳定运行）。新增「真实 agent 会话（dsh UI 口径）」实测：5 轮 31 步，90 tok/s（UI 累计口径，4 轮快照 88）/ 首 token 平均 3.1s / 缓存命中 84%（输入 1.3M tok · 输出 40.9K tok）；90 与 63-79 的口径差异、首 token 解释见该节。核心配置与坑位全部不变。整体用下来，感觉驱动dsh是非常丝滑，不太适合驱动hermes（如果显存有至少48GB，应该没问题）。相比llama，我的感觉是更适合聊天，sglang才适合驱动agent，仅代表个人观点。