|
| 1 | +# Embedded Mode |
| 2 | + |
| 3 | +## Background |
| 4 | + |
| 5 | +TuFT is designed to serve as a **transparent compute service layer** for RL training frameworks like Trinity and veRL. In production, TuFT typically runs as a standalone daemon (`tuft launch`), and users must: |
| 6 | + |
| 7 | +1. Write a `tuft_config.yaml` configuration file |
| 8 | +2. Manually start the server with `tuft launch --config ...` |
| 9 | +3. Set the `TINKER_BASE_URL` environment variable for clients to connect |
| 10 | + |
| 11 | +This manual setup creates friction, especially for: |
| 12 | +- **RL framework users** who just want to run training scripts without learning TuFT internals |
| 13 | +- **Development/debugging** workflows where quick iteration is key |
| 14 | +- **CI pipelines** that need reproducible, self-contained environments |
| 15 | + |
| 16 | +**Embedded mode** solves this by providing a `tuft.init()` API — similar to `ray.init()` — that handles service discovery, configuration generation, startup, and connection automatically. |
| 17 | + |
| 18 | +## Two Modes of Operation |
| 19 | + |
| 20 | +| | Daemon Mode | Embedded Mode | |
| 21 | +|---|---|---| |
| 22 | +| How to start | `tuft launch --config ...` | `tuft.init(model=...)` | |
| 23 | +| Lifecycle | Independent process, manually managed | Follows main process, auto-cleanup via atexit | |
| 24 | +| Best for | Production deployments, multi-user shared clusters | Dev/debug, training scripts, CI | |
| 25 | +| Service discovery | User sets `TINKER_BASE_URL` manually | Automatic (env var → address file → process scan → default port) | |
| 26 | + |
| 27 | +**Both modes coexist**: `tuft.init()` first tries to discover an existing daemon. Only when no running service is found does it start an embedded instance. |
| 28 | + |
| 29 | +## Quick Start |
| 30 | + |
| 31 | +```python |
| 32 | +import tuft |
| 33 | + |
| 34 | +# Initialize TuFT — auto-discovers existing service or starts one |
| 35 | +tuft.init(model="/path/to/Qwen2.5-0.5B-Instruct") |
| 36 | + |
| 37 | +# Use the service client for training |
| 38 | +training_client = tuft.create_training_client( |
| 39 | + base_model="Qwen2.5-0.5B-Instruct", |
| 40 | + rank=8, |
| 41 | +) |
| 42 | +# ... your training loop ... |
| 43 | + |
| 44 | +# Optional: explicit shutdown (atexit handles this automatically) |
| 45 | +tuft.shutdown() |
| 46 | +``` |
| 47 | + |
| 48 | +### Other `init()` patterns |
| 49 | + |
| 50 | +```python |
| 51 | +# Connect to a specific running server |
| 52 | +tuft.init(address="http://gpu-cluster:10610") |
| 53 | + |
| 54 | +# Use an existing config file |
| 55 | +tuft.init(config="/path/to/tuft_config.yaml") |
| 56 | + |
| 57 | +# No arguments — relies on env vars or default config file |
| 58 | +tuft.init() |
| 59 | + |
| 60 | +# Get a service client (auto-inits if not already done) |
| 61 | +service_client = tuft.get_service_client() |
| 62 | +``` |
| 63 | + |
| 64 | +## Service Discovery Priority |
| 65 | + |
| 66 | +When `tuft.init()` is called, it tries to find an existing service in this order: |
| 67 | + |
| 68 | +1. `address=...` argument passed to `init()` |
| 69 | +2. `TUFT_ADDRESS` environment variable |
| 70 | +3. Address file at `~/.tuft/tuft_current_server` |
| 71 | +4. Process scan (looks for running `tuft launch` or `uvicorn` processes) |
| 72 | +5. Default port probe: `http://127.0.0.1:10610` |
| 73 | + |
| 74 | +If no service is found, embedded mode starts a new one using configuration from: |
| 75 | + |
| 76 | +1. `config=...` argument passed to `init()` |
| 77 | +2. `TUFT_CONFIG` environment variable |
| 78 | +3. `model=...` argument → auto-generates minimal config |
| 79 | +4. `TUFT_MODEL_PATH` environment variable → auto-generates minimal config |
| 80 | +5. Default config file: `~/.tuft/configs/tuft_config.yaml` |
| 81 | +6. None available → raises `RuntimeError` with helpful guidance |
| 82 | + |
| 83 | +## Environment Variables |
| 84 | + |
| 85 | +| Variable | Description | Default | |
| 86 | +|----------|-------------|---------| |
| 87 | +| `TUFT_ADDRESS` | Address of running TuFT service | — | |
| 88 | +| `TUFT_API_KEY` | API authentication key | Auto-generated | |
| 89 | +| `TUFT_CONFIG` | Path to configuration file | — | |
| 90 | +| `TUFT_MODEL_PATH` | Model path for auto-config generation | — | |
| 91 | +| `TUFT_ENABLE_AUTO_CONNECT` | Enable auto-connect in `get_service_client()` | `"1"` | |
| 92 | +| `TUFT_HOME` | TuFT home directory | `~/.tuft` | |
| 93 | +| `TUFT_HOST` | Server bind address | `127.0.0.1` | |
| 94 | +| `TUFT_PORT` | Server bind port | `10610` | |
| 95 | + |
| 96 | +## Lifecycle |
| 97 | + |
| 98 | +- **Embedded services** are tied to the main process. When the Python process exits (normally or via signal), the embedded TuFT server is automatically terminated via `atexit`. |
| 99 | +- **Daemon services** (`tuft launch`) are independent and persist until manually stopped. |
| 100 | +- `tuft.shutdown()` can be called explicitly to stop an embedded service early. |
| 101 | +- `tuft.init()` is **idempotent** — calling it multiple times is safe (no-op after first success). |
| 102 | + |
| 103 | +## Integration with RL Frameworks |
| 104 | + |
| 105 | +For framework integrations (e.g., Trinity), the pattern is: |
| 106 | + |
| 107 | +```python |
| 108 | +import tuft |
| 109 | + |
| 110 | +# In your framework's initialization code: |
| 111 | +tuft.init(model=model_path, ignore_reinit_error=True) |
| 112 | +service_client = tuft.get_service_client() |
| 113 | + |
| 114 | +# Use service_client as before... |
| 115 | +``` |
| 116 | + |
| 117 | +This requires no changes to the user's workflow — the framework handles TuFT setup transparently. |
0 commit comments