### TLDR
LiteLLM is an open-source LLM Gateway with 34K+ stars on GitHub and trusted by companies like NASA, Rocket Money, Samsara,
Lemonade, and Adobe. We're rapidly expanding and seeking our 6th Engineer focused on owning reliability, performance, and
infrastructure stability for the LiteLLM proxy.
### What is LiteLLM
LiteLLM provides an open source Python SDK and Python FastAPI Server that allows calling 100+ LLM APIs (Bedrock, Azure,
OpenAI, VertexAI, Cohere, Anthropic) in the OpenAI format.
We just hit $6M ARR and have raised a $1.6M seed round from Y Combinator, Gravity Fund and Pioneer Fund. You can find more
information on our website, Github and Technical Documentation.
### Why do companies use LiteLLM Enterprise
Companies use LiteLLM Enterprise once they put LiteLLM into production and need enterprise features like Prometheus metrics
(production monitoring) and need to give LLM access to a large number of people with SSO (secure sign on) or JWT (JSON Web
Tokens).
### What you will be working on
Skills: Python, FastAPI, PostgreSQL, Redis, Kubernetes, Prometheus, performance profiling
As the SRE, you'll own the reliability and performance of the LiteLLM proxy in production. Our users run LiteLLM as a
critical gateway handling millions of LLM requests — when it goes down, their entire AI stack goes down. You'll work
directly with the CEO and CTO on critical projects including:
- Fixing OOM issues — e.g. Prisma Query Engine unable to recover from OOMKill in K8s deployments, unbounded in-memory
buffers in spend log transactions
- Solving database connection problems — e.g. database query limits getting reached under load, spend logs loading
extremely slowly, Prisma connection pool exhaustion
- Fixing race conditions and deadlocks — e.g. max_parallel_requests deadlocking API keys after provider timeouts (counter
never released, Redis reset required), PodLockManager releasing another pod's lock, in-memory cache increment race
conditions
- Performance optimization — e.g. update_database() doing 7 deep copies per request in the spend tracking hot path, health
check fan-out overloading startup
- Improving Redis/cache reliability — e.g. budget limiter reading stale Redis data, cache sync issues between in-memory and
Redis layers
- Production monitoring — making Prometheus metrics accurate (fixing missing/inf budget metrics), adding alerting,
improving observability for multi-pod deployments
- Making the proxy self-healing — graceful degradation when DB/Redis is temporarily unavailable, connection retry logic,
proper health checks
### What is our tech stack
The tech stack includes Python, FastAPI, Redis, Postgres, Prisma ORM, Kubernetes, Prometheus, Docker.
### Who we are looking for
- 1-4 years of experience running Python services in production at scale
- Experience debugging OOMs, memory leaks, connection pool issues, and race conditions
- Comfortable with PostgreSQL (query optimization, connection pooling, PgBouncer) and Redis
- Kubernetes experience — you've dealt with pod restarts, resource limits, health probes, and multi-replica coordination
- Familiarity with Prometheus/Grafana for monitoring and alerting
- Passion for open source and user engagement
- Strong work ethic and ability to thrive in small teams
- Eagerness to talk to users and help solve real problems — our GitHub issues are full of production debugging sessions and
you'd be jumping into those directly
Visa sponsorship is not available for this role.
