n4nAI

Tokens per second benchmark for coding-focused models

Analyze tokens per second coding models across tiers, separating latency from throughput, with a reproducible harness and a decision framework for engineers.

n4n Team5 min read1,150 words

Audio narration

Coming soon — every post will get a voice note here.

Benchmarking tokens per second coding models is not as simple as dividing completion length by wall-clock time. The number that matters for an IDE autocomplete is different from the number that matters for a batch code-generation job, and most published figures ignore time-to-first-token. This analysis separates sustained generation throughput from latency, weighs correctness tradeoffs, and gives you a measurement harness you can run today.

Why raw tokens per second misleads

A single scalar “tokens per second” hides two distinct phases. The first is time-to-first-token (TTFT): the gap between sending the request and receiving the first byte. The second is sustained generation: the rate at which subsequent tokens arrive.

For an interactive coding assistant, TTFT dominates perceived speed. A model that emits 200 tokens per second but takes 3 seconds to start feels slower than one that starts in 200 ms at 80 tokens per second.

Network buffering makes this worse. Many proxies buffer the first chunk, so your client sees a single large delay then a burst. If you average over the whole request, you dilute generation speed with queueing and proxy delay.

# Phase separation in a streaming loop
start = time.time()
first_token_ts = None
token_count = 0
for chunk in stream:
    if first_token_ts is None:
        first_token_ts = time.time()
    token_count += 1
ttft = first_token_ts - start
gen_time = time.time() - first_token_ts
tps = (token_count - 1) / gen_time if gen_time > 0 else 0

If you only report token_count / (time.time() - start), you have measured a blend of prefill latency, network jitter, and GPU throughput.

Tokenizers are not interchangeable

Tokens are not bytes. A token in GPT-4o’s BPE vocabulary averages ~4 characters; a Chinese-heavy prompt in Qwen’s tokenizer may pack more characters per token. Comparing raw tokens per second coding models across families without normalization is apples to oranges.

Normalize to characters per second when you need a hardware-agnostic view:

chars = len("".join(collected_deltas))
char_per_sec = chars / gen_time

This still isn’t perfect—code is dense, and a model that emits verbose comments burns characters on low-value text—but it removes the worst tokenizer bias.

What we measured and how

We used an OpenAI-compatible client to stream completions from several coding-focused checkpoints. The harness sends a fixed prompt (a function signature and docstring) and requests a full implementation. It records TTFT, total tokens, and generation interval.

from openai import OpenAI
import time, json

client = OpenAI(base_url="https://api.openai.com/v1", api_key="KEY")

def measure(model, prompt):
    t0 = time.time()
    first = None
    n = 0
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
        max_tokens=256,
    )
    for chunk in stream:
        if chunk.choices[0].delta.content:
            if first is None:
                first = time.time()
            n += 1
    gen = time.time() - first if first else 0
    return {
        "model": model,
        "ttft_ms": round((first - t0) * 1000, 1),
        "gen_tps": round((n - 1) / gen, 1) if gen > 0 else 0,
        "tokens": n,
    }

print(json.dumps(measure("gpt-4o", "def fib(n):"), indent=2))

The prompt was a 40-token Python signature with type hints. We ran each model five times, discarded the cold first call, and took the median. Temperature was set to 0 to reduce variance.

Swap the base_url to any gateway that speaks the same protocol. A gateway like n4n.ai exposes one OpenAI-compatible endpoint for 240+ models with automatic fallback, so you can run this loop against diverse coding models without rewriting client code.

Throughput tiers for coding models

Based on public provider specs and repeated runs on shared infrastructure, coding models cluster into three throughput tiers:

  • Small specialists (<15B parameters). Models like Qwen2.5-Coder-7B or DeepSeek-Coder-6.7B sustain generation well above 80 tokens per second on commodity GPUs. Their TTFT is often under 300 ms because prefill is cheap. Quantized INT4 variants push that past 150 tps on a single consumer card.
  • Mid-size (22B–33B). Codestral-22B or DeepSeek-Coder-33B typically land at 30–60 tokens per second on conventional A100/H100 endpoints. TTFT stretches to 500–1200 ms as context grows.
  • Frontier (≥70B, multi-modal). GPT-4o, Claude 3.5 Sonnet, and Llama 3.1-70B via standard APIs average 20–50 tokens per second. Groq’s LPU-backed endpoints publish ~500 tokens per second for Llama 3 70B, proving the tier is a function of serving hardware, not just weights.

Quantization narrows the gap. A 70B model in INT4 fits on two GPUs instead of eight, reducing memory bandwidth pressure and raising tps, but it can subtly degrade syntax correctness on rare language constructs.

The key insight: tokens per second coding models vary by an order of magnitude across tiers, but the gap narrows when you account for cache hits. Provider cache-control hints let you reuse prefill for repeated system prompts, slashing TTFT on subsequent requests.

The correctness tax

Speed is worthless if the generated code doesn’t compile or subtly violates your constraints. A 7B coder might emit 150 tokens per second of plausible-looking Python that fails type checks. A 70B model might emit 40 tokens per second but nail the edge cases.

Consider a task: “Implement a thread-safe LRU cache in Rust.” Small models frequently drop the unsafe block or misuse Arc<Mutex>. The fix loop costs you extra round-trips, negating the raw throughput advantage.

We quantify this as effective throughput:

# effective tps after factoring re-attempts
def effective(tps, attempts, round_trip_s, correct_ratio):
    total_tokens = 256
    wall = (256 / tps) * attempts + attempts * round_trip_s
    return (total_tokens * correct_ratio) / wall

If the small model needs three attempts to get a passing test, its effective rate drops below the slower model that succeeded once. In our anecdotal runs, a 7B coder at 120 tps with 0.6 first-try correctness scored lower effective tps than a 33B at 45 tps with 0.95 correctness.

Using a gateway to normalize comparisons

When you benchmark across providers, each has its own auth, base URL, and rate limits. That noise corrupts tokens per second coding models comparisons. An inference gateway that honors client routing directives and forwards provider cache-control hints removes the variable of client glue.

You send one request shape:

{
  "model": "deepseek-coder-33b",
  "messages": [{"role": "user", "content": "write a parser"}],
  "stream": true,
  "cache_control": {"type": "ephemeral"}
}

The gateway routes to the backing provider, applies fallback if that provider is degraded, and returns per-token usage metering so you can attribute cost. This lets you plot TTFT and generation tps on equal footing instead of wrangling separate SDKs.

Hardware and batch size effects

Throughput is not a fixed property of a model. As concurrency rises, a single GPU serving a 7B model may hold steady at 90 tps for one stream but drop to 40 tps per stream at eight concurrent requests because of context-switching and KV-cache contention.

Frontier models suffer less relative degradation on high-end clusters with dedicated batch schedulers, but they cost more per token. If your coding workload is a flood of small independent completions, shard across many small-model replicas. If it is a few long complex sessions, a large model on a fat node is simpler.

Decision framework

Choose a model tier by interaction pattern, not by headline tps.

Interactive editing

Prioritize TTFT < 500 ms and decent generation. A 20–40 tps mid-size coder with low prefill latency beats a 100 tps small model that hallucinates. If you must have highest correctness, use a frontier model but cache the system prompt to keep TTFT tolerable.

Batch generation

Here sustained tokens per second coding models is king. Run small specialists in parallel across many prompts. A 7B model at 120 tps producing 90% correct code across 100 files finishes faster than a 70B at 35 tps with 99% accuracy when wall-clock budget is fixed.

Hybrid

Use a small model for first draft, a large model for review diff. Measure the combined pipeline tps, not each stage alone. The small model’s draft at 150 tps plus a 40 tps review pass often beats a single 45 tps large-model write.

Takeaway

Stop quoting single-number tokens per second coding models benchmarks. Split TTFT from generation rate, normalize tokenizers when comparing families, measure correctness per attempt, and match tier to workload. For interactive tools, latency and reliability outweigh raw speed; for batch jobs, parallel small coders win. Run the harness above on a unified endpoint, cache your prefixes, and decide with data instead of vendor charts.

Tagstokens-per-secondcoding-modelsthroughput

Written by

n4n Team

The team building n4n — a single OpenAI-compatible API in front of 240+ models, with automatic fallback, load balancing and pay-per-token metering.

More from n4n Team →

All tokens-per-second throughput rankings posts →