Skip to content
cogniphicSuperintelligenceDownload Forge

ComputeAfterburn

Measure every endpoint. Route on the evidence.

Afterburn connects to the inference endpoints a team already runs (vLLM, SGLang, llama.cpp, Ollama or a hosted API), measures them on its own prompts, and sends each request to the one that keeps its latency limit for the least cost. Every change keeps its evidence.

  • OpenAI-compatible gateway
  • Benchmarks on your prompts
  • Every change a revision

Inside Afterburn

A working Afterburn,
right here. Click around.

This is the console in miniature, running in your browser. Watch traffic go through a route, run a benchmark across four endpoints, decide from it, apply the change and roll it back, or race three answers in the playground.

afterburn/app/Simulated in your browser · sample data

Overview route support-chat · revision 1

Requests

0none failed

First token, p95

–limit 300 ms

Cost

$0.000priced endpoints only

Answering

4 / 4endpoints up

Latest requests live

    Who answered

    First token, recent average

    Everything in this window is simulated with sample endpoints and prompts; nothing is sent anywhere. The real console measures your own endpoints with the same screens.

    The problem

    Tuned once,
    never measured again.

    Most inference endpoints are chosen from a launch-day benchmark and kept long after the models, the engines and the traffic have moved on.

    1. Picked on a hunch

      An endpoint is chosen once, from someone else’s numbers, on prompts that look nothing like yours.

    2. Latency nobody owns

      The 95th percentile creeps up a few milliseconds at a time, and nobody sees it until users do.

    3. No baseline

      When an engine, a model or a provider changes, there is nothing kept to say whether it helped.

    The loop

    Observe. Decide.
    Route. Prove.

    One loop, running all the time. Each panel is laid out the way the console shows it, filled with sample data.

    Observe

    Afterburn measures each endpoint the way users meet it: time to first token, time between tokens, the whole answer and its errors, timed on the stream. Where the engine publishes Prometheus metrics, it reads the queue and the KV cache too.

    Endpoint · vllm-h100Sample data

    model
    Llama 3.1 8B Instruct
    first token, p95
    45 ms
    between tokens, p50
    11 ms
    KV cache in use
    64%
    errors
    0 of 40

    Decide

    A route has a limit: first token under a p95, the whole answer under a p95, an error budget. A benchmark keeps only the endpoints that hold it, ranks them by measured cost per million tokens, and says why the others were turned down.

    Route · support-chatSample data

    limit
    first token p95 ≤ 200 ms · errors ≤ 2%
    vllm-h100
    45 ms · $0.24 / 1M · selected
    llama-cpp-mac
    126 ms · qualifies
    sglang-l40s
    254 ms · over the limit

    Route

    Apps call one OpenAI-compatible URL and name a route as the model. Each request goes to the route's primary endpoint and falls through to the next on errors and timeouts. Every change is a revision; going back is one step.

    Gateway · support-chatSample data

    primary
    vllm-h100
    fallbacks
    llama-cpp-mac, sglang-l40s
    revision
    2, from 1
    rollback
    one step

    Prove

    Every request through the gateway is logged with its endpoint, latency, tokens and cost. When a route changes, Afterburn holds the hour before against the hour after, so each decision keeps its own receipt, good news or not.

    Change · revision 1 → 2Sample data

    first token, p95
    254 → 45 ms
    total, p95
    256 → 47 ms
    cost per 1M output
    $0.16 → $0.24
    requests compared
    36 before, 44 after

    Benchmarks

    Where each endpoint
    breaks the limit.

    A benchmark is the same prompts, at a chosen concurrency, to every endpoint. Run it at several loads and you see where each one stops keeping the route's limit; set it against price and you see which one should serve it. Switch the prompt set: long contexts change the answer.

    60 tokens in, about 140 out, per request

    First token p95 as load riseslog scale · sample data

    50 ms100 ms300 ms1.00 s3.00 s1 at once2 at once4 at once8 at once16 at once32 at oncelimit · 300 msvllm-h100 at 1: 105 msvllm-h100 at 2: 107 msvllm-h100 at 4: 122 msvllm-h100 at 8: 144 msvllm-h100 at 16: 197 msvllm-h100 at 32: 302 mssglang-l40s at 1: 233 mssglang-l40s at 2: 222 mssglang-l40s at 4: 297 mssglang-l40s at 8: 323 mssglang-l40s at 16: 386 mssglang-l40s at 32: 568 msllama-cpp-mac at 1: 451 msllama-cpp-mac at 2: 451 msllama-cpp-mac at 4: 623 msllama-cpp-mac at 8: 1.06 sllama-cpp-mac at 16: 1.80 sllama-cpp-mac at 32: 3.14 sopenrouter-8b at 1: 817 msopenrouter-8b at 2: 738 msopenrouter-8b at 4: 743 msopenrouter-8b at 8: 725 msopenrouter-8b at 16: 1.07 sopenrouter-8b at 32: 1.41 s

    vllm-h100sglang-l40sllama-cpp-macopenrouter-8b

    Cost against speed, 8 at onceSample data

    keeps the limit$0.000$0.166$0.3320 ms547 ms1.09 svllm-h100sglang-l40sopenrouter-8b

    sglang-l40s keeps the limit for the least: $0.177 per 1M output tokens.llama-cpp-mac is unpriced (local) and not on the chart.

    MeasureWhat it isWhere it comes from
    First tokenTime from sending the request to the first generated token, as a user waits for it.Timed on the stream
    Between tokensThe average gap between tokens after the first; how fast the answer reads.Timed on the stream
    TotalTime until the last token, for the whole answer.Timed on the stream
    ThroughputAll output tokens over the endpoint's whole run, at the run's concurrency.Benchmark
    ErrorsRequests that failed, timed out or returned nothing, as a share of all.Benchmark and gateway
    Cost per 1M outWhat a million output tokens cost at your prices, input included, or from hourly capacity.Prices you set
    Queue and KV cacheRequests running and waiting, and how full the cache is, while you measure.Engine /metrics

    The gateway

    One URL for every app.
    The route decides the rest.

    Point any OpenAI client at Afterburn and name a route instead of a model. When the primary fails, the next endpoint takes the request before anything has been sent back, and the response says which endpoint answered.

    { }Your appOpenAI SDK · model: "support-chat"
    afterburnroute support-chat
    vllm-h100primary · 45 ms p9592%
    llama-cpp-macfallback 1 · 126 ms p956%
    sglang-l40sfallback 2 · 254 ms p952%

    Route support-chat with its share of requests by endpoint. Sample data.

    Your stack

    It sits in front.
    It replaces nothing.

    Anything that speaks the OpenAI-compatible API can be measured and routed: the engines a team serves itself, the models on a laptop, and hosted providers. Keys are sealed at rest, and every change is on the audit trail.

    • vLLMServing engine
    • SGLangServing engine
    • TensorRT-LLMServing engine
    • llama.cppLocal models
    • OllamaLocal models
    • LM StudioLocal models
    • OpenRouterHosted models
    • PrometheusEngine metrics

    Questions

    Does Afterburn replace my serving engine?
    No. It sits in front of the endpoints a team already runs and decides which one each request goes to. The models, engines and GPUs stay where they are.
    What does it need from an endpoint?
    An OpenAI-compatible base URL (the one ending in /v1), the model it serves, and a key if it needs one. A Prometheus metrics URL is optional.
    Are the numbers on this page real?
    The panels and screenshots here are sample data, measured against test engines, and every one is labelled. In the console, every number comes from the requests Afterburn sends or forwards for you.
    Can a routing change be undone?
    Yes. Every change to a route is a revision, a fallback is always on the line-up, and rolling back is one step.