Hard

Design a Multi-Tenant LLM Inference Platform System Design Interview

Design a global inference service for mixed chat, coding, and long-context workloads across heterogeneous accelerators.

1. Problem Statement

Design a multi-tenant LLM inference platform serving interactive chat, coding agents, and long-document requests. How would you scope the problem?

2. Architecture Discussion Map

Use this as one discussion aid, not a single correct answer. Your design should follow from the requirements, scale, and trade-offs you establish.

Rendering architecture diagram...
Mermaid Source (For AI Bots)
graph LR
    A["Design a Multi-Tenant LLM Inference Platform"]
    A --> F1["Workload classes and SLO admission control"]
    A --> F2["Prefill/decode scheduling and continuous batching"]
    A --> F3["KV-cache placement, paging, and prefix reuse"]
    A --> F4["Heterogeneous accelerator routing and autoscaling"]
    A --> F5["Correctness gates, observability, and multi-region failure handling"]

3. Key Focus Areas

  • 1
    Workload classes and SLO admission control
  • 2
    Prefill/decode scheduling and continuous batching
  • 3
    KV-cache placement, paging, and prefix reuse
  • 4
    Heterogeneous accelerator routing and autoscaling
  • 5
    Correctness gates, observability, and multi-region failure handling

4. What Strong Candidates Should Demonstrate

  • Reason separately about prefill and decode bottlenecks.
  • Balance p99 latency, throughput, cost per token, fairness, and output correctness.
  • Design safe rollouts across model, runtime, and accelerator changes.

Evaluation Guide

This is an evaluation framework, not a single model answer. Strong designs may make different choices when their assumptions and trade-offs are explicit.

SLOs, workload isolation, and capacity

20%

Senior signals

  • Defines TTFT, inter-token latency, p95/p99, throughput, context-length, and tenant fairness targets.
  • Estimates tokens per second, concurrency, memory, and accelerator capacity by workload class.

Common red flags

  • ×Uses QPS alone without token volume, sequence length, or latency decomposition.

Scheduler and memory architecture

30%

Senior signals

  • Explains continuous batching, admission control, prefill/decode behavior, KV paging, fragmentation, and eviction.
  • Prevents long prompts or one tenant from starving latency-sensitive traffic.

Staff-level signals

  • Considers disaggregated prefill/decode pools and network cost of KV transfer.

Fleet routing and economics

25%

Senior signals

  • Routes by model, accelerator capability, cache locality, region, SLO tier, and capacity.
  • Uses autoscaling signals tied to queueing delay, utilization, and cost rather than raw QPS.

Correctness and reliability

25%

Senior signals

  • Canaries model/runtime/quantization changes with output-quality gates and rollback.
  • Covers overload, regional loss, hot tenants, accelerator failures, backpressure, and observability.

Trade-offs to articulate

  • Batch efficiency versus tail latency.
  • Cache locality versus even load distribution.
  • Quantization throughput versus output quality.

Practice follow-up questions

  1. 1.A long-context tenant doubles p99 for chat users. What changes?
  2. 2.How do you detect a fast runtime that silently changes model outputs?

Want interactive feedback?

Practice drawing this system component-by-component on a live whiteboard while the interviewer probes at your target level.

Start Interview

Core Concepts

LLM ServingContinuous BatchingKV CacheAutoscalingMulti-tenancy