Optimal Stopping at the Edge of a Limit Cycle

12 August 2026 • Yuriy Polyulya •

#distributed-systems #scheduling #queueing-theory #dynamical-systems

The Failure Mode This Series Has Avoided by Construction

Post 3 cited a result and then, honestly, mostly set it aside. A June 2026 paper models memory-constrained LLM serving under threshold-based admission and eviction as a discrete-time dynamical system. It proves something specific about the eviction case, not just something qualitatively worrying [1] . Under saturated demand, the eviction-free equilibrium is unstable. The system doesn’t degrade gracefully as pressure rises. Except for a measure-zero set of exact-capture initial conditions the paper itself carves out and doesn’t lean on for safety, it converges to a limit cycle instead: a self-sustaining oscillation. The server evicts a batch of in-flight tasks to free memory; the freed memory admits a new batch; that batch grows toward the same threshold, gets evicted in turn, and the cycle repeats indefinitely rather than settling. The mechanism has a name in the paper: service-induced congestion. The service process manufactures its own future capacity crisis, because KV caches keep growing as generation proceeds. Admitting freely today is exactly what forces the eviction tomorrow. Worst case, the paper’s own bound puts the throughput loss at 50%. Half the fleet’s useful work, gone to an oscillation nobody chose and the threshold rule itself creates.

It’s worth being honest about why any operator would want to reintroduce eviction at all, rather than treating Posts 1 and 2’s non-preemptive answer as good enough for everything. Blood Oath’s own machinery buys safety by refusing to touch anything already admitted. That’s exactly what makes it safe, and exactly what makes it expensive: every reserved-margin slot Definition 2a prices, every demoted task Definition 4 refuses to admit, is capacity held back specifically because nothing, once running, can be taken back. A pool that could evict cheaply wouldn’t need nearly as much of that margin, because a bad admission would be a recoverable mistake rather than a committed one. That’s the entire economic case for wanting eviction back for any part of the population that can actually support it, and it’s a real one. It’s also exactly the case Ao et al.’s own result should make an operator pause before accepting uncritically. The same mechanism that promises to recover margin can, under the wrong conditions, cost half of the fleet’s throughput instead: a worse outcome than the conservative posture it was meant to improve on.

Post 3 had a clean way out of engaging with this directly, and used it. Blood Oath’s own second property, no preemption, a task runs to completion or the node dies with it, rules the entire mechanism out by construction. There is no evict step in Definition 4’s world. So the paper’s specific instability has no channel to operate through. Definition 4 refuses new admissions under pressure; it never touches anything already running. Post 3 drew that distinction carefully, with a Mermaid diagram showing the two paths side by side. It closed with an honest hedge of its own: even the admission-refusal loop that’s left has a control-theoretic delay in it. Blood Oath’s heavy-tailed duration distribution gives it a structural reason to expect better behavior than a fixed-duration system would show, but that’s an argument from analogy, not a proof. Whether Definition 4’s own loop is provably stable was left as unfinished work, named rather than assumed away.

This post is where that avoidance stops being available. Not because Definition 4 changes, and not because Blood Oath does. Post 1’s own closing “Compute it.” already named the case this post has to answer. A workload with ingress blindness, but where preemption is available and the task’s own accumulated state can genuinely be relocated rather than only ever discarded, doesn’t need Proposition A’s response. It needs the eviction-crossover treatment, a strictly easier problem than the one Post 1 and Post 2 solve. Easier does not mean free of the exact hazard Post 3 spent a whole section proving Blood Oath avoids. The moment this series relaxes non-preemptibility for any part of its population, even a narrower, more cooperative part than Blood Oath itself, the door the cited paper walked through is open again, on purpose this time. This post is obligated to check what’s on the other side of it before recommending anyone walk through it too.

The Population This Post Actually Studies

Definition 1 built three properties into a single workload by design: ingress blindness, execution immortality, locality lock. This post studies a task that keeps the first and drops the other two. The difference between “drops” and “never had” matters enough to state precisely. A Blood Oath task’s KV cache is architecturally locked to the accelerator that built it. Property 3 isn’t a policy choice this post is free to override; it’s a physical fact about where the memory lives and how fast it can be reached from anywhere else. A checkpointable task is a different physical object: one whose accumulated state, its KV cache, can actually be serialized and moved off the accelerator holding it, whether to another accelerator, to host memory, or across a network link, at a real, finite, computable cost rather than an architecturally prohibitive one. Property 1 stays untouched either way. Nothing about being checkpointable tells a scheduler how long a task will run; that’s still unknown at admission and stays unknown until completion, the same ingress-blindness property Definition 1’s first clause names.

This is worth stating plainly rather than leaving implicit. Post 3’s own DRF correction already taught this series what happens when a scope boundary goes unstated for too long: Blood Oath itself is not in this post’s population. A reasoning-trace generation with a locked-in cache is exactly the workload Post 1 and Post 2 exist to protect. Nothing here changes that protection or claims to improve on it. What this post studies is whatever fraction of a real production pool is checkpointable in the first place, an ordinary and common case in practice. vLLM’s PagedAttention, and comparable mechanisms in other serving stacks, already support swapping a sequence’s paged KV cache out to host memory and back, precisely to make eviction survivable rather than destructive. A task built on that kind of infrastructure pays a real relocation cost when evicted, but it doesn’t pay Blood Oath’s cost, restart from zero, discard everything computed so far. It resumes.

What actually falls into this population, in a real deployment, is worth naming concretely rather than left as an abstract property. Batch and offline inference jobs, where nothing downstream is waiting on a specific token’s latency, are checkpointable almost by default: nobody notices a few extra seconds of relocation overhead on a job that wasn’t real-time to begin with. Long-running agentic sessions built around explicit tool-call boundaries are checkpointable at those boundaries even when they aren’t checkpointable mid-generation, since a tool call is already a natural pause point where state can be serialized cheaply. What stays outside this population, deliberately, is anything built the way Blood Oath was built: a single, continuous, latency-sensitive generation with no natural pause point and a KV cache the accelerator’s own memory bus assembled incrementally, the exact case Definition 1’s property 3 was written to describe. A real pool’s mix between these categories is deployment-specific, and this post makes no claim about what fraction of any given fleet falls on which side of that line. What it claims is narrower and checkable: whatever fraction is checkpointable can be reasoned about with Proposition 5’s machinery, and whatever fraction isn’t should be left entirely to Posts 1 and 2’s treatment, not quietly folded into this post’s more permissive one.

The specimen, then, is Post 3’s own multi-resource pool, narrowed to its checkpointable sub-population: tasks under real, disaggregated-serving memory pressure, holding KV cache that grows the same way this series has priced it since Post 3. It reuses this series’ own Pareto$(x_m, \alpha=2.2)$ duration distribution, since nothing about being checkpointable changes how long a task tends to run, only whether it can be interrupted along the way. Everything Post 3 built for pricing the resource stays load-bearing here. What’s new is the decision this post’s population can make that Blood Oath’s never could: evict, at a price, or keep running.

Definition 5a: What Trading Continuation Against Eviction Actually Costs

Definition 5a -- Eviction Achievable Region: continuation cost traded against eviction cost, for a single, isolated eviction decision

Definition 5a (Eviction Achievable Region). For a checkpointable task that has run for elapsed time $t$ , holding accumulated state $S(t)$ , a decision to continue running carries an expected opportunity cost, $E[R \mid T > t] \cdot c_{\text{opp}}$ , the expected remaining holding time times the cost of holding the resource per unit time. A decision to evict instead carries a real relocation cost, $C_{\text{evict}}(S)$ , a function of how much accumulated state has to move. Every choice of when to evict maps to a point on the same two-cost frontier shape as Definition 0 and Definition 2a. Waiting longer before evicting raises the opportunity cost paid if eviction turns out to be the right call; evicting sooner raises the chance of paying a relocation cost for a task that was about to finish on its own. No policy improves one side of that tradeoff without worsening the other; that is what makes it an achievable-region object at all, not a threshold to guess at.

This Definition describes a single, isolated eviction decision, and no more than that. It says nothing yet about what happens when the same rule fires repeatedly, across a whole population, under sustained pressure. Post 3’s cited instability result is specifically about a policy applied at scale, not a single well-priced choice. Keeping that scope narrow here is what lets Proposition 5b, further down, ask the population-scale question honestly instead of quietly assuming the isolated-decision answer already covers it.

Physical translation. This is the same shape of question Definition 2a asked about reserved margin and Definition 4a asked about per-resource frontiers, asked here about a genuinely different kind of decision: not how much capacity to hold back, but how long to keep running a task that’s already admitted before cutting your losses on it. The frontier exists because both extremes are bad in an obvious, checkable way. Never evict, and a pool of checkpointable tasks behaves exactly like Blood Oath, paying every heavy task’s full opportunity cost with no escape hatch, despite having one available. Evict immediately, on the first sign a task might be heavy, and the pool pays relocation costs constantly, for tasks that would have finished cheaply on their own. Proposition 5, next, is the specific rule that sits on this frontier rather than guessing at either extreme.

Pricing Both Sides of the Decision

Two quantities need real numbers before Proposition 5 can say anything more precise than “somewhere in between.” Neither should be invented from scratch; both are extensions of numbers this series has already earned.

Why dollars, and not slot-equivalents, the unit Definition 2a and Proposition 3 both used for their own cost accounting. Those two objects priced a binary reservation decision, how many of thirty-two fungible slots to hold back, where every slot was interchangeable and the natural unit of account was the slot itself. Proposition 5’s decision isn’t binary and its two sides aren’t measured in the same physical unit to begin with: one side is a duration, expected remaining seconds of occupancy, and the other is a data transfer, bytes of accumulated state times a link speed. A slot-equivalent has no natural way to compare “seconds not yet spent” against “bytes not yet moved.” Forcing both into that unit would hide the comparison Proposition 5 actually needs to make, rather than clarify it. Dollars are the one unit both sides convert into without a category error. That’s exactly the same justification Post 3’s Definition 4 leaned on when it borrowed DRF’s normalization idea to compare a GPU-slot count against a memory-byte count against a network-Mbps figure. This post borrows that same move once more, on a decision Definition 4 never had to make, whether to spend money moving something now against the money at stake in letting it keep running.

The opportunity cost of continuing to run, $c_{\text{opp}}$ . Holding a checkpointable task’s accelerator instead of freeing it for other work has a real per-second cost, and a real, if illustrative, way to price it: on-demand cloud GPU rates for the class of accelerator this series has used throughout, roughly $2.50/hour. That figure is flagged here as a representative order of magnitude rather than tied to a specific vendor quote, the same discipline Post 3 applied to its own illustrative per-token streaming overhead. That works out to $c_{\text{opp}} \approx \$0.000694$ per second.

The cost of evicting, $C_{\text{evict}}(S)$ . Definition 1’s own property 3 discussion already named what a relocation actually costs, physically: moving accumulated KV cache across a link slower than the memory bus that built it, a cost that grows with however much state has accumulated by the time the move happens. Kept fully symbolic, that cost is a fixed overhead plus a link-bandwidth-limited transfer term:

$$C_{\text{evict}}(S(t)) = c_0 + c_{\text{opp}} \cdot \frac{S(t)}{B}$$

where:

• $S(t)$ - the accumulated state a task holds at elapsed time $t$
• $c_0$ - the fixed, size-independent overhead of any eviction
• $B$ - the relocation link’s bandwidth

$c_0$ covers control-plane bookkeeping, re-scheduling, re-attaching the relocated state on its new host, and a modest allowance for the destination accelerator warming back up rather than resuming at full speed instantly. Neither is a mathematical constant the way $\alpha$ or $\pi$ would be: both are specimen-specific parameters, priced separately, the same discipline this series has applied to $c_{\text{opp}}$ and $C_u$ , $C_o$ since Post 1.

Instantiating $B$ and $S(t)$ . This post can price the relocation link for the first time using a real number this series already has on hand: the 200 Gb/s ConnectX-7 InfiniBand port Post 3 used to time the prefill-to-decode KV-cache handoff, a real $B \approx 25$ GB/s of effective transfer bandwidth [2] . $S(t)$ itself reuses this series’ own established accounting exactly: the decode rate Post 3 measured, $500/33 \approx 15.15$ tokens per second [3] , and the 320KiB-per-token KV-cache cost Post 3 derived from Llama-2-70B’s real published configuration [4] . Together they give a task accumulating cache at a rate $\sigma \approx 4.97$ MB per second of elapsed decode, so $S(t) = \sigma t$ . $c_0$ itself is priced the same illustrative way, at $\$0.50$ . Plugging $\sigma$ and $B$ into the transfer-time term shows something worth stating before it gets buried in the next section’s arithmetic. Even accumulated over the crossover time this post derives below, the total transfer cost stays a tiny fraction of $c_0$ : roughly four thousand times smaller, the same order of magnitude the later per-second comparison finds. A real, modern interconnect moves KV cache fast enough that, for any task in the range this post actually cares about, the size of the cache being relocated barely matters to what eviction costs. What matters is the fixed cost of deciding to relocate at all. As the next section shows, exactly how large that fixed cost is relative to the opportunity-cost rate isn’t a detail; it determines whether a single, well-behaved crossover exists at all.

Proposition 5: The Eviction Crossover

Proposition 5 -- Eviction Crossover: preempt exactly when expected remaining opportunity cost exceeds relocation cost

Proposition 5 (Eviction Crossover). For a checkpointable task with elapsed running time $t$ :

