Talk by Nan Jiang (Modal) on synchronizing reinforcement learning rollout fleets across datacenters. Frontier-scale checkpoints (~500 GB) take minutes to hours to ship, preventing fast weight updates. The talk argues that fewer than 1% of rollout-visible weights actually change between consecutive versions — not because gradients are sparse (they're dense), but because a typical Adam step at RL post-training learning rates (~3e-6) is too small to cross the BF16 rounding boundary, so the served weights stay unchanged ("Adam absorption"). Lower-precision serving (e.g., FP8 on an internal GLM 4.7 Air run) sharpens this further (~0.15% changing on the first step, settling near 0.05%). Sending a ~500 MB lossless patch instead of a full checkpoint decouples rollout islands from the trainer's cluster, enabling geographically scattered inference capacity to act as one elastic rollout fleet via a version-aware sidecar. Modal's implementation is called Stitch. Timestamps cover the standard RL post-training loop, the precision floor, Adam step size, patch-based sync, measurement results, FP8/NVFP4 formats, the bulletin board architecture, and open questions (Muon, fully async RL). # Video Identity Observations — RL Cross Datacenter Talk ## Video Context - **Title:** *Taking Reinforcement Learning Cross Datacenter — Nan Jiang, Modal* - **Format:** Conference talk (speaker opens with "hope you all have a good time at the conference"). - **Speaker affiliation:** Speaker identifies as "from Modal" ("I'm N from Moto [Modal]"). ## Explicit Self-Description (Creator Claims) - **Company mission framing:** "At Modal, we spend a lot of time thinking about GPU capacity, like where it exists, how do we make it elastic, and what kind of workload can we actually use it." - **Product claim:** "Stitch is one of very concrete implementation from Modal that implementing everything above" — described as "framework agnostic about trainer and engine and also transport," "async first and also agent first." - **Recruiting:** "We are working on some very hot problem and come work with us you can check the link there." ## Observable Presentation Patterns - **Audience:** ML infrastructure engineers and researchers working on RL post-training at scale — assumes familiarity with RLHF/RL loops (trainer, rollout workers, environments), **RDMA**, **GRPO**, **PPO**, **BF16**, **Adam/Muon optimizers**, serving formats (**FP8**, **MXFP4**, **NVFP4**), and engines (**SGLang**, **vLLM**). - **Claimed scope:** Distributed/elastic GPU infrastructure for AI training and inference; specifically cross-region, cross-provider rollout fleets decoupled from trainer clusters. - **Evidence style:** Technical mechanism arguments (push vs. floor analysis of BF16 rounding, ~99% bit-identical weights per step), plus internal empirical results: "Here's the model we serve like [GPT-4.7?] in FP8 and we can see in the beginning there are only like 0.15% of weights got changed." - **Positioning via ecosystem references:** Cites model providers ("Cursor, Composer 2, MI," "Moonshot and also DeepSeek") adopting Adam/Muon post-training to argue generality. ## Demonstrated Identity Signals - **Channel persona:** Practitioner from a cloud/GPU-elasticity company presenting deep systems research — blends internal engineering (Stitch) with external research citations. - **Values demonstrated:** Bitwise correctness ("bitwise reconstruction"), elasticity, and pragmatism about commodity networking ("moving that over commodity link might not be the smartest choice"). - **Openness:** Explicitly flags open questions — Muon compatibility, async RL scalability, generalization beyond RL ("pre-training, mid-training and SFT"). ## Claim vs. Demonstration Distinction - **Claim:** Scattered inference capacity "became one elastic rollout fleet" via Stitch — a product claim, not independently verified in the talk. - **Demonstrated:** The sparsity argument (Adam absorption vs. BF16 rounding floor) is shown with reasoning and one internal measurement, but measurement details are speaker-reported, not reproducible from the talk alone. # Delivery Observations — “Taking Reinforcement Learning Cross Datacenter” (Nan Jiang, Modal) ## Tone and Register - **Conversational, low-key conference talk style.** Opens casually: <blockquote>“All right, cool. Hi everyone. Uh, hope you all have a good time at the conference.”</blockquote> - Frequent filler and self-repair: **“uh”, “like”, repeated word restarts** appear throughout, e.g. <blockquote>“So this is my talk about many about.”</blockquote> and <blockquote>“This is not saying the master weights uh in is frozen forever.”</blockquote> ## Teaching Habits and Structure - **Question-driven scaffolding.** Repeatedly poses the next question before answering it: - <blockquote>“So the ne next question is what kind of compute shape did we actually force everything into?”</blockquote> - <blockquote>“So that leads to the key question does the whole out loop actually need that like this kind of shape.”</blockquote> - <blockquote>“So right now we need to justify the less than 1% like claim. Why would this roll of visible like weights barely change?”</blockquote> - **Numbered ingredients framing:** <blockquote>“We need a two uh prerequisite. The first one two two ingredients. The ingredient one is the precision.”</blockquote> - **Concrete-vs-abstract rhythm:** introduces an abstraction, then grounds it with numbers (e.g., ~500 GB checkpoints, ~0.4% BF16 boundary, 3e-6 Adam step, “0.15% of weights got changed”). - **Explicit misconception correction:** <blockquote>“A common misconception there is like the work it works because all our gradients are sparse. They are not.”</blockquote> ## Recurring Phrases and Vocabulary - **Repeated stock connectors:** “So”, “So let's…”, “So this is…”, “The important part here is…” — notably: - <blockquote>“The important part here is still a bit wise reconstruction.”</blockquote> - <blockquote>“The important part is not only the number it is the patch is lossless”</blockquote> - **Repeated domain vocabulary:** “rollout”, “trainer”, “cluster”, “checkpoint”, “RDMA”, “version”, “policy” — used consistently as anchor terms across the talk. - **Metaphorical labels** for compute shapes: <blockquote>“On the left side is the cathedral… On the right it is bro.”</blockquote> (likely transcribed for “bazaar”; the contrast itself is observable in the transcript.) ## Anticipating Audience Pushback - Repeatedly pre-empts misreading: <blockquote>“This is not saying the master weights… is frozen forever. It is saying the value that rollout engine would serve does not change on this part.”</blockquote> - Tells audience what *not* to memorize: <blockquote>“So you do not need to actually remember the exact like bound there.”</blockquote> ## Closing Pattern - **Open-ended forward questions** rather than a summary: <blockquote>“does the spicy still hold for muan… how scalable is the fully async RL… does it generalize pass”</blockquote> - Standard recruiting close: <blockquote>“come work with us you can check the link there”</blockquote> ## Uncertainty Notes - Transcript quality is rough (likely ASR), so **word-level delivery judgments** (filler frequency, exact restarts) may partly reflect transcription artifacts rather than speech. - The apparent metaphor pair “cathedral / bro” occurs only once; the second term is likely a transcription error, so I avoid claiming the intended wording. # Position Record: Taking Reinforcement Learning Cross Datacenter — Nan Jiang, Modal ## Speaker - **Nan Jiang** (introduced as "N from Moto" / Modal), speaking about GPU capacity and distributed RL post-training. ## Core Claim The default shape of RL post-training compute — one tightly coupled cluster — is too restrictive. **The rollout fleet can leave the trainer cluster** and run on scattered, autoscaled, cross-globe capacity, because weight synchronization can be reduced from full checkpoints (~500 GB) to sparse bit-level diffs (~hundreds of MB). ## Reasoning Chain ### 1. The mismatch between compute supply and RL demand - Much RL discussion focuses on algorithms, environments, sandboxes, GRPO, low-precision training, deterministic kernels — "but when you run those experiments at scale the problem became more physical." - Useful compute lives across "different providers, different regions, different price and different availability" — not in one RDMA island. - RL training wants **all four at once**: enough GPUs, same region, fast fabric, available now. "Any of these... is manageable, but all four of them is pretty hard to get." - Trainer clusters are not elastic like inference capacity; if the loop must live in one cluster, rollout inherits the hottest capacity constraint. ### 2. What can move and what cannot - **Training** is a tightly coupled job with collectives and model-parallel communication — it wants one fast fabric. - **Rollout** is a fleet of serving jobs with **no global all-reduce** across rollout jobs. - The movable unit is the **rollout serving island** — a coherent endpoint or local group serving one policy version, possibly with local parallelism / PD disaggregation. - Cross-island dependency is light: "policy version in, trajectory and metadata out." - Speaker explicitly states: "the thing I want to move here is not back propagation." ### 3. Full checkpoints are the wrong synchronization unit - A Kim-scale checkpoint: "500 gigabytes, normally take a minute or maybe... multiple minutes to hours" — commodity links can't deliver the desired seconds-level weight update latency. - Bet: fewer than **1% of rollout-visible weights** (served BF16/FP8/MXFP4 view, not FP32 optimizer states) change between consecutive versions. ### 4. Why the sparsity holds (Adam + finite precision) Two "primitives": - **The floor (BF16 rounding):** BF16 spacing ≈ θ/128; update must cross a boundary of roughly half a ULP ≈ θ/256. For weight ≈ 1: boundary ≈ 0.0039. - **The push (Adam step):** ignoring weight decay, per-parameter Adam updates are ≈ learning rate in magnitude; the speaker cites a paper proving Adam step ≤ B × learning rate. Typical Adam step ≈ **3e-6**, i.e., "more than a thousand [times] smaller than the boundary." - Result: **Adam absorption** — small weights can move; large weights' updates are absorbed and invisible in the served view. - **Qualification preserved:** "This is not saying the master weights... is frozen forever. It is saying the value that the rollout engine would serve does not change on this step." ### 5. Patch mechanics - Ship a **diff**, not the FP32 optimizer state: positions + replacement bits + metadata; encodings can be selective overrides or XOR — **bit-level equivalent**, no floating-point additive drift; bitwise reconstruction of the same version. ### 6. LoRA vs full-parameter - **Full-parameter:** delta small *by absorption*. - **LoRA:** delta small *by construction* (frozen base model, small adapter) — push-vs-floor argument not needed. ### 7. Empirical evidence cited - Referenced paper: ~**99% bit-identical per step** when casting to BF16 across model families; sparsity persists even with rollout staleness. - **Correcting a misconception:** "it works because gradients are sparse — they are not." Gradients are dense (~99% of parameters get nonzero gradients); FP32 master update is dense, just small. - Lower precision (FP8, MXFP4, NVFP4): coarser floors → even fewer visible changes; block-scaled formats (MXFP4 group scales, NVFP4 hierarchical scales) discussed with same rationale. - Internal run: model served in FP8 — **~0.15% weight change first step** (high LR), stabilizing to **~0.05%** per step. Similar patterns across research teams and model providers (DeepSeek, Kimi, mentioned as using Adam in post-training). ## Proposed Architecture - Trainer stays in its cluster; publishes **immutable rollout weight versions** to a shared bulletin board. - Rollout engines live outside the cluster (different regions/providers), pull versions and materialize checkpoints locally (HF safetensors format — compatible with SGLang, vLLM, etc.). - Requests are **version-aware**: request specifies accepted version; response returns version plus tokens, log probs, rollout replay metadata. - **Version-aware scaler/sidecar:** if at acceptable version → proxy; behind but catchable → apply missing transitions; otherwise → return "not ready." Any idle GPU can join the fleet. - Latency claim: full checkpoint across regions (network) slow; delta transfer **500 GB → ~500 MB**, "extremely fast in seconds." ## Concrete Implementation - **Stitch** (Modal): implements the above protocol; framework-agnostic about trainer, engine, and transport; "async first and also agentic first." - Effect: "scattered inference capacity became one elastic rollout fleet... inference capacity can now become our [RL] capacity." ## Open Questions / Unresolved Tensions (as stated) - Does the sparsity claim hold for **Muon** (adopted by Moonshot, DeepSeek)? "A lot of things we discussed previously [are] only for Adam." - **How scalable is fully async RL at scale?** — "very open-ended question." - Does the paradigm generalize to pre-training, mid-training, SFT? - Closing: recruiting pitch — "come work with us." # Speaker Attribution Record ## Video Metadata - **Title:** Taking Reinforcement Learning Cross Datacenter — Nan Jiang, Modal - **Video ID:** `01a15ca7-fd99-7ff9-a890-9c8d0bf6bd9c` - **Format:** Conference talk (speaker opens with a greeting to a conference audience) ## Speakers | Speaker | Role | Identification Basis | |---|---|---| | "N from Moto" (phonetically transcribed; likely **Nan Jiang, Modal**) | **Creator / Presenter / Sole speaker** | Self-introduction: "I'm N from Moto" (transcript appears to be an automatic transcription of "Nan from Modal"); title metadata names Nan Jiang, Modal | - No guests, narrators, or additional speakers appear. - The audience is referenced but does not speak. ## Promotional Segments - **Flagged:** Closing segment — "we are working on some very hot problem and come work with us you can check the link there model" — an explicit recruiting/hiring pitch for Modal. ## Referenced Sources and Third-Party Claims - **"The paper"** (unnamed, referenced repeatedly): claims ~99% of rollout-visible weights are bit-identical per step; proves an AdamW step bound of at most β times the learning rate; reports gradients are dense (~99% of parameters get non-zero gradients). The specific paper is not named in the transcript. - **Third-party adopters cited** (claimed, not independently verified in transcript): - Model providers using Adam in post-training: "cursor composer 2 mi" (transcription unclear) - **Moonshot** and **DeepSeek** (transcribed as "deepc4") — claimed to be adopting **Muon** optimizer (transcribed as "muan") in post-training - **Internal data cited:** an internal run serving "GM 4.7 air in FP8" (transcription unclear; likely a model name), showing ~0.15% initial and ~0.05% steady-state weight change per step. - **Named tools/formats referenced:** Adam/AdamW, Muon, GRPO, PPO, BF16, FP8, MXFP4/NVF4, RDMA, SGLang (transcribed "sjet"), vLLM (transcribed "VLM"), HuggingFace safetensors format, Modal's internal system "Stitch". ## Provenance Notes and Uncertainty - Transcript is an automatic phonetic transcription; names ("N from Moto", "cursor composer 2 mi", "GM 4.7", "deepc4", "muan") are uncertain renderings. - No curated metadata (comment availability, cited URLs, publication details) was supplied beyond the title. - No timestamps are present in the transcript; quotations cannot be timestamped. All right, cool. Hi everyone. Uh, hope you all have a good time at the conference. Uh, I'm N from Moto. Uh, at Moto, we spend a lot of time thinking about GPU capacity, like where it exists, how do we make it elastic, and what kind of workload can we actually use it. Today I want to talk about one place where everything became like gets really interesting the IO post training. A lot of IO discussion right now is about algorithm and the environments sandbox PO GRPO like to call maybe low precision training maybe deterministic kernels. Um but when you run those experiments at a scale the problem became more physical. Where are the GPUs? Are they in the same region? Uh do they have fast fabric? Uh can we get them right now? Maybe the default shape of IO comput is too restrictive. Maybe some of the work we usually force them one cluster uh like can actually run on scattered autoscaled capacity. So can we do our cross globe? So this is my talk about many about. So to make this more concrete let's start with the IO loop itself. So in the standard uh our post training loop we can see there's a one trainer and the trainer updates the policy rollout worker or maybe people call it sampler use those policy to generate trajectories. The environment will be returning the reward and observations. Those trajectory will go back to trainer for the next updates. The important error here is the way sync in the default setup trainer and the rollout will be living in the same cluster and the the way sync will be super fast with RDMA. But that also couple the rollout fleet to the to the trainer cluster. If the rollout needs to more to have more capacity maybe no more nodes during runs um you are normally limited by the fixed size during your trainer maybe your trainer cluster. So the ne next question is what kind of compute shape did we actually force everything into? On the left side is the cathedral uh one region one faster interconnect uh many GPUs wild together. This is the right shape for the trainer. On the right it is bro. This is where a lot of like usable useful usable compute actually lives. Different providers different regions different price and different availability. There's still a lot of capacity out there, but it's not one perfect RDM in the island. This is the mismatch. Available computer is distributed, but the default IO loop ask one tightly coupled cluster. And that cluster is exactly the hot part hard to get. IO wants all four of these at the same time. Enough GPU, same region, fast fabric, and available now. Any of these like is manageable, but all four of them that are pretty hard to get at the same time. ADMIC capacity is not elastic in the way the inference capacity is elastic. You cannot assume you can grow the trainer cluster uh halfway through a run just because roll out wants more nodes for a trainer. So if the whole out loop has no live like has to live inside the the one cluster rollout inherents the hottest part capacity constraint in here. So that leads to the key question does the whole out loop actually need that like this kind of shape. So let's dive into this training is one tightly coupled job. Every step has collectives all reduced and the model parallel communication that part actually wants one fast fabric a RDM connected rollout is a fleet of serving jobs. It generates trajectories call environments or maybe tools and they will be sending back data back to the trainer. So cross rollout jobs there's no global or reduce. So the thing I want to move here is not back propagation. Back propagation should stay in the cluster. The run the rollout fleet is the one that can leave. More precisely, the movable unit is the rollout serving island a coherent endpoint or maybe a local group of endpoint or that they can be serving one policy version inside island. A large model may still be having like local parallelism. They can do PD segregation. They can have like local serving constraints. So across islands the dependency is much lighter right now. policy version in and the trajectory and the metadata out. So once we define the unit that way the architecture is much much more natural. Once we define the movable unit the architecture is very straightforward. In this case we just have trainer standing audic cluster and that's where the back proper and the collective go the rollout side will be fing out across the SPR. Each rollout island will be can be single engine will be a local serving group depending on the model and the serving topology there. across island there is no global or reduce that's the most important thing there the global interface is very simple the trainer send policy weight version out and the rollout sending trajectory and the metadata back at this point the architecture depends on one remaining link the weight update so if you want to if you want to send the full parameter like full checkpoint from disk or maybe through the network then everything is like minimless and like it will be breaking immediately so uh after this aggregation The things we will be discussing about like the size of like go the size of the full parameters go through the disk. Naively that means shipping all full checkpoints every time rollout needs a new way version. At this scale the checkpoint is very huge. So a Kim scale NVIP for checkpoint you have like 500 gigabytes normally take a minute or maybe normally take multiple minutes to hours to just do the way. So moving that over commodity link is might not be the smartest choice because like uh when you're doing async maybe even even fully async training you still want way updates latency to be as low as possible like within seconds. So the problem here is not whether rollout can leave the cluster the problem is like the full checkpoint is a wrong unit of synchronization. So the next question is can we keep the exact same serve version there but send a much smaller object. So this is the bet. What if less than 1% of rollout visible weights got changed from one version to another one by rollout visible weights I mean the weights in the served rollout checkpoint uh not the FP32 optimizer states not the atom like moments like the weights are the rollouts engine which will actually use to serve maybe let's say the FBA or maybe MVP4 format if that's true we do not need to shift the entire full parameter over the network we just need to shift the change the server view the precision data got different. The important part here is like still a bit wise reconstruction. The rollout engine gets the same served served version. You would have gotten to as sync to the full checkpoint there. So if this works then the link shrinks from hundreds of gigabytes to maybe hundreds of megabytes and this is something smaller enough we can just send it across like the network. So right now we need to justify the less than 1% like claim. Why would this roll of visible like weights barely change? Uh now we get we will get into this mechanism. So it's kind of small atom like step meets finite precision. We need we need a two uh prerequisite. The first one two two ingredients. The ingredient one is the precision. The optimizer may keep very high precision master weights but the next four will pass really a BF6 visible view. That view has final resolution around a value of magnitude theta. uh BF16 spacing is roughly theta over 128. Uh that spacing is people call it oop basically the unit in the last piece. Basically it's the distance between the adjacent representable BF systeming value. But the update only needs to cross the near surrounding boundary to be viable to be visible. That boundary is about half of the oop. So roughly like the over 256 for weight around one. The BF systeming loop is around uh 0.78 and the near surrounding boundary is about 00039. If the optimizer notched the master weight by something like smaller than that uh the BFC visible value will run back so you will not see any change from the weight perspective rollout weight perspective. So that's the floor. The second primitive there is we call push. So for Adam maybe add here we just like we ignore the weight decay turn the per per sorry the the per parameter updates is the learning rate times a normalized direction the raw gradient can be dense and can have very different magnitudes across parameters and add like device by running uh gradients statistics. So the per wise push is usually on the order of learning rates. The paper passed I sight there they prove a bound. The addon step is at most B times the learning rates. So you do not need to actually remember the exact like bound there. Like the important notes is the adden makes the push small and very controlled. So at our post training learning rates the push is very very tiny. So that's the push. Combining these two primitives now we have to we have a whole like better picture assert the value changed only if the push clear the floor the push is the addent step roughly the learning rate the floor is the nearest the BF16 rounding boundary roughly theta over 256 take theta equal one the BF6 boundary is about 039 a typical added step here is around 3 millions so the update is more than a thousand smaller than the boundary so the BF visible value will not change. This is not saying the master weights uh in is frozen forever. It is saying the value that rollout engine would serve does not change on this part. So the whole magnet is pushing is is pushed versus four. Let's visualize this to have better understanding. The x-axis is the weight magnitude and the y-axis is the update magnitude. First we look at the red line. The red diagonal is the bxis invisible boundary. It's like theta over 256. And now we look at the green bound. This is the atom push. Is this roughly around the learning rate and with a conservative upper bound? So now we ask like where the most point fits for most of the weights. The red floor is above the green push. Those updates exists in the master weights but they are not visible in the served BI6 view. This step small weights on the left can move. Large weight on the right. They will just stay the same. They will be absorbed it. This is the addon absorption. This is why the serve update become very sparse. In this case, the object will be shipped is just a diff uh is just a diff not the entire FP32 automated state. We first look at the rollout view. The weight cast or projected to the dype that the rollout engine will be serving. Then we will be comparing the version t minus one and the version t. Uh in this view the patch is the patch is the change the position plus like uh replacement bits and also like some metadata. There are multiple lossless encoding. People can do selective overrides. They can people can also do xor. The important part is like there are bit equivalent bit level equivalent. So it's not a floating point addition. So there's no additive uh delta drift. If a roller engine applied the patch correctly, it reconstruct the sync server version bitwise. So everything so far we explained is about the full parameter which is hot power. So in full parameter reinforcement learning the automizer update the whole model but the roll of view patch is sparse as the thing we just explained lower is a small for a different purpose for for a different reason. The base model is frozen and the adapter is small enough by construction. So you do not need to pu So you do not need to have the push versus flow arguments here. So full parameter delta is small by absorption and the lower updates are small by construction. Let's dive into deeper about the paper itself. So the paper they mentioned more stats I will be showing here. The measurement is not great in sposity. It's not optimized state sposity. They cast weights to BF16 compare consecutive version stness and they compare the the version bitwise and they count what did not change over time across model family the result around 99% of the time is bit identical per step is also it also survives stillness even when the roller lax the changes set remain very small the important part is not only the number it is the patch is lossless change index plus imprint value reconstruct the exact same version. So a common misconception there is like the work it works because all our gradients are sparse. They are not. The paper reports the gradients are dense. About 99% of the parameter gets non-zero gradients. The FP32 master update is also dense. It's just small. The main thing is like the rollout weight change is just 1% from the perspective of rollout engine. So far we mostly talk about BF16 but the rollout of open serving even lower precision such as like MFP4 FA and NVF4 and we can see many many model providers doing this in the roll out. Uh this is not a training precision the training is just like in the normal BFC although people can do QA on that. So for fixed stale flow format the visibility for is roughly theta over two to the mantisa plus one. So as you can see the F4 will be higher and FA also will be between BF60 and F4 which means in even lower precision there will be less weight changed. So plane flows are easy to reason about. So each element has its own rounding sling one value cross the floor one value they just flip and changed group scale such in4 they are they're a bit different. This is the regime where many low precision serving system are moving towards right now. For in four each ways is quantized against a shared group scale and we can apply the same rationale and also we can observe similar thing for NBF4 is hierarchical scales and uh we can see there are different encoding and the displaying mechanism for MPV4. So this is the from one internal run. So here's the model we serve like GM 4.7 air in FP8 and we can see in the beginning there are only like 0.15% of weights got changed in the first step where the learning is high and after we have more training step like when the adden is going relatively stable and you can see the entire curve goes stable when you got only one 05% uh weight change during each step. So we can see this pattern showing more generally. We have a different research uh we saw different research sync have a similar conclusion and we saw a different model providers such as cursor composer 2 mi they all using add in the post training at at this point assume we can produce exact rollout weights version cheaply. The next question is how do we do this in practice? So from sparse delta to to our cross globe. How do we do this with elastic rollout engines and also explicit stness this is the whole shape the trainer saying a cluster after it got updated it publish immutable rollout based version to a shared bulletboard rollout engine leave outside of the training cluster which means they don't need to be RDM connected with the trainer they can be in different region or different providers. This is also request lane. You can see a request does not just say give me the completion. You will also say which version you will be sending request to and which version you will be accepting and the response will come back with the version and also like exact same information as if as if they are in the same cluster as the trainer. They will be returning tokens log prop like router replay information and many more metadata. The trainer writes immutable version to the broad after optimizer state uh after optimizer step engine pool version and the materialize it locally in the checkpoint layout. So they can just like serve directly the artifact defined version the engine choose how to how to load and shot it. It does not change it does it does not choose a different server version since it will be displaying in a hugging HF will be saved tensor format which is accepted widely by many rollout engines such as sjet and VLM. So we can support any compatible back end attention back end back end different parallelism compatible serving these type and any compatible GPUs there. We can talk more about the scar itself. The scikar is basically what makes a normal roller engine version aware. If the version is already at acceptable commit version, the psychar just proxy the request. If the engine is behind but can they can catch up the psychar just apply the missing transition. If they cannot get there the the psychar just simply return not ready. So this will be supporting elasticity rollout and any idle GPU can just be used with design with this design to support this aggregated roll out. So this is more like a system latency analyst incluster way syncing is fast because they have RDMA. Uh a full checkpoint across regions through network is pretty slow and but if we use the delta if we use exactly what we described previously we can decrease the number of like transfer transfer size from like 500 gigabytes to 5 500 megabytes. So it will be like extremely fast in seconds. So everything above was very general protocol. Stitch is one of very concrete implementation from model that we imple implementing everything above. So on the on the trainer side stitch publish uh what defines a rollout weights version and on the contract side you will be pulling out and record everything on the bulletboard and the only rollout side you will be pulling the latest weights and it start doing way sync across different region and different providers. So stitch itself is a very framework agnostic about trainer and engine and also transport. It's very async first and also agent first agentic first. By doing this we can have rollouts uh engines like autoscale globally. Each one self-s sync it weights serve accept version and return rollout metadata. That means scattered inference cap capacity became one elastic rollout fleet. Instead of being limited by the trainer cluster rollout can be the global pool. So inference capacity can now become our capacity. Last section we have some uh ongoing explorations. So we can see a lot of model providers such as moonshot and also deepc4 they have like they're adopting muan in their post training. Um does the spicy still hold for muan because a lot of thing we discussed previously only for Adam. Second question is async RL at the scale right now we can use the compute across the globe then how like how scalable is the fully async RL this is a very open-ended question there and uh third question is like does it generalize pass because like we have pre-training mid training and SFT like do we have can we apply same paradigm there last but not least we are working on some very hot problem and come work with us you can check the link there model Thank you.