You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(epp): widen p2p source sampling to a one-block band
Exact-count argmax re-concentrates pull traffic the moment one replica
drifts a block ahead: the queue weighting never sees near-tied peers,
so a deeply-queued source absorbs every pull while an idle peer one
block short sits unused. Sample among peers within one block of the
maximum instead; the one-block shortfall costs the destination a
single block of recompute, noise next to a queue-depth difference on
the source. The stashed count is the chosen peer's own, so the
minCachedTokenDelta gate judges the actual pull benefit.
Signed-off-by: nilig <nili.ifergan@gmail.com>
Copy file name to clipboardExpand all lines: pkg/epp/framework/plugins/requestcontrol/dataproducer/p2psource/README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,9 +2,9 @@
2
2
3
3
**Type:**`p2p-source-producer`
4
4
5
-
Sets the `x-kv-cache-source-host-port` header to the endpoint holding the most cached prompt prefix, so the routing sidecar can pull those blocks over the P2P connector instead of recomputing them. Runs in the request handling's `DataProducer` phase before scheduling, then emits the header in `PreRequest` after the scheduling decision.
5
+
Sets the `x-kv-cache-source-host-port` header to an endpoint within one block of the most cached prompt prefix, so the routing sidecar can pull those blocks over the P2P connector instead of recomputing them. Runs in the request handling's `DataProducer` phase before scheduling, then emits the header in `PreRequest` after the scheduling decision.
6
6
7
-
For each request the plugin consumes the per-endpoint `PrefixCacheMatchInfo` produced by a prefix-cache producer (`approx-prefix-cache-producer` or `precise-prefix-cache-producer`) and selects the source among the endpoints caching the most prompt tokens, sampling one with probability proportional to `1/(1+waiting queue)` using a request-ID hash as the deterministic sampling coordinate. Load-blind argmax alone would send every consumer of a widely-replicated prefix to the same peer, concentrating pull traffic on one source; a hard minimum-queue rule would herd whole scrape windows onto whichever peer last read the shortest queue, since metrics refresh about once per second and a one-request difference is noise at that granularity. Proportional weighting spreads exact ties uniformly, shifts share about 2:1 on a one-request queue difference, and effectively starves deeply-queued sources. The waiting queue is a proxy for engine-step responsiveness (a busy engine serves its P2P session slower), not for pull-serve fanout; the hash spread is what distributes pull traffic among equally-suitable sources. After scheduling it compares the chosen peer against the pod that will compute the prefix — the `prefill` profile target under P/D disaggregation, otherwise the primary target — and sets the header only when the peer out-caches the computing pod by at least `minCachedTokenDelta` tokens. Any inbound value of the header is removed. When no peer out-caches the computing pod, the request proceeds unchanged.
7
+
For each request the plugin consumes the per-endpoint `PrefixCacheMatchInfo` produced by a prefix-cache producer (`approx-prefix-cache-producer` or `precise-prefix-cache-producer`) and selects the source among the endpoints caching within one block of the most prompt tokens, sampling one with probability proportional to `1/(1+waiting queue)` using a request-ID hash as the deterministic sampling coordinate. Load-blind argmax alone would send every consumer of a widely-replicated prefix to the same peer, concentrating pull traffic on one source; a hard minimum-queue rule would herd whole scrape windows onto whichever peer last read the shortest queue, since metrics refresh about once per second and a one-request difference is noise at that granularity. The one-block band keeps a peer one block short competitive — the shortfall costs the destination a single block of recompute, noise next to a queue-depth difference on the source — so exact-count argmax cannot re-concentrate traffic the moment one replica drifts a block ahead. Proportional weighting spreads ties uniformly, shifts share about 2:1 on a one-request queue difference, and effectively starves deeply-queued sources. The waiting queue is a proxy for engine-step responsiveness (a busy engine serves its P2P session slower), not for pull-serve fanout; the hash spread is what distributes pull traffic among equally-suitable sources. After scheduling it compares the chosen peer against the pod that will compute the prefix — the `prefill` profile target under P/D disaggregation, otherwise the primary target — and sets the header only when the peer out-caches the computing pod by at least `minCachedTokenDelta` tokens. Any inbound value of the header is removed. When no peer out-caches the computing pod, the request proceeds unchanged.
0 commit comments