Worker Setup

Workers are the machines that run your processing tasks. MOD supports embedded workers (in the Docker Compose stack) and remote workers.

Supported Platforms

Platform	Status	Notes
Linux (Ubuntu, Debian, RHEL, Fedora)	Fully supported	Recommended for production. GPU drivers auto-installed.
Windows (via WSL2)	Community supported	Install WSL2 + Docker Desktop, then run the setup script inside your WSL terminal. Not officially tested — may need manual troubleshooting. GPU passthrough requires NVIDIA drivers installed on the Windows host.
macOS	Development only	Docker Desktop works for local testing. Apple does not license macOS for server use. No GPU passthrough support.

For production workers, use Linux. The setup script handles everything — Docker, GPU drivers (NVIDIA, AMD, Intel), and the worker binary.

Adding a Remote Worker

1. Go to Dashboard > Workers
2. Click Add Worker
3. Fill in the label and options:
   • Max Uses: 1 for a single server, higher for cloud burst
   • Auto-approve: skip manual approval step
   • Auto-license: activate immediately
4. Copy the setup command
5. Run it on the target machine as root:

curl -sfL https://your-api-url/workers/setup-script | ENROLLMENT_TOKEN=<token> bash

The script will:

• Install Docker if not present
• Detect and install GPU drivers (NVIDIA, AMD, Intel)
• Download the MOD worker binary
• Enroll with the platform
• Set up a systemd service

Verify & manage the worker

Once the script finishes, the worker runs as a systemd service. Check it from the host:

systemctl status mod-worker        # is it running?
journalctl -u mod-worker -f        # live logs (enrollment, heartbeats, task pickup)
systemctl restart mod-worker       # restart after a config change

It should appear as Active in Dashboard → System → Workers within a few seconds of its first heartbeat. If it stays Pending, approval may be required (see the Add a Remote Worker options above) or the enrollment token expired.

Hardware Tags

Workers auto-detect their GPU type (CUDA, ROCm, Intel). You can add custom tags during setup or via environment variable:

WORKER_HARDWARE_TAGS=tensorrt,triton

These tags are used by the scheduler to select the right container variant for each task.

Hardware Benchmarking

New workers are automatically benchmarked when they first connect. The benchmark measures:

• CPU (multi-threaded + single-threaded)
• Memory bandwidth
• Disk I/O (sequential + random read/write)
• GPU compute
• MinIO throughput
• Docker pull speed + container startup time

Results are stored in the worker's Hardware Profile and used by the ML scheduler for optimal task placement.

Monitoring

Workers appear in Dashboard > System > Workers with:

• Status (Active / Offline / Pending)
• Hardware specs (CPU, RAM, GPU model, VRAM)
• Benchmark status (Profiled / Profiling / Not profiled)
• Current activity (idle / running tasks)

Tuning concurrency

Each worker has a Concurrency slider on its detail row. The default is auto-derived from the hardware profile (one slot per GPU on GPU workers, one slot per CPU core block on CPU workers). Override it to throttle a noisy host or scale up a beefy one without re-profiling. Changes take effect on the worker's next heartbeat (~5s).

Platform admins can also tune the fleet-wide scheduler from Dashboard > Settings > AI Configuration > Scheduler — capacity floor, packer aggressiveness, and variance penalty.