After an independent Opus-agent forensic audit, the previous "(c) 增量
fetch (工程量较大，未实现)" line in V2_DEEP_ANALYSIS §4.2 was understating
the gap. The audit confirmed:
- No D->P KV transfer code exists in the framework at any layer
(agentic_pd_hybrid orchestration, vendored SGLang disaggregation,
or mooncake transport).
- Mooncake MooncakeKVManager has a hard role split: PREFILL = sender,
DECODE = receiver-only loop. `add_transfer_request` asserts the
disaggregation_mode is PREFILL.
- The BaseKVSender / BaseKVReceiver abstraction has no bidirectional slot.
- session_aware_cache.release_session only calls kv_pool_allocator.free()
on eviction -- no serialization, no outbound network call.
- _commit_prefill_backup_residency is only called from the seed/reseed
path (_invoke_kvcache_seeded_router). direct-to-D path never updates
P-side backup state.
- "capacity-backup" policy semantics: it only skips the close on P after
reseed -- the backup is the seed-time static snapshot, never refreshed
by D-side append-prefill activity.
V2_DEEP_ANALYSIS §4.2:
- Decomposed the 3-7s reseed cost into the P-side re-prefill segment
(1.5-3s, dominant) and the P->D mooncake transfer segment (1.5-4s).
- Quantified the realistic effect of enabling RDMA: only the transfer
segment shrinks, reseed reduces to 1.7-3.2s, TTFT p99 ~0.7s, still
loses to DP's 0.43s.
- Replaced the throwaway "(c) incremental fetch" line with a full
paragraph explaining what D->P sync would require, why it's the
largest engineering gap, and that the blocker is SGLang's radix-tree
single-producer assumption, not the network layer.
KVC_ROUTER_ALGORITHM §9:
- Refined Open Question 3 (RDMA) to clarify it only helps the transfer
segment, not the re-prefill segment.
- Added Open Question 4: D->P incremental KV sync as the central
future-work contribution gap, with cited evidence for why it doesn't
currently exist.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
9ccd853066