3.2 KiB
部署心得与后续优化
记录日期：2026-09-18。结论对应本仓库固定的镜像、模型和实测，不自动适用于后续 nightly。
先核对硬件，再计算预算
这台 VMware 机器提供 247 GiB 可用总内存和 85651 MiB GPU 显存，不能直接套用社区 96GB 显卡的预算。虚拟 PCIe 链路显示也不能代表物理吞吐，本次通过锁页内存复制测得约 57.81 GB/s。
CPU 内存充足适合存放约 47.7 GiB 的 PLE 表。官方实现保留 FP8 数据及缩放，分配锁页主机内存，通过 UVA 访问。普通独立显卡主机与 Spark 统一内存架构不同，配置应分别维护。
优先减少补丁
社区方案有参考价值，但旧版本所需的 resident PLE、FP8 和 MTP 修复可能已经进入新版本。先逐项对照固定官方源码，再决定是否回补。本项目没有引入社区 EXL3 镜像、B12x 自定义内核或 mmap 分支，仅保留两处带源码哈希保护的 Mamba prefix alignment 修复。
CUDA Graph 要实际对照
本机 eager 与原生 FULL Graph 在相同输入、固定 256 输出 token 下，三次测量中位数分别约 22.0 和 77.1 token/s，正文和思考文本一致。这个收益不能直接套到 Spark，也不代表长输入预填充快了 3.5 倍：127988 token 首次输入两组首 token 都约 14.14 秒。
因此区分首 token 延迟、解码速度、前缀缓存命中和请求总耗时。固定长度计时包含思考 token，输出截断不应被当成质量测试。
基线先保住用户需要的能力
保留视觉编码器，已验证图片和短视频。128K、FP8 KV、单活动请求、不开 MTP 是本次选定基线。仍有空闲主机内存不等于应该继续扩大 GPU KV 或加载更多模型；主机内存余量不能直接替代显存预算。
接下来可分别测试 MTP、并发、较长视频和真实业务质量，每次只调整一个主要变量，记录 OOM、首 token、速度、正确性和资源峰值。当前没有证据宣称更高并发、262K 或任意长视频稳定。
遇到的问题
- 驱动安装后缺少
nvidia-smi：本机补装nvidia-utils-595-server并加载当前内核模块后恢复。重装或升级前先核对正在运行的内核、模块和用户态工具版本。 - Hugging Face 直连失败、代理限流：从 Spark 已有缓存内网复制，并以原始 blob SHA256 校验全部 11 个权重文件。
--calculate-kv-scales不被固定版本识别：删除不支持的参数，以当前实际 CLI 和源码为准。- 启动期健康接口未就绪会连接重置：先等待健康检查成功，再开始验收。最终复测结果见运行回执。
维护方式
main 保存已验收基线。实验从独立分支开始，记录镜像 digest、模型 revision、配置、测试条件和原始回执，验证后再合并。升级前保留旧镜像与配置；故障时先恢复已验收版本。
历史 audit/runtime/compose-*.yaml 是实验快照，不是可直接覆盖生产的完整运维配置，其端口绑定和重启策略可能不同。最终部署以根目录 compose.yaml 为准。回退 eager 时仅将 Graph compilation 参数替换成 --enforce-eager，保留端口、鉴权和重启策略，并复测。