Training RL Models on Self-Built Compute: No Sign of Saturation Yet

Team completes training and inference on self-built compute; RL performance shows no saturation, but limited disclosure warrants cautious interpretation.
A short tweet reveals that a team completed model training and inference services on its own compute and observed that reinforcement learning performance has not yet saturated. The article analyzes two keywords: self-built compute involves cost control, data security, and engineering autonomy, but requires upfront investment in clusters, networking, and inference services; RL not being saturated suggests that scaling training still yields gains, consistent with early RL scaling law research, but the tweet lacks task and metric details, so the conclusion is only indicative. The combination matters for experimental iteration speed and inference autonomy, especially for sampling-intensive RL training. The article highlights information gaps and cautions against over-extrapolation.
From Tweet to Practice: Completing Training and Inference on Self-Built Compute
Recently, a short tweet from Twitter caught the attention of AI practitioners: "That one took some groundwork. Trained and served on our own compute, and RL shows no sign of saturation." The accompanying image only showed a source attribution, but the information was concentrated in two sentences: the team did not rely on external cloud services, but completed model training and deployment on their own compute; at the same time, they observed that the performance curve of reinforcement learning (RL) has not yet saturated—which usually means that increasing compute resources or training steps can still yield gains.

The tweet did not provide specific model scale, compute configuration, or benchmark data, so we can only perform a qualitative analysis based on its statements. However, the two keywords "self-built compute" and "RL not saturated" happen to touch on two core issues in current large model R&D.
Self-Built Compute: Dual Considerations of Cost Control and Autonomy
Choosing to train and run inference on self-built compute rather than fully renting public cloud is usually driven by several considerations. First, long-term cost: when training tasks are continuous and large-scale, the marginal cost of a self-built cluster may be lower than pay-as-you-go cloud services. Second, data and model security: self-built compute means that training data, model weights, and inference requests do not pass through third-party infrastructure. Third, engineering autonomy: teams can perform deep optimization for specific hardware, such as custom communication libraries and adjusted parallelism strategies.
The tweet author used "took some groundwork" to describe this process, implying that self-built compute is not plug-and-play and requires upfront engineering investment. This is consistent with common industry understanding: building a usable training cluster involves hardware selection, network interconnection, storage configuration, and failure recovery mechanisms, while inference services must balance batching, latency, and throughput. Only after completing this groundwork can the team iterate on RL experiments on its own compute.
Network interconnection of the training cluster is the engineering difficulty most easily underestimated in self-built compute. Large model training relies on high-frequency communication between GPUs (such as All-Reduce gradient synchronization), and network bandwidth and latency directly determine training efficiency. Common industry solutions include InfiniBand high-speed interconnection and RoCE (RDMA over Converged Ethernet); the former offers better performance but higher cost. In addition, the choice of parallelism strategy—data parallelism, tensor parallelism, pipeline parallelism, and their combinations—must match the hardware topology, otherwise communication bottlenecks will occur. The "groundwork" mentioned in the tweet largely includes the debugging and optimization of these underlying engineering aspects.
RL Not Saturated: A Signal Worth Noting
The importance of reinforcement learning in the post-training stage of large models continues to rise, especially in reasoning, code generation, and agent tasks. "Saturation" refers to the performance improvement tending to flatten or even stagnate after continuing to increase training compute or data. The tweet's statement that RL shows "no sign of saturation" means that under the team's current setup, scaling up RL training can still bring observable improvements.
This observation aligns with trends in some public research: research on RL scaling laws is still in its early stages, and many teams have reported curves that continue to improve as compute increases. However, it should be noted that the tweet did not disclose specific tasks, reward design, or evaluation metrics, so the judgment of "not saturated" should be understood as the experience of a single team in a specific scenario, not a universal conclusion. Different tasks respond very differently to RL; tasks with sparse rewards or complex environments may encounter bottlenecks earlier.
RL scaling law refers to the empirical patterns of how model performance changes with increases in compute, data, or training steps in reinforcement learning training. Unlike the scaling laws widely validated in the pre-training stage, RL scaling behavior is more complex: it is affected by multiple factors such as reward signal quality, sampling efficiency, and environment diversity. At present, academic research on RL scaling laws is still in an early stage, and public results are mostly concentrated on specific tasks (such as mathematical reasoning and code generation), without a general quantitative prediction framework like that for pre-training. The judgment of "no sign of saturation" in the tweet essentially means that the RL performance curve observed by the team is still in an upward range and has not yet entered a plateau.
The Significance of Combining Self-Built Compute with RL
A potential advantage of running RL training on self-built compute is the speed of experimental iteration. RL training usually requires a large amount of sampling and multiple forward inferences; if compute scheduling is limited by external services, the experiment cycle will be lengthened. A self-built cluster allows the team to allocate resources more flexibly and quickly try different reward functions and training configurations. The phrase "took some groundwork" in the tweet may precisely refer to the engineering effort required to make this process work.
Another angle is the autonomy of inference services. The tweet mentions "served on our own compute," indicating that the model is not only trained on self-built hardware but also hosted for online inference by the team itself. This is especially important for RL applications that require low latency or special data processing (such as interactive agents).
Sampling overhead in RL training is key background for understanding the "advantage of self-built compute." Unlike supervised learning, RL training requires the model to repeatedly interact with the environment to generate trajectories, and each policy update is accompanied by a large amount of sampling and forward inference. Taking RLHF (reinforcement learning from human feedback) as an example, the training process requires frequent calls to the reward model and reference model for scoring, and the inference load is much higher than supervised fine-tuning of the same scale. This means that RL training has higher requirements for compute scheduling flexibility and inference throughput; the pay-as-you-go billing and queuing mechanisms of external cloud services may become bottlenecks for experimental iteration, while self-built clusters can alleviate this problem through resource reservation and priority scheduling.
Information Gaps and Rational Interpretation
It must be acknowledged that the information density of this tweet is limited. There is no model parameter count, no compute scale, no benchmark scores, and no explanation of which stage RL is specifically used for (post-pre-training alignment, reasoning enhancement, or agent training). Therefore, readers should not over-extrapolate. But it at least conveys a directional signal: running RL training and inference on self-built compute is feasible, and in this team's scenario, the gains from RL have not yet peaked. For teams evaluating self-built clusters or increasing RL investment, this is a reference point worth noting.
As RL gains more weight in large model R&D, the intersection of compute autonomy and algorithmic scaling will produce more practical sharing. We look forward to more detailed technical disclosures in the future to verify the scope of applicability of the "not saturated" observation.
One-line Summary
A team completed training and inference on self-built compute, with RL performance showing no saturation, but disclosed information is limited and should be interpreted cautiously.
Paragraph Summary
A short tweet revealed that a team completed model training and inference services on its own compute and observed that reinforcement learning performance has not yet saturated. The article analyzes two keywords: self-built compute involves cost control, data security, and engineering autonomy, but requires upfront investment in building clusters, networks, and inference services; RL not being saturated suggests that scaling up training still yields gains, consistent with early research trends on RL scaling laws, but the tweet did not disclose tasks or metrics, so the conclusion is only indicative. The significance of combining the two lies in experimental iteration speed and inference autonomy, especially suitable for sampling-intensive RL training. The article concludes by emphasizing information gaps and reminding readers not to over-extrapolate.
Related articles

Running Real-Time Local Voice AI on a Single 12GB GPU: Full Pipeline with a 35B Model and Voice Conversation
A developer shows how to run a 35B MoE LLM, Whisper ASR, and Breeze TTS2 locally on a single 12GB GPU, cutting end-to-end voice chat latency from 8s to 2–3s via streaming, parallel synthesis, and quantization, plus Agent tool-calling integration.

Qwen4 Architecture Preview Open-Sourced: 125B Parameters, 512 Experts, Designed for VRAM-Constrained Hardware
Qwen4 isn't released yet, but its architecture is previewed via open-source Qwen3.8 Flash Next: 125B params, 6B activated per token, 512 experts, 262K context, built for VRAM-limited hardware. This article covers official confirmations, key config.json metrics, and local deployment tests on 24G memory.

Run 8K Images on 6GB VRAM! Hands-On Test of Fudan's Open-Source MOSS-Image Model
Fudan OpenMouse team and Shanghai MOSS Intelligence open-source MOSS-Image, a 500M-parameter DT architecture text-to-image model that runs locally on 6GB VRAM with precise text rendering, structured layout control, and 4K Token prompt support—ideal for e-commerce posters and local deployment by individual creators.