PaperlayerView exact revision on arXiv

Source-linked AI summary

MinT: Managed Infrastructure for Training and Serving Millions of LLMs

Mind Lab, :, Song Cao, Vic Cao, Andrew Chen, Kaijie Chen, Cleon Cheng, Steven Chiang, Kaixuan Fan, Hera Feng, Huan Feng, Arthur Fu, Jun Gao, Hongquan Gu, Aaron Guan, Nolan Ho, Mutian Hong, Hailee Hou, Peixuan Hua, Charles Huang, Miles Jiang, Nora Jiang, Yuyi Jiang, Qiuyu Jin, Fancy Kong, Andrew Lei, Kyrie Lei, Alexy Li, Lucian Li, Ray Li, Theo Li, Zhihui Li, Jiayi Lin, Kairus Liu, Kieran Liu, Logan Liu, Xiang Liu, Irvine Lu, Maeve Luo, Runze Lv, Pony Ma, Verity Niu, Anson Qiu, Vincent Wang, Rio Yang, Maxwell Yao, Carrie Ye, Regis Ye, Wenlin Ye, Josh Ying, Danney Zeng, Yuhan Zhan, Anya Zhang, Di Zhang, Ruijia Zhang, Sueky Zhang, Ya Zhang, Wei Zhao, Ada Zhou, Changhai Zhou, Yuhua Zhou, Xinyue Zhu, Murphy Zhuang

arXiv:2605.13779v2cs.LGcs.AIcs.DC

TL;DR

Post-training now involves many policy variants over a few expensive base-model deployments, a setting where full-checkpoint workflows do not scale. MinT manages exported LoRA adapter revisions over resident bases, validating this path across three scaling axes, including measured handoff-step reductions of 18.3× on a 4B dense model and 2.85× on a 30B MoE.

  • Problem

    Post-training must manage many policy variants over few expensive base deployments, while full-checkpoint workflows do not scale to continuously changing populations of trained behaviors.

    Source: §7 · p. 22

  • Method

    MinT makes exported LoRA adapter revisions the managed unit, keeping base-model deployments resident as revisions move through post-training and serving.

    Source: §7 · p. 22

  • Results

    18.3× on a 4B dense model and 2.85× on a 30B MoE are the measured handoff-step reductions; MinT validates its adapter-revision path across Scale Up, Down, and Out.

    Source: §7 · p. 22

  • Takeaways & Limitations

    The results support LoRA as a service-level unit for large-scale post-training over shared 1T-class base models.

    Source: §7 · p. 22

    MinT currently lacks replay for every DSA indexer selection and does not reconstruct the exact sparse-attention token set selected by the inference engine.

    Source: §2 · p. 5

Abstract

from arXiv · show

We present MindLab Toolkit (MinT), a managed infrastructure system for Low-Rank Adaptation (LoRA) post-training and online serving. MinT targets a setting where many trained policies are produced over a small number of expensive base-model deployments. Instead of materializing each policy as a merged full checkpoint, MinT keeps the base model resident and moves exported LoRA adapter revisions through rollout, update, export, evaluation, serving, and rollback, hiding distributed training, serving, scheduling, and data movement behind a service interface. MinT scales this path along three axes. Scale Up extends LoRA RL to frontier-scale dense and MoE architectures, including MLA and DSA attention paths, with training and serving validated beyond 1T total parameters. Scale Down moves only the exported LoRA adapter, which can be under 1% of base-model size in rank-1 settings; adapter-only handoff reduces the measured step by 18.3x on a 4B dense model and 2.85x on a 30B MoE, while concurrent multi-policy GRPO shortens wall time by 1.77x and 1.45x without raising peak memory. Scale Out separates durable policy addressability from CPU/GPU working sets: a tensor-parallel deployment supports 10^6-scale addressable catalogs (measured single-engine sweeps through 100K) and thousand-adapter active waves at cluster scale, with cold loading treated as scheduled service work and packed MoE LoRA tensors improving live engine loading by 8.5-8.7x. MinT thus manages million-scale LoRA policy catalogs while training and serving selected adapter revisions over shared 1T-class base models.

1 Introduction

MinT keeps base models resident and manages evolving LoRA adapter revisions across post-training and serving, avoiding repeated full-checkpoint transfers. It targets the growing infrastructure demands of post-training with a shared-base workflow spanning training, evaluation, deployment, and rollback.