$$\text{Preempt when } E[R \mid T > t] \cdot c_{\text{opp}} > C_{\text{evict}}(S(t))$$ $$\text{Continue when } E[R \mid T > t] \cdot c_{\text{opp}} \leq C_{\text{evict}}(S(t))$$

where:

• $E[R \mid T > t]$ - the expected remaining running time, given survival to $t$
• $c_{\text{opp}}$ - the opportunity cost of continuing, per unit time
• $C_{\text{evict}}(S(t))$ - the relocation cost, a function of accumulated state

$E[R \mid T > t]$ is not a new quantity. It is Proposition 2b’s mean residual life, corrected there to be piecewise: $m(t) = E[S_h] - t$ for $t < x_m$ , where survival is certain, and $m(t) = t/(\alpha-1)$ for $t \geq x_m$ , once elapsed time itself becomes genuine evidence about how much longer a task will run. The same derived object Post 2 built to decide when autoscaling arrives in time now decides when eviction is worth its cost: one formula doing a second, structurally identical job. The same domain the formula requires there applies here too, without exception.

The two-inequality form above is the rule as a decision; the same comparison also has a value form, named here because later sections in this post reuse it by name:

$$V(t) = m(t) \cdot c_{\text{opp}} - C_{\text{evict}}(S(t))$$

$V(t) > 0$ is exactly the preempt case above; $V(t) \leq 0$ is exactly the continue case. The same rule, rewritten as a single signed quantity rather than a pair of inequalities, is useful precisely because later sections need to ask not just which side of zero $V(t)$ falls on, but how it moves and what it correlates with.

Physical translation. The rule compares two things, and which one is bigger depends on where $t$ sits relative to $x_m$ . Below $x_m$ , survival is certain, so expected remaining opportunity cost falls as elapsed time passes. Every second run is a second closer to the point where the task’s own tail behavior takes over, not evidence the task will keep going. Past $x_m$ , the opposite holds: elapsed time becomes real evidence of a long remaining run, and expected remaining opportunity cost grows without bound. The right side, eviction cost, is nearly flat throughout, dominated by a fixed overhead that doesn’t scale with how long the task has already run. For a fixed overhead large enough to sit above the opportunity-cost curve’s own value at $t=0$ , the two curves don’t meet anywhere in $[0, x_m)$ at all: continuing is cheaper than evicting for the entire span where survival is guaranteed. The only crossing happens once, on the rising branch past $x_m$ , never to cross back. That’s not automatic. It’s a condition on the prices, checked below before it’s assumed, and it’s also the condition doing the real work in the claim that follows. A one-step-look-ahead rule, compare continuing against stopping now, stop the moment continuing stops paying, is only a heuristic in general. Nothing guarantees a myopic threshold beats every other stopping strategy unless the problem is monotone: once stopping is favorable, it stays favorable, so no policy that ever continues past that point can do better than one that stops there. The single crossing just established is exactly that monotonicity. With it, this is precisely, and not by metaphor, an optimal-stopping rule in the classical decision-theory sense, the myopic rule provably optimal, not merely shaped like one. Without it, a myopic rule can be beaten by a policy willing to look further ahead: exactly what a non-monotone hazard would produce. That’s the same mixture risk Post 1’s own Model Scope names for a population blending multiple sub-populations with different characteristic durations, four hazard-rate reversals instead of one smooth decline. That risk was named there for a different mechanism, whether elapsed time reliably predicts remaining time at all, but it bears just as directly here. A duration mixture doesn’t just weaken the elapsed-time signal Proposition 5’s own $m(t)$ depends on; it can break the single-crossing property this optimal-stopping claim requires, reopening the crossing more than once and making the myopic rule provably suboptimal rather than merely approximate.

Solved symbolically first, then instantiated, not left symbolic forever, but not built on a hardcoded number either. $t^*$ here is a new crossover, not a reuse of Post 1’s Definition 1b crossover time of the same name. That one marks when an elapsed-time posterior overtakes a fixed classification confidence, a probabilistic quantity measured in single-digit seconds for this series’ own specimen. This one marks an economic optimal-stopping point, measured in the hundreds of seconds. The two share a symbol because both are, structurally, the point where one curve overtakes another, not because they’re the same object. Context disambiguates which is meant everywhere this series uses $t^*$ , but it’s worth naming once rather than trusting a reader to infer it. For $t \geq x_m$ , expanding $C_{\text{evict}}(S(t)) = c_0 + c_{\text{opp}}\sigma t/B$ and setting it equal to the opportunity-cost side, $(t/(\alpha-1)) \cdot c_{\text{opp}}$ , and solving for $t$ :

$$t^* = \frac{c_0}{c_{\text{opp}} \left(\dfrac{1}{\alpha-1} - \dfrac{\sigma}{B}\right)}$$

where:

• $t^*$ - the economic optimal-stopping crossover, in seconds, not Definition 1b’s own $t^*$ (see note above)
• $\alpha, c_0, c_{\text{opp}}, \sigma, B$ - this specimen’s own priced parameters, instantiated above

Trace example, continued. Plugging this series’ own numbers straight through: $\alpha=2.2$ , $c_{\text{opp}}\approx\$0.000694$ /s, $c_0=\$0.50$ , $\sigma\approx4.97$ MB/s, $B\approx25$ GB/s.

Every quantity in that expression is a parameter of the specimen, not a universal constant: $\alpha$ from this series’ own tail, $c_{\text{opp}}$ and $c_0$ priced above, $\sigma$ and $B$ instantiated above. The formula is agnostic to what any of them turn out to be. Before plugging numbers in, the first thing worth checking is whether a single, well-behaved crossover exists at all: it does exactly when $c_0$ exceeds the opportunity-cost curve’s own maximum on $[0,x_m)$ , which (since that branch is decreasing) is its value at $t=0$ , $E[S_h] \cdot c_{\text{opp}}$ . With $\alpha = 2.2$ , $c_{\text{opp}} \approx \$0.000694$ /s, and $c_0 = \$0.50$ from above: $E[S_h]\cdot c_{\text{opp}} \approx \$0.2083$ , and $\$0.50 > \$0.2083$ , with room to spare. (This is worth flagging as a real modeling choice, not a coincidence: a fixed overhead priced much below roughly $\$0.21$ would reopen a second, early-eviction zone before $x_m$ , an artifact this post is deliberately pricing around rather than papering over, see Model Scope.) With that checked, the crossover sits entirely on the $t \geq x_m$ branch. There, the left-hand side grows at $c_{\text{opp}}/(\alpha - 1) \approx \$0.000579$ per second of elapsed time, and the right-hand side ($c_0$ plus the $c_{\text{opp}}\sigma/B$ transfer term) grows at roughly $\$0.00000014$ per second, over four thousand times slower. Instantiating the symbolic solution above with this specimen’s own numbers:

$$t^* \approx 864.2\text{ seconds}$$

864 seconds is worth sitting with, because it’s a genuinely different shape of surprise than a first guess might expect, not “surprisingly soon,” but “surprisingly rare.” It’s roughly 2.9$\times$ $E[S_h] = 300$ s, the mean heavy-task duration this series has treated as its own unit of “long” since Post 1, and roughly 5.3$\times$ $x_m \approx 163.6$ s. Since Pareto’s density is highest at its own minimum and falls off from there, the fraction of the heavy population that ever runs long enough to clear $t^*$ at all is $(x_m/t^*)^\alpha \approx 2.6$ %: fewer than one heavy task in thirty-eight. At $t=300$ s, exactly the mean, continuing is still comfortably cheaper: $m(300) \cdot c_{\text{opp}} \approx \$0.174$ against a relocation cost of $\$0.50$ . Even at $t=600$ s, twice the mean, the comparison hasn’t flipped: $m(600) \cdot c_{\text{opp}} \approx \$0.347$ still under $\$0.50$ . Only past $t^*\approx864$ s does eviction actually win. For a genuinely checkpointable task under real, grounded pricing, eviction isn’t a routine intervention against ordinary heavy-task duration at all. It’s a remedy reserved for the rare, genuine long-tail outlier, exactly the population a heavy tail’s own shape says will be hardest to predict in advance and, per Proposition 5b below, the population least likely to arrive in lockstep with anything else.

How much does the crossover move if the illustrative prices are wrong? $t^*$ scales linearly in the ratio $c_0 / c_{\text{opp}}$ , since the negligible transfer-time term barely touches either slope: provided the well-behaved-crossover check above still passes at the adjusted prices. Doubling the GPU-hour price to $5.00/hour halves the crossover to roughly 432.1 seconds; halving it to $1.25/hour doubles the crossover to roughly 1,728.4 seconds. Both remain safely inside the checked, single-crossover regime (at $5.00/hour, $E[S_h]\cdot c_{\text{opp}} \approx \$0.417$ , still under $c_0=\$0.50$ ). What doesn’t move with the price assumptions is the qualitative shape of the finding: across this $1.25-to-$5.00 spread, the crossover stays multiples of $E[S_h]$ , not a fraction of it. Eviction remains a rare-outlier remedy at every price in this range, not a routine one. What moves is the exact second and the exact rarity; what doesn’t move is that shape, and it’s the shape, not the specific 864, that this post’s later sections lean on.

$t^*$ moves with $\alpha$ too. It’s worth checking the actual shape of that dependence rather than assuming it’s fragile, because $\alpha$ governs a different, less forgiving threshold elsewhere in this series. On the $t\geq x_m$ branch this crossover lives on, mean residual life takes the closed form $m(t) = t/(\alpha-1)$ , so $t^* = c_0(\alpha-1)/c_{\text{opp}}$ : linear in $\alpha-1$ , not explosive, and well-behaved everywhere except the limit $\alpha \to 1$ , where the mean itself stops existing: a boundary this specimen’s own $\alpha=2.2$ sits nowhere near.

$\alpha$	$t^*$
2.2 (this specimen)	864.2s
2.0	720.5s
1.9	648.4s

The eviction crossover moves lower, not higher, as the tail heavies (lower $\alpha$ ): linear in $\alpha-1$ , not explosive.

Lower, not higher: and not by an order of magnitude, because a heavier tail means $m(t)$ grows faster with elapsed time, so the crossover where growing opportunity cost finally exceeds the fixed relocation cost is reached sooner, not later. There’s a real, separate reason $\alpha \leq 2$ matters to this series: Proposition 4’s own second moment, in Post 3, genuinely does stop existing at that exact boundary. But that’s a different quantity than $t^*$ , which only ever needed the first moment. Conflating the two thresholds overstates what an $\alpha$ drift into the 1.9–2.2 range actually does to this specific number.

The real gap this exposes. $t^*$ was computed once, from a single measured $\alpha$ . Nothing in Proposition 5c re-derives it the way Post 2’s own Knowledge phase re-derives $G$ from a continuously-updated $\hat{\lambda}$ . A 0.3 shift in $\alpha$ moves $t^*$ by roughly 25% here: real, boundable, checkable against the formula above. But a deployment running Proposition 5’s crossover as a value baked in at design time, rather than recomputed against a periodically re-measured $\alpha$ the way Post 2’s own Hill-estimator discipline already prescribes, will drift out of sync with its own true optimum. That drift is continuous, not catastrophic, as the underlying duration distribution moves: a slow, compounding inefficiency rather than the sudden breakdown a naive reading of “the tail got heavier” might suggest.

What this rule buys back, named against the exact bound Proposition A took away. Post 1’s Proposition A proved that under Definition 1’s three properties together, no algorithm can achieve any non-trivial competitive-ratio guarantee. It named the mechanism: an adversary that keeps extending whatever job the algorithm is currently running, unable to abandon it [5] . That same paper’s own positive result, round-robin’s 2-competitive deterministic bound, is part of what preemption buys back the moment it’s available; the broader literature it opened up adds a further result on top, randomized preemptive algorithms reaching $\Theta(\log n)$ -competitiveness. Neither bound requires knowing task durations in advance, the same ingress blindness this post’s population still carries. Both require exactly the one thing this post’s population has and Blood Oath doesn’t: the ability to stop running a job before it finishes. Proposition 5’s crossover rule is one concrete way to exercise that ability, priced against this series’ own specimen rather than left as an abstract competitive-ratio guarantee.

The Constraint Sequence Framework note, and why it runs backward here. Every earlier use of the Constraint Sequence Framework in this series has run the same direction: a fix at one level of abstraction reveals a tighter constraint one level down, and the fix has to move down to meet it. This post is the one place that sequencing reverses. Proposition A excluded a face of the achievable region, the world where preemption exists, by fiat, because Blood Oath’s own Definition 1 rules it out. This post doesn’t discover a new constraint underneath that exclusion. It relaxes the property that created the exclusion in the first place, for a population narrow enough to afford relaxing it, and the excluded face becomes reachable again, not despite the framework but because of it. The framework never claimed a downstream constraint was permanent, only that it couldn’t be dissolved by re-optimizing upstream. Removing the actual property that generated it is a different move entirely, available here specifically because this post’s specimen was scoped, honestly, to exclude the population where that property is load-bearing rather than optional.

Proposition 5 Answers a Question Definition 4 Never Asked

Proposition 5 is a per-task rule. It has no term in it for the pool’s own state. It compares one task’s own opportunity cost against its own relocation cost and says nothing about whether the node is, at that exact moment, comfortably provisioned or seconds from running out of memory. That’s a real, load-bearing gap, not a simplification that washes out in the aggregate: worth stating plainly rather than discovering by consequence: Proposition 5, exactly as derived, governs only the voluntary regime. It answers “is this task worth moving, on its own economics”, never “does the node need memory right now.” Definition 4, from Post 3, already has a signal for that second question: $H_r(t) \leq H_{\min}^r$ for the memory resource specifically. But Definition 4’s own response was scoped to admission (refuse new work, touch nothing already running) precisely because Post 3’s specimen had no eviction mechanism to reach for. This post’s population does. Composing the two isn’t automatic just because both now exist; it has to be stated, or the gap between them becomes a real operational failure mode, not a hypothetical one.

