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.