Adapter-centered workflow

  • MinT keeps the base model resident and represents task, product, experimental, tenant-specific, and rollback variants as adapters rather than separate full checkpoints.It connects rollout, update, export, evaluation, serving, and rollback behind a service interface that hides distributed training, sharding, tensor-layout conversion, adapter admission, and serving access.Source: §1 · p. 2

Training-serving handoff

  • Unlike full fine-tuning or merge-based LoRA, MinT exports serving-compatible adapter revisions matched to the resident base and loads them into an inference engine already holding that base.This moves adapter revisions rather than full or merged checkpoints across the training-serving boundary.Source: §1 · p. 2, Figure 2 · p. 3

Scale Up

  • MinT supports LoRA RL on frontier-scale dense and MoE architectures, with model-parallel training and serving validated beyond 1T total parameters.Reported paths include 235B-A22B-scale training and a 1T-class MoE countdown task.Source: §1 · pp. 2–3

Scale Down

  • 18.3× on a 4B dense model and 2.85× on a 30B MoE, adapter-only handoff reduces the measured handoff step; concurrent multi-policy GRPO shortens wall time by 1.77× and 1.45×, respectively, without increasing peak memory.In compact rank-1 settings, the exported adapter can be less than 1% of base-model size.Source: §1 · p. 3

Scale Out

  • 1,000,000 adapter revisions were materialized with zero build errors, and a 256-adapter audit was validated across 100 shards; packed MoE LoRA tensors improve live engine loading by 8.5–8.7×.MinT separates durable policy addressability from bounded CPU/GPU working sets; admission-aware readiness gates expose adapters only after background prewarm, trading rollout delay for avoiding loads on ready-path requests.Source: §1 · p. 3

Adapter lifecycle

  • MinT exports trained LoRAs as PEFT adapter revisions with sharded-to-serving conversion, compatibility checks, rollout records, sampler loading, served-result attribution, and rollback.The revision is the fixed behavior selected by rollout, evaluation, online serving, and recovery.Source: §1 · p. 3

Large-scale multi-LoRA RL training

  • MinT time-slices LoRA training sessions over resident shared bases and supports single-worker PEFT and distributed Megatron training paths.It reports end-to-end LoRA RL on large dense and MoE deployments.Source: §1 · p. 3

Public reproducibility paths

  • MinT provides a Tinker-compatible API and mint-cookbook recipes to reproduce SFT, preference optimization, rollout-based RL, and AutoResearch examples through the same adapter lifecycle.Post-training combines cluster scheduling, artifact versioning, and frequent deployment, while copying or serving a full checkpoint for each variant no longer scales.Source: §1 · pp. 1, 4

2 From LoRA Adapters to Managed Policy Revisions

MinT separates the fixed LoRA payload used for behavior from the durable service state that makes a policy resumable, schedulable, reloadable, and rollbackable. This lets many policies share a resident base while revisions move through training, rollout, evaluation, and serving.

2 From LoRA Adapters to Managed Policy Revisions

  • An adapter revision is a fixed exported LoRA snapshot in serving layout, while its policy record is durable service state; this separation lets policies share a resident base without full-checkpoint copies.The policy record keeps the base deployment, training checkpoint, rollout records, exported revisions, and cache state as separate facts.Source: §2 · pp. 4–5
  • Each RL iteration rolls out with a selected fixed revision, updates adapter and optimizer state from trajectories, then exports again for inference; evaluation also identifies its fixed revision.Trainer-local optimizer checkpoints remain on the training side, while inference engines consume fixed adapter files in serving layout.Source: §2 · p. 4
  • Each policy record names its base, adapter shape, latest checkpoint, retained rollout records, and exported revisions; workers save and restore adapter and training state when switching records, while base weights remain resident.MinT permits one training session per record; concurrent branches use separate records.Source: §2 · pp. 4–5
  • Serving resolves a policy name to a revision and engine-local id, then uses GPU-active bytes, promotes CPU-cached bytes, or fetches and loads the adapter from shared storage.This keeps the addressable catalog large while bounding CPU-cache and same-batch working sets.Source: §2 · pp. 4–5
  • For sparse rollouts, MinT reuses mappable MoE expert paths and drops unmappable tokens; DSA replay is incomplete, so out-of-band importance weights are zeroed rather than exact selections reconstructed.The rollout record stores the backend/model path and correction policy, not per-token DSA indexer selections.Source: §2 · p. 5

