1.9 KiB
PLE 与统一内存
GB10 的 CPU/GPU 共用统一内存。把 PLE 固定放到 CPU 内存仍会占用同一内存池。 本模型约 47.7 GiB 的 PLE 表不需要每一步完整读取，因此映射原始 safetensors，按索引收集所需行。 Linux 页缓存保留访问过的数据，未命中才访问 SSD。此方式不重新量化、不截断表、不修改哈希。
patches/spark_ngram_adapter.py 适配 nightly 新的 ngram_embedding 接口，
复用上游哈希/缩放和 vendor 的 mmap/custom-op；只支持此 FP8 PLE 布局和 ETP=1。
它修改内部类，因此不能随意升级基础镜像。失败时应修复版本兼容，不能吞掉异常继续运行。
实测默认配置模型权重占 76.36 GiB，KV 缓存约 14.52 GiB。 主机空闲时 used 约 102 GiB、buff/cache 约 19 GiB、available 约 18 GiB、free 约 1.6 GiB。 这些是不同口径，available 包含可回收缓存，不能与 buff/cache 相加；也不能认定所有缓存都是 PLE。 主机约 227 MiB 的 swap 存量不等同于持续发生 swap I/O。
增大 GPU_MEMORY_UTILIZATION 主要增加 KV 空间，适合更多并发或长输入，并不直接提高单流解码速度。
它会减少 PLE 页缓存空间。应比较 TTFT、tokens/s、排队时间、KV 使用率、页缺失和 swap I/O，
而不是追求 100% 内存占用。社区默认同样为 0.80，但社区性能数字不是此配置的测试结果。
完整 PLE 运算包含 GPU 同步，日志中的 op 总时长不能全部归因于磁盘；分析时应区分 gather 与 gpu-wait。 当前使用 eager 执行，优化版开启经过 Mamba 块对齐修正的 prefix caching；没有采用二次 FP8 量化或词表裁剪。 原基线的内存数字见上文；优化版本次启动 KV 约 15.11 GiB，可用主机内存约 18 GiB，随页缓存状态变化。
来源：社区方案、 Linux 内存指标。