research29 min studyLesson 748 in Engineering

Topology placement: shared cuts constrain aggregate handoff

Calculate cross-cut load and bottleneck bounds while preserving actual shard redistribution, device staging, and parallelism traffic.

On this page

What you’ll understand

  • Calculate aggregate bytes per second crossing a shared topology cut.
  • Separate per-flow bandwidth from cut and endpoint limits.
  • Explain how shard layout and placement can add traffic beyond logical cache size.

A fast point-to-point cache copy does not prove a cluster can sustain many simultaneous handoffs. Transfers can share a NIC, switch uplink, PCIe path, host staging buffer, or destination memory controller. DistServe explicitly coordinates placement with the available network, while Splitwise and Mooncake study their own transfer architectures. We use hypothetical byte budgets and simple necessary bounds, not a recommendation about current hardware or a claim that every disaggregated deployment has negligible communication cost.

Map logical shards onto physical paths

Draw source and destination parallel groups and identify which layer, head, and position slices cross which links. Different stage parallelism degrees can require redistribution rather than a one-to-one shard copy. KV-head replication, packing, staging, and protocol metadata can increase actual traffic beyond a logical payload inventory. Include model-parallel communication and other tenants sharing the path. A placement that minimizes one cache transfer can worsen an intra-stage collective, so the complete stage-and-transfer topology must be evaluated together.

Use the actual endpoint path: GPU-to-NIC reachability, NUMA placement, PCIe switches, host copies where applicable, and inter-node or inter-rack links. An advertised aggregate NIC rate may be unavailable to one device or one flow. A local copy benchmark can avoid the shared uplink that dominates production. Record payload size, concurrent flows, source/destination placement, and all relevant competing traffic when reporting effective bandwidth. Without that context, a transfer-rate number cannot be converted safely into a per-request latency budget.

∑iλiVi,c≤Bc\sum_i\lambda_iV_{i,c}\le B_c
For a shared cut c, λi is transfers/s and Vi,c bytes crossing that cut per transfer, with Bc usable bytes/s. This necessary average-load bound omits bursts, latency, protocol overhead, and scheduling, and does not prove a feasible multi-resource placement.↔ Scroll wide equations horizontally.

An aggregate cut and a single transfer have different bounds

For one transfer, each required stage with finite bandwidth supplies a lower bound on completion time from its traffic volume. The maximum of those bounds is necessary even if stages overlap perfectly. Serial dependencies, setup, contention, and fill/drain can make actual time larger. Do not add independent-path bandwidths unless the transfer is genuinely striped across them with compatible routing and endpoints. Conversely, do not count the same logical payload twice simply because two counters observe it along the same path; distinguish traffic at each constrained resource.

At cluster scale, crossing only a fraction of requests over a scarce cut can reduce average load, but it changes placement and possibly cache reuse or resource balance. A local prefill-to-decode pair still needs capacity and compatible model state. Confining all transfers to one locality can create a decoder hotspot while remote resources sit idle. Compare the saved cut traffic against resulting stage queueing and failure domains. A cut below its mean capacity can still violate token deadlines under synchronized bursts.

Ttransfer≥max⁡jVjBjT_{\rm transfer}\ge\max_j\frac{V_j}{B_j}
For required path resources j with positive usable bandwidth Bj and traffic Vj in bytes, the result is seconds. This is an optimistic bottleneck lower bound with overlap allowed; resource serialization, setup, shared traffic, and completion dependencies can add time.↔ Scroll wide equations horizontally.

Validate placement with concurrent transfer and compute

Benchmark the intended number of concurrent transfers while both stages execute representative model work. Measure queueing, effective payload bandwidth, link and endpoint utilization, first-token and streaming gaps, and retransmission or staging costs. Move one stage or shard group to test a predicted bottleneck, then verify that another resource has not become limiting. Repeat under relevant failure and reroute conditions. A topology-aware policy should log why it chose a placement and what capacity estimate it relied on, so regressions can be traced to concrete path changes.

The roofline lab illustrates only a bandwidth ceiling. Reset, explicitly set intensity eight and bandwidth 80, predict the result, then Play or Step. Compare a fresh Reset with intensity eight and bandwidth 40 explicitly set; the ceilings are 640 and 320 GFLOP/s under its fixed compute roof. The instrument has no network graph, topology cut, concurrent flow, shard map, or cache transfer. Use it for the effect of a bandwidth parameter, while the actual path inventory and concurrency benchmark establish placement feasibility.

