在 H100/H200/B300 上部署 GLM

Why SGLang#

无他，因为一开始 VLLM 和 SGLang 我两个框架都不熟，然后 SGLang 的文档明显比 VLLM 好一万倍，于是我就选 SGLang 了

两者都是相当成熟的模型框架，问 AI 怎么选的时候容易被骗，看个人吧

H100 on AWS#

第一台服务器是老板用 AWS 大客户权益给我们摸的 8XH100,实例类型是 p5.48xlarge, 拥有 8 卡 H100，28 TB NVME SSD，2TB 内存和双路 AMD EPYC 7R13

不过，8xH100 用来跑黄图可以,部署当时比较热门的大模型, 比如 GLM-5.1-FP8，除非 CPU offload,但是 fp8 cpu offload 后只有 8-10 TPS,有点神了,Hopper 还不支持 NVFP4

后面还试了 GLM-5.1-AWQ,SGLang 不支持，魔改了 SGLang 识别 model name 的代码才算跑起来，有点神

GLM-5.1-GGUF UD-Q4_K_XL 倒是可以跑起来，现在想想，KTransformer 的应该更适合这种推理场景

卡在哪#

主要原因就是长上下文未缓存命中的请求进来，该 TP 会调度用来 Prefill,尽管 B300 上的 prefill speed 高达 10000TPS,但是对于动辄 100K 以上的上下文，prefill 速度还是不够快,那么就会产生大量排队，导致 TTFT 严重增加，影响用户体验

一些我的优化经验：

上下文#

上下文砍半是个相当不错的选择,1M 上下文大部分人完全用不到，但一次就是要占用这么多 KVCache，导致 KVCache 严重浪费，经过评估 context-length 548576 完全够用，Claude Code 大部分情况下都会把 context 控制在 400K 以内

1
--context-length 548576

HiCache#

将内存作为 L2 Cache 存储 KVCache,显著提升高请求下的 Prefill 速度

但是代价就是 Prefill 阶段下的 Cuda Graph 被强制关闭，影响 Prefill 速度，需要根据实际情况权衡

1
--enable-hierarchical-cache \
2
--hicache-size 224 \
3
-hicache-write-policy write_back \
4
--hicache-mem-layout page_first \

加载速度优化#

方便修改参数调试,CPU 多且带宽足够的情况下可以显著提升加载速度

1
  --model-loader-extra-config {"enable_multithread_load":true,"num_threads":64} \
2
  --weight-loader-prefetch-checkpoints \
3
  --weight-loader-prefetch-num-threads 64 \

使用 fastsafetensor 并没有感受到明显提升，所以暂不使用

上下文并行#

以前只支持 Hopper,最近 Blackwell 也上了，体验一波，虽然可以提升 Prefill 速度，但是和 DP 模式不兼容，会影响最大吞吐量,我们人少

1
  --attn-cp-size 8 \
2
  --enable-prefill-cp \
3
  --cp-strategy interleave \

一些小优化#

1
--tokenizer-backend fastokens

优化 tokenizer 足够，千万不要加上什么 tokenizer worker,几乎没有收益，并且会提升系统不稳定性（有天 DetokenizerWorker 突然崩溃，整个系统宕机了 20 Min,然后 SGLang 才自动恢复 tokenizer）

1
  --enable-nccl-nvls \
2
    --pre-warm-nccl \

使用 NCCL 优化传输

其他未来的尝试#

1
HiSparse 通过在 GPU 上只保留一个小的“热”KV 缓冲区，同时将完整的 KV 数据保留在 CPU 钉置内存中，从而减少解码阶段的每次请求 GPU 内存消耗。结合PD拆分，它实现了显著更高的译码并发性。