CoreWeave Cost Tuning

Community-contributed. Not affiliated with, endorsed by, or sponsored by CoreWeave, Inc. CoreWeave is a registered trademark of CoreWeave, Inc.

Overview

Reduce GPU spend by matching a workload's memory, throughput, availability, and latency requirements to the smallest approved capacity. Cost changes must preserve the service SLO and retain a measured rollback path; approximate public prices are planning inputs, not a billing source of truth.

Prerequisites

Read-only access to workload utilization, namespace quota, and billing allocation data.
A named service owner and target SLO for the workload being resized.
Approval for any change that can reduce production capacity or alter availability.

GPU Pricing Reference (approximate)

GPU	Per GPU/hour	Best For
A100 40GB PCIe	~$1.50	Development, smaller models
A100 80GB PCIe	~$2.21	Production inference
H100 80GB PCIe	~$4.76	High-throughput inference
H100 SXM5 (8x)	~$6.15/GPU	Training, multi-GPU
L40	~$1.10	Image generation, light inference

Cost Optimization Strategies

Scale-to-Zero for Dev/Staging

autoscaling.knative.dev/minScale: "0"
autoscaling.knative.dev/scaleDownDelay: "5m"

Right-Size GPU Selection

def recommend_gpu(model_size_b: float, inference_only: bool = True) -> str:
    if model_size_b <= 7:
        return "L40" if inference_only else "A100_PCIE_80GB"
    elif model_size_b <= 13:
        return "A100_PCIE_80GB"
    elif model_size_b <= 70:
        return "A100_PCIE_80GB (4x tensor parallel)"
    else:
        return "H100_SXM5 (8x tensor parallel)"

Quantization to Use Smaller GPUs

Use AWQ or GPTQ quantization to fit larger models on smaller GPUs:

# 70B model at 4-bit fits on single A100-80GB instead of 4x
vllm serve meta-llama/Llama-3.1-70B-Instruct-AWQ --quantization awq

Instructions

Baseline seven days of GPU utilization, queue time, request latency, error rate, and allocated cost by namespace; do not decide from a single peak.
Propose one reversible change—right-size a non-production workload, set a conservative scale-down delay, or run a quantized canary.
Compare the canary against its SLO and budget for an agreed observation window. Promote only if quality, latency, and error rate remain within the published limit.
Record the instance choice, owner, forecast, and rollback trigger in the change record. Revert capacity immediately if the workload breaches its SLO.

Output

A documented utilization baseline and cost allocation for the selected workload.
A right-sizing or scale-to-zero recommendation with its performance guardrails.
A reversible change record containing owner, observation window, and rollback threshold.

Error Handling

Condition	Likely cause	Safe response
Latency rises after downsizing	Insufficient GPU capacity or queueing	Restore the previous resource request and investigate with the service owner.
Cost data is incomplete	Labels or billing export are missing	Stop the optimization; repair allocation labels before making a pricing decision.
Quantized canary loses quality	Model or quantization setting is unsuitable	Route traffic back to the baseline model and retain the evaluation result.
Scale-to-zero causes cold-start failures	Delay or startup budget is too small	Restore minimum replicas for the affected service and tune in a non-production lane.

Examples

Run an approved staging canary with an explicit resource limit, then compare it to the baseline before touching production:

kubectl -n inference-staging patch deployment summarizer \
  --type merge -p '{"spec":{"template":{"spec":{"containers":[{"name":"server","resources":{"limits":{"nvidia.com/gpu":1}}}]}}}}'
kubectl -n inference-staging rollout status deployment/summarizer --timeout=10m

If p95 latency, error rate, or evaluation quality crosses the signed threshold, restore the prior manifest and attach the redacted measurements to the change record.

Resources

Next Steps

For architecture patterns, see coreweave-reference-architecture.

coreweave-cost-tuning