3 System Design

MinT provides a Tinker-compatible service for training, exporting, evaluating, and serving LoRA revisions while base models remain resident. It separates service control from resident compute and moves adapter state—not merged base checkpoints—between training and inference.

3 System Design

  • MinT exposes rollout, update, export, evaluation, and serving through a client service that routes work to resident trainers, samplers, and serving actors.The service plane resolves policy records and admits work to compatible workers; the compute plane includes single-worker PEFT trainers, distributed Megatron trainer groups, and vLLM actors.Source: §3 · p. 5

3.1 Service Plane and Resident Workers

  • The service plane assigns pollable operation ids, resolves policy records, and schedules requests on compatible workers while preserving completed results and revisions across retries.Files become visible only after metadata records their completed state; idle workers can be evicted while stored checkpoints, adapter state, rollout records, and exported revisions remain requestable.Source: §3.1 · pp. 5–6

3.2 Time-Sliced Multi-LoRA Training

  • Time-sliced trainers keep one frozen base resident while swapping each selected policy’s LoRA tensors and training state between requests.The swapped state includes optimizer moments, scheduler position, accumulated gradients, and rollout records; each trainer runs one policy session at a time, while other policies can progress on other workers or samplers.Source: §3.2 · pp. 6–7

3.3 Adapter Data Flow Between Training and Serving

  • MinT exports trained LoRA state as a fixed PEFT adapter revision, without base checkpoint bytes, for evaluation or serving on a compatible resident base.Distributed export gathers tensor-parallel slices and expert tensors into serving layout, while evaluation and serving select the particular exported revision even if training continues.Source: §3.3 · p. 7

3.4 Shared-Base Rollout and Serving

  • Shared-base vLLM samplers select exported revisions and manage adapters across shared-storage, CPU-cache, and GPU-batch tiers.A cold adapter load is scheduled before inference; warm adapters can be promoted from CPU cache, while resident GPU-batch adapters are used directly.Source: §3.4 · p. 8

4 Three Scaling Axes

MinT scales LoRA post-training and serving by placing training across large bases, handing off adapter revisions instead of merged checkpoints, and separating policy-catalog addressability from engine-local cache and batch state. Its scaling mechanisms preserve a stable adapter revision while controlling model placement, export, and serving lifecycle.

4.1 Scale Up: LoRA RL on Large Dense and MoE Bases

  • Megatron placement shards dense tensors by tensor parallelism and assigns MoE experts to expert-parallel groups, with LoRA tensors following the corresponding shard and expert ownership.Policy switches restore adapter tensors, optimizer moments, and accumulated gradients while base shards remain resident; distributed export gathers tensor-parallel slices, deduplicates replicated tensors, and collects expert tensors into a serving-layout PEFT revision.Source: §4.1 · pp. 8–9
  • R3 identifies router mismatch as an MoE RL instability source (Ma et al., 2025), so MinT records expert routes and replays them when the backend can reconstruct the path.MinT masks tokens when selected expert ids are missing or cannot map to the training layout; for DSA it fixes observed implementation mismatches and applies IcePop-style zero importance weight outside a trusted probability-ratio band (Ling Team et al., 2025), but does not guarantee the exact inference token set (GLM-5-Team, 2026; Chiang et al., 2026b).Source: §4.1 · p. 9

4.2 Scale Down: Adapter-Only Training-Serving Handoff

  • About 0.10% of a bf16 base-weight floor is the estimated size of a rank-1 adapter with the measured target pattern, supporting adapter-only rather than full-checkpoint handoff.The measured Qwen3-4B rank-32 adapter was 264,310,274 bytes (about 252 MiB), or about 3.3% of the 8.0 GB base-weight floor; broader target modules and metadata can increase footprint.Source: §4.2 · pp. 9–10