A shared cut can invalidate a fast per-flow plan

Eight hypothetical handoffs per second each send 96 MiB across one cut with usable capacity 512 MiB/s. Ignore other traffic and overhead. Consider placing half the requests so their cache transfer no longer crosses that cut.

  1. The original offered cut load is 8×96=768 MiB/s, or 150 percent of usable capacity. The necessary mean-rate bound allows at most 512/96=16/3, about 5.333 handoffs/s at this payload.

  2. If exactly four handoffs/s still cross the cut, their load is 384 MiB/s, or 75 percent. The remaining 128 MiB/s is modeled headroom, not a promise of tail latency or capacity at other endpoints.

  3. One isolated 96-MiB transfer at 512 MiB/s has a serialization bound of 0.1875 seconds. If two flows share that bandwidth equally, each at 256 MiB/s, the corresponding bound is 0.375 seconds under that explicit sharing assumption.

The result

Placement can bring mean cut load below capacity, but concurrent-flow and stage-queue effects still determine the visible handoff path.

Explore the model

Interactive lab

Interactive lab · roofline

A bandwidth parameter does not model a cluster topology

Use independent Reset → explicitly set BOTH I and B → predict → Play/Step runs for (8,80) and (8,40), giving synthetic ceilings 640 and 320 GFLOP/s. There are no NICs, cuts, flows, or KV shards in the instrument.

A bandwidth parameter does not model a cluster topologySynthetic roofline ceiling min(1000, B·I), in GFLOP/s, with B in decimal GB/s and I in FLOP/byte. Playback traces the roof without changing the selected kernel. This upper-bound model is not a measured throughput prediction, hardware comparison or price model. Current readings: Attainable ceiling: 640 GFLOP/s; Ridge intensity: 12.5 FLOP/byte; Ceiling regime: Memory-bound ceiling. All parameters are adjustable with the labeled controls below.Hypothetical roofline upper bound: 640 GFLOP per second at operational intensity 8 FLOP per byte and bandwidth 80 gigabytes per second.0.1110641101001000Operational intensity · FLOP/byte · log scaleCeiling · GFLOP/s · log scalePeak: 1000
Attainable ceiling / kernelBandwidth roof / traceCompute ceiling
Attainable ceiling
640 GFLOP/s
Ridge intensity
12.5 FLOP/byte
Ceiling regime
Memory-bound ceiling
t = 0 s

Synthetic roofline ceiling min(1000, B·I), in GFLOP/s, with B in decimal GB/s and I in FLOP/byte. Playback traces the roof without changing the selected kernel. This upper-bound model is not a measured throughput prediction, hardware comparison or price model. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.

Look forValidate actual aggregate and endpoint traffic rather than extrapolate a point-to-point rate to the entire deployment.

Check your understanding

A single handoff saturates a fast local path, but production transfers cross one shared rack uplink. What is still needed?

Try it yourself

Six handoffs/s each cross a cut with 64 MiB and usable capacity 320 MiB/s. Calculate offered load and the maximum mean handoff rate allowed by this payload-only bound. If two handoffs/s are placed locally instead, what load remains?

Take a moment to make a prediction or work it out on paper. Open a hint when you need one.

Give me a hint

Count only transfers that cross the specified cut, without assuming other path resources are unconstrained.

Compare with the solution

The original load is 384 MiB/s, above 320. The payload-only mean bound is five handoffs/s. Moving two of the six locally leaves four crossing handoffs/s, or 256 MiB/s, eighty percent of the cut budget. This does not establish endpoint memory, decode capacity, burst latency, or routing feasibility. Include actual metadata, redistribution, staging, retries, and competing traffic before treating the residual 64 MiB/s as usable operational headroom.

Take it with you

  • Inventory actual shard paths and shared endpoint resources.
  • Check aggregate cut load and single-transfer bottleneck bounds separately.
  • Measure concurrent transfer with representative stage computation.

Read further

Original sources and deeper explanations to follow at your own pace.

Optional progress, saved in this browser when available. Revisit any lesson at any time.

Lesson not marked complete.