Put the failure mode concretely. Suppose $H_{\text{mem}}(t)$ crosses $H_{\min}^{\text{mem}}$ (Definition 4’s redline fires) and the pressure is coming from already-admitted checkpointable tasks accumulating KV cache, not from a burst of new arrivals Definition 4’s admission-refusal can actually stop. Suppose further that none of those running tasks has individually crossed Proposition 5’s own $t^* \approx 864$ s: a likely state, not a rare one, since fewer than 3% of heavy tasks ever reach it. Proposition 5, read as the only eviction rule, says: evict nothing. Definition 4 says: refuse new admissions, which does nothing about memory already committed. The node has no lever left, and heads toward the failure this whole series exists to price precisely: an uncontrolled exhaustion. A working eviction mechanism sits unused because the per-task economics haven’t individually caught up to what the pool’s own state is already saying.

Proposition 5c -- Emergency Eviction Priority: once the redline is real, rank candidates by how fast they relieve pressure within the time the node actually has, not by how economically ready they are, and account for the ones already in flight

Proposition 5c (Emergency Eviction Priority). When $H_{\text{mem}}(t) \leq H_{\min}^{\text{mem}}$ and admission-refusal alone is not relieving it, eviction of at least one running checkpointable task becomes mandatory, not optional. Two corrections to the voluntary rule apply, not one: which task to evict, and how fast the control loop is allowed to react to its own commands.

Which task. Not Proposition 5’s own comparison quantity, $V(t) = m(t)\cdot c_{\text{opp}} - C_{\text{evict}}(S(t))$ . That quantity answers a different question: whether this one task is worth evicting on its own economics, not which order clears a redline breach fastest across a whole population. Reusing it here would also mean re-estimating $m(t)$ for every candidate under exactly the time pressure an emergency doesn’t have to spare. The actual objective is speed: minimize the wall-clock time until enough memory is freed, evicting sequentially, one transfer at a time.

Operational Axiom. Rank eviction candidates by descending $S(t)$ , largest accumulated state first, not ascending. A larger transfer amortizes the same fixed overhead over more freed bytes, so relief rate rises with $S$ . It doesn’t fall.

$c_0$ dominates the transfer term at any realistic $S$ (established above). That means a single eviction’s own effective relief rate, bytes freed per second spent evicting it, is $S/(\delta_0 + S/B)$ , where $\delta_0$ is $c_0$ ’s own wall-clock counterpart, not the transfer-only rate $S/(S/B)=B$ , a constant that doesn’t discriminate between candidates at all. Rank candidates by descending $S(t)$ instead: largest accumulated state first, among tasks that have already cleared Definition 1b’s own confidence crossover, not the ordinary sub-second traffic that hasn’t been running long enough to say, and evict down that list until the projected headroom clears.

Mathematical proof: why relief rate strictly increases with S

Relief rate $= S/(\delta_0 + S/B)$ , where $\delta_0$ is $c_0$ ’s own wall-clock counterpart. Its derivative with respect to $S$ is $\delta_0/(\delta_0+S/B)^2$ , strictly positive for any real $\delta_0$ . A larger transfer amortizes the same fixed overhead over more freed bytes: so relief rate rises with accumulated state, not falls, at every point on the curve, not just at the extremes.

That ranking maximizes relief per second of effort, which is a throughput objective. It quietly assumes any candidate’s own transfer is guaranteed to land before it matters. That’s not automatic, since the node keeps losing memory to every surviving task at rate $\sigma$ each while a chosen eviction is still in flight. There is a real deadline this maximization doesn’t see:

$$T_{\text{OOM}}(t) = H_{\text{mem}}(t) / (\sigma \cdot N_{\text{survivors}}(t))$$

where:

• $T_{\text{OOM}}(t)$ - the wall-clock time until the node exhausts on its own, nothing freed
• $H_{\text{mem}}(t)$ - the current real headroom
• $N_{\text{survivors}}(t)$ - tasks still running, still consuming memory

$T_{\text{OOM}}(t)$ prices survivor consumption theoretically, at the constant $\sigma$ this post’s own Model Scope has since shown isn’t always true. The fix isn’t swapping in $\dot{H}(t)$ , though, and it’s worth being precise about why not. Definition 2’s own $\dot{H}(t)$ is a live physical signal, but it’s a finite difference of the EWMA-smoothed $\hat{H}(t)$ , smoothed specifically to trade reaction speed for noise immunity. Post 2’s own Model Scope already names the cost of differentiating that smoothed signal: phase lag, a standard route to oscillation, unpriced anywhere in this series. Substituting it into $T_{\text{OOM}}(t)$ would import that exact lag into a hard safety deadline computed during an active emergency, the one moment lag is least affordable, and it cuts both ways: if relief from an earlier eviction is already landing, $\dot{H}(t)$ reflects a mix of consumption and partial credit, which could read $T_{\text{OOM}}(t)$ as safer than it actually is. The theoretical $\sigma \cdot N_{\text{survivors}}(t)$ has a real weakness of its own, the $\sigma$ -jitter this post’s own Model Scope names elsewhere, but it responds instantly to a directly observable count, $N_{\text{survivors}}(t)$ , rather than lagging behind a smoothed derivative. Whichever error is worse, in which direction, at a given deployment’s own tick rate and jitter magnitude, this post hasn’t compared. A team that wants a live correction to $T_{\text{OOM}}(t)$ should reach for an unsmoothed, purpose-built rate estimate distinct from $\dot{H}(t)$ , not the demotion trigger’s own signal repurposed for a job it wasn’t tuned for.

Design Guardrail. The most efficient candidate by relief rate can still be a fatal pick.

A candidate whose own $T_{\text{evict}} = \delta_0 + S/B$ exceeds $T_{\text{OOM}}(t)$ is the most efficient pick by relief rate and a fatal one to make: the node fails mid-transfer, before the one eviction chosen to save it finishes arriving. The ranking needs that deadline as a ceiling alongside Definition 1b’s own floor: descending $S(t)$ , subject to $\delta_0 + S/B < T_{\text{OOM}}(t)$ , taking the largest candidate that still clears its own deadline rather than the largest candidate unconditionally. Whether this ceiling actually binds at any real deployment’s own numbers turns on $\delta_0$ , deliberately left illustrative above rather than pinned, and on how many survivors a real breach finds running concurrently. At this specimen’s own scale, $B$ some four thousand times larger than $\sigma$ , transfer time stays small enough across any $S$ this pool produces that the ceiling is unlikely to bind, unless $\delta_0$ itself turns out to be unusually large or a breach catches an unusually large survivor population running concurrently. Unlikely to bind here is not the same as safe to omit: a deployment with a slower relocation path, a heavier per-eviction control-plane cost, or a much larger concurrently-running pool should check $T_{\text{OOM}}(t)$ against its own $\delta_0$ before trusting descending-$S(t)$ to pick a candidate that actually arrives in time.

This deadline is stated per candidate. It has to be re-checked at the level a real deployment actually runs evictions at, not left there. If a single relocation clears the deficit, the per-candidate check above is the whole story. If it doesn’t, the deficit needs several evictions off the top of the ranked list before projected headroom recovers. Those evictions run one at a time, to protect the fabric from exactly the incast pattern named below. The relevant deadline isn’t any single candidate’s own $T_{\text{evict}}$ against $T_{\text{OOM}}(t)$ ; it’s the cumulative serialized time, roughly $k$ candidates’ worth of $\delta_0$ each since transfer time itself stays negligible, against the same $T_{\text{OOM}}(t)$ . Serializing to protect the fabric and satisfying the physical deadline are not automatically compatible, and nothing checked so far verifies they are. A redline breach deep enough to need several evictions, on a control plane with a real, non-trivial $\delta_0$ , can serialize its way past $T_{\text{OOM}}(t)$ , even though every individual candidate would have cleared its own per-candidate check in isolation. Whichever mechanism ends up bounding fabric exposure has to be checked against this cumulative version of the deadline, not just the single-candidate one. That’s a real, engineering-level tension this post names rather than resolves, since resolving it means choosing a specific fabric-safety mechanism this post’s own symbolic model doesn’t commit to.

This same fixed-overhead argument is why “evict smallest first” was the wrong direction to begin with, not a right direction that merely needed a floor to stay safe at the extreme. A light task finishing in half a second accumulates roughly 2.5MB of state: genuinely negligible relief for the fixed overhead $c_0$ an eviction pays regardless of size. Freeing the same $\approx1$ GB a single moderately-elapsed heavy task holds at $t=200$ s would take roughly 400 light-task evictions instead, paying $400 \times c_0 \approx \$200$ in fixed overhead. More to the point in an emergency, that’s 400 separate control-plane round trips, each with its own wall-clock cost, to do what one eviction of the heavy task does in one. That’s not a corner case an otherwise-sound ascending rule mishandles only at the extreme; it’s the same arithmetic at every point along the ranking, which is exactly why the rule itself needed reversing, not bounding. Definition 1b’s own confidence floor still matters here, for a narrower reason than before: descending $S(t)$ already reaches for the largest available candidates first, so it only risks dipping into ordinary, not-yet-confidently-classified traffic in the residual case where every currently-running task past that floor has already been evicted and the deficit still isn’t cleared. That’s a real boundary worth keeping stated, just no longer the rule’s main defense against its own worst case.

How fast the loop reacts. A redline check run against raw $H_{\text{mem}}(t)$ at every control-loop tick will keep firing new eviction commands for every tick the first transfer hasn’t yet completed. Freed memory doesn’t physically exist until the transfer finishes, but the loop has no way to know that from $H_{\text{mem}}(t)$ alone. A pending-credit term alone isn’t sufficient either, and shouldn’t be presented as though it were. Crediting $S_i$ for every in-flight eviction as if it were already free treats the moment those transfers land as now, when it’s actually $T_{\text{wait}}(t)$ in the future: time during which every surviving task keeps consuming memory at rate $\sigma$ . Evaluate the redline against a headroom that accounts for both, natively, not as two separate patches:

$$\hat{H}_{\text{mem}}(t) = H_{\text{mem}}(t) + \sum_{i \in \text{pending}} S_i - \sigma \cdot N_{\text{survivors}}(t) \cdot T_{\text{wait}}(t)$$

where:

• $T_{\text{wait}}(t)$ - time until the slowest still-pending transfer completes, shrinking tick by tick
• $N_{\text{survivors}}(t)$ - checkpointable tasks still running, still consuming memory during that wait

Operational Axiom. $\hat{H}_{\text{mem}}(t)$ is a projection, not a snapshot.

It asks not “would I be safe if pending credits applied instantly” but “will I actually be safe once they land, given what survivors will have consumed by then.” $H_{\text{mem}}(t)$ is re-sampled live at every tick. A task’s pending credit is removed from the sum and folded into real $H_{\text{mem}}(t)$ once its transfer actually finishes, at which point it also drops out of $N_{\text{survivors}}$ ’s count on the pending side, and the projection shrinks to match.

This arithmetic is exact for the instant it targets: crediting every pending $S_i$ in full and subtracting $\sigma \cdot N_{\text{survivors}}(t)$ once over the whole $T_{\text{wait}}(t)$ gives precisely the real, physical headroom at the moment the slowest transfer lands, regardless of the order in which faster transfers complete along the way. Addition and subtraction don’t care when within the interval each pending credit actually arrived, only that it arrives by the end of it.

What that exactness doesn’t cover: whether headroom ever dips below that endpoint value before reaching it. It can, and does whenever more than one transfer is pending. Between now and the slowest transfer’s own landing, survivors keep consuming continuously while relief arrives in discrete jumps, one per completing transfer. So the real trajectory’s lowest point sits before the fastest pending transfer lands, not at $T_{\text{wait}}(t)$ : the moment with the least relief credited and the most accumulated consumption, not the moment with all of it. $\hat{H}_{\text{mem}}(t)$ , checked only at the endpoint, is systematically the best point on that trajectory, not a conservative estimate of the worst one. A redline evaluated solely against it can read “safe” while the real, physical $H_{\text{mem}}(t)$ is, at that same moment, still falling toward a trough the projection has already priced past.

Whether that gap is small enough to ignore depends on how close together pending transfers actually land. At this specimen’s own numbers, where $\delta_0$ dominates every transfer’s own duration regardless of $S$ , a full wave’s individual completions cluster within a few seconds of each other, keeping the trough shallow. But “keeps it shallow at this specimen’s scale” is a checked observation, not a property the formula itself guarantees. A more conservative check verifies the trajectory’s minimum directly rather than only its endpoint, computable in closed form from the same pending set, at negligible extra cost, since the minimum can only occur at $t$ or immediately before one of the already-known pending completion times, not at an unknown point requiring a search.

    
    stateDiagram-v2
    [*] --> Running
    Running --> Eligible: past confidence floor
    Eligible --> Running: V(t) < 0

    state fork_choice <>
    Eligible --> fork_choice
    fork_choice --> Evicting_Voluntary: V(t) > 0
    fork_choice --> Evicting_Emergency: redline breach

    Evicting_Voluntary --> Transferring: pays C_evict(S)
    Evicting_Emergency --> Transferring: pays C_evict(S)

    Transferring --> Resuming: transfer lands
    Resuming --> Running: penalization clears
    Resuming --> [*]: T_timeout elapsed