4.3 Scale Out: Policy-Population Serving

  • 1,000,000 packed adapter revisions were materialized and audited as a catalog artifact, while Qwen3-30B TP=4 probes exercised 64 distinct adapters—not simultaneous GPU residency.An actor kept hundreds of adapters cached near the engine; catalog addressability, local cache capacity, and same-batch execution are distinct scales.Source: §4.3 · p. 10, Table 2 · p. 11
  • Cold loading is scheduled service work: MinT deduplicates concurrent requests for the same missing policy and applies bounded backpressure to distinct loads.Traffic locality supports CPU-cache reuse; registration, prewarming, and readiness are separate states, and ready means user requests no longer perform adapter loading.Source: §4.3 · p. 10
  • 8.5–8.7× live-load speedup came from packing MoE LoRA tensors, reducing 37,248 tensors to 672 while keeping declared bytes nearly unchanged.The measured packed live engine-load slice was below 0.2 seconds; cold loading remains a longer path involving routing, queueing, fetch, activation, and readiness.Source: §4.3 · p. 11

5 Evaluation

MinT’s evaluation examines the LoRA lifecycle across training, handoff, and serving, including learning across dense and sparse models and multiple training paradigms, and distinguishes addressable policy catalogs from execution working sets. It also evaluates serving large policy populations through cache coordination, cold-load scheduling, adapter readiness, and packed MoE adapter loading, with speedups reported for the live engine-load slice rather than end-to-end cold latency.

5.1 Scale Down and Multi-Train Utilization

  • Qwen3-4B adapter handoff records 4.114 s versus 55.704 s for merge, while Qwen3-30B records 117.304 s versus 156.074 s.The adapter artifacts are 252 MiB and 1.692 GB, compared with full-model files of 8.061 GB and 61.084 GB; reduced materialization and loading dominate rollout-throughput differences in these runs.Source: §5.1 · p. 12, Figure 7 · p. 12, Table 3 · p. 12
  • Concurrent GRPO cuts Qwen3-4B time from 3081.2 s to 1736.1 s and Qwen3-30B time from 10130.0 s to 7008.4 s, with unchanged peak memory.The speedups are 1.77× and 1.45×, respectively; overlapping policies fill schedule gaps while each policy’s model computation remains unchanged.Source: §5.1 · p. 12, Figure 8 · p. 13, Table 4 · p. 13

5.2 Scale Up Across Training Paradigms and Model Scales

  • Qwen3-4B SFT held-out accuracy rises from 0.4226 to 0.7811 on Fineval, while FPB, FiQA-SA, TFNS, and NWGI also improve.The respective score changes are 0.6906→0.8804, 0.8255→0.8473, 0.5959→0.9095, and 0.4954→0.5925. The same adapter lifecycle also supports chat-DPO reward-margin optimization and Qwen3-8B GRPO; the exported step-240 sampler scores 20/30, 19/30, and 18/30 on AIME24/25/26.Source: Table 5 · p. 14, §5.2 · p. 14
  • Qwen3-235B-A22B GRPO reaches 0.967 peak mean@1 on AIME24, while the same LoRA RL lifecycle extends to a 1.04T-parameter Kimi K2 countdown task.GLM-5.1 A2UI GRPO’s 5-step reward mean rises from about 0.21 to 0.27 over 40 steps, with 5 hard failures among 256 responses at step 40.Source: §5.2 · pp. 14–15, Figure 10 · p. 15, Figure 11 · p. 15
  • LawBench’s maintained v23 recipe scores 0.5079 on the full benchmark versus the 0.4628 base, while high-proxy v11 scores 0.4858, below v10’s 0.4889.The later-manifest full-control score is 0.4712; proxy screening alone did not predict full-benchmark improvement.Source: §5.2 · p. 16, Figure 12 · p. 16

