What Workloads and Services Can You Run on CoreWeave?
Updated
CoreWeave's documentation describes a platform for deploying, managing, and observing workloads, organized into two main areas: Infrastructure (the platform layer) and Forge (the development and evaluation layer). If you want to run model training, inference, or isolated compute jobs, the docs point you to specific products depending on whether you need full cluster control, a managed serving endpoint, or a throwaway sandbox.
Workload products
The Workloads section of the documentation lists three named products:
| Product | What it is for |
|---|---|
| SUNK for Slurm on Kubernetes | Running Slurm-style workloads on Kubernetes |
| CoreWeave Inference | Serving models |
| CoreWeave Sandbox | Isolated environments |
These cover the core execution patterns: batch/HPC-style scheduling (SUNK), model serving (Inference), and isolation (Sandbox).
Serverless services
If you don't want to manage infrastructure yourself, the docs describe serverless options:
- Serverless Inference — open-source foundation models through an OpenAI-compatible API, integrated with Weave.
- Post-Training — post-train and fine-tune LLMs with Serverless RL and SFT, and distill specialized models from real application traffic.
- Serverless Sandbox — on-demand, isolated compute environments you create and discard from Python.
The distinction matters: Serverless Inference is for consuming models behind a familiar API, Post-Training is for adapting models to your own data, and Serverless Sandbox is for short-lived isolated execution driven from Python code.
Managing and observing workloads
Two infrastructure products sit alongside the workload layer:
- Mission Control — an agent and an MCP server for investigating your environment and making supported changes.
- Infra Control — CoreWeave Kubernetes Service (CKS) plus the storage and networking products your clusters use.
For monitoring, Observability provides Grafana dashboards, logs, metrics, telemetry, and alerts for fleet hardware and workloads. Access Control covers accounts and authentication, IAM access policies, automated user provisioning, and trust and compliance.
In practice these work together: you define who can act (Access Control), run and adjust workloads (Infra Control, Mission Control), and watch what happens (Observability).
Forge: developing and evaluating
Forge is the development and evaluation side of the platform:
- Weights & Biases — W&B Models for experiment tracking, hyperparameter sweeps, artifacts, reports, and automations, with W&B Weave for LLM and agent evaluation.
- ARIA — an AI research agent that analyzes experiments, explains results, and builds visualizations and reports (marked Preview).
- Agent Lens — intelligent agent observability and improvement.
- Notebooks — reactive Python notebooks for exploring data, prototyping model workflows, and analyzing runs and artifacts.
- Registry — a versioned hub for models and datasets with lineage and deployment handoff.
Where to start
The documentation index splits into Infrastructure (Platform, Mission Control, Infra Control, Observability, Workloads, Access Control) and Forge (the development and evaluation tools above). If your goal is to run a job, start with Workloads or the serverless services; if your goal is to experiment and track results, start with Forge.