Each edge compresses a checked condition, spelled out in full above and below: “past confidence floor” is Definition 1b’s own crossover, “redline breach” additionally requires ranking candidates by descending $S(t)$ and clearing the $T_{\text{OOM}}(t)$ deadline, $C_{\text{evict}}(S) = \delta_0 + S/B$ , and “T_timeout elapsed” means the client gave up before the second transfer could land: nothing left worth preserving.

What this diagram deliberately leaves out: demotion, Definition 4’s own admission-refusal mechanism, never appears here: it’s a scheduling-priority change that touches nothing running, a structurally separate mechanism from the physical relocation this diagram traces.

Physical translation. Both corrections exist to close the same gap: Proposition 5’s own logic was built for a world where nothing is urgent, and urgency changes what “the right candidate” and “the right reaction speed” mean. On ranking: a superficially appealing shortcut is to rank by bytes freed per second of transfer. But that ratio is exactly the link bandwidth, a constant, for every candidate: it doesn’t discriminate at all, and treating it as the relevant rate is what makes “ascending” look defensible when it isn’t. The rate that actually determines how fast a redline breach clears is bytes freed per second spent evicting, fixed overhead included, and that ratio isn’t constant. It rises with $S$ , because the same fixed cost buys more relief the larger the transfer is. Ranking by descending $S(t)$ , bounded below by Definition 1b’s own confidence floor so it never needs to reach into ordinary light traffic, is the formalization that rate actually supports. On reaction speed: the credited-headroom check isn’t a cosmetic addition. Without it, a control loop ticking faster than a single transfer completes is a real risk, since even a full-pool emergency transfer only takes several seconds while a Monitor/Analyze cycle typically ticks in a fraction of that. It will see the redline still breached after issuing one eviction command and simply issue another, then another, gutting far more of the node’s workload than the pressure ever required, before the first freed byte has finished crossing the wire. Definition 2a already settled the underlying cost comparison this whole mechanism rests on: a 32:1 underage-to-overage ratio, node failure costing dramatically more than one idle slot. $C_{\text{evict}}(S(t))$ stays close to $c_0$ across any realistic elapsed time, still within a fraction of a percent of $\$0.50$ even at ten thousand seconds of accumulated runtime. Against a node-failure cost this series has always treated as categorically larger, evicting something is never a close call. Evicting the right something, fast enough to matter, is the actual design problem, and it’s a ranking-and-pacing problem, not a stopping problem.

The projection term isn’t optional, and at this post’s own numbers it isn’t small. A $k=32$ emergency wave with a 5.5-second wait and 30 surviving tasks burns $\sigma \times 30 \times 5.5\text{s} \approx 820$ MB before the credited transfers land. That’s a figure large enough, next to a margin sized in the single-digit gigabytes, to leave a control loop that only credits pending bytes and never subtracts projected consumption genuinely short of the redline it thinks it already cleared, not just flickering at tick granularity. That’s why $\hat{H}_{\text{mem}}(t)$ carries the $\sigma N_{\text{survivors}} T_{\text{wait}}$ term directly rather than treating it as a refinement a careful implementer might add later. What the live re-sampling of $H_{\text{mem}}(t)$ still buys, on top of that: $N_{\text{survivors}}(t)$ and $T_{\text{wait}}(t)$ are themselves estimates, evaluated at whatever the loop currently believes about who’s running and how much longer the slowest transfer needs. A live tick corrects both against reality as new information arrives, rather than compounding a stale projection for the full duration of the wait. The residual risk that’s left is narrower than the one this post started with: not “the formula ignores survivor consumption,” but “the projection is only as good as its own estimate of $N_{\text{survivors}}$ and $T_{\text{wait}}$ between ticks.”

“Normal estimation-error problem” undersells that residual risk for one specific case, worth naming rather than folding into the general one. It’s the right description for ordinary jitter: a transfer running a little slower or faster than the last tick’s estimate, the kind of noise live re-sampling corrects for smoothly, tick over tick. It’s the wrong description for the PFC-storm case this post’s own Model Scope already establishes: a collapse, not a slowdown, the cited production failure mode’s own word for it. There, $T_{\text{wait}}$ doesn’t drift a little between ticks; it jumps, discontinuously, from a sub-second figure to several seconds, once incast congestion actually triggers. Live re-sampling corrects for drift. It only corrects for a jump after the tick that observes it. Every tick before that one was computing $\hat{H}_{\text{mem}}(t)$ against a $T_{\text{wait}}$ -estimate that PFC collapse has already made wrong by orders of magnitude, not a normal estimation error at all. How much damage that one-tick lag does depends on the control loop’s own tick rate relative to how fast a real PFC storm actually develops, a comparison this post has never run, the same way it has never run the $\sigma$ -under-contention check named just above. A team on lossless RDMA fabric should treat both gaps as one question, not two: how fast can this specific fabric’s own congestion collapse, and does the control loop tick faster than that.

What this doesn’t solve, named rather than assumed away. Proposition 5c assumes there’s an evictable population large enough to relieve the pressure it’s responding to. If the checkpointable sub-population running at the moment of a redline breach is too small, or too uniformly early in its own lifetime, to free enough memory by evicting the top of the ranked list, this rule has nothing further to offer. The node’s fate reverts to whatever Definition 4’s admission-refusal alone can do, which Post 3 already showed is not much once the pressure comes from work already in flight. Sizing the checkpointable population itself against a real redline-breach scenario, the way Definition 2a sized $H_{\min}$ against a real bridging-window arrival process, is unfinished work this post is naming, not solving. Ranking by descending $S(t)$ happens to track, rather than fight, Proposition 5’s own economic preference. Since $S(t)$ accumulates with elapsed time for this resource, the tasks a footprint-first emergency ranking reaches for first are the same ones with larger $m(t)$ , which is what Proposition 5’s own $V(t)$ rewards evicting. Within this specimen’s own model, that’s not a loose tendency: it’s exact, and worth proving rather than asserted, since “disproportionately” undersells what’s actually true here. Mean residual life for a Pareto tail takes the closed form $m(t) = t/(\alpha-1)$ for $t \geq x_m$ , already established in Proposition 5’s own derivation above: strictly increasing in elapsed time $t$ . $S(t) = \sigma t$ , this post’s own accumulation model, is strictly increasing in that same $t$ , using the single specimen-wide $\sigma$ Proposition 5’s own $C_{\text{evict}}(S)$ formula uses everywhere else in this post. Two quantities that are each strictly increasing functions of the same variable induce the same ordering: for any two candidates with elapsed times $t_1 < t_2$ , $S(t_1) < S(t_2)$ exactly when $m(t_1) < m(t_2)$ , since both inequalities reduce to $t_1 < t_2$ directly. Descending-$S(t)$ ranking is descending-$m(t)$ ranking, exactly, not approximately, wherever this post’s own constant-$\sigma$ model holds. The emergency channel’s own speed-first rule and Proposition 5’s own economics-first rule pick the identical order, for a real, provable reason, not a fortunate accident of this specimen’s own numbers.

What keeps this from being unconditional is real, and worth stating precisely now that the exact case is proven rather than left blurred together with it. A real deployment’s $\sigma$ need not be identical across tasks the way this specimen’s own single-$\sigma$ model assumes. A task with a longer prompt accumulates state at a different effective rate than one with a shorter prompt, even holding elapsed decode time fixed, the same per-task variation Post 3’s own Model Scope section named for prompt length generally. Where $\sigma$ genuinely varies task to task, $S(t)$ and $t$ stop being interchangeable, and the exact equivalence above degrades to a strong correlation rather than a guaranteed one. A deployment with meaningfully heterogeneous prompt lengths across its checkpointable population should treat descending-$S(t)$ as a strong, but no longer exact, proxy for descending-$m(t)$ , and re-verify the gap between the two rankings against its own measured $\sigma$ distribution before leaning on it as strictly as this specimen’s own single-$\sigma$ model permits. Where they do diverge, it’s still the price of the same regime shift Definition 5a’s own physical translation named at the start: continuing to run something stops being available once the redline is real.

From One Eviction to a Policy of Evicting

Splitting Proposition 5 into a voluntary rule and Proposition 5c’s emergency priority ranking closes the trigger gap. The node no longer goes silent exactly when it needs eviction most. It opens a different one. Proposition 5c’s whole design evicts more than one task per redline breach, on purpose, and evicts them together, in response to a single shared signal, which is a structurally different pattern than Proposition 5’s own naturally-sparse, individually-timed voluntary evictions. Whether applying either version of this machinery repeatedly, across a whole pool of checkpointable tasks under sustained pressure, is safe to run as a standing policy is not a hypothetical question. It is the exact question Post 3’s own citation answers, and answers unfavorably, for a system that behaves the way a naive population-scale application of eviction would behave. Proposition 5c’s emergency channel is, if anything, the more dangerous of the two to check.

Restated precisely, because the distinction is the whole point of this section: Ao et al.’s proof is about eviction, not admission-refusal. Post 3’s own admission-refusal loop, Definition 4, was a structurally different mechanism, and Post 3 said so explicitly, hedging honestly that its own stability was an open question argued from analogy, not proof. This post’s population doesn’t get to lean on that same distinction. A checkpointable task under Proposition 5’s rule is evicted, not merely demoted or refused re-admission. Applied at population scale, under sustained memory pressure, this post’s own mechanism is not adjacent to the paper’s subject. It is the paper’s subject, run for real rather than borrowed as an analogy.

The mechanism the paper proves unstable has a specific shape, worth restating precisely rather than trusted as “roughly what happened in Post 3’s diagram.” Memory pressure rises toward a threshold. A batch of tasks crosses Proposition 5’s crossover point at roughly the same time and gets evicted together. The memory that frees up admits a fresh batch. If that fresh batch’s tasks tend to reach the same crossover point at roughly the same elapsed time as each other, because they were admitted together and share a similar duration profile, the system evicts them together too, and the cycle repeats, synchronized, without settling. Fifty percent of throughput, in the paper’s own worst case, spent on compute that gets evicted before it pays off, over and over, not because any single eviction decision was wrong, but because the population of decisions resonates with itself.

The paper’s own model has one more assumption worth checking before its mechanism is reused wholesale. It studies tasks that are evicted and, on re-admission, start from zero: a fresh task with no relationship to whatever was evicted before it. This post’s population doesn’t behave that way. The difference isn’t cosmetic. A checkpointable task that’s evicted isn’t discarded; its state is serialized and moved, and the system still owes it that state back the moment it’s re-admitted. Re-admission for this population isn’t a fresh start. It’s a second transfer: the same multi-hundred-megabyte-to-multi-gigabyte KV cache pulled back across the same kind of link the eviction just used to move it out, before the task can resume doing anything useful at all. Call this memory gravity: a checkpointable task doesn’t leave the system’s own accounting when it’s evicted, it just becomes a liability with a return trip already owed. If the scheduler treats a just-evicted task as an ordinary new arrival, competing for readmission on the same footing as anything else waiting, the specific failure mode Ao et al. describe gets a second, worse channel to run through. Not just compute wasted on tasks evicted before they paid off, but the same large task’s state paid to move out and immediately paid again to move back in, every time it wins re-admission only to get caught by the next redline breach. A limit cycle built on this population isn’t bounded by compute waste alone, the way the cited paper’s own model is. It’s compounded by bidirectional transfer cost the paper’s stateless model never has to pay. The minimal defense: a just-evicted checkpointable task should not be immediately eligible to compete for re-admission on equal terms. A penalization window, sized against this post’s own transfer-time numbers rather than guessed at, keeps a task’s return trip from starting until there’s real reason to believe the memory it would re-claim is actually going to stay available.

A re-admitted task doesn’t just compete for memory on the same footing as a genuinely new one. If it’s counted the same way, it corrupts the signal Post 2’s own Knowledge phase uses to decide how much margin the whole node needs. Knowledge’s $\hat{\lambda}$ is an EWMA of $c_n$ , “the observed arrival count” of heavy tasks per bridging window: a mechanism that predates this post’s own population and was never revisited once eviction-and-resume entered the picture. A resumption isn’t a new piece of work arriving; it’s the same task’s own state coming back, already priced once when it was first admitted. Counting it again as a fresh arrival inflates $c_n$ by exactly the number of resumptions landing in that window. The timing is the dangerous part, not the double-count in isolation: resumptions cluster in the immediate aftermath of an eviction wave, precisely when a redline breach has already happened and the node is already under the most pressure it sees. An inflated $\hat{\lambda}$ in that window doesn’t just overstate ordinary demand. It feeds directly back into $H_{\min}$ ’s own re-derivation and Definition 4’s admission-refusal threshold, widening the reserved margin and tightening admission exactly when the system just finished evicting to relieve pressure. That’s a real, closed feedback path this post’s own memory-gravity mechanism creates, and Post 2’s counter was never built to filter out. The fix costs nothing structurally, the same shape as the censored-demand fix Post 3 needed once Definition 4 started refusing admissions: $c_n$ has to count genuinely new heavy-task classifications at Definition 1b’s own classification point, tagged as such, and exclude resumptions of a task this node (or any node) has already counted once before. A resumption still needs its own accounting, since it still consumes memory and still needs Definition 4’s redline to see it coming, but it belongs in $H_{\text{mem}}(t)$ directly, not in the arrival-rate estimator that sizes tomorrow’s buffer against today’s new demand.

