lowercase

Signed-off-by: youkaichao <[email protected]>

Author: youkaichao

_posts/2025-08-05-gpt-oss.md

@@ -1,13 +1,13 @@
 ---
 layout: post
-title: "vLLM Now Supports GPT-OSS"
+title: "vLLM Now Supports gpt-oss"
 author: "The vLLM Team"
 image: /assets/logos/vllm-logo-text-light.png
 ---
 
-We're thrilled to announce that vLLM now supports GPT-OSS on NVIDIA Blackwell and Hopper GPUs, as well as AMD MI300x and MI355x GPUs. In this blog post, we’ll explore the efficient model architecture of GPT-OSS and how vLLM supports it.
+We're thrilled to announce that vLLM now supports gpt-oss on NVIDIA Blackwell and Hopper GPUs, as well as AMD MI300x and MI355x GPUs. In this blog post, we’ll explore the efficient model architecture of gpt-oss and how vLLM supports it.
 
-To quickly get started with GPT-OSS, you try our container:
+To quickly get started with gpt-oss, you try our container:
 ```
 docker run --gpus all \
     -p 8000:8000 \
@@ -24,12 +24,12 @@ uv pip install --pre vllm==0.10.1+gptoss \
 
 vllm serve openai/gpt-oss-120b
 ```
-See [vLLM User Guide](https://docs.vllm.ai/projects/recipes/en/latest/OpenAI/GPT-OSS.md) for more detail. 
+See [vLLM User Guide](https://docs.vllm.ai/projects/recipes/en/latest/OpenAI/gpt-oss.md) for more detail. 
 
 
 ### **MXFP4 MoE**
 
-GPT-OSS is a sparse MoE model with 128 experts (120B) or 32 experts (20B), where each token is routed to 4 experts (with no shared expert). For the MoE weights, it uses [MXFP4](https://arxiv.org/abs/2310.10537), a novel group-quantized floating-point format, while it uses the standard bfloat16 for attention and other layers. Since MoE takes the majority of the model parameters, using MXFP4 for MoE weights alone reduces the model sizes to 63 GB (120B) and 14 GB (20B), making them runnable on a single GPU (while often not recommended for the best performance)!
+gpt-oss is a sparse MoE model with 128 experts (120B) or 32 experts (20B), where each token is routed to 4 experts (with no shared expert). For the MoE weights, it uses [MXFP4](https://arxiv.org/abs/2310.10537), a novel group-quantized floating-point format, while it uses the standard bfloat16 for attention and other layers. Since MoE takes the majority of the model parameters, using MXFP4 for MoE weights alone reduces the model sizes to 63 GB (120B) and 14 GB (20B), making them runnable on a single GPU (while often not recommended for the best performance)!
 
 In MXFP4, each weight is represented as a 4-bit floating-point (fp4 e2m1). Additionally, MXFP4 introduces a power-of-two scaling factor for each group of 32 consecutive fp4 values, to represent a wide numerical range. When it runs on hardware, two fp4 values are packed into a single 8-bit unit in memory, and then unpacked on the fly within the matmul kernel for computation.
 
@@ -40,23 +40,23 @@ To efficiently run MXFP4 MoE, vLLM has integrated two specialized GPU kernels vi
 
 ### **Efficient Attention**
 
-GPT-OSS has a highly efficient attention design. It uses GQA with 64 query heads and 8 KV heads. Importantly, the model interleaves full attention and sliding window attention (with window size **128**) with 1:1 ratio. Furthermore, the head size of the model is 64, 50% of the standard head size 128. Finally, each query head has a trained “attention sink” vector.
+gpt-oss has a highly efficient attention design. It uses GQA with 64 query heads and 8 KV heads. Importantly, the model interleaves full attention and sliding window attention (with window size **128**) with 1:1 ratio. Furthermore, the head size of the model is 64, 50% of the standard head size 128. Finally, each query head has a trained “attention sink” vector.
 
 To efficiently support this attention, vLLM has integrated special GPU kernels from FlashInfer (Blackwell) and FlashAttention 3 (Hopper). Also, we enhanced our Triton attention kernel to support this on AMD GPUs.
 
 Furthermore, to efficiently manage the KV cache with different types of attention (i.e., full and sliding window), vLLM has integrated the [hybrid KV cache allocator](https://arxiv.org/abs/2503.18292), a novel technique proposed by the vLLM team. With the hybrid KV cache manager, vLLM can dynamically share the KV cache space between the full attention layers and sliding window attention layers, reducing the potential memory fragmentation down to zero. 
 
 ### **Built-in Tool Support: Agent Loop & Tool Server via MCP**
 
-GPT-OSS includes built-in support for powerful tools, such as web browsing and Python code interpreter. When enabled, the model autonomously decides when and how to invoke these tools, interpreting the results seamlessly.
+gpt-oss includes built-in support for powerful tools, such as web browsing and Python code interpreter. When enabled, the model autonomously decides when and how to invoke these tools, interpreting the results seamlessly.
 
 vLLM natively supports these capabilities by integrating the [OpenAI Responses API](https://platform.openai.com/docs/api-reference/responses) and the gpt-oss toolkit. Through this integration, vLLM implements a loop to parse the model’s tool call, actually invoke the search and code interpreter tools, parse their outputs, and send them back to the model.
 
 Alternatively, users can launch an MCP-compliant external tool server, to let vLLM use the tool server instead of directly leveraging the gpt-oss toolkit. This modular architecture simplifies the creation of scalable tool-calling libraries and services, requiring no internal changes to vLLM.
 
 ### **Looking Ahead**
 
-This announcement is just the beginning of vLLM’s continued optimization for GPT-OSS. Our ongoing roadmap includes:
+This announcement is just the beginning of vLLM’s continued optimization for gpt-oss. Our ongoing roadmap includes:
 
 * Hardening the Responses API