5.3 Policy-Population Serving

  • A materialized 1M adapter catalog supports selected-revision serving, with hundreds of CPU-cached adapters, 64 tested same-batch adapters, and 100% TTFT≤5s SLO through 2 rps.The million-scale result is a catalog and routing claim, not evidence that one engine keeps every adapter resident or active.Source: §5.3 · pp. 17, 19
  • Admission-aware prewarming protects old warm traffic: two-phase readiness yields 9.63 s old-traffic p95 and 4.60 s first-user TTFT for new adapters after activation.The new adapters’ ready-path load p95 is 0.00 s; this is not zero deployment wait, since the probe’s prewarm span is reported separately. Without admission, old warm p95 reaches 24.03 s with 10 stalls above 20 s.Source: Figure 13 · p. 18, §5.3 · p. 19, Table 7 · p. 20
  • Packed MoE LoRA loading uses 55.4× fewer tensor objects, reads tensors 54.8× faster, and builds loader objects 29.5× faster.The file-size reduction is only 1.05×, so the measured loading gains come from replacing many small tensor objects with a compact serving representation.Source: Table 8 · p. 20
  • Packing targets a small-object loading bottleneck: rank-1 MoE adapters contain 37,248 mostly tiny expert tensors, and local-disk staging leaves tensor fanout and loader-side registration work unchanged.The packed serving representation reduces object fanout with nearly unchanged declared bytes.Source: §5.3 · p. 20
  • Packing reduces tensor objects from 37,248 to 672, improves direct loading by 29.5–54.8×, and improves live engine loading by 8.5–8.7×.File size changes only from 110.75 MB to 105.58 MB; packed live-load medians are under 0.2 seconds. The live-load speedup excludes routing, queueing, fetch, and generation.Source: §5.3 · p. 20
  • Routing and prewarming turn recurring traffic into CPU-cache hits, while batch construction respects the same-batch adapter limit and cache misses enter an explicit cold-load stage.Admission-aware two-phase rollout determines when a newly registered adapter becomes user-visible; packing reduces activation cost without changing the same-batch adapter window.Source: §5.3 · p. 20
  • MinT treats the 1M catalog as durable addressability, while CPU-cache size, same-batch diversity, warm SLO capacity, cold-load cost, and readiness define online execution scales.The measurements distinguish catalog size from the working-set and latency constraints encountered during serving.Source: §5.3 · p. 20

6 Related Work

Related work spans post-training services, RL execution, training-serving consistency, LoRA training and serving, and large-model infrastructure. MinT’s distinction is connecting these systems through policy-specific adapter revisions and lifecycle state.

Post-training workload

  • MinT targets workloads that produce many policy variants over fewer base models, including task variants, evaluation candidates, product branches, tenant adapters, rollback points, and personal adapters.The passage situates this workload amid growing emphasis on problem definition, evaluation, agent-environment interaction, and learning from streams of experience.Source: §6 · p. 21

Service interfaces

  • Remote post-training interfaces make training loops programmable; MinT adds a LoRA service path linking policy records, checkpoints, rollouts, exported revisions, and cache state.Tinker provides remote post-training primitives, while SkyRL tx and OpenTinker cover broader model, benchmark, and RL-as-a-Service capabilities.Source: §6 · p. 21

RL execution systems

  • RL execution systems address rollout scheduling, execution placement, asynchronous optimization, GPU utilization, and failure isolation; MinT ties these concerns to policy-specific adapter and rollout state.MinT also associates optimizer state, MoE route records, DSA correction metadata, exported adapters, and cache state with the policy that produced them.Source: §6 · p. 21

Training-serving consistency

  • Training-serving consistency work studies probability gaps, precision mismatch, and MoE router disagreement; MinT records adapter revisions, rollout data, route or DSA metadata, and served evaluation paths.These records identify which behavior generated and scored a token.Source: §6 · p. 21

Parameter-efficient tuning and multi-LoRA training

  • LoRA methods freeze the base model and train low-rank updates, while MinT manages RL updates and exports as serving revisions over a resident base.The cited work includes rank allocation, quantized bases, and evidence that LoRA can achieve strong post-training quality.Source: §6 · p. 21

Multi-LoRA serving

  • Multi-LoRA serving systems optimize batching, memory, scheduling, kernels, compression, cache dependencies, and distributed placement; MinT connects addressable adapters to trained policies and reloads exported revisions on cache misses.The cited systems include Punica, S-LoRA, dLoRA, FastLibra, and LoRAServe.Source: §6 · pp. 21–22

Large-model infrastructure

  • Large-model infrastructure supplies distributed execution, model parallelism, memory partitioning, and MoE techniques; MinT keeps base deployments resident while adapter revisions move and cache state controls hot policies.The passage also notes infrastructure state units such as KV-cache entries, on-disk cache storage, rollout WALs, and teacher-state scheduling.Source: §6 · p. 22

7 Conclusion

MinT addresses the poor scalability of full-checkpoint workflows by managing exported LoRA adapter revisions over resident base-model deployments. Its measurements validate this path across Scale Up, Scale Down, and Scale Out.

7 Conclusion

  • MinT makes exported adapter revisions the managed unit, while policy records keep payloads reproducible, schedulable, and durable across worker changes and cache movement.Selected revisions train and serve over bounded resident working sets, making LoRA a service-level unit for large-scale post-training over shared 1T-class bases.Source: §7 · p. 22
  • Adapter-only handoff reduces the measured step by 18.3× on a 4B dense model and 2.85× on a 30B MoE; concurrent multi-policy GRPO shortens wall time by 1.77× and 1.45×.The concurrent GRPO gains hold under the same resident-base allocation.Source: §7 · p. 22
  • MinT supports LoRA RL on dense and MoE architectures, with model-parallel training and serving paths exercised beyond 1T total parameters.Source: §7 · p. 22
  • MinT builds 1,000,000 packed adapter revisions with zero errors, audits sampled adapters across all 100 shards, and serves selected revisions through bounded local working sets.Source: §7 · p. 22
  • Warm open-loop serving keeps 100% TTFT≤5s through 2 rps for the measured 64-adapter workload.Source: §7 · p. 22
  • Packed MoE LoRA tensors reduce live-load fanout by 8.5–8.7×, while admission-aware two-phase rollout protects warm tenants by moving loading before readiness.Ready-path first requests avoid load cost at the price of explicit prewarm delay; cold activation interference, rather than catalog registration, is the dominant online risk.Source: §7 · p. 22

B Additional Serving Measurements

The appendix probes MinT’s serving path from million-scale catalog addressability to warm and cold adapter activation. It identifies cache locality, cold-load scheduling, rollout readiness, and adapter representation as distinct deployment control points.

One-million-adapter catalog artifact

  • The packed Qwen3-30B-A3B rank-1 catalog contains 1,000,000 adapters, built with zero errors across 100 shards and verified by reading sampled adapters.A fresh audit sampled 256 adapters across all 100 shards; this establishes a built, readable artifact, not that all adapters are resident.Source: B Additional Serving Measurements · p. 26, Table 9 · p. 26

Hot reload, admission, and readiness probes

  • Two-phase readiness moves activation waiting into rollout or prewarm, so zero user-visible load p95 describes the ready path, not zero-time deployment.Admission serializes cold work to protect existing warm traffic; cold activation, unlike registration, interferes with that traffic.Source: B Additional Serving Measurements · p. 27, Table 11 · p. 27

Native vLLM baseline and caveat

  • Native vLLM cannot directly load MinT’s packed 1M layout, a format-compatibility boundary; its standard-PEFT 1k baseline is not an apples-to-apples lifecycle comparison.The appendix notes that native vLLM performs well on small static PEFT sets, which does not establish performance for MinT’s packed catalog lifecycle.Source: B Additional Serving Measurements · p. 27, Table 12 · p. 27

Adaptive activation scheduler negative result

  • Aggressive SLO-aware activation shortened rollout wall time but hurt warm tails, so the paper retains conservative two-phase gating rather than higher prewarm concurrency.The probes identify executor/add-LoRA activation interference as the next bottleneck.Source: B Additional Serving Measurements · p. 27, Table 13 · p. 28

Packed cold-load representation

  • Packing reduced adapter tensor fanout from 37,248 tensors to 672, addressing cold-load object overhead despite moderate adapter bytes.The original measured adapter had 37,152 tensors no larger than 4 KB; the appendix attributes cold-load overhead to object and registration costs.Source: B Additional Serving Measurements · p. 28

Cached working sets

  • The unique-adapter ladder reached 550 CPU-warm cached adapters at 2,048 requested, while clean same-batch GPU-active probes extended to 64 adapters.These measurements distinguish the local CPU cache tier from the same-batch GPU adapter window.Source: B Additional Serving Measurements · p. 28, Table 16 · p. 29

Cold-load accounting

  • Unique cold-adapter loading into one engine is the cold-path bottleneck; deduplication avoids repeated work for identical misses, while distinct cold adapters remain separate jobs.Requests wait for LoRA loading before generation, API queue wait is small, and bounded backpressure protects service behavior.Source: B Additional Serving Measurements · p. 29, Table 18 · p. 30

Fleet-level active-wave model

  • For a modeled 2,300-distinct-adapter active wave, ideal warm placement requires 36 engines, while a cold burst of 2,300 uniques is sized at 72 engines.The fleet sketch is planning intuition based on measured single-engine limits, not the evidence for the 1M artifact; its warm headroom band is 44–54 engines.Source: B Additional Serving Measurements · p. 30, Table 19 · p. 30

Related papers

Loading 2605.13779v2…