[Bugfix] Fail fast when hierarchical cache is enabled with FP4 KV cache dtype

[jerry-he]

Motivation

Enabling the hierarchical cache (HiCache) together with an FP4 KV cache dtype (--kv-cache-dtype nvfp4 / fp4_mx_block16) currently passes server args validation but silently produces corrupted outputs after write-back/load-back. Two concrete gaps on current main:

1. Scale buffers are never transferred to/from the host pool. All L2 write-back/load-back transfers in python/sglang/srt/mem_cache/pool_host/mha.py operate exclusively on the packed data buffers (k_data_ptrs / v_data_ptrs); k_scale_buffer / v_scale_buffer do not appear in any host transfer set. After a page is written back and later reloaded, its FP4 block scales are lost, so attention consumes packed FP4 data with missing/garbage scales — silent corruption, no error anywhere.
2. Host pool capacity is computed with a full-width dtype formula. MHATokenToKVPoolHost.get_size_per_token() (pool_host/mha.py, the head_dim * head_num * layer_num * dtype.itemsize * 2 formula) does not account for FP4's half-width packed data plus the separate scale buffers, so the host pool size is also wrong for FP4.

There is no existing guard rejecting this combination (checked on v0.5.17, v0.5.18, and main).

Modifications

Add a minimal fail-fast guard in ServerArgs._handle_hicache() (python/sglang/srt/server_args.py): when any of the paths that build a hierarchical-cache host pool is active (--enable-hierarchical-cache, decode KV-cache offload, or decode host_pool retraction backup) and --kv-cache-dtype is nvfp4 or fp4_mx_block16, raise a ValueError explaining that the L2 write-back/load-back path does not transfer FP4 scale buffers and that the host pool sizes tokens with a full-width formula, directing users to pick either HiCache or an FP4 KV dtype.

Also add a unit test (TestHiCacheArgs.test_hicache_rejects_fp4_kv_cache_dtype) covering both FP4 dtypes.

Why fail-fast instead of a fix

Full FP4 HiCache support requires host-side scale-buffer transfer in every write-back/load-back path, an FP4-aware host-pool capacity formula, and dedicated correctness validation — each of which is meaningful follow-up work on top of the FP4 KV cache roadmap (#29913). Until then, rejecting the combination at startup is the safe behavior; this mirrors the fail-fast precedent for unsupported NVFP4 KV cache platforms in vLLM (vLLM PR #43669). Related area: #36010.

Verification

• python -m py_compile on both changed files.
• pytest test/registered/unit/server_args/test_server_args.py: 150 passed; the 2 failures present (TestFa4PageSizeAutoForce::test_explicit_prefill_fa4_forces_page_size_128, TestGrpcServerArgs::test_start_server_call_site_matches_native_signature) also fail on unmodified upstream main in this CPU-only environment, i.e. pre-existing and unrelated.
• New TestHiCacheArgs tests: all pass.
• ruff (repo pre-commit selection F401,F821,UP037), black, and isort clean on the changed files.
• No GPU available locally, so runtime behavior was verified by code inspection plus the args-validation unit tests only.

---

CI States

Latest PR Test (Base): ❌ Run #32680970506
Latest PR Test (Extra): ❌ Run #32680970320
Latest PR Test (AMD ROCm 7.2): ❌ Run #32680970426