deploy: 583690d

Author: zhuzilin

.doctrees/blogs/introducing_slime.doctree

@@ -36,7 +36,7 @@ It wasn’t always like this: no one forks PyTorch just for a new dataloader. We
 
 slime views the data sampling in RL differently. We manage all SGLang servers within slime with [sgl-router](https://github.com/sgl-project/sglang/tree/main/sgl-router) and provide an interface for the data generation component, **allowing users to inject custom logic and freely interact with SGLang servers**. Unleash their creativity.
 
-![slime architecture](/images/blog/slime/slime-arch.png)
+![slime architecture](/imgs/arch.png)
 
 With the sgl-router, users only need to send HTTP requests to a single endpoint. By exposing this endpoint, complex agent environments can directly interact with slime through an OpenAI-compatible API — no need to modify the environment, and training-deployment consistency is preserved.
 

.doctrees/environment.pickle

@@ -482,7 +482,7 @@ <h2>Customizability Brings Freedom<a class="headerlink" href="#customizability-b
 <p>A prevailing misconception within the RL community is the need for separate frameworks for different tasks: one for plain math, one for multi-turn tool calling, one for asynchronous training, one for agentic tasks, and so on. Forking and maintaining multiple frameworks is dreadful, leading to time-wasting bugfix cherry-picking, or worse, training crashes by missing patches.</p>
 <p>It wasn’t always like this: no one forks PyTorch just for a new dataloader. We believe the current chaos stems from the trap of dictating how people should build their applications. If we insist on defining a universal template for every rollout scenario, we’ll inevitably create an RL framework that meets only a fraction of real-world needs.</p>
 <p>slime views the data sampling in RL differently. We manage all SGLang servers within slime with <a class="reference external" href="https://github.com/sgl-project/sglang/tree/main/sgl-router">sgl-router</a> and provide an interface for the data generation component, <strong>allowing users to inject custom logic and freely interact with SGLang servers</strong>. Unleash their creativity.</p>
-<p><img alt="slime architecture" src="images/blog/slime/slime-arch.png" /></p>
+<p><img alt="slime architecture" src="imgs/arch.png" /></p>
 <p>With the sgl-router, users only need to send HTTP requests to a single endpoint. By exposing this endpoint, complex agent environments can directly interact with slime through an OpenAI-compatible API — no need to modify the environment, and training-deployment consistency is preserved.</p>
 <p>Regarding training schemes, slime uses Ray for resource management, enabling <strong>colocated</strong> (same GPUs) or <strong>decoupled</strong> (separate GPUs) setups with a single flag (<code class="docutils literal notranslate"><span class="pre">--colocate</span></code>).</p>
 <p>And with Ray’s asynchronous execution via <code class="docutils literal notranslate"><span class="pre">.remote()</span></code>, slime naturally supports asynchronous training. Changing synchronization behavior is as simple as moving the <code class="docutils literal notranslate"><span class="pre">ray.get</span></code> operation. And to make experimenting with different strategies easy, we didn’t wrap the code with trainer classes, but simply exposed the training loop in entrypoint  <code class="docutils literal notranslate"><span class="pre">train.py</span></code>.</p>