That window has an upper bound this post hasn’t named. The bound comes from outside the system this post has modeled entirely in terms of memory and money. A synchronous serving architecture holds a live client connection open against every in-flight request, with its own timeout, $T_{\text{timeout}}$ , independent of anything this post’s accounting prices. A task paused for longer than its client is willing to wait doesn’t get resumed into a system that still cares about the answer. The connection is already gone, and whatever compute the resumption spends finishing the task is spent for nobody. That breaks Proposition 5’s own recoverability assumption more fundamentally than a bad price ever could. $C_{\text{evict}}(S)$ was priced on the premise that relocating a task preserves the value of finishing it. A task whose client has already timed out has no value left to preserve, regardless of how cheaply its state moved. The physical bound this forces: $W_{\text{penalize}} \leq T_{\text{timeout}} - t - T_{\text{transfer\_out}} - T_{\text{transfer\_in}}$ : whatever’s left of the client’s own patience once elapsed time and both transfer legs, out and back, are subtracted. A task for which that bound is already negative (one whose remaining timeout budget can’t cover even a zero-length penalization window) has nothing left to protect by checkpointing at all; the honest choice for that task is the same one Blood Oath was always stuck with, terminate outright, not pay a relocation cost for a resumption nobody will be there to receive. This post names $T_{\text{timeout}}$ as a real, unpriced parameter rather than assume synchronous clients wait indefinitely; sizing the window against a real arrival process, and against a real client-timeout distribution, is unfinished work, the same way Proposition 5c’s own population-sizing question is.

Proposition 5c’s own batching channel is worth separating from this description, not folded into it, because it’s a structurally closer match to the paper’s mechanism than Proposition 5’s voluntary rule ever was. The “batch crosses the crossover point at roughly the same time” story above describes several tasks coincidentally reaching Proposition 5’s own $t^*$ together: a coincidence Proposition 5b, next, argues a heavy tail makes unlikely. Proposition 5c doesn’t need that coincidence. It evicts several currently-running tasks by design, all in response to one shared signal, a single redline breach, regardless of whether any of them individually cleared $t^*$ . That’s not a coincidental batch the duration distribution happens to avoid. It’s a designed batch, triggered by exactly the kind of shared threshold-crossing event Ao et al.’s own mechanism is built around. Whether the heavy tail’s protection carries over to this designed batch turns out to depend on exactly which candidates the ranking rule reaches for, which the next section works out in full. It isn’t automatic just because the batch is deliberate rather than coincidental.

“Admitted together” is itself worth checking against this specimen rather than accepted as a clean starting assumption. Definition 2a already committed this series to a real arrival model, a Poisson process, not a scheduler that batches admissions into discrete cohorts. Under a Poisson process, tasks trickle in continuously rather than arriving in synchronized waves. That on its own gives a second, independent reason to expect less clustering than a worst-case resonance scenario needs: even before duration heterogeneity enters the picture, the tasks a real eviction event frees memory for were rarely admitted at exactly the same instant to begin with. That doesn’t make the resonance mechanism impossible; a memory-pressure threshold crossing is still a shared, synchronizing event regardless of how staggered the arrivals were. But it’s a second structural reason, independent of the duration-distribution argument Proposition 5b makes, worth naming rather than leaving Proposition 5b’s heavy-tail argument to carry the whole case alone.

The paper’s own finding about what prevents that resonance is precise enough to check against, not just gesture at: workload heterogeneity, completions desynchronized from each other rather than clustered, breaks the resonance that drives the cycle. In the paper’s own setting, that desynchronization comes from coprime decoding lengths: task durations chosen so that no small set of tasks admitted together tends to reach a shared milestone at the same time. The paper states this specifically for what it calls input-dominated scaling, not as a claim that holds for every scaling regime a real deployment might sit in. This series’ own specimen was never built with coprime lengths in mind, but it was built, since Post 1, on a heavy-tailed Pareto$(x_m, \alpha=2.2)$ duration distribution, and a heavy tail is, structurally, a very different shape from a narrow, clustered one. Post 3 already leaned on exactly this property once, for its own admission-refusal loop. The honest version of that argument transfers here more directly than it did there: this post’s eviction loop is not an analogy to the paper’s subject needing its own separate justification. It is the paper’s actual subject. The same heavy tail that gave Post 3’s hedge its structural footing is now doing that job on the paper’s own literal case, not a borrowed one, with the same regime question Post 3 left open still open here: whether this specimen’s own scaling is the input-dominated case the paper’s own result is stated for is a measurement this series hasn’t made.

Proposition 5b: Eviction Stability Condition

Proposition 5b -- Eviction Stability Condition: heavy-tailed duration provides a structural, not proven, defense against the limit cycle

Proposition 5b (Eviction Stability Condition, Voluntary Regime). A population of checkpointable tasks, each governed by Proposition 5’s voluntary crossover rule, has a structural reason to avoid the mass-simultaneous-eviction resonance Ao et al. prove drives a worst-case limit cycle under threshold-based eviction. Proposition 5’s own corrected crossover sits deep in the tail ($t^* \approx 864$ s, reached by fewer than 3% of heavy tasks) so the population actually at risk of eviction is never the bulk of admitted tasks, clustered near $x_m$ , but specifically the rare, genuine long-tail survivors. That’s the population a heavy tail’s own defining property speaks to most directly. Past $x_m$ , elapsed time carries decreasing information about exactly how much longer a task has left, which spreads when different long-tail survivors individually cross $t^*$ rather than clustering it: precisely the opposite of the synchronized-completion structure the cited instability depends on. This condition is stated for the voluntary regime specifically and does not extend to Proposition 5c’s emergency channel without further argument, see below.

This is a structural argument, not a stability proof, and the difference matters enough to state without softening it. Ao et al.’s own paper achieves desynchronization through a specific, engineered mechanism, coprime decoding lengths, chosen by construction to guarantee no small subset of tasks shares a completion milestone. This post’s specimen achieves whatever desynchronization it has as a byproduct of a duration distribution chosen for entirely different reasons, back in Post 1, to model a real reasoning-trace workload, not to defeat this specific instability. That the same property happens to point the same direction is a real, load-bearing reason for optimism about the voluntary mechanism. It is not a derivation showing Proposition 5’s rule, applied at population scale under this specimen’s actual arrival and duration statistics, provably avoids the limit cycle the way Ao et al. prove their own eviction-free equilibrium is unstable in the first place. Whether it does is unfinished work this post names rather than assumes away, the same discipline Post 3 already applied to its own, structurally easier, admission-refusal question.

Physical translation. Post 3 asked essentially this same question about a milder mechanism, refuse admission, touch nothing running, and still only managed an honest hedge, not a proof. This post’s voluntary mechanism, evict work already in flight, is the mechanism the cited paper actually studied and proved unstable under a threshold rule with no heterogeneity to break the resonance. Having a genuine structural reason to expect better behavior, grounded in the same heavy tail that’s done real work everywhere else in this series, is worth a great deal more than an unexamined assumption that eviction is fine because Proposition 5’s own math checked out. It is still, honestly, short of a proof, and a team running this mechanism in production should treat that gap as real rather than papered over by the strength of the analogy.

Proposition 5c’s emergency channel turns out to inherit Proposition 5b’s desynchronization protection rather than lack it. The correction from ascending to descending state changes which population the emergency channel draws from, and it lands on nearly the same one. Proposition 5b’s whole argument rests on desynchronization that arises from the duration distribution, different tasks reach their own $t^*$ at different, spread-out times because the tail is heavy, which is a real structural property of the rare, long-tail survivors specifically. Proposition 5c’s corrected ranking rule selects close to that same population: it evicts by descending accumulated state, largest and most memory-heavy first. Because $S(t)=\sigma t$ is an exactly increasing function of elapsed time within this specimen’s own constant-$\sigma$ model, the same equivalence proven above for $m(t)$ applies here directly. Ranking by $S(t)$ among currently-running tasks is ranking by elapsed time itself, not merely correlated with it. The tasks with the largest $S(t)$ at any given moment are exactly the rare tasks that have already run long, the same sparse long-tail survivors Proposition 5b’s desynchronization argument is about, not the common, populous early-elapsed-time majority Pareto’s density concentrates near $x_m$ . That equivalence holds exactly within this post’s own single-$\sigma$ model; it degrades to a strong but no longer exact correlation for a deployment with real, per-task-varying $\sigma$ , the same boundary named above. A task there could accumulate unusual footprint early without having run long. With that caveat stated, the emergency channel’s resonance risk looks better than a first pass without the ranking correction would suggest, not worse. A redline breach now draws disproportionately from the same heavy-tailed, spread-out population whose desynchronization Proposition 5b already argues for, rather than from a population concentrated enough in elapsed time to resonate the way Ao et al.’s adversarial construction requires. Whether repeated emergency-channel breaches can still fall into that resonance through some other correlation this post hasn’t ruled out is a genuinely open question it has not fully answered, but the ranking correction removes what would otherwise have been the clearest reason to expect the emergency channel’s risk to exceed the voluntary channel’s. It remains worth naming as unfinished work, behind only the more basic question of whether $m(t)$ is even well-behaved in the first place, see Model Scope.

Putting a number on “spread out,” rather than leaving it qualitative. A Pareto$(x_m, \alpha)$ distribution’s coefficient of variation, the ratio of its standard deviation to its mean, has a closed form for $\alpha > 2$ :

$$CV = \frac{1}{\sqrt{\alpha(\alpha-2)}}$$

At this series’ own $\alpha = 2.2$ , $CV \approx 1.51$ .

Finding. Blood Oath’s own duration distribution is more variable than the textbook “maximally unpredictable” baseline, not less.

An exponential distribution, the case queueing theory treats as its own no-memory, no-structure reference, has $CV = 1$ exactly, by definition.

That number describes the unconditional population, though, and Proposition 5b’s actual claim is about a narrower group: tasks that have already survived to somewhere near $t^*$ . The right quantity is the coefficient of variation of residual life at elapsed time $t$ , not of total duration, and the two aren’t the same object.

Regime	Residual-life CV	Why
$t < x_m$	rises from 1.51 toward 3.32	survival certain, so shifting $t$ moves the mean without touching variance: $CV(t)=\text{SD}(T)/(E[T]-t)$
$t \geq x_m$	flat at $\sqrt{\alpha/(\alpha-2)} \approx 3.32$	Pareto’s own scale-invariance: $T\mid T>t$ is again Pareto, now with scale $t$

Residual-life coefficient of variation by elapsed-time regime: the sparse long-tail survivors Proposition 5’s crossover draws from are more spread out than the unconditional population, strengthening the desynchronization case.

Pareto’s density is highest at $x_m$ and falls off from there, so the bulk of the population clusters near the low end. But the population Proposition 5’s crossover actually draws from, the sparse survivors past $t^* \approx 864$ s, is more spread out in relative terms than the aggregate $CV \approx 1.51$ figure suggested, not less. That’s a stronger, not weaker, structural case for desynchronization among voluntary-channel evictions than this post originally claimed.

This holds the same way for Proposition 5c. Ranking by descending $S(t)$ selects, for the reason given above, disproportionately from the high-$t$ end of this same curve: candidates near or past $t^*$ , where residual-life $CV$ sits at or near the flat $3.32$ figure that governs the deep survivors, rather than the lower, rising range in $[1.51, 3.32]$ that governs the early-elapsed-time majority. Trading $V(t)$ for descending $S(t)$ , made for a real and separate reason (transfer speed, not economics), doesn’t cost this protection the way the earlier, incorrect ascending rule would have. The emergency channel’s candidates end up about as heterogeneous, on this specific axis, as the ones the voluntary channel would have picked, because both rankings draw from the same long-elapsed-time tail for the same underlying reason: one directly, since $V(t)$ grows with elapsed time, the other by strong correlation, since $S(t)$ does too. This isn’t a guarantee at every instant, for the same reason named above: $S(t)$ and elapsed time aren’t identical. But it means the ranking correction, made purely for speed, doesn’t carry the additional desynchronization cost an earlier version of this argument found.

A separate, narrower caveat still stands on its own: neither $CV \approx 1.51$ nor its $3.32$ residual-life counterpart is something a real deployment could cheaply confirm from its own traffic. Because $\alpha=2.2 < 4$ , the distribution’s fourth moment is infinite, and the sample coefficient of variation converges to its true value very slowly, dominated by rare extreme draws. A team trying to verify “my own traffic actually has $CV$ this high” from a real trace should expect the empirical figure to underestimate the true value substantially, even at millions of observations, and should not treat a measured shortfall as evidence the theoretical argument is wrong. It is still not the same thing as checking this specimen’s own arrival-and-duration process against Ao et al.’s precise desynchronization condition, which the paper states for its specific coprime-length construction, not for a general class of high-$CV$ distributions. A high coefficient of variation is necessary-looking evidence for the kind of spread that condition needs; it is not, on its own, a demonstration that this specimen’s spread takes the specific form the paper’s own proof requires. That gap is named here precisely so neither number gets mistaken, on a second reading, for having closed it.

Watch out for: treating Proposition 5b’s structural argument as though it closes the question Proposition 5 opened. It doesn’t. The temptation to read “heavy tails help” as “heavy tails are enough” is exactly the kind of shortcut this series has spent three posts warning against taking on faith. Proposition 5 alone answers whether a single eviction is worth its cost; nothing about it says the resulting policy is stable at scale. Proposition 5b alone gives a structural reason for optimism about that stability; nothing about it is a proof. Both are required, together, before “eviction is the right mechanism for a checkpointable population” is a conclusion this series is actually entitled to, rather than one theorem doing the rhetorical work of two.

Does This Pool Actually Have the Heterogeneity It’s Leaning On?

Proposition 5b’s whole structural argument rests on one assumption worth checking rather than inheriting silently: that the checkpointable sub-population carries the same heavy-tailed spread the full pool does. That’s not guaranteed by definition. There’s a real, specific reason it might not hold. Checkpointability is a property of a task’s infrastructure, not of its duration, but the two aren’t necessarily independent in a real deployment. If the workloads an operator chooses to make checkpointable in the first place, because they’re the ones expected to run long enough for eviction to matter, skew toward a narrower duration profile than the pool as a whole, restricting to “checkpointable tasks” could itself select a more synchronized, more resonance-prone sub-population than the one Posts 1 through 3 analyzed. That would be exactly backward from what this post needs to be true.

Put a concrete shape on the worry rather than leaving it abstract. Suppose an operator’s actual policy is “make checkpointing available only past some minimum expected duration,” a reasonable-sounding engineering rule, since checkpointing infrastructure has its own fixed cost to build and isn’t worth paying for tasks that finish in milliseconds anyway. That rule, applied naively, truncates the left tail of the duration distribution feeding this post’s own population: every checkpointable task, by construction, already ran long enough to clear the operator’s own minimum-duration bar before checkpointing was even switched on for it. A truncated Pareto distribution has a smaller coefficient of variation than the untruncated version Proposition 5b’s $CV \approx 1.51$ was computed against, precisely because truncating the short end removes exactly the mass that made the untruncated distribution so spread out relative to its own mean. This post has not computed how much smaller, because it depends on where the truncation point sits relative to $x_m$ , an operator-specific choice this post has no way to know in advance. What it can say is the direction of the effect. That direction is the one Proposition 5b needs to not be true.

This is not a settled question, and it shouldn’t be presented as one. It’s a real, checkable empirical question about a real deployment’s own task-classification policy, not a property of the mathematics this post has derived. A team running this mechanism has a concrete, cheap check available before trusting Proposition 5b’s structural argument: measure the tail index of the checkpointable sub-population specifically, using the same Hill-estimator approach Post 2 already priced, rather than assuming it inherits the full pool’s $\alpha = 2.2$ by default. If the checkpointable slice turns out to have a lighter, more clustered duration distribution than the pool as a whole, Proposition 5b’s own structural defense weakens or disappears. A team in that position should weight the honest gap named above more heavily, not less, before running eviction as a standing policy at scale.

That measurement itself has a trap this post hasn’t named: the same mechanism built to escape one censoring gap has a censoring problem of its own. A Hill estimator needs real observations of how long tasks actually run, out to the true extreme. Proposition 5’s own crossover exists specifically to remove tasks from observation once they cross $t^*$ : an evicted task’s own remaining duration, on the node that was measuring it, simply stops there. Feed that truncated record into a standard Hill estimator and it reads the absence of extreme durations as evidence of a lighter tail than the population actually has, since it never sees what would have happened past the point eviction cut it off. A falsely inflated $\alpha$ pushes $t^*$ further out, $t^* = c_0(\alpha-1)/c_{\text{opp}}$ rises directly with $\alpha$ , which changes how much of the tail gets truncated on the next round of measurement too. Whether that self-referential loop converges or compounds is a question this post hasn’t checked either way. The fix is the same shape as the one this post already applied to $\hat{\lambda}$ ’s own re-admission bias above, not a new discipline: either track a checkpointable task’s true duration end to end, stitching its pre-eviction and post-eviction segments into one observation regardless of which node it finishes on, or fit the Hill estimator against the right-censored data directly, using a survival-analysis variant built for exactly that case rather than the plain estimator this series uses everywhere else. Measuring $\alpha$ on a population actively being evicted by threshold, then feeding that number back into the same threshold, is not a loop this post has verified is safe to run unmodified.

What Real Systems Already Decide This Way

vLLM’s own PagedAttention design already forces production serving engines to make a recompute-or-swap decision when memory pressure evicts a running sequence. It’s worth checking what actually governs that decision, rather than assuming it matches this post’s own variable [6] . Once an evicted sequence gets re-admitted, the engine can either swap its paged KV-cache blocks back in from wherever they were relocated, or discard them and recompute the sequence’s cache from scratch. The paper’s own reported result is precise about what drives the choice, and it isn’t a sequence’s elapsed progress or how much compute is sunk into it. Recomputation is more efficient at small block sizes, swapping is more efficient at large ones, with recomputation overhead never exceeding roughly 20% of swapping’s latency regardless: a real system tuning parameter, decided once for the deployment, not a per-task, per-eviction decision the way Proposition 5’s crossover is. That’s a real, useful data point about how a genuinely deployed system reasons about the same underlying tradeoff (relocate accumulated state versus rebuild it). But it’s evidence for a different decision variable than this post’s own $t$ , not a direct precedent for Proposition 5’s specific per-task crossover rule, and this post shouldn’t imply otherwise.

That correction also sharpens a real simplification in this post’s own model, worth naming rather than smoothing over. PagedAttention’s actual granularity is the block, not the whole task: a running sequence’s cache lives in many small, independently pageable blocks. Definition 5a’s frontier and Proposition 5’s crossover rule both price a task’s accumulated state as a single scalar $S(t)$ , treating an eviction decision as all-or-nothing per task. A production implementation built on block-level paging has a cheaper-looking option this post hasn’t priced: evict only the oldest blocks of a task’s cache rather than the whole thing, trading a smaller relocation cost against a partial, rather than total, loss of accumulated work. Per the paper’s own finding above, the swap-versus-recompute choice for those individual blocks would itself be governed by block size, not by how far into Proposition 5’s own crossover the task has run.

Cheaper-looking, not cheaper, and worth stopping on rather than filing as a footnote: block-level eviction that discards rather than relocates the oldest blocks doesn’t just lose a partial amount of accumulated work. It breaks this specimen’s own strict prefill/decode separation the moment the task resumes. Self-attention needs the KV cache for every prior token still in context to generate the next one. A task whose oldest blocks were discarded, not swapped, has no path back to correct generation without reconstructing them, and reconstructing a block of KV cache from its own token IDs means running those tokens through the model again: a multi-token forward pass over already-known content, which is what prefill is, not what a decode node’s own hardware is provisioned to do at any real volume. If that reconstruction runs on the decode node itself, it’s chunked-prefill in every way that matters, the exact coupling Definition 4a’s separable-regions claim excludes by name, and it needs the same joint-frontier re-derivation this post already requires before trusting Definition 4’s per-resource mechanism under real chunked-prefill. If it runs by shipping the task back to a prefill node instead, the relocation this option was supposed to make cheaper is now a full prefill-side reconstruction plus a second handoff, closer to Definition 1’s own KV-cache-handoff cost than to a fraction of $C_{\text{evict}}(S)$ . Either way, “smaller relocation cost” describes the transfer alone, not what resuming the task actually costs once the missing blocks have to come back from somewhere. That finer-grained version of Proposition 5 is a real, well-motivated extension this post’s single-scalar $S(t)$ doesn’t capture, but it isn’t free the way this section’s opening framing suggests, named here as a limitation rather than folded quietly into the next section as an afterthought.

Would a Fleet-Wide Eviction Coordinator Beat Proposition 5c’s Local Ranking?

Proposition 5c’s ranking rule is entirely local: each node ranks its own candidates by descending $S(t)$ , blind to what any other node is doing. The natural question: would a coordinator with a fleet-wide view of every node’s candidate population make a strictly better emergency-eviction decision?

For the decision Proposition 5c actually makes, the honest answer is no. The reason is physical, not architectural. Eviction relieves memory pressure on exactly the node the evicted task was running on: freeing bytes on node B does nothing for node A’s own redline breach. A fleet-wide coordinator can see every node’s own candidates, but it can’t spend node B’s memory to pay node A’s debt; the two headroom pools don’t share a budget the way a genuinely pooled, fleet-wide reserve would. Whatever a coordinator adds here, it isn’t a better choice of which task to evict on a given node. Proposition 5c’s own descending-$S(t)$ rule is already the right local answer, established above, and no amount of fleet-wide visibility changes what maximizes relief-per-second on a node in genuine trouble.

There is a real place fleet-wide coordination could help, and it’s a different question than the one Proposition 5c answers. Not which task, but when, across nodes sharing physical fabric. A single upstream trigger can plausibly push a heavy-task surge across many nodes at once, not just one. If several nodes independently breach their own redlines close together, each running its own local emergency channel with no knowledge of the others, $k$ concurrent relocations from node A and $k$ more from node B can converge on the same shared upstream fabric (the top-of-rack switch, the spine link) at the same moment. That doubles the incast this post’s own $k=32$ -on-one-node PFC-storm analysis priced, and scales the same way, roughly linearly, with however many more nodes than two fire together. A real deployment where a correlated surge trips redlines on ten nodes at once, not an exotic count for the kind of single upstream trigger this series has already priced elsewhere, sees an order of magnitude past the single-node figure, not just double. That’s a real gap this post’s own per-node model structurally can’t see: it prices contention within one node’s own emergency wave, never contention across several nodes’ waves landing on shared fabric simultaneously. A coordinator with visibility into which nodes are about to fire their own emergency channels could stagger them, the same pacing problem, one level up, that a single node’s own credited-headroom projection ($\hat{H}_{\text{mem}}(t)$ ) already solves within one node. Whether that coordination is worth building, against what it costs to run, a single point every node’s own emergency channel now has to check in with before firing, is a real tradeoff this post names rather than resolves.

Model Scope and Failure Envelope

Eleven assumptions are doing real work in this post and deserve the same naming Posts 1 through 3 gave their own.

#	Assumption	What it threatens	Status
1	$m(t)$ is monotonic (single Pareto population)	Undermines the crossover for one task, before population scale	Highest priority, unresolved
2	Checked against this post’s own prices	Confirms #1 concretely: crosses threshold 4 times, $t$ =150-1300s	Reproduced with real numbers
3	#1 is a prerequisite to the two gaps below it	Neither #6 nor #8 is worth trusting until #1 is checked	Structural ordering
4	$m(t)$ stays untruncated (no hard ceiling $L$ )	Reopens a second crossing, from the opposite direction of #1	Unresolved, distinct from #1
5	$c_{\text{opp}}, c_0$ are illustrative, not measured	The specific $t^*\approx864$ s isn’t load-bearing	Priced: the shape survives re-pricing
6	No repeated-batch resonance in the emergency channel	Whether freed memory re-triggers the next breach	Unfinished, second priority
7	Descending $S(t)$ isn’t gamed	Emergency channel’s own effectiveness, not the voluntary channel	Named, unchecked empirically
8	Voluntary channel’s stability holds under this specimen’s real arrivals, not just its durations	Proposition 5b’s argument is structural, not a proof	Unfinished, third priority
9	$c_0$ fully captures resume-side cost	May undercount cache-locality and warm-up cost on the destination	Named, treat $C_{\text{evict}}$ as a lower bound
10	The destination’s own opportunity cost is zero	$V(t)=m(t)\cdot c_{\text{opp}} - C_{\text{evict}}(S)$ treats eviction as fully recovering $m(t)\cdot c_{\text{opp}}$ , but the task still runs its remaining $m(t)$ seconds somewhere	Named here, unpriced everywhere in this post
11	The relocation link is uncontended	$k=32$ concurrent transfers share bandwidth, and can collapse non-linearly under PFC	Partially priced below, partially open
12	$c_{\text{opp}}$ is priced at the rental rate, not the shadow price of admission foregone	This pool runs persistently close to its own memory ceiling, not in an uncongested equilibrium	Named, unpriced, distinct from #10

Twelve assumption boundaries this post depends on, numbered in the order the paragraphs below name them, not in strict priority: priority is stated explicitly where it matters (#1 above #6 above #8).

Every well-behaved-crossover check in this post, referenced repeatedly below, reduces to the same condition:

$$c_0 > E[S_h] \cdot c_{\text{opp}}$$

Get the price ratio wrong and what breaks isn’t the crossover’s timing, it’s its existence: a second, early-eviction zone opens up instead of the single clean threshold this post presents.

The well-behaved-crossover check above verifies a single crossing exists given that $m(t)$ is monotonic past $x_m$ . It does not verify that assumption itself. This is the one gap that undermines the voluntary rule for a single task in isolation, before any population-scale question is even asked. Post 1’s own Model Scope names the underlying risk: the heavy class this whole series builds on is assumed to be one clean Pareto population. A real fleet’s own “heavy” traffic is often a mixture of genuinely distinct workload types (different tenants, batch jobs, agentic loops), each with its own comparatively narrow characteristic duration. Post 1 works a three-component mixture where mean residual life reverses direction four times rather than settling into the clean fall-then-rise Proposition 2b’s formula assumes. Checking for this in production isn’t a one-time verification either: a workload mix drifts, and confirming the heavy class still looks unimodal is exactly the kind of ongoing engineering burden this series doesn’t put a price on until several posts from now.

Checked against this post’s own prices, not just Post 1’s illustrative ones. The eviction threshold is $c_0/c_{\text{opp}} = 0.50/0.000694 \approx 720$ : a value the same mixture’s mean residual life crosses four separate times between $t=150$ s and $t=1{,}300$ s (continue, evict, continue, evict, continue), not once. A task governed by that trajectory would be marked for eviction, left running because the ranked list was already clear, re-marked, and un-marked again, the exact control-loop thrashing a badly-behaved hazard rate predicts, reproduced with this post’s own numbers rather than left as a hypothetical.

Priority: this is the single highest-priority gap this post leaves standing, ahead of both gaps named below: it’s a prerequisite, not a peer. The emergency channel’s own batching risk and Proposition 5b’s population-scale argument both assume $m(t)$ behaves the way a clean Pareto tail predicts. Neither one is worth trusting until that assumption is actually checked against real data. Every other assumption in this section, and Proposition 5b’s whole stability argument, presupposes this one holds. If a real fleet’s heavy traffic doesn’t pass a multimodal check against its own empirical duration distribution (the same check Post 2’s Model Scope now asks for) this post’s crossover rule should be applied per workload segment, not to an unexamined aggregate, or it inherits a failure mode no amount of correctly-priced $c_{\text{opp}}$ and $c_0$ can fix.

A team following Post 3’s own remedy for $\alpha \leq 2$ inherits a second monotonicity break this post has never named, distinct from the mixture-hazard one above. Post 3’s own Vector Sedimentation proof requires a hard ceiling $L$ on $S_r$ whenever a real deployment’s measured tail index falls at or below 2, since the untruncated second moment diverges otherwise. This post’s own crossover, built on $m(t) = t/(\alpha-1)$ rising without bound past $x_m$ , assumes exactly the untruncated tail Post 3’s own remedy removes. A task can’t survive past $L$ , so residual life under truncation can’t keep rising toward $t=L$ : it has to fall back toward zero as the ceiling approaches, the same certain-survival logic that makes $m(t)$ fall on $[0, x_m)$ in the untruncated case, mirrored at the opposite end. That reopens a second crossing this post’s own well-behaved-crossover check was built specifically to rule out, and not merely as a possibility worth flagging. $C_{\text{evict}}(S(t))$ stays bounded below by $c_0 > 0$ for every $t$ , while $m(t) \cdot c_{\text{opp}} \to 0$ as $t \to L$ . So $V(t)$ is forced back below zero before the ceiling, for certain, the moment any point past $x_m$ clears the threshold at all: a task nearing $L$ simply has too little remaining opportunity cost left to protect. The single, permanent crossing Proposition 5 proves is a property of the untruncated tail specifically, not something this post re-derives for the truncated case Post 3 actually prescribes. A team whose own measured $\alpha$ sits at or below 2, and who has therefore imposed Post 3’s own hard cap, should not reuse Proposition 5’s crossover as stated: $m(t)$ needs to be re-derived against the truncated distribution first, and the well-behaved-crossover check re-run against whatever shape that produces, which may no longer be a single clean threshold at all.

$c_{\text{opp}}$ and $c_0$ are illustrative, grounded order-of-magnitude figures, not measured production costs. The transfer-time component of $C_{\text{evict}}$ is priced against a real ConnectX-7 bandwidth figure this series has already used once, and that piece of the arithmetic is load-bearing and defensible as stated. The GPU-hour opportunity cost and the fixed relocation overhead are not pinned to a citation the way the bandwidth is, the same discipline Post 3 applied to its own per-token streaming-overhead estimate. And $c_0$ carries an additional obligation this post’s numbers don’t get to skip: it has to exceed $E[S_h]\cdot c_{\text{opp}}$ , or the crossover degenerates into a second, early-eviction zone rather than the single clean threshold this section presents. What survives a change to either number, provided that check still passes, is the shape of Proposition 5’s result (eviction as a rare-outlier remedy, multiples of $E[S_h]$ out) not the specific value $t^* \approx 864$ s. A team with real, measured cloud pricing and a real, measured control-plane overhead should re-run this post’s arithmetic, including the well-behaved-crossover check, against its own numbers before trusting the specific crossover time on a different deployment.

Proposition 5c’s emergency channel has a structural desynchronization argument after all, not none. It’s established above, where descending $S(t)$ was shown to draw from exactly the same long-tail population Proposition 5b’s argument covers. That argument covers a single batch, not repeated ones, and closing that gap is unfinished work this post leaves standing, behind only the more basic mixture-hazard question named above. A ranked, multi-task eviction triggered by one redline breach is a designed batch, not a coincidental one. Proposition 5b’s heavy-tail argument was built to explain away coincidental clustering in individually-timed voluntary evictions. It was never built to rule out a repeated designed batch resonating with itself. Whether emergency breaches can do that, freed memory admitting a batch that grows into the next breach, evicted in its own wave, is still open. It’s worth flagging here specifically rather than trusting the single-batch result above to have settled it: the two are different claims, and only the first one has an argument behind it.

A rule stated precisely enough to implement is also precise enough to game, and descending $S(t)$ is exactly that kind of rule. It’s a real behavioral-drift risk distinct from the general non-adversarial boundary named elsewhere in this series, because it targets this post’s own mechanism specifically rather than admission in general. Every other adversarial gap this series has named is about a tenant misrepresenting demand to avoid demotion, gaming Definition 1b’s classifier, or Definition 4’s per-resource redline. Proposition 5c creates a narrower, sharper target: once a ranking rule that reaches for the largest $S(t)$ first is known, published, reverse-engineered from observed eviction patterns, or simply the obvious design once “emergency eviction” is mentioned, a rational client, with no adversarial intent at all, has a direct incentive to keep any single request’s own accumulated state below whatever an emergency sweep is likely to reach.

The mechanism. Chunking a long generation into several shorter ones, resumed across separate requests, does exactly that: no request in the chain individually presents a large $S(t)$ to the ranking rule, even though the aggregate work is the same or larger. This is a Goodhart-style failure specifically, not a repeat of the demand-gaming gap already named. The measure $S(t)$ was chosen because it correlates with how much relief an eviction buys, and a population that reorganizes itself around dodging that specific measure breaks the correlation between “high $S(t)$ candidates exist to evict” and “evicting them actually relieves pressure,” which is the premise the whole ranking rule stands on.

What this doesn’t threaten. Proposition 5’s own voluntary crossover, driven by $m(t)$ and each task’s own economics rather than a published ranking order, gives a rational client nothing obvious to game, since dodging it costs the client nothing but also buys nothing: voluntary eviction never touches a task that hasn’t individually crossed $t^*$ .

What it does threaten: specifically the emergency channel’s own effectiveness. A population that has learned to stay chunked below the ranking’s own reach is a population Proposition 5c’s descending-$S(t)$ selection has nothing left to select from. It forces the rule down toward Definition 1b’s own confidence floor into ordinary traffic, for exactly the near-zero relief this post’s own fixed-overhead argument already showed is the worst case, not the exception. Whether real client behavior actually drifts this way is an empirical question this post hasn’t checked, the same honest limit as every other behavioral assumption named here. But it’s worth naming specifically, rather than folded into the general non-adversarial boundary, because unlike that boundary this one doesn’t require a strategic actor to trigger. An ordinary engineering team chunking long-running jobs for unrelated reasons (retry safety, progress checkpointing) produces the same effect without ever intending to game anything.

Proposition 5b’s own stability argument, for the voluntary channel, has not been checked against this specimen’s actual arrival process, only its duration distribution. Ao et al.’s own instability result depends on the joint behavior of admissions and evictions over time, not just on how spread out individual task durations are. This post has argued that a heavy-tailed duration distribution gives a structural reason to expect desynchronized completions; it has not simulated or analytically verified that this specimen’s own arrival pattern, layered on top of that duration distribution, actually avoids the resonance the cited paper proves possible. That gap is named above and repeated here because it is real, unfinished work: third in priority, behind both the mixture-hazard question and the emergency-channel gap, not because it matters less in absolute terms, but because the voluntary channel at least has a structural argument to lean on while it’s resolved.

Checkpoint-and-resume cost is only partly captured by $C_{\text{evict}}(S)$ ’s fixed overhead. $c_0$ ’s $0.50 is deliberately priced to include a modest allowance for the resuming side (destination warm-up, re-attachment) rather than charging nothing there. But “modest allowance” is doing real work in that sentence. A relocated task that resumes on a different accelerator may pay a larger real cost this post hasn’t fully priced: cache-locality effects, contention with whatever else is already running on the destination, or warm-up time well beyond a flat per-eviction estimate. Definition 5a’s frontier, and Proposition 5’s crossover rule built on it, price the cost of moving a task with a single fixed number, not a cost that itself depends on destination-side conditions. A deployment where the resuming side’s cost is significant, and variable, relative to this post’s flat $c_0$ should treat $C_{\text{evict}}(S)$ as a lower bound, not a complete accounting. It should re-check the well-behaved-crossover condition from Proposition 5 against its own, larger $c_0$ , not assume it still holds.

A more fundamental gap than the resume-side cost above: $V(t)$ prices only the source’s own ledger, never the destination’s. $V(t) = m(t) \cdot c_{\text{opp}} - C_{\text{evict}}(S(t))$ treats evicting a task as recovering its entire expected remaining opportunity cost, $m(t) \cdot c_{\text{opp}}$ , in full. But a relocated task doesn’t stop consuming resources. It keeps running its own remaining $m(t)$ seconds somewhere, on whatever node it lands on. If that destination has a genuinely idle slot the fleet would otherwise waste, the source’s own opportunity cost really is recovered net, since the destination was paying nothing for that capacity anyway. If the destination has to give up capacity it would otherwise have used for something else, and most fleets running close enough to a redline to trigger eviction in the first place aren’t sitting on free capacity, the true net benefit is smaller: the source’s own $m(t)\cdot c_{\text{opp}}$ avoided, minus whatever opportunity cost the destination now incurs holding the same task for the same remaining time, minus $C_{\text{evict}}(S)$ . In the limit where the destination’s own opportunity cost equals the source’s, evicting buys nothing at all beyond the relocation fee itself, since the task’s own remaining cost was never eliminated, only moved. $V(t)>0$ as stated is the right rule exactly when the destination is meaningfully cheaper than the source. That’s an assumption this post has never stated, and Proposition 5c’s own routing (send relocations toward whichever node has headroom) makes plausible but doesn’t prove: a node with headroom isn’t necessarily a node with zero opportunity cost for the capacity it’s about to spend.

A separate, more basic gap sits underneath both of the ones above: $c_{\text{opp}}$ itself is priced as if the source’s own accelerator were an uncongested resource, freely rentable at a fixed market rate, when this post’s own specimen is nowhere close to that. $c_{\text{opp}}$ ’s $\$2.50$ /hour is an on-demand cloud rental figure: what the accelerator would cost to rent on an open, uncongested market. That’s the right price for “holding this resource” only when the alternative use of the freed capacity is itself worth roughly that much, the ordinary case for a spot market with slack in it. Post 3’s own numbers say this pool doesn’t have that slack: memory utilization at the Sedimentation Threshold runs at 278.7% of budget, and even at this specimen’s own resting baseline the pool sits at 64.6% of raw capacity with a redline crossed well before that. A resource this scarce has a shadow price, the value of the admission a freed slot could actually serve, not a rental-market price, and nothing says the two coincide. Worth being precise about where this does and doesn’t bite: it’s a claim about Proposition 5’s own voluntary channel, priced continuously against ordinary, non-emergency conditions, not about Proposition 5c’s emergency channel, which never references $c_{\text{opp}}$ or $V(t)$ at all, ranking by $S(t)$ and a hard $T_{\text{OOM}}(t)$ deadline instead, precisely because per-task economics don’t apply once a redline has actually breached. A shadow-priced $c_{\text{opp}}$ would move $t^*$ closer, by the same linear relationship the earlier sensitivity check already established: a higher $c_{\text{opp}}$ shrinks the crossover proportionally. Whether the shape of this post’s finding, eviction as a rare-outlier remedy rather than a routine one, survives that repricing is a question this post hasn’t run, since it depends on how large the true shadow price actually is relative to the rental figure, not on whether shadow pricing applies at all. A team pricing this mechanism against a genuinely scarce pool should treat $c_{\text{opp}}$ as a shadow price to be estimated from admission-refusal data, not assumed from a cloud rate card, and re-run the well-behaved-crossover check against whatever that repricing produces.

$C_{\text{evict}}(S)$ assumes uncontended access to the relocation link, and this is now checked rather than left as an open question: with a real, narrower finding than a first guess suggests. The 25GB/s ConnectX-7 figure pricing the transfer-time term is a per-port number, available in full to a single relocation happening in isolation. Proposition 5c’s own emergency channel is exactly the mechanism that breaks that isolation on purpose, evicting several tasks concurrently in response to one redline breach. So $k$ concurrent relocations sharing the same link, each seeing $B/k$ instead of $B$ , is the realistic case to check, not a hypothetical.

Quantity	at $k=1$	at $k=32$ (full pool)
$t^*$ (dollar-cost crossover)	864.2s	870.6s: a 0.7% shift
Transfer time	0.17s	5.5s

Link contention across a $k=32$ concurrent eviction wave: the dollar-cost crossover barely moves, but transfer time stretches from 0.17s to 5.5s.

Design Guardrail. The dollar-cost crossover is robust to contention. Transfer time is not.

It would need $k\approx4{,}200$ concurrent evictions sharing one link before the transfer term rivaled $c_0$ at all. But transfer time, not transfer cost, scales linearly with $k$ the same way. That’s not destabilizing feedback on $t^*$ , but it is a real, previously-unquantified delay between “eviction triggered” and “memory actually freed,” landing specifically on Proposition 5c’s own emergency channel at the exact moment a node is most stressed. A team running a full-pool eviction wave should expect the last relocation in that wave to complete several seconds after the first, not simultaneously, and should size the redline’s own margin, $H_{\min}^{\text{mem}}$ , to absorb that delay rather than assume relief is instantaneous once Proposition 5c fires.

The $B/k$ fair-share model is itself an idealization the 5.5-second figure inherits without checking. The direction of the error is the wrong one to be casual about. Equal division of link bandwidth across $k$ concurrent flows assumes the network fabric multiplexes them costlessly. A real RDMA fabric running RoCEv2 doesn’t: it depends on Priority Flow Control, a lossless-delivery mechanism that pauses an entire upstream link rather than dropping packets when a receiving buffer fills. A real, documented production failure mode of that mechanism is exactly the many-to-one pattern Proposition 5c’s own emergency channel creates on purpose: $k$ relocations converging on however many destination nodes have headroom, at the same moment, is textbook incast. Microsoft’s own production RDMA deployment work names the resulting pathology directly: PFC pause frames propagating upstream from a congested receiver can cascade into a pause-frame storm, and under the wrong traffic pattern, into deadlock [7] . That’s a materially different failure shape than $B/k$ describes: not a graceful, linear slowdown as $k$ grows, but a control-plane-level collapse triggered by the pattern of concurrent transfers, not just their count. Whether this specimen’s own $k=32$ emergency wave, run against real fabric hardware rather than this post’s own uncontended-link arithmetic, stays inside the region where $B/k$ is a reasonable approximation, or crosses into the PFC-storm regime the cited work documents, is a question about a specific deployment’s own switch buffering, traffic-class configuration, and congestion-control settings. It’s not one this post’s own symbolic model has the inputs to answer. A team running this mechanism on a lossless RDMA fabric should treat the 5.5-second figure as a floor, not an estimate, and should check its own fabric’s incast behavior under a synthetic $k=32$ burst before trusting $\hat{H}_{\text{mem}}(t)$ ’s own projection to hold at the exact moment it matters most.

One more assumption inside $\delta_0$ itself has never been checked: whether it’s actually $k$ -independent. This post treats $\delta_0$ as a fixed, per-eviction control-plane cost, the same figure whether one relocation is running or thirty-two. That holds only if the relocation link’s own RDMA queue pairs are already established and reused across evictions. If they aren’t, each new relocation pays a real connection-setup cost, queue-pair creation and path negotiation, before the first byte moves: a cost the $B/k$ model and the PFC-storm correction above both fold silently into $\delta_0$ ’s own illustrative $\$0.50$ without checking whether it’s actually there. This risk cuts the opposite direction from the PFC-storm risk above. Pause-frame storms are a large-$k$ problem; connection setup is a small-$k$ one, since a queue pair, once established, amortizes across every later relocation that reuses it. The danger is sharpest for the very first eviction in a wave, or for infrastructure that tears connections down between waves rather than pooling them. A team implementing this mechanism should check whether its own relocation transport reuses connections across evictions or re-establishes one per transfer, and price the difference into $\delta_0$ directly rather than assume the illustrative figure already accounts for it.

The $B/k$ model, and the PFC-storm correction to it, both price contention on the transfer link. Neither prices whether the same contention reaches back into $\sigma$ itself, the generation rate of the survivors an emergency wave exists to protect. This post treats $\sigma$ and $B$ as drawing from separate budgets throughout, the entire premise Post 3’s own disaggregated architecture was built on: a dedicated ConnectX-7 port for relocation, distinct from the GPU compute that drives decode. On hardware where that separation genuinely holds, the credited-headroom projection $\hat{H}_{\text{mem}}(t)$ is safe to treat $\sigma$ as constant through an emergency wave, exactly as this post does. It doesn’t hold unconditionally. A real server’s own PCIe topology can put the relocation NIC and the accelerators driving decode behind a shared root complex or a shared memory controller. A $k=32$ relocation wave saturating that shared resource degrades both sides of the same contention at once. $T_{\text{wait}}$ stretches, the way the PFC-storm discussion above already prices. $\sigma$ for every surviving task on that host can fall at the same time, for the same underlying reason. $\hat{H}_{\text{mem}}(t)$ ’s own projection term, $\sigma \cdot N_{\text{survivors}}(t) \cdot T_{\text{wait}}(t)$ , treats $\sigma$ as a constant multiplied against a $T_{\text{wait}}$ that’s already inflated by contention. A $\sigma$ that’s simultaneously falling under the same contention makes that product wrong in a direction this post hasn’t checked, not obviously conservative and not obviously the reverse. A team whose own hardware shares PCIe lanes or a memory controller between the relocation NIC and decode compute should measure whether $\sigma$ actually holds steady under a synthetic $k=32$ burst before trusting this projection at all, the same discipline this section already asks for $T_{\text{wait}}$ .

Compute it. Before running any eviction rule against a real checkpointable population, work through these in order.

• Is there a mechanism for what happens when a redline breach isn’t relieved by any task individually clearing Proposition 5’s own crossover? That state is not rare, it’s the expected case, given fewer than 3% of heavy tasks ever reach $t^*$ . If the only eviction logic in the system is Proposition 5’s voluntary rule with no Proposition-5c-style emergency fallback wired to the actual redline signal, the system has the same gap this post just fixed: it goes silent exactly when pressure is real.
• Is the population actually one, in the strict sense Definition 5a needs? Can accumulated state genuinely be serialized and relocated at a finite, computable cost, or is “checkpointable” a label applied to a workload nobody has actually tested a real eviction-and-resume cycle against? If it hasn’t been tested, treat every number in this post as conditional on infrastructure that doesn’t exist yet.
• If it has been tested, price both sides of Proposition 5’s rule against your own real numbers, not this post’s illustrative GPU-hour rate and fixed overhead, and check the well-behaved-crossover condition ($c_0 > E[S_h]\cdot c_{\text{opp}}$ ) first, since with the wrong price ratio the crossover’s existence, not just its timing, is what changes.
• If your own measured $\alpha$ sits at or below 2, and you’ve imposed Post 3’s own hard ceiling $L$ as a result, don’t reuse this post’s crossover as stated. Re-derive $m(t)$ against the truncated distribution first, since a single clean crossing is a property of the untruncated tail, not something this post proves survives a cap.
• If your own relocation NIC shares PCIe lanes or a memory controller with the accelerators driving decode, check whether $\sigma$ actually holds steady under a synthetic $k=32$ burst before trusting $\hat{H}_{\text{mem}}(t)$ ‘s own projection: this post prices contention on the transfer link, not contention that reaches back into the survivors’ own generation rate.
• Before running that rule as a standing policy rather than a one-off decision, measure your own population’s tail index the way Post 2’s Hill-estimator approach prescribes, specifically on the checkpointable subset, not the pool as a whole, since this post’s own open question is exactly whether that subset inherits the heterogeneity the argument leans on or quietly loses it. If the measured tail turns out lighter than $\alpha = 2.2$ , treat Proposition 5b’s structural defense as weaker in direct proportion, not as a fixed guarantee that survives any duration distribution.
• If none of this measurement has happened yet, the honest fallback isn’t “don’t evict.” It’s Blood Oath’s own answer, restated for a population that happens to have an escape hatch it hasn’t verified is safe to use: a policy nobody has checked for the specific failure mode a real, cited result proves possible is a policy running on faith, dressed in the vocabulary of a theorem it hasn’t actually earned.

Cognitive Map

1. Post 3 cited a real result and mostly set it aside: threshold-based eviction is provably unstable under saturated demand, a worst-case limit cycle costing up to 50% of throughput. Blood Oath’s non-preemptibility ruled the mechanism out by construction, not by choice.
2. This post studies the population Blood Oath excludes: checkpointable tasks, which keep ingress blindness but can actually be relocated at a real, finite cost rather than an architecturally prohibitive one.
3. Definition 5a builds the achievable-region frontier for a single, isolated eviction decision, explicitly scoped to say nothing yet about repeated application at population scale.
4. Proposition 5 prices both sides using numbers this series already earned: Proposition 2b’s corrected, piecewise mean residual life, Post 3’s KV-cache cost and decode rate, and, for the first time, Post 3’s own ConnectX-7 bandwidth figure. It finds a genuine crossover at roughly 864 seconds, nearly three times the mean heavy-task duration: eviction is a rare-outlier remedy, not a routine one, reached by fewer than 3% of heavy tasks.
5. This is the one place in the series the Constraint Sequence Framework runs backward: relaxing the property that excluded a face of the achievable region makes that face reachable again, for the narrower population that can afford to relax it.
6. Proposition 5, taken as the only eviction rule, has no term for the pool’s own state. It can say “evict nothing” while a redline is breached and admission-refusal alone can’t relieve it, since fewer than 3% of tasks ever individually justify eviction. Proposition 5c closes that gap with corrections to both which task and how fast the loop reacts. Rank by descending accumulated state, largest and most memory-heavy first, floored at Definition 1b’s confidence crossover so the rule can’t reach into ordinary light traffic for near-zero relief at full fixed cost, and capped by a real time-to-exhaustion deadline so the rule never picks a candidate whose own transfer wouldn’t land before the node fails outright. That’s rather than Proposition 5’s own economic comparison, since fixed per-eviction overhead means relief rate strictly increases with the size of what’s evicted, not the reverse. And evaluate the redline against a projected headroom: physical state, plus pending eviction credits, minus what surviving tasks will still consume before the slowest pending transfer lands, so neither a lagging transfer nor ongoing survivor growth triggers a cascade of unnecessary further evictions before relief actually arrives.
7. Every crossover rule in this post assumes the heavy class is one clean Pareto population. A real fleet’s heavy traffic is often a mixture of distinct workload types instead, and Post 1’s own worked three-component mixture shows what that does: mean residual life reverses direction four times rather than settling into a single fall-then-rise. Checked against this post’s own prices, that mixture crosses the eviction threshold ($\approx720$ ) four separate times between $t=150$ s and $t=1{,}300$ s: continue, evict, continue, evict, continue. This is the single highest-priority gap in the post, a prerequisite the other two below both assume away.
8. Proposition 5c’s own batching is a designed one, not a coincidental one, and its descending-state ranking draws from close to the same sparse long-tail survivors Proposition 5b’s desynchronization argument is about, by strong correlation rather than by construction. It inherits most of that argument’s protection, not none of it, though not as a proven guarantee. Closing that gap from correlation to proof is unfinished work this post names.
9. Proposition 5b gives a structural, heavy-tail-grounded reason to expect the voluntary channel avoids Post 3’s cited instability. The same argument Post 3 made for its own milder mechanism, now applied to the paper’s own literal subject: honestly short of a proof, and explicitly scoped to not cover the emergency channel.
10. That structural argument depends on the checkpointable sub-population actually inheriting the full pool’s heterogeneity, an assumption worth measuring, not assuming, since the classification itself could plausibly select against it.
11. Ao et al.’s own model evicts stateless tasks that restart from zero. This post’s population has memory gravity instead (an evicted task is owed its state back, not discarded), so a real limit cycle here is compounded by a second, return-trip transfer the cited paper’s model never has to price. That’s a cost channel this post names but doesn’t yet size a defense for beyond a penalization window on re-admission, one bounded from outside this post’s own accounting by a live client’s own timeout.
12. The $B/k$ fair-share model behind the 5.5-second $k=32$ transfer-time figure assumes costless multiplexing. Real RDMA fabrics running RoCEv2 depend on Priority Flow Control, whose own documented production failure mode (pause-frame storms triggered by exactly the many-to-one pattern an emergency eviction wave creates) collapses non-linearly rather than degrading linearly with $k$ . The 5.5-second figure should be read as a floor on real fabric hardware, not an estimate.
13. A team following Post 3’s own truncation remedy for $\alpha \leq 2$ breaks this post’s crossover proof from the opposite direction of the mixture-hazard gap: $m(t)$ can’t keep rising toward a hard ceiling $L$ , so it has to fall back toward zero as $t \to L$ , reopening a second crossing the well-behaved-crossover check was built to rule out. Proposition 5’s single, permanent crossing is a property of the untruncated tail specifically, unproven for the truncated case Post 3 actually prescribes.
14. $\hat{H}_{\text{mem}}(t)$ ‘s own projection prices contention on the transfer link; it doesn’t price contention that reaches back into $\sigma$ , the survivors’ own generation rate. Where the relocation NIC and decode compute share PCIe lanes or a memory controller, a $k=32$ wave can degrade both at once, and a falling $\sigma$ multiplied against an already-inflated $T_{\text{wait}}$ makes the projection wrong in a direction this post hasn’t checked.
15. Live re-sampling of $N_{\text{survivors}}(t)$ and $T_{\text{wait}}(t)$ corrects for ordinary estimation drift between ticks, not for a PFC-storm collapse, which jumps rather than drifts. Every tick before the one that observes the jump computed $\hat{H}_{\text{mem}}(t)$ against an estimate already wrong by orders of magnitude. That’s a one-tick lag whose real cost depends on the control loop’s own tick rate against how fast a real fabric can actually collapse, a comparison this post has never run.

---

^[1] Ao, R., Dong, J., Luo, G. & Simchi-Levi, D. (2026). Service-Induced Congestion in Memory-Constrained LLM Serving. arXiv:2606.15555.

^[2] NVIDIA (2021). ConnectX-7 InfiniBand Adapter Card Datasheet.

^[3] TrueFoundry (2024). Benchmarking Llama-2-70B.

^[4] Touvron, H. et al. (2023). Llama 2: Open Foundation and Fine-Tuned Chat Models. arXiv:2307.09288.

^[5] Motwani, R., Phillips, S. & Torng, E. (1994). Nonclairvoyant scheduling. Theoretical Computer Science, 130(1), 17–47.

^[6] Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C.H., Gonzalez, J.E., Zhang, H. & Stoica, I. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. Proceedings of the 29th Symposium on Operating Systems Principles (SOSP 2023).

^[7] Guo, C., Wu, H., Deng, Z., Soni, G., Ye, J., Padhye, J. & Lipshteyn, M. (2016). RDMA over Commodity Ethernet at Scale. Proceedings of the 2016 ACM SIGCOMM Conference, 202–215.

---

Back to top