Skip to content

Document SGLang server startup timing in GRPO training workflow - #6

Draft
zhshgmail with Copilot wants to merge 2 commits into
litefrom
copilot/fix-2fb7ee09-a0ef-4631-9141-19cd635e5c88
Draft

Document SGLang server startup timing in GRPO training workflow#6
zhshgmail with Copilot wants to merge 2 commits into
litefrom
copilot/fix-2fb7ee09-a0ef-4631-9141-19cd635e5c88

Conversation

Copilot AI commented Aug 1, 2025

Copy link
Copy Markdown

This PR addresses the question: "When does the SGLang server get started if GRPO training process triggered by examples/arealite/gsm8k_grpo.py?"

Problem

The startup sequence and timing of SGLang servers in relation to GRPO training was not clearly documented, leading to confusion about when and how inference servers are initialized.

Solution

Added comprehensive documentation and logging to clarify that SGLang servers are started BEFORE the GRPO training script begins execution.

Key Changes

  1. Enhanced Training Script Documentation (examples/arealite/gsm8k_grpo.py)

    • Added detailed docstring explaining SGLang server prerequisites
    • Added runtime validation for AREAL_LLM_SERVER_ADDRS environment variable
    • Clear error messages guide users to proper launcher usage
  2. Improved Launcher Logging (arealite/launcher/local.py)

    • Added explicit "STARTUP SEQUENCE" logging to show timing
    • Users can now see exactly when servers start vs when training begins
    • Better visibility into the asynchronous architecture
  3. Better Engine Documentation (arealite/engine/sglang_remote.py)

    • Enhanced RemoteSGLangEngine with clear prerequisite documentation
    • Improved error messages when servers not found
    • Explicit logging about connecting to pre-existing servers
  4. Comprehensive Guide Update (docs/arealite/gsm8k_grpo.md)

    • Added "SGLang Server Startup Timing" section
    • Step-by-step startup sequence explanation
    • Directly answers the original question with examples

Startup Sequence Clarified

The documented startup sequence is now:

  1. Launcher Invocation: python -m arealite.launcher.local examples/arealite/gsm8k_grpo.py --config ...
  2. SGLang Servers Start First: Launcher starts inference servers based on allocation_mode
  3. Server Readiness: Launcher waits for all servers to be healthy
  4. Environment Setup: Server addresses set in AREAL_LLM_SERVER_ADDRS
  5. Training Script Launch: Only then is gsm8k_grpo.py started
  6. Connection: Training script connects to pre-existing servers via RemoteSGLangEngine

This timing enables AReaL's asynchronous RL training architecture where inference and training are fully decoupled, allowing for better resource utilization and scalability.

Testing

All changes validated with tests confirming proper documentation, error handling, and logging improvements are in place. The original question about SGLang server startup timing is now clearly and definitively answered.


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Co-authored-by: zhshgmail <126103537+zhshgmail@users.noreply.github.com>
Copilot AI changed the title [WIP] When does the SGLang server get started if GRPO training process triggered by examples\arealite\gsm8k_grpo.py? Document SGLang server startup timing in GRPO training workflow Aug 1, 2025
Copilot AI requested a review from zhshgmail August 1, 2025 19:00
zhshgmail pushed a commit that referenced this pull request Oct 29, 2025
This commit addresses design issues #1-#4 by reorganizing interfaces:

## Changes

**1. Moved to api module (proper location for interfaces):**
- `QueueAPI` → `areal/api/queue_api.py`
- `CacheAPI` → `areal/api/cache_api.py`
- `EventType`, `EventContext`, `EventHandler` → `areal/api/event_api.py`
- `QueueFilter` → `Filter` in `areal/api/filter_api.py`

**2. Created separate queue/cache event handler protocols:**
- `QueueEventHandler` + `QueueEventContext` in `areal/api/queue_event_handler.py`
- `CacheEventHandler` + `CacheEventContext` in `areal/api/cache_event_handler.py`

**3. Simplified event_system.py:**
- Now only contains `EventRegistry` class
- Imports interfaces from api module
- No longer defines protocols

**4. Renamed QueueFilter → Filter:**
- Generic name since it applies to both queue and cache
- Located in api module as proper interface
- StalenessFilter now implements Filter protocol

## Why Protocol as superclass? (Answer to #4)

Protocol enables **structural subtyping** (duck typing with types):

```python
from typing import Protocol

class QueueAPI(Protocol):
    def put(self, item): ...

# No need to inherit!
class MyQueue:
    def put(self, item):
        pass

# Type checker accepts this ✓
def foo(q: QueueAPI):
    q.put(1)

foo(MyQueue())  # Works! Structural typing
```

vs ABC (requires inheritance):
```python
from abc import ABC

class QueueAPI(ABC):
    ...

class MyQueue:  # Must inherit from QueueAPI
    ...
```

**Protocol = Interface without inheritance requirement**

## Remaining Work

Still TODO (per user feedback):
- Redesign ProximalRecomputer with propagator pattern (#3)
- Fix AsyncTaskRunner to require QueueAPI/CacheAPI (#5)
- Remove executor._filter_context (#6)
- Add CacheFilter or apply Filter to all operations (areal-project#7, areal-project#8)
- Fix RemoteInfEngine to not expose queue/cache (areal-project#9)
- Merge event_factory into workflow_factory (areal-project#10)
- Add vLLM recompute support (areal-project#11)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants