Illustrative inference operations studio showing image, video and language workloads beside server cabinets

Project 04 / Production inference

Inference
as a service.

For an AI API provider serving two of India’s largest consumer-internet apps.

← All our work

The platform between
models and applications.

Client
An AI API provider serving two of India’s largest consumer-internet apps
Our work
Inference as a service
Environment
Bare metal, in the client’s data centre
Our role
Design, build and 24×7 operation
Hardware
Accelerator nodes, two scheduling models
Across the stack
Infrastructure · Applied AI

Requests in.
Metered results out.

Every hop emits a span. Every request becomes one metered row with 15 stage timings.

ClientApplication request
GatewayEnvoy
Auth and policyTenant checks
RouterPer-model queues
Model workerAccelerator pools
Metering15 stage timings
Simplified request path

From bare metal
to live inference.

We designed, built and operate the end-to-end inference platform behind a commercial AI API.

30.3M

Metered requests

Since July 2026, each one metered and traceable end to end.

~560k

Requests a day

Peaking near 17 requests per second.

99.99%

Requests without a platform fault

Fewer than 0.01% platform-caused failures over 7 days.

Zero

Dropped requests

During model and platform rollouts.

~0.5s

Platform overhead

Per request, under 1 s regardless of model. Inference itself takes 2.7–4.1 s.

64

Model workers

On 25 accelerator nodes, operated 24×7.

Reported production results, as of 28 October 2026. Request reliability is not an uptime SLA.

Three workloads.
One commercial API.

Image, video and language models behave differently on the same hardware, and every request has to be billable.

01 / Image

High concurrency.

Short requests. Bursty traffic.

02 / Video

Long-running jobs.

Async queues. Large outputs.

03 / Language

Streaming tokens.

OpenAI-compatible API. Per-token metering.

Every layer,
working together.

Six layers, from hardware to the application. Observability and security run across all of them.

Application

OpenAI-compatible API · Operator and customer consoles

Inference platform

Gateway · Auth · Quotas · Routing · Async jobs · Metering

Model serving

Worker pools · Accelerator profiles · Weights · vLLM

Kubernetes platform

Kubespray · Cilium · Rook-Ceph · CNPG Postgres · ClickHouse · Redis · Vault

Hardware enablement

In-house device plugin · Kubernetes DRA · Device telemetry

Hardware

Accelerator servers · Ansible bare-metal provisioning

Two scheduling models.
One fleet.

64 model workers on 25 accelerator nodes, run from a control plane on 3 nodes.

Control plane / 3 nodes

Gateway and state.

Envoy gateway, Postgres, ClickHouse, Redis, Vault and full observability.

Accelerator pool / 20 nodes

32 slices.

Split by an in-house device plugin. Serving image-edit models.

Accelerator pool / 5 servers

Kubernetes DRA.

Scheduled with Dynamic Resource Allocation. Serving image-edit models, with one server spare.

Observability

Prometheus · OpenTelemetry · Tempo · VictoriaLogs · Pyroscope · ClickHouse

60 dashboards covering device, model and request health.

Operated 24×7, with tested alert rules and a runbook per alert group.

Security

Vault · Kyverno · Falco · Cilium policies · Signed digests

Policy enforced at admission. Runtime behaviour watched on every node.

ISO 27001 and SOC 2 assurance.

Every release follows
the same path.

From automated provisioning to real-request tests and signed, stage-to-prod promotion.

  1. 01

    Preflight

    Checks pass

  2. 02

    Provision

    Ansible

  3. 03

    Orchestrate

    Kubespray · Kubernetes

  4. 04

    Devices

    Device plugin · Kubernetes DRA

  5. 05

    Deploy

    Argo CD ApplicationSets

  6. 06

    Serve

    vLLM

  7. 07

    Validate

    Real requests

  8. 08

    Promote

    Signed digests, stage to prod

How upgrades keep traffic moving

Workers drain gracefully before they are replaced, while a hot spare takes traffic. Model and platform rollouts have dropped zero requests.

How the platform handles failures

If a worker crashes mid-request, the request is retried on another free worker within its deadline and the failed worker is quarantined. Devices that trigger health alerts are quarantined and re-probed.

How overload is handled

Traffic beyond capacity waits in a first-come, first-served queue per model, with a bounded wait, then a fast shed. Priority tenants keep reserved slots.

How state and deliveries are protected

Customer webhooks leave through an outbox with leases, backoff, a circuit breaker per target and a full delivery trail. Postgres runs on 3 nodes with synchronous replicas, beside replicated ClickHouse, Redis Sentinel and Ceph, all with verified backups.

How performance is benchmarked

A reproducible harness runs on real hardware. It replays load from anonymised production traffic, uses per-stage timings from metering and produces comparable reports: throughput, latency per stage and cost per request.

A commercial API.
Run as a platform.

The client sells inference. We run the platform underneath it, around the clock.

01 / Production

Live at scale.

A production inference platform serving two of India’s largest consumer-internet apps.

02 / Billing

Every request accounted for.

100% of requests metered and traceable end to end: one row per request, with 15 stage timings.

03 / Repeatable

Two weeks to production.

For a new deployment: discovery on day 1, install on days 2–3, a pilot with real tenants by day 10 and production on day 14.