Skip to content

Add comprehensive architectural analysis documentation for AReaLite vs Core#5

Merged
zhshgmail merged 3 commits into
litefrom
copilot/fix-859fc418-3fda-4982-a7b6-027648395937
Jul 30, 2025
Merged

Add comprehensive architectural analysis documentation for AReaLite vs Core#5
zhshgmail merged 3 commits into
litefrom
copilot/fix-859fc418-3fda-4982-a7b6-027648395937

Conversation

Copilot AI commented Jul 30, 2025

Copy link
Copy Markdown

This PR addresses the request to analyze the main differences between AReaLite and Core from a software architecture perspective, using the sync examples as a starting point.

Overview

Added a complete documentation set that provides in-depth architectural analysis of AReaL's two parallel systems:

  • AReaLite (/arealite/, /examples/arealite/) - Lightweight, AI researcher-friendly framework
  • Core (/realhf/, /training/) - Full-scale distributed system for production training

Key Findings

The analysis reveals fundamental architectural differences:

Aspect AReaLite Core
Design Philosophy AI-centric, algorithm-focused System-centric, production-focused
Abstraction Layers 3 layers 6 layers
Code Complexity ~233 lines entry point 70 + 300 lines configuration
Learning Curve 1-2 days 1-2 weeks
Target Scale 1-64 GPUs 64-1000+ GPUs

Documentation Structure

📋 docs/architecture/README.md

Navigation index with quick access paths for different user types (AI researchers, industrial teams, system engineers).

📊 docs/architecture/final_summary_report.md

Executive summary with strategic recommendations and clear selection criteria based on team capabilities and project scale.

🔧 docs/architecture/arealite_vs_core_analysis.md

Detailed technical comparison covering:

  • Entry point architecture differences
  • System design patterns (Component-based vs Master-Worker)
  • Synchronous/asynchronous training implementations
  • Code complexity analysis
  • Customization approaches

💻 docs/architecture/code_examples_comparison.md

Real code snippets showing practical differences:

  • AReaLite's direct PyTorch-style APIs vs Core's declarative configuration
  • Single-file customization vs multi-module registration systems
  • SPMD programming model vs distributed worker architecture

📈 docs/architecture/architecture_diagrams.md

Visual representations using Mermaid diagrams to illustrate system architectures, abstraction layers, and training workflows.

Architecture Insights

AReaLite Example (simple and direct):

def main(args):
    rollout = RemoteSGLangEngine(config.rollout)
    actor = FSDPPPOActor(config.actor)
    
    for step in range(max_steps):
        batch = rollout.rollout_batch(data, workflow)
        stats = actor.ppo_update(batch)
        actor.upload_weights(weight_update_meta)

Core Example (declarative and complex):

class PPOMATHConfig:
    def make_dfg(self):
        dfg.add_mfc_dataflow(prompt_mfc, gen_mfc, {"prompt"})
        dfg.add_mfc_dataflow(gen_mfc, ppo_mfc, {"response"})
        return dfg

Selection Guidelines

The documentation provides clear decision criteria:

  • Choose AReaLite for: Research, rapid prototyping, teams with PyTorch background, <64 GPU scale
  • Choose Core for: Production training, >64 GPU scale, teams with dedicated system engineers

Impact

This analysis helps users make informed architectural decisions and understand the "90% functionality, 10% complexity" philosophy that drives AReaLite's design as the foundation for future AReaL API evolution.


💡 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.

…s Core

Co-authored-by: zhshgmail <126103537+zhshgmail@users.noreply.github.com>
Copilot AI changed the title [WIP] 请帮忙分析下arealite与core的主要区别。可以从example下的sync例子入手,arealite在example下有独立的目录,而example下的其他文件则是core的入口。 请从软件架构的角度分析两者的区别 Add comprehensive architectural analysis documentation for AReaLite vs Core Jul 30, 2025
Copilot AI requested a review from zhshgmail July 30, 2025 03:44

@zhshgmail zhshgmail left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved

@zhshgmail zhshgmail marked this pull request as ready for review July 30, 2025 04:25
@zhshgmail zhshgmail merged commit cba2b1e into lite Jul 30, 2025
1 check passed
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>
zhshgmail pushed a commit that referenced this pull request Oct 29, 2025
Addresses Issue #5 from user feedback: AsyncTaskRunner should not support
both QueueAPI and plain queue.Queue. It should REQUIRE QueueAPI/CacheAPI.

Changes:
1. Made output_queue and result_cache REQUIRED parameters (not optional)
2. Typed as QueueAPI and CacheAPI using TYPE_CHECKING
3. Removed default creation logic (no fallback to plain queue.Queue or list)
4. Updated event_factory to pass parameters in correct order
5. Added __future__ annotations for forward references

This enforces the Spring @configuration pattern where the factory is
responsible for creating and configuring queue/cache instances. AsyncTaskRunner
no longer creates defaults - it MUST receive properly configured QueueAPI and
CacheAPI implementations.

Benefits:
- Enforces proper factory pattern
- No mixing of plain queue.Queue and QueueAPI
- Clearer separation of concerns
- Enables future distributed implementations

🤖 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