26 lines
1.9 KiB
Markdown
26 lines
1.9 KiB
Markdown
# 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，随页缓存状态变化。
|
||
|
||
来源：[社区方案](https://github.com/blazux/qwen3.8-Flash-DGX)、
|
||
[Linux 内存指标](https://docs.kernel.org/filesystems/proc.html)。
|