Skip to main content
SGLang provides OpenAI-compatible APIs to enable a smooth transition from OpenAI services to self-hosted local models. A complete reference for the API is available in the OpenAI API Reference. This tutorial covers the following popular APIs:
  • chat/completions
  • completions
Check out other tutorials to learn about vision APIs for vision-language models and embedding APIs for embedding models.

Launch A Server

Launch the server in your terminal and wait for it to initialize.
Example

Chat Completions

Usage

The server fully implements the OpenAI API. It will automatically apply the chat template specified in the Hugging Face tokenizer, if one is available. You can also specify a custom chat template with --chat-template when launching the server.
Example

Model Thinking/Reasoning Support

Some models support internal reasoning or thinking processes that can be exposed in the API response. SGLang provides unified support for various reasoning models through the chat_template_kwargs parameter and compatible reasoning parsers.

Supported Models and Configuration

Model FamilyChat Template ParameterReasoning ParserNotes
DeepSeek-R1 (R1, R1-0528, R1-Distill)enable_thinking--reasoning-parser deepseek-r1Standard reasoning models
DeepSeek-V3.1thinking--reasoning-parser deepseek-v3Hybrid model (thinking/non-thinking modes)
Qwen3 (standard)enable_thinking--reasoning-parser qwen3Hybrid model (thinking/non-thinking modes)
Qwen3-ThinkingN/A (always enabled)--reasoning-parser qwen3-thinkingAlways generates reasoning
KimiN/A (always enabled)--reasoning-parser kimiKimi thinking models
Gpt-OssN/A (always enabled)--reasoning-parser gpt-ossGpt-Oss thinking models

Basic Usage

To enable reasoning output, you need to:
  1. Launch the server with the appropriate reasoning parser
  2. Set the model-specific parameter in chat_template_kwargs
  3. Optionally use separate_reasoning: False to not get reasoning content separately (default to True)
Note for Qwen3-Thinking models: These models always generate thinking content and do not support the enable_thinking parameter. Use --reasoning-parser qwen3-thinking or --reasoning-parser qwen3 to parse the thinking content.

Example: Qwen3 Models

Example
ExampleOutput:
Output
Setting "enable_thinking": False (or omitting it) will result in reasoning_content being None. Qwen3-Thinking models always generate reasoning content and don’t support the enable_thinking parameter.

Logit Bias Support

SGLang supports the logit_bias parameter for both chat completions and completions APIs. This parameter allows you to modify the likelihood of specific tokens being generated by adding bias values to their logits. The bias values can range from -100 to 100, where:
  • Positive values (0 to 100) increase the likelihood of the token being selected
  • Negative values (-100 to 0) decrease the likelihood of the token being selected
  • -100 effectively prevents the token from being generated
The logit_bias parameter accepts a dictionary where keys are token IDs (as strings) and values are the bias amounts (as floats).

Getting Token IDs

To use logit_bias effectively, you need to know the token IDs for the words you want to bias. Here’s how to get token IDs:
Example
Important: The logit_bias parameter uses token IDs as string keys, not the actual words.

Example: DeepSeek-V3 Models

DeepSeek-V3 models support thinking mode through the thinking parameter:
Example
Example Output:
Output
DeepSeek-V3 models use the thinking parameter (not enable_thinking) to control reasoning output.
Example

Parameters

The chat completions API accepts OpenAI Chat Completions API’s parameters. Refer to OpenAI Chat Completions API for more details. SGLang extends the standard API with the extra_body parameter, allowing for additional customization. One key option within extra_body is chat_template_kwargs, which can be used to pass arguments to the chat template processor.
Example
Streaming mode is also supported.

Logit Bias Support

The completions API also supports the logit_bias parameter with the same functionality as described in the chat completions section above.
Example

Returning Routed Experts (MoE Models)

For MoE models, set return_routed_experts: true in extra_body to return expert routing data. Requires --enable-return-routed-experts server flag. The routed_experts field will be returned in the sgl_ext object on each choice, containing base64-encoded int32 expert IDs as a flattened array with logical shape [num_tokens, num_layers, top_k]. By default this returns [0, seqlen - 1), the full available sequence, because RL workflows need routed experts for the full sequence. Set routed_experts_start_len in extra_body to an absolute prefix length to return only [routed_experts_start_len, seqlen - 1). For example, in multi-turn RL rollouts, routed experts for tokens from previous turns have already been collected, so setting this value avoids unnecessary transfer that cause bottlenecks.
Example

Completions

Usage

Completions API is similar to Chat Completions API, but without the messages parameter or chat templates.
Example

Parameters

The completions API accepts OpenAI Completions API’s parameters. Refer to OpenAI Completions API for more details. Here is an example of a detailed completions request:
Example

Returning Routed Experts (MoE Models)

For MoE models, set return_routed_experts: true in extra_body to return expert routing data. Requires --enable-return-routed-experts server flag. The routed_experts field will be returned in the sgl_ext object on each choice, containing base64-encoded int32 expert IDs as a flattened array with logical shape [num_tokens, num_layers, top_k]. By default this returns [0, seqlen - 1), the full available sequence, because RL workflows need routed experts for the full sequence. Set routed_experts_start_len in extra_body to an absolute prefix length to return only [routed_experts_start_len, seqlen - 1). For example, in multi-turn RL rollouts, routed experts for tokens from previous turns have already been collected, so setting this value avoids unnecessary transfer that cause bottlenecks.

Structured Outputs (JSON, Regex, EBNF)

For OpenAI compatible structured outputs API, refer to Structured Outputs for more details.

Using LoRA Adapters

SGLang supports LoRA (Low-Rank Adaptation) adapters with OpenAI-compatible APIs. You can specify which adapter to use directly in the model parameter using the base-model:adapter-name syntax. Server Setup:
Command
For more details on LoRA serving configuration, see the LoRA documentation. API Call: (Recommended) Use the model:adapter syntax to specify which adapter to use:
Example
Backward Compatible: Using extra_body The old extra_body method is still supported for backward compatibility:
Example
Note: When both model:adapter and extra_body["lora_path"] are specified, the model:adapter syntax takes precedence.
Example