Standalone reference document capturing the v2 reseed slow-path forensic
audit before opening the feat/d-to-p-sync branch. Designed to be quoted
directly by future paper drafts and to prevent the team from re-relitigating
the same questions verbally.
Contents:
§1. The three team-member challenges that disproved "capacity-backup will
save the slow path" (each with code citation and verdict):
1) P pool can't fit all backups -- replay.py:1618-1620 caps backup
count at 1 for sessions with ~50K peak input.
2) P's backup is a stale snapshot -- 49K of direct-to-D append work
never flows through P. _commit_prefill_backup_residency
(replay.py:1483) is only called from seed/reseed paths;
direct-to-D path (replay.py:2719) never touches P-side state.
3) When D evicts, old KV is freed directly (no D->P dump).
session_aware_cache.release_session only calls
kv_pool_allocator.free().
§2. End-to-end reseed timeline (t=0 to t=4550ms) with code citations
showing exactly where each component sits. P-side re-prefill =
1.5-3s, mooncake transfer = 1.5-4s, both contributing 50/50 to
total reseed cost.
§3. Table of "looks like D->P but isn't" code locations -- every
candidate found during forensic search ruled out with line citations.
§4. Specification of what D->P incremental sync would require:
mooncake bidirectional roles (~400 LOC), D-side append commit hook
(easy), P-side radix tree multi-producer extension (the real blocker),
agentic-pd-hybrid replay.py hooks. Estimated 1-2 weeks engineering.
§5. Confirmation via `git ls-remote origin --refs` that author has NOT
secretly implemented D->P on another branch -- only main + this
working branch exist on the server.
§6. Roadmap for the upcoming feat/d-to-p-sync branch.
Appendices: code position crosswalk, related commits, paper section
suggestions.
This document is referenced by V2_DEEP_ANALYSIS_ZH §4.2 and by
KVC_ROUTER_ALGORITHM §9 Open Question 4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
c01d6101d6