tonyd2wild/GLM-5.2-QuantTrio-200K-4x-DGX-Spark--36tok-s

# 在 4× DGX Spark 上运行 GLM-5.2（未剪枝的 QuantTrio Int4-Int8Mix） — 单流峰值 36 tok/s，200K context ## TL;DR - **你能得到什么：** 全质量的 GLM-5.2 — 未剪枝的 QuantTrio `GLM-5.2-Int4-Int8Mix` checkpoint，**保留了全部 256 个专家**（无 REAP/专家剪枝），跨 4× GB10 提供 200K context 服务，支持 MTP k=5 推测解码（speculative decode）、`fp8_ds_mla` KV、完整的 CUDA graphs 以及 vLLM 原生多节点（无需 Ray）。 - **测试数据（2026-07-17 配置）：** **单流平均 32.5 tok/s，峰值 36.0**（预热后，单实例）， **6 并发时聚合速度为 65-75 tok/s**，200,000-token context，未剪枝。设置 `enable_thinking:false` 时， 首个可见 token 仅需 **0.36 秒**。 - **内置 Drafter：** MTP drafter 位于 checkpoint 中（layer 78） — 无需单独 下载、对齐或版本匹配 drafter 模型；`--speculative-config` 只需直接 指向 checkpoint 本身。 - **适用人群：** 拥有 4× DGX Spark (GB10) RoCE 集群，并希望复现 全质量 GLM-5.2 服务，而不是经过外科手术式精简模型的任何人。 ## 硬件 - **4× NVIDIA DGX Spark (GB10)** — 每台 121 GB 统一内存。 - **四个节点之间采用 RoCE fabric。** 我们使用 CRS812 交换机，fabric 子网为 `192.168.192.0/24`，**端到端 MTU 9000（巨型帧/Jumbo frames）** — 包括交换机和 每个 NIC。如果 NCCL 能识别 IB 设备，直连线缆 mesh 也是可行的。 - **每个节点约 420 GB 可用磁盘空间** — 包含 405 GB 权重、镜像、缓存及预留空间。 **内存预算。** 405 GB 权重 → 在 TP=4 下**每个节点约 95 GiB 权重**（实测 98.07 GiB）。 在 121 GB 统一内存的 GB10 上，这为 KV cache、CUDA graphs 和 OS 留出了真正的空间。 相比之下，429 GB NVFP4 混合模型为：约 107 GB/节点 — 这是一个极其紧绷的临界点，一旦 page cache 或 预热分配稍作变动就会发生 OOM。 ## 快速开始 前置条件（均在[设置](#setup-detailed)中说明）：每个节点上均需配置修改过的 vLLM 镜像， 在 `/var/tmp/models` 中准备好 405 GB 的 checkpoint，在 `~/glm-triton` 中准备好 10 个 Triton kernels，以及 NCCL 2.30.4。然后，从**主节点**执行： ``` # 1. Edit the EDIT-marked config block in launch.sh (node IPs, SSH user/key, HCA + interface names). # 2. Sanity-check the generated docker commands first. ./launch.sh --dry-run # 3. Launch (workers start headless first, head last). ./launch.sh # 4. Smoke test — ready after ~12 min weight load + ~10 min cudagraph warmup. curl -s http://localhost:8210/v1/models ``` 每个节点执行普通的 `docker run`；vLLM 原生多节点（`--nnodes/--node-rank`），**无需 Ray**。 `./launch.sh --stop` 会通过 `docker rm -f` 移除每个节点上的容器。 ## 设置（详细） 步骤 和 步骤 运行在一台构建机器上（任意一台 Spark 均可）。步骤 涉及**每个节点**。步骤 仅从主节点运行。在通过步骤 分发镜像之前，请将步骤 （indexer 补丁）作为步骤 烘焙过程的一部分执行。 ### 镜像与修改（步骤 a, b, h） **a. 构建 vLLM 镜像（约 35-60 分钟）。** 克隆 [eugr/spark-vllm-docker](https://github.com/eugr/spark-vllm-docker) 并基于指定的 vLLM commit 进行构建： ``` git clone https://github.com/eugr/spark-vllm-docker cd spark-vllm-docker # PIN THE HARNESS. Later harness commits carry inline vLLM patches that do not # apply to our pinned ref (the build fails at an llm_base_proposer.py hunk), # and harness HEAD moves fast. git checkout 4ed3ebf # DISABLE THE HARNESS'S PRESET-PR AUTO-MERGE. By default ("auto"), when no # --apply-vllm-pr is given, the Dockerfile merges a preset list of vLLM PRs # fetched LIVE from GitHub. Those branches have moved since this recipe was # written: merging them today fast-forwards the pinned ab666069 to current # vLLM main. The build still "succeeds" -- and the engine then dies at # KV-cache init (view 576 vs 656 B/token) with the b12x backend missing. # (build-and-copy.sh's own APPLY_PRESET_VLLM_PRS=false default is NOT # forwarded to docker build, so this sed is required.) sed -i 's|^ARG VLLM_APPLY_PRESET_PRS=""|ARG VLLM_APPLY_PRESET_PRS="false"|' Dockerfile ./build-and-copy.sh --vllm-ref ab666069935c1f23e8ef56038b4659ac9e8f19f8 \ -t vllm-node-tf5-glm52-b12x:probe --tf5 # VERIFY THE PIN HELD. The wheel version must be a dev build AT the pin: # grep -oE "vllm==[0-9a-z.+]*" build.log | tail -1 -> ...dev190+gab6660699... # If it reads dev893+g52b6667xx (or any other suffix), the tree was silently # un-pinned and the resulting image will NOT boot this recipe. ``` **b. 将修改项烘焙进镜像。** 从 [CosmicRaisins/glm-5.2-gb10](https://github.com/CosmicRaisins/glm-5.2-gb10) 的 `kernels/` 获取 10 个 kernel 文件并放入 构建机器的 `~/glm-triton` 中，然后在容器内运行两个修改脚本并 commit 结果。这两个修改脚本的作用是： - `mods/glm52-sm12x-sparse/run.sh` — 安装 Triton sparse-MLA kernels 和 DeepGEMM bypass （完全照搬自 ciprianveg 的压缩包）。 - `mods/glm52-b12x-sparse/run.sh` — 安装 b12x 以实现 CUDA-graph 安全的 sparse-MLA 解码（完全照搬 自 ciprianveg 的压缩包）。 **kernels 必须挂载到 `/root/models/models15/glm-triton`** — 这是 `mods/glm52-sm12x-sparse/run.sh` 预期的路径（脚本顶部的 `KERNELS=`）。完全按照我们的运行方式： ``` docker run -d --name glm52-modding \ -v ~/glm-triton:/root/models/models15/glm-triton:ro \ -v $(pwd)/mods/glm52-sm12x-sparse:/mods/glm52-sm12x-sparse:ro \ -v $(pwd)/mods/glm52-b12x-sparse:/mods/glm52-b12x-sparse:ro \ vllm-node-tf5-glm52-b12x:probe sleep infinity docker exec glm52-modding bash /mods/glm52-sm12x-sparse/run.sh docker exec glm52-modding bash /mods/glm52-b12x-sparse/run.sh docker commit \ --change 'ENTRYPOINT ["/opt/nvidia/nvidia_entrypoint.sh"]' \ --change 'CMD []' \ glm52-modding vllm-node-tf5-glm52-b12x:probe-modded docker rm -f glm52-modding ``` 你需要从 CosmicRaisins/glm-5.2-gb10 的 `kernels/` 获取的 10 个 kernel 文件（Apache-2.0；未在此处内联打包）： ``` b12x_sparse_helpers.py deepseek_v2.py flashmla_sparse.py patch_flashmla_ops.py sm12x_deep_gemm_fallbacks.py sm12x_mqa.py sm12x_sparse_mla_attn.py sparse_attn_indexer.py sparse_mla_env.py sparse_mla_kernels.py ``` 两个脚本都会打印 `✓` 行；sm12x 脚本必须以 `=== glm52-sm12x-sparse complete ===` 结尾， 而 b12x 脚本必须显示成功执行 `import b12x`。 **h. 烘焙 indexer MTP-overhang 补丁（使用 `--max-num-seqs >= 3` 时必需）。** 请在步骤 的同一构建会话中进行此操作，即在 commit 和分发镜像之前。 `patches/fix-indexer-mtp-overhang.py` 修复了一个 vLLM bug，该 bug 导致 DSA indexer 仅为 `max_model_len` 分配其扩展 block-table 缓冲区大小；MTP spec tokens 可能会将请求扩展 越过该限制，并在 ≥3 个并发请求时导致引擎崩溃，报错 `RuntimeError: The expanded size of the tensor (3125) must match the existing size (3126)`。有关完整说明，请参阅补丁的 docstring。 像修改脚本一样进行烘焙 — 将其挂载到 patch 容器中，并在执行 `docker commit` 之前运行它： ``` docker run -d --name glm52-modding \ ... \ -v $(pwd)/patches:/patches:ro \ vllm-node-tf5-glm52-b12x:probe sleep infinity # (after the two mod scripts from step b) docker exec glm52-modding python3 /patches/fix-indexer-mtp-overhang.py docker commit \ --change 'ENTRYPOINT ["/opt/nvidia/nvidia_entrypoint.sh"]' \ --change 'CMD []' \ glm52-modding vllm-node-tf5-glm52-b12x:probe-modded docker rm -f glm52-modding ``` 成功时会输出 `patched: .../indexer.py`，并且该操作是幂等的（可安全重复运行）。 ### c. 将镜像分发到所有节点 ``` # from the build machine, for each OTHER node: docker save vllm-node-tf5-glm52-b12x:probe-modded | \ ssh @ docker load ``` （通过 RoCE fabric 只需几分钟，而不是几小时。在较慢的链路上，中间使用 `pigz` 会有所帮助。） ### d. 权重 — 下载一次，rsync 到所有节点 **只需下载一次** checkpoint（405 GB — 请在网络最好的节点上执行）： ``` hf download QuantTrio/GLM-5.2-Int4-Int8Mix \ --local-dir /var/tmp/models/glm52-int4-int8mix ``` 然后**通过 RoCE fabric**（而不是外网链路）分发： ``` # from the node holding the weights, for each other node's fabric IP: rsync -a --info=progress2 /var/tmp/models/glm52-int4-int8mix/ \ @192.168.192.X:/var/tmp/models/glm52-int4-int8mix/ ``` 在**每个**节点上创建 hub-layout 的 symlink（容器内的服务路径为 `/cache/huggingface/hub/glm52-int4-int8mix`）： ``` mkdir -p /var/tmp/models/hub ln -sfn ../glm52-int4-int8mix /var/tmp/models/hub/glm52-int4-int8mix ``` ### e. 在每个节点上暂存 NCCL 2.30.4 镜像自带的 NCCL 会在运行时通过 `LD_PRELOAD` 被替换。在**每个**节点上： ``` pip download nvidia-nccl-cu13==2.30.4 -d /tmp/nccl --no-deps mkdir -p /var/tmp/models/hub/nccl-2.30.4 cd /tmp/nccl && unzip -o nvidia_nccl_cu13-2.30.4*.whl 'nvidia/nccl/lib/libnccl.so.2' cp nvidia/nccl/lib/libnccl.so.2 /var/tmp/models/hub/nccl-2.30.4/ ``` ### f. 在每个节点上配置 Kernels 将 CosmicRaisins/glm-5.2-gb10 `kernels/` 中的 10 个 `.py` 文件复制到**每个** 节点的 `~/glm-triton` 目录（launch.sh 会以只读方式将它们逐文件挂载到 vLLM 目录树上）： ``` git clone https://github.com/CosmicRaisins/glm-5.2-gb10 for node in 192.168.192.1 192.168.192.2 192.168.192.3 192.168.192.4; do rsync -a glm-5.2-gb10/kernels/ @$node:~/glm-triton/ done ``` ### g. 启动 编辑 `launch.sh` 中标记为 `EDIT` 的配置块（节点 IP、SSH 用户/密钥、HCA 和接口 名称），然后从主节点执行： ``` ./launch.sh --dry-run # sanity-check the generated docker commands first ./launch.sh ``` 每个节点执行普通的 `docker run`；vLLM 原生多节点（`--nnodes/--node-rank`），**无需 Ray**。Worker 会先无头启动，head 最后启动。 ### 验证 预计在 API 响应前需要 **约 12 分钟加载权重 + 约 10 分钟预热 cudagraph**： ``` curl -s http://localhost:8210/v1/models # serves as 'glm-5.2' docker logs -f vllm_slot # follow bring-up on the head node ``` ## 基准测试 ### Speed-Night 2 更新（2026-07-17） — 当前服务配置 MTP k=4 → **k=5** + 显式 `cudagraph_capture_sizes`（并发为 6 时之前一直运行在 无完整 CUDA graph 状态 — 默认的 size 列表跳过了该 batch size） + `VLLM_MARLIN_USE_ATOMIC_ADD=1`： | 指标 | 2026-07-05 配置 | **2026-07-17 配置** | |---|---|---| | c1 代码 / 数学 / 散文 | ~28.8 中位数 | **32.0 / 36.0 / 29.6**（平均 32.5） | | c6 聚合 | 60.5 | **65–75** | | 首个可见 token（交互式） | 7–10 s | 使用 `enable_thinking:false` 时为 **0.36 s** | | MTP accept (k=5) | 3.3–3.6 (k=4) | 最高 4.88，pos-5 accept 0.547 | 完整的逐项结果、死胡同及排名路线图：[SPEED-NIGHT-FINDINGS.md](SPEED-NIGHT-FINDINGS.md)。 ### 原始并发结果（2026-07-05，k=4 配置 — 历史数据） **最终并发结果（2026-07-05）** — 在此集群上使用最终服务配置进行测量 （gmu 0.91，KV 10.95 GB，max-num-seqs 6，MTP k=4），并且在包含已验证的 indexer 补丁的镜像上启动。所有运行：512-token 生成，temperature 0，低深度 context。全部 6 个并发 级别均完成，且**零崩溃**。 | 并发 | 聚合 tok/s | 每流平均 | 每流最小 | MTP accept len | |---|---|---|---|---| | 1（预热，3 次中位数） | **28.8** | 28.8 | 27.3 | 3.3–3.6 | | 2 | 37.6 | 20.2 | 18.8 | 3.50 | | 3 | 39.3 | 13.6 | 13.1 | 3.22 | | 4 | 53.5 | 14.1 | 13.4 | 3.28 | | 5 | 59.1 | 12.5 | 11.8 | 3.22 | | 6 | **60.5** | 10.6 | 10.1 | 3.23 | 备注： - **c1 是 3 次运行的预热中位数 (27.3 / 29.0 / 28.8)。** 启动后第一次冷请求的读数会 偏低（16-22 tok/s） — 请引用预热中位数，并附带此注意事项。 - **c3-c6 行的存在仅仅是因为有了 indexer 补丁** （`patches/fix-indexer-mtp-overhang.py`，步骤 h）：没有它，引擎在 3 个并发 请求时会崩溃。这次运行验证了该补丁 — 6/6 并发级别，零崩溃。 ### Context 深度 (2K-32K) — 2026-07-17 实测 事实植入召回 + 连贯性探测（事实埋在文档中段，temp 0，任务 = 召回 事实 + 总结文档）。针对在线集群运行；预热后进行提示测试。 | 深度（提示词 token 数） | 事实召回 | 输出连贯性 | 实际运行时间（含 prefill） | |---|---|---|---| | 2,057 | 通过 | 清晰 | 18 s | | 4,071 | 通过 | 清晰 | 10 s | | 8,065 | 通过 | 清晰 | 15 s | | 16,248 | 通过 | 清晰 | 25 s | | 32,653 | 通过 | 清晰 | 45 s | 在此技术栈上，直到 32K 深度都没有出现退化、重复或“token 沙拉”现象。背景：issue #1 曾报告（在 MLX/Apple-Silicon pipeline 上）指出，低于 BF16 的 indexer 精度会在 约 3-5K 深度时导致长上下文连贯性崩溃。该故障模式在此 vLLM/GB10 配方上直到 32K 都**没有**复现 — 这可能是因为指定的参考代码中的 indexer 路径（vLLM #4595 + b12x sparse 修改）处理 DSA indexer 的方式与 MLX 量化 pipeline 不同。如果你在其他技术栈上重新量化此 checkpoint，他们的警告依然 值得注意：请将 indexer 保持在 BF16。 ### 启动遥测（已验证） - 权重：**每个节点 98.07 GiB**。 - KV pool：**200,064 tokens**，`fp8_ds_mla`。 - 稳定状态：MemAvailable 0.6-0.9 GB + 3.6-4.5 GB swap parked（**这是设计预期** — 与 上游作者针对此配置类型的内存分析相符）。 ## 配置 关键服务设置及其原理： | 设置 | 值 | 原因 | |---|---|---| | `--tensor-parallel-size` | `4` | 每个 TP rank 对应一个 GB10；405 GB / 4 ≈ 95 GiB 权重/节点。 | | `--speculative-config` | `{"method":"mtp","num_speculative_tokens":4,"draft_tensor_parallel_size":1,"attention_backend":"FLASHMLA_SPARSE"}` | MTP drafter 位于 checkpoint 内（layer 78）。k=4 且 draft TP=1 (back199640, #89)：微小的 drafter 并不能从 TP 中受益，并且 draft TP=1 消除了每个推测步骤中的跨节点跳转。 | | `--kv-cache-dtype` | `fp8_ds_mla` | fp8 sparse-MLA KV：将 KV 占用减半，仅用 10.5 GB/节点的 cache 即可实现 200K。 | | `--compilation-config` | `{"cudagraph_mode":"FULL"}` | 为解码提供完整的 CUDA graphs。需要 b12x 修改 — 没有它，graph 捕获会崩溃（捕获期间运行 `torch.full`）。 | | `--async-scheduling` | 开启 | 使 CPU 调度与 GPU 执行重叠 (back199640, #80) — 对 GB10 上的 tok/s 提升显著。 | | `--max-num-batched-tokens` | `8192` | Prefill chunk 大小：大到足以实现约 700+ tok/s prefill，小到不会在深度增加时耗尽内存。 | | `--gpu-memory-utilization` + `--kv-cache-memory-bytes` | `0.91` + `10950000000` | **确定性启动 + 精确满足 200K 的 KV 预算。** 单靠 gmu 会让 vLLM 根据*当前可用*内存来计算 KV，而在 GB10 统一内存上，这会随 page cache 波动 — 同样的命令可能会根据 cache 状态出现 OOM 或成功启动。而且 gmu 0.90 只为 KV 留下 9.78 GiB，而 200000 ctx 需要 10.19 GiB（见故障排除）。gmu 0.91 加上锁定为 10.95 GB 的 KV 可以保证每次都分配出 200,064-token 的 pool。 | | `--max-model-len` | `200000` | 200K context，配合 fp8_ds_mla 可适应锁定的 KV 预算。 | | `--max-num-seqs` | `6` | 最多 6 个并发流。需要 indexer MTP-overhang 补丁（步骤 h） — 如果不打补丁，引擎在 ≥3 个并发请求时会崩溃。如果构建纯单流延迟架构，请降至 1。 | | `NCCL_MIN/MAX_NCHANNELS` | `4` | ciprianveg (#107)：在 GB10 RoCE 上收窄 NCCL channels 可减少争用；更多的 channels 在这里反而更慢。 | | `--reasoning-parser` / `--tool-call-parser` | `glm45` / `glm47` | 匹配 GLM-5.2 的推理追踪和工具调用格式的正确解析器。 | | `--distributed-executor-backend` | `mp` | 原生多进程 + `--nnodes/--node-rank` 会合。无需 Ray。 | ## 体感延迟：思考模式是最大的影响因素 GLM-5.2 默认在输出任何可见内容之前会先输出一条推理轨迹。在此 集群上实测（短提示词，流式传输）：开启默认思考时**首个可见 token 约在 7-10 秒**， 关闭思考时为 **0.36 秒** — 每个请求有约 20 倍的体感延迟差异，且无需更改服务器配置： ``` {"model": "glm-5.2", "messages": [...], "stream": true, "chat_template_kwargs": {"enable_thinking": false}} ``` 测量备注（2026-07-17）：`/nothink` 提示词后缀并不能在此聊天模板上抑制思考 — 请使用 kwarg。`reasoning_effort: "low"` 方向上能减弱，但 方差很大（其中一个样本的思考时间*比默认情况更长*）。前缀缓存（Prefix caching）已启用并且有效 （相同的 8K 提示词：第二次调用时的 TTFT 为 9.9 s -> 0.7 s），因此稳定的系统提示词 + 完整历史记录重发可使多轮对话的 TTFT 保持在约 0.5 s 的下限附近。 ## 超越指定的版本号进行升级（在升级任何引用前必读） 该版本指定是承重墙。10 个 Triton kernels 被直接挂载到特定的 `dist-packages/vllm/...` 路径上，修改脚本会修补特定的文件，并且服务 标志是根据 `ab666069` 的内部结构验证的 -- 例如，此配方不需要 `index_topk_pattern` 覆盖，*正是因为*该指定包含了 vLLM #45895（见 配置中的说明）。在不同的引用上，这些假设会发生变化：在 2026-07 main 版本上，b12x backend 根本无法注册，并且 fp8_ds_mla KV 布局发生了变化（656 vs 576 B/token 视图） -- 引擎在 KV-cache 初始化时就会死掉。 将任何版本引用升级视为一次**重新验证事件**，而不是简单的重新构建： 1. 将构建框架和 vLLM 引用**一起**升级（存在更新的框架是为了构建 更新的 vLLM；混淆版本方向正是隐蔽故障的温床）。保持 `VLLM_APPLY_PRESET_PRS="false"` -- 固定的构建永远不应合并活动的 PR。 2. **以 wheel 后缀为准**：构建的 wheel 版本必须是 你所要求引用的开发版本构建。如果后缀是任何其他哈希值，停止 -- 代码树发生了变动。 3. 在信任之前先进行冒烟测试：在所有节点上启动；启动日志选择了预期的 sparse attention backend；`GPU KV cache size` 符合预期；在已知提示词上测试 temp-0 正确性；c1 数据在此 README 的数值上下 10% 范围内。 4. 预计在较大跨度的跳跃中需要重新移植 kernels/mods -- 首先对比新镜像内的 overlay 目标路径。 长期出路：上游 vLLM 在 sm_121 上提供原生的 GLM-DSA sparse 支持 (vllm-project/vllm#45317 是跟踪此问题的 ticket)。一旦完成，kernel overlay -- 以及 与之相关的大部分版本指定工作 -- 都将变得不再必要。 ## 故障排除 1. **RoCE fabric IP 必须位于正确的接口上 — 并且必须在 netplan 中持久化。** 如果 fabric IP 是临时添加的，链路本地地址 (169.254.x.x) 可能会在重启/链路抖动后占据该端口， 这会**改变 GID table** — 你的 `NCCL_IB_GID_INDEX` 现在指向了错误的 GID，NCCL 要么失败要么会静默退化。请将 fabric IP 放入 netplan 中，并在 任何重启后使用 `show_gids` 进行验证。 2. **必须开启 IB 设备直通。** 如果没有 `--device /dev/infiniband` + `--cap-add IPC_LOCK` + `--ulimit memlock=-1:-1`，NCCL 将会**静默**回退到 socket 接口上的 TCP。 一切看起来都在运行；但解码速度只有约 12 tok/s 而不是 30+ tok/s。如果数值看起来减半了，请检查 `NCCL_DEBUG=INFO` 输出中是 `NET/IB` 还是 `NET/Socket`。 3. **GB10 统一内存上的 Page-cache 压力。** 在 CPU 和 GPU 共享相同 121 GB 内存的机器上，加载约 95 GiB 的权重会填满 page cache。 在启动之前，在每个节点上执行： `sync && echo 3 | sudo tee /proc/sys/vm/drop_caches`。这加上显式的 `--kv-cache-memory-bytes` 就是让启动变得确定性的关键。 4. **交换机上也必须开启巨型帧，而不仅仅是 NIC。** MTU 9000 必须端到端设置； 处于 1500 的交换机端口会静默分片，并严重拖累总线带宽。 5. **不要单独信任 `--gpu-memory-utilization`。** 参见[配置](#configuration)表： 显式固定 `--kv-cache-memory-bytes`，否则相同的启动命令会根据剖析时 page cache 的状态~偶尔~发生 OOM。 6. **加载权重期间的 Page-cache 抖动。** 在 GB10 上，即使有 14–18 GB 的“可用”内存，大规模加载也会因内核内存回收而在 100% CPU 下卡顿。 在加载阶段，**每** 60 秒在**每个**节点上无条件执行一次 `sync; echo 3 > /proc/sys/vm/drop_caches` （并且在启动前执行一次）。症状：shard 加载进度在加载过程中冻结； 手动执行 drop 操作可在几秒钟内解决卡顿。 7. **精确满足 200K 的 KV 预算。** `--gpu-memory-utilization 0.90` 只为 KV 留下 9.78 GiB — 200000 ctx 需要 10.19 GiB。使用 gmu `0.91` 和 `--kv-cache-memory-bytes 10950000000`；启动会 分配出 200,064-token 的 pool。 ### 许可证 **Apache-2.0** — 见 [LICENSE](LICENSE)。这是必需的且经过深思熟虑的：`launch.sh` 源自 CosmicRaisins 的 Apache-2.0 `launch.sh`（版权声明保留在文件头中），并且 `mods/` 脚本复制了他的 Apache-2.0 修改。有关出处请参见 [NOTICE](NOTICE)。

标签：DLL 劫持, GLM, vLLM, 人工智能, 分布式系统, 响应大小分析, 大语言模型, 模型部署与推理, 模型量化, 用户模式Hook绕过, 请求拦截