Self-hosted DeepSeek-V3 vs API: cost per token vs speed

DeepSeek-V3 self-hosted vs API cost and speed is the central tradeoff for teams choosing how to run this 671B-parameter Mixture-of-Experts model. The thesis is blunt: self-hosting only wins when you have steady, high-volume traffic and already own the GPUs; for nearly everyone else, the API delivers better latency at lower total cost of ownership.

The hardware reality of self-hosting DeepSeek-V3

Before debating DeepSeek-V3 self-hosted vs API cost and speed, count the GPUs. DeepSeek-V3 ships as open weights. It is a 671B parameter MoE with roughly 37B active parameters per token. That is not a model you run on a single consumer GPU. Even with FP8 quantization, the weights alone approach 670GB, and KV caches for long contexts add more. Practical deployments use 8x H100 80GB (or A100 80GB) with tensor parallelism and often expert offloading.

A minimal vLLM launch looks like this:

python -m vllm.entrypoints.openai.api_server \
  --model deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --quantization fp8 \
  --max-model-len 8192

That command assumes you already have the 8-GPU box provisioned, drivers matched, and a high-speed interconnect (NVLink/InfiniBand) to avoid communication bottlenecks. If you are on cloud, eight H100s at prevailing on-demand rates cost a four-figure sum per day before you serve a single token. Amortized over a month, that is a fixed cost regardless of whether you push 1M or 1B tokens.

Memory bandwidth, not just capacity, governs decode speed. MoE helps by activating few experts, but the router and all-expert weight fetches still stress the interconnect. A node without NVLink will see TTFT balloon under parallel load. Self-hosting also forces you to manage quantization: FP8 keeps quality close to BF16 but needs Hopper or Ada GPUs; INT4 fits on fewer cards but degrades output on reasoning tasks.

API economics: what you pay per token

The API side removes hardware from the equation. DeepSeek’s official API prices DeepSeek-V3 at roughly $0.27 per million input tokens and $1.10 per million output tokens, with cache-hit input at $0.07. Those numbers are public and shift over time, but they set the baseline.

Calling it is trivial:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.deepseek.com",
    api_key="YOUR_KEY",
)

resp = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "Explain MoE routing."}],
    max_tokens=512,
)
print(resp.usage.total_tokens)

A gateway such as n4n.ai collapses 240+ models behind one OpenAI-compatible endpoint and meters per token, which simplifies cost attribution when you mix DeepSeek-V3 with other models. It also honors client routing directives and forwards provider cache-control hints, so a cache_control block in your request can trim input cost on repeated prefixes.

At $1.10 per million output tokens, generating 100M output tokens costs $110. The same volume on self-hosted hardware still requires the full daily GPU burn, and 100M output tokens on a well-tuned 8-GPU node might take days depending on batch size. The API turns a capital and ops problem into a variable cost.

The DeepSeek-V3 self-hosted vs API cost and speed equation flips only when that variable cost exceeds the fixed burn. A quick estimator:

def api_monthly_cost(out_m=0, in_m=0, out_rate=1.10, in_rate=0.27):
    return out_m * out_rate + in_m * in_rate

def gpu_monthly_cost(gpus=8, rate_per_gpu_hr=3.0, hours=720):
    return gpus * rate_per_gpu_hr * hours

# Example: 200M output, 800M input tokens
print(api_monthly_cost(200_000_000 / 1e6, 800_000_000 / 1e6))  # ~$436
print(gpu_monthly_cost())  # ~$17,280 at $3/hr/GPU

The numbers above use illustrative rates; plug your own. The point is the slope.

Latency and throughput: where self-host shines or suffers

Speed is where the naive analysis gets inverted. People assume self-host is faster because it’s “local.” In reality, a single small request to a cold self-hosted DeepSeek-V3 instance faces tensor-parallel startup overhead and kernel warmup. Time-to-first-token (TTFT) can be hundreds of milliseconds to seconds on a lightly loaded 8-GPU server. The API provider runs persistent, heavily batched fleets and typically returns TTFT in the 200–500ms range for small prompts.

Where self-host wins is saturated throughput. If you drive continuous concurrency of 64+ requests with large batches, the per-GPU utilization climbs and you can exceed 10K tokens/sec aggregate on 8 H100s. The API will rate-limit or queue you at extreme volume. But hitting that concurrency requires real product traffic, not a trickle.

A crude latency probe:

import time
def ttft(client, prompt):
    t0 = time.time()
    stream = client.chat.completions.create(
        model="deepseek-chat",
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for chunk in stream:
        if chunk.choices[0].delta.content:
            return time.time() - t0

Run that against both your self-hosted vLLM and the API with identical prompts. You will usually see the API win on isolated calls and self-host win only when you pack the batch. Inter-token latency (tokens/sec after first) is also better on the API for low batch because their fleet is tuned for exactly that; your self-host node may be starved if you underutilize it.

Break-even without fake math

Nobody can quote a universal break-even because GPU rents and API prices move. But the structure is clear: self-host fixed cost = (GPU-hours × rate) + ops salary. API cost = (input + output tokens) × price. Plot your monthly token volume. The lines cross only when token volume is high enough that API variable cost exceeds the always-on GPU bill.

For a team already owning 8 H100s for other work and leaving them idle at night, the marginal cost of self-hosting DeepSeek-V3 is near zero, and the speed is “free.” For a team renting GPUs specifically for this model, the crossing point is typically in the hundreds of millions of tokens per month—and that assumes you maintain high utilization. If your traffic is spiky, the GPU node sits idle between spikes while the API simply scales to zero.

Operational overhead

Self-hosting is not a one-night stand. You own weight downloads (hundreds of GB), quantization config, vLLM upgrades, CUDA mismatches, and fallback when a node dies. DeepSeek-V3 will get fine-tuned successors; you re-deploy. The API provider handles all of that and adds multi-region redundancy.

If your compliance regime forbids sending data to third parties, self-host is the only path. That is a valid reason that overrides cost. But engineering teams often cite “cost” while ignoring the on-call burden of keeping a 671B model served, patching CVEs in the inference stack, and building their own load balancing.

Decision matrix

Takeaway

Run the API until your token bill consistently dwarfs a dedicated GPU cluster’s monthly burn, or until regulation forces your hand. DeepSeek-V3 self-hosted vs API cost and speed favors the API for the vast majority of engineering teams because it converts a heavy infrastructure commitment into a linear, predictable expense while matching or beating latency at low concurrency. Self-host only when you have the GPUs, the throughput, and the compliance need—not because of a spreadsheet hunch.