感觉是strata 0.1.44.1的bug （已更新， 可能是特性不是bug）

[J Z 0]

先说更新的结果吧： 又测试了一下， 可能不是bug， 是为了提速的特性？

• 0.1.44.1 / 0.1.44 的引擎在冷前缀路径上把专家数据重新从 GGUF 流一遍，而且走 ZFS 文件缓存。0.1.43 不走这条路，所以它的冷 prompt 读盘是 ~0。
• 我nas有个ARC 4G 的上限设置（不知道为什么跟这个有关系），78 GiB 的工作集永远装不住
• ARC 抬到 32 GiB 后它稳定在 ~28GB，工作集被装住，启动读盘后降到接近 0. 但内存占用依然又110g
  *还是不方便， 关键没有提速。先退回0.1.43，打算买个便宜nvme看看有没有帮助

---

起因是看到farmer node升级到ROCM10.1.0， 7900xtx有显著提升， 我就从-7.14.1 升上来了 （我也不知道当时AI为什么选这个， 可能是抄作业的）， 顺手升了strata。TrueNAS SCALE 上升级后， 只要跑模型就持续满速读 SSD，内存疯狂增长， 窜到100多G。吐字速度倒是没变慢， 但也没提升，回退 0.1.43 后恢复正常

环境：

• TrueNAS SCALE 25.10.7，Docker 部署，HIP 后端。
• 模型：Qwen3.8-Flash-Next GSQ-RCO IQ3_S。
• i5 9600k 128g ddr4 内存
• 设置了 --ple-io ram（所有参数设置都让agent查过， 一模一样）

过程：

1. 升级前使用 0.1.43：模型加载时大量读取 SSD；加载完成后，处理请求期间几乎不读盘。
2. 升级到 0.1.44.1 后：生成回复期间持续大量读取 SSD，回复结束后读盘回落。
3. 回退到 0.1.43 后，恢复正常。

[Xiaote]

@farmer-node 对照你在 2343 帖说的：那边你用的是 --ple-io mmap，这帖环境是 --ple-io ram，这可能是 0.1.44 与 0.1.43 行为差异的直接来源，建议先把它当 A/B 变量各跑一版。

0.1.44.x 的冷前缀路径会重新从 GGUF 拉一遍专家张量，ZFS 这层缓存实际吃的是 ARC：你 ARC 上限 4G、工作集 78GiB，装不住 → 每次冷 prompt 都走盘；ARC 抬到 32G 后读盘回落，正好印证是缓存容量问题，不是逻辑坏了。

三个可核对点：

1. 110G 内存先分清是页缓存还是匿名内存：free -h（buff/cache）、arcstat 1、cat /proc/PID/smaps_rollup（Rss / FilePmdMapped）。多半是 ARC + page cache 双份 file-backed，属可回收，不是泄漏。
2. 为什么没提速：多出的 I/O 只在冷 prefill 段；你负载里 decode 占大头，decode 是显存带宽受限，前缀读盘再快也顶不动 t/s。把「预热后 TTFT/prefill」和「decode」分段测，别混在一个数里。
3. 如果留 0.1.44.x：给模型所在 dataset 设 primarycache=metadata，让 page cache 而不是 ARC 装文件（避免双份占内存），再 vmtouch 预热。

NVMe 只解决「读得快」，不解决「装不下」——78GiB 在 128G 内存里本应装得下，先调缓存比买盘划算；0.1.43 能用就不急着换。

[farmer node]

@J-Z-0 说:

--ple-io ram

--ple-io ram 这个改成 mmap ， 你这个是把ngram 全部用内存加载了， QFN 的ngram 的原始权重有51G ， 如果是IQ3 的话也有 20多G ， 这是写冷专家，用的比较少，官方的建议是放ssd ， --ple-io mmap ， 这个是按需调用， 依然是ssd ， --ple-io ram ，这个是直接放ram ，所以你的 内存上升的比较快， --ple-io ram 如果内存充裕可以放， 可以减少 token 输出的抖动。