Avoid compaction stalls during checkpoint restore
Restoring CUDA checkpoints advised huge pages even when the destination host policy had disabled them. On the affected host this caused direct compaction while loading and pinning restored memory. Honor the existing immutable ExpectHugepages policy at both advice sites, retaining eager page loading, writable prefaulting and CUDA pinning.
Use eight 4 MiB page reads instead of 128 256 KiB reads, keeping 32 MiB in flight. Writer defaults, read limits, short-read/error handling and serialized checkpoint fields remain unchanged.
The optional artifact-build input preserves ebbaed3f9dd5 for this state-compatible hotfix. Both strict checkpoint-version checks remain enabled, and the worker's runtime-version fingerprint input is unchanged. Identify the artifact by its new source revision, immutable release tag and SHA512; default builds retain their existing git-described version behavior.
Validation: the canonical Linux artifact restored the original, unmodified owned VoxCPM2 checkpoint with retained nonce and identical audio. Final runtime durations were 13.56–14.34s on the affected host and 11.64–13.24s on the control host; one corresponding deployed control took 19.31s with 12.28s in prefault versus 4.03–4.65s for the candidate. Registered host memory, GPU allocations, module and stream state also passed. Profiling demonstrated direct compaction in deployed restores and none in the policy-guard cases.
These private runtime measurements exclude scheduling and checkpoint transfer. Some warmed deployed restores were faster, and the reader change's independent full-model benefit is not established; this addresses compaction stalls rather than guaranteeing every restore is faster. No production runtime was replaced during validation.