硬件与软件

• Ubuntu 24.04.3，NVIDIA 驱动 580.178.04。
• 双路 AMD EPYC 7443，合计 96 逻辑 CPU；安装内存约 512GB。
• 8 × RTX 4090D 48GB 改装卡；每卡 nvidia-smi 显存总量 49140 MiB，requested/enforced 功耗上限均为 350W。
• Docker Linux amd64 部署，每个 LLM 容器只绑定一张物理卡，shm_size=8gb。七份独立模型副本，TP=1；不是七卡 TP=7。
• SGLang 0.5.21，固定源码 commit：e00930c5489053f26d86b179cee0d087f846acbb，固定镜像 CUDA 13.0.3。
• 上游镜像标识 lmsysorg/sglang:v0.5.21；实际固定来源为 docker.io/lmsysorg/sglang@sha256:b1259f3ea3275f66237c498ea388919729018bc9f01c3d638391e06e2cf3f469。本地加载标签为 llm-inference/sglang:prepared-20261003。
• 模型：cyankiwi/Qwen3.8-27B-AWQ-INT4；revision：6e134bae811fb5adac50ee042ae5f029ac6779aa。
• checkpoint 实际为 compressed-tensors / pack-quantized，W4A16、INT4 权重、group size 32、非对称量化；运行 dtype=BF16。不能仅根据 AWQ 仓库名把加载参数改写成 awq 或 awq_marlin。
• checkpoint 自带一层原生 MTP；draft 路径与主模型相同。相关 MTP 线性权重在 INT4 量化的 ignore 清单中，不能描述为全模型 INT4 或全模型 BF16。

卡片分配与关键差异

GPU0–5 是六个普通 128K 副本，通过网关分配请求。GPU6 是独立的 256K 服务，只有获管理员授权并在当前对话打开 256K 的账户使用；不加入普通网关轮询。GPU7 独立运行 OCR，不参与 LLM 的 TP 或 MTP。

上下文是输入、思考和最终回答的合计预算。32K／64K 是最大输出预算，包含思考，并不保证每次都输出这么多。普通卡的 4 个运行槽位不代表能同时容纳 4 个完整 128K 请求；配置 max-total-tokens=262144 也不能替代实际分配的 token pool 数值。

普通 128K 实例实际启动参数

每个普通容器分别运行以下命令。LLM_API_KEY 为私有环境变量，这里没有给出其值。

export SGLANG_MAX_NEW_TOKENS_LIMIT=32768

python3 -m sglang.launch_server \
  --model-path /models/Qwen3.8-27B-AWQ-INT4 \
  --served-model-name Qwen3.8-27B-AWQ-INT4 \
  --host 0.0.0.0 --port 30000 \
  --tensor-parallel-size 1 \
  --dtype bfloat16 \
  --kv-cache-dtype auto \
  --context-length 131072 \
  --max-running-requests 4 \
  --max-total-tokens 262144 \
  --mem-fraction-static 0.88 \
  --chunked-prefill-size 2048 \
  --prefill-decode-interval 1 \
  --cuda-graph-max-bs-decode 4 \
  --max-mamba-cache-size 20 \
  --mamba-ssm-dtype float32 \
  --attention-backend triton \
  --quantization compressed-tensors \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --log-level warning \
  --api-key "$LLM_API_KEY" \
  --enable-metrics \
  --speculative-algorithm EAGLE \
  --speculative-draft-model-path /models/Qwen3.8-27B-AWQ-INT4 \
  --speculative-num-steps 1 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 2 \
  --speculative-draft-attention-backend triton \
  --mamba-radix-cache-strategy extra_buffer

其他容器环境：HF_HUB_OFFLINE=1、TRANSFORMERS_OFFLINE=1、HF_HOME=/cache/huggingface、OMP_NUM_THREADS=2、TOKENIZERS_PARALLELISM=false。模型目录只读挂载，各容器有独立缓存目录。

GPU6 的 256K 实例

与上面的普通启动参数相同，只有下面六项变化；其余参数，包括 served model name、主／draft 路径、精度和 MTP 参数都保持相同。该实例在独立容器中运行，不与普通实例占用同一卡。

SGLANG_MAX_NEW_TOKENS_LIMIT=65536
--context-length 262144
--max-running-requests 1
--mem-fraction-static 0.93
--cuda-graph-max-bs-decode 1
--max-mamba-cache-size 6

两类服务 kv-cache-dtype=auto 实际采用 BF16，Mamba SSM 状态为 float32，没有使用 FP8 KV。CUDA graph 没有禁用（运行读回 disable_cuda_graph=false）；LLM 未启用 mixed-chunk。GPU6 保存的 CUDA graph 分配记录包含 target verify 0.105GiB、draft extend 0.002GiB；1 step 下 draft decode 记录为 0。分配记录不能证明每一步都成功 replay，也不能把 draft decode=0 单独当成未启用 CUDA graph 的证据。

第八卡 OCR，仅供了解是否有资源干扰

GPU7 使用 SGLang 运行 PaddleOCR-VL-1.6-0.9B，TP1、BF16、context=16384、max-running-requests=32、max-queued-requests=128、max-total-tokens=524288、mem-fraction-static=0.68、chunked-prefill-size=8192、max-prefill-tokens=16384、enable-mixed-chunk、num-continuous-decode-steps=2、cuda-graph-max-bs-decode=32、attention-backend=triton、mm-attention-backend=triton_attn、mm-processor-worker-num=2。另有 4 个完整文档解析管线绑定同一 GPU7，文档级并发 4。OCR 没有启用本次 LLM 的 MTP。

测量方式与已观察现象

原网页用“字符数÷4”估计 token，中文速度因此明显低估。现已改为服务端真实累计 usage token 和单调时钟计量，包含思考、正文及工具参数；输出速度不包含首字等待和工具执行。不能拿旧网页的 20 多或 10 t/s 直接当作原生解码吞吐。

直接推理同题对照：关闭思考（reasoning_effort=none），temperature=0，max_tokens=2048，串行单请求，各卡 1 次预热后 3 次正式样本。每个请求使用不同 cache_salt，不清空缓存、不重启服务、不强制忽略 EOS。所有请求实际输入 118 tokens、输出 450 tokens，均正常 stop。

Agent 全流程另有两条无工具、关闭思考的合成请求：普通实际输入 640／输出 428 tokens，网页 53.9 t/s；随后同一会话开启 256K，实际输入 1185／输出 467 tokens，网页 54.7 t/s。它们有不同输入和历史，不能当成严格同输入性能比较。服务端首段等待分别约 0.098 秒和 14.005 秒；这次 256K 的长等待尚未归因，不能据输出阶段吞吐宣称首字已经解决，也不能从单样本断言是 MTP 或 256K 参数导致。

此前独立 GPU0-MTP / GPU1-无MTP 对照，三种短题、每种 3 次正式样本、1024 token 上限：无 MTP 约 51 t/s，MTP 约 67–71 t/s，提升约 31%–40%；首个原始模型 chunk 增加约 7–12ms。该旧对照输出以 length 截断，不能证明完整回答质量相同，也不能替代长上下文性能结论。

用户体感：较强思考时正文首字等待更长。实际 Agent 请求可能带有系统提示、工具定义和工具返回，“空聊天窗口”不等于模型实际输入为空。曾观察到真实 Agent 输入 10894–19117 tokens；没有导出真实用户问答。

希望请教

1. 对这个 compressed-tensors 非对称 W4A16 模型和改装 4090D 48GB，当前 Triton 后端、MTP 和缓存参数是否有可验证的优化空间？
2. 保持 128K／32K、256K／64K、350W 上限，以及目前 KV／SSM 精度时，哪些设置值得优先做单变量对照？
3. 如何进一步区分上述 256K Agent 首段约 14 秒是队列、预填充、编译／缓存还是应用侧等待？应追加采集哪些日志或指标？
4. 怎样进一步确认原生 MTP 接受率和 CUDA graph replay，而不把缓存容量、chunk 字符估算或思考结束时间误当成解码速度？

不过2、3、4都是建立在1的基础上的XD..., 这一套流程下来十几二十路长程代理任务是没问题的。

玩笑归玩笑。
现在你们打算计划多少并发？因为sglang有个memba池和kvcache池均衡换算的问题。
kvcache肯定是要8bit的。

具体的配置方案可以参考sglang官方的cookbook：https://lmsysorg.mintlify.app/cookbook/autoregressive/Qwen/Qwen3.8-27B#hw=h200&variant=default&quant=fp8&nodes=single&spec=none&tier=low-latency&ssmDtype=float32

@terry 说:

啊，你这个配置跑这个数据简直是受罪，认真优化下啊我哥，8张4090 48G，这得多土豪的装备。显卡特写下。

咋优化哦，开个MTP? 我是单张卡跑 TP1兄弟 不是8张跑一个副本

用AI助理有個矛盾
AI太厲害，老闆會感覺不需要這麼多員工了，
從員工的角度AI工具介於好用與不好用的中間可能是最佳配置？