LLM Gateway Architecture
How to design a centralized LLM access layer that handles routing, rate limiting, cost tracking, caching, and logging across multiple model providers.
As organizations scale their use of large language models, direct point-to-point integrations between application services and model providers become unmanageable. An LLM gateway is a centralized access layer that sits between all consuming applications and all LLM providers, consolidating cross-cutting concerns into a single infrastructure component.
Origins and History
The concept of an API gateway predates LLMs by over a decade. Early API management platforms such as Apigee (founded 2004, acquired by Google in 2016) and Kong (open-sourced in 2015) established patterns for request routing, rate limiting, and authentication at the network edge. When OpenAI released GPT-3 via API in June 2020, organizations began wrapping these calls in custom proxy layers to manage costs and enforce policies. By 2023, purpose-built LLM gateways emerged as a distinct category. LiteLLM (open-sourced in 2023) provided a unified Python interface across 100+ LLM providers. Portkey (founded 2023) offered a managed gateway with built-in observability, caching, and fallback routing. These tools formalized what many teams had already built internally: a single control plane for all LLM traffic [1][2][3].
Core Components
Request routing determines which model serves each request. Static routing maps use cases to specific models. Dynamic routing selects models based on request characteristics, latency requirements, or cost constraints. Canary routing sends a percentage of traffic to a new model for evaluation before full migration.
Rate limiting and quotas prevent any single team or application from exhausting shared API budgets. The gateway enforces per-consumer limits centrally, smoothing traffic spikes and protecting against runaway loops that could generate thousands of unintended API calls.
Cost tracking logs token usage per request, tagged by team, application, and use case. This enables chargeback models and early alerts when spending deviates from forecasts. Without centralized tracking, organizations routinely discover unexpected bills weeks after the fact.
Caching stores responses for repeated or semantically similar queries. Exact-match caching handles identical prompts. Semantic caching uses embedding similarity to serve cached responses for paraphrased queries, reducing latency and cost for common requests.
Logging and observability captures request and response metadata, latency, token counts, and error rates. This data feeds dashboards for operational monitoring and provides audit trails for compliance.
Implementation Approaches
LiteLLM is an open-source proxy that translates a unified API into provider-specific calls. It supports OpenAI, Anthropic, Cohere, Azure, Bedrock, and many others. Teams deploy it as a sidecar or standalone service and configure routing rules via YAML.
Portkey is a managed gateway that adds reliability features such as automatic retries, fallback chains, and load balancing across providers. It includes a dashboard for cost and performance monitoring without requiring custom instrumentation.
Custom gateways built on NGINX, Envoy, or a lightweight application server offer maximum control. Teams add middleware for authentication, logging, and routing. This approach suits organizations with strict data residency requirements or highly specific routing logic that off-the-shelf tools do not support.
Deployment Considerations
Place the gateway close to your application infrastructure to minimize added latency. Use asynchronous logging to avoid blocking request processing. Encrypt API keys at rest and rotate them through the gateway rather than distributing them to individual services. Implement circuit breakers so that a failing provider triggers automatic failover rather than cascading errors.
Treat the gateway as critical, internet-facing infrastructure, because it holds every provider key your organisation has. In September 2026 CISA added two LiteLLM flaws to its Known Exploited Vulnerabilities catalog: an MCP endpoint authentication bypass (CVE-2026-59822) and CVE-2026-42271, which can be chained with a Starlette request-smuggling bug (CVE-2026-48710) to bypass authentication and execute code [4]. Separately, Wiz found that 294 of 3,074 internet-facing LiteLLM gateways it scanned accepted sk-1234, the example admin key from LiteLLM’s own setup guide [5]. Patch the gateway promptly, never ship example credentials, and keep the admin interface off the public internet.
Sources
- LiteLLM documentation and GitHub repository (2023). Open-source LLM proxy supporting 100+ providers.
- Portkey documentation (2023). Managed AI gateway with observability and reliability features.
- Richardson, C. Microservices Patterns (2018). Foundational API gateway patterns that informed LLM gateway design.
- The Hacker News, “CISA Adds Seven Exploited Flaws…” (3 September 2026): https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html
- The Hacker News, “Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example ‘sk-1234’ Admin Key” (10 September 2026): https://thehackernews.com/2026/09/nearly-1-in-10-exposed-litellm-gateways.html