Engines
SGLang hosting on the same cluster as vLLM.
Run SGLang from a denv recipe on your GPUs. Same endpoint, same repair and failover. denv does not sell per-token inference.
SGLang is the other open engine denv serves with. It shows up once in the homepage FAQ and, until this page, nowhere you could land from search. This is the page.
A recipe is still one model on one GPU type. Some recipes use vLLM. Some use SGLang. You call either one with an OpenAI-compatible endpoint. denv does not sell tokens, and does not sell the GPU.
SGLang vs vLLM
They solve the same job: load weights, batch requests, manage the KV cache, stream tokens. They are not the same code.
- vLLM is the default in the public H100 measurements on this site. If you are comparing a number you read here, it was vLLM.
- SGLang is often the better fit for heavy prefix reuse and for generation that has to follow a structure. That is a reason to pick a recipe, not a reason to run a second platform.
- You should not run both as snowflake clusters. On denv they are two profiles on one Kubernetes cluster, with the same health checks, the same failover, and the same provider list.
If a model you care about has no SGLang recipe yet, say so. Custom recipes are tested on your GPU type before they serve. The product is early, so “yet” is doing real work in that sentence.
What you still have to bring
A GPU. From Lambda, Nebius, AWS, Hetzner, or a machine you already run. NVIDIA MIG and Kubernetes DRA apply the same way they do for vLLM: a small model can take a slice, a large one should take the card the recipe was tested on.
Write to anup@denv.ai if you want SGLang on a specific model and GPU.