Add reproducible DGX Spark deployment for Qwen3.8 Flash Next NVFP4

docs/architecture.md

@@ -0,0 +1,24 @@
+# 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 执行，未开启 prefix caching，也没有采用社区可选的二次 FP8 量化或词表裁剪。
+
+来源：[社区方案](https://github.com/blazux/qwen3.8-Flash-DGX)、
+[Linux 内存指标](https://docs.kernel.org/filesystems/proc.html)。