Stay updated on AI infrastructure, inference techniques, and performance optimization.

Subscribe to our newsletter

Expert how-tos, deep-dive guides, and real-world stories from the Bento team, to help you build and scale AI at blazing speed.

Sherlock Xu

The rapid rise of large language models (LLMs) has transformed how we build modern AI applications. They now power everything from customer support chatbots to complex LLM agents that can reason, plan, and take actions across tools.For many AI teams, closed-source options like GPT-5 and Claude Sonnet 4 are convenient. With just a simple API call, you can prototype an AI product in minutes — no GPUs to manage and no infrastructure to maintain. However, this convenience comes with <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/llm-inference-basics/serverless-vs-self-hosted-llm-inference">trade-offs</a>: vendor lock-in, limited customization, unpredictable pricing and performance, and ongoing concerns about data privacy.That’s why open-source LLMs have become so important. They let developers self-host models privately, fine-tune them with domain-specific data, and optimize inference performance for their unique workloads.In this post, we’ll explore the top-rated open-source LLMs for chat in 2025. After that, we’ll answer some of the FAQs teams have when evaluating LLMs for production use.<h2>DeepSeek-V3.1</h2><a target="_blank" rel="noopener noreferrer" href="https://huggingface.co/deepseek-ai/DeepSeek-V3.1">DeepSeek-V3.1</a> is one of the best open-source LLMs available today. Built with a Mixture-of-Experts (MoE) architecture, it combines the strengths of predecessors V3 and R1 into a single hybrid model. It features a total of 671B parameters (37B activated) and supports context lengths up to 128K.The model is built on DeepSeek-V3.1-Base, trained with an expanded long-context process: 630B tokens for the 32K phase and 209B tokens for the 128K phase.DeepSeek came to the spotlight during the “DeepSeek moment” in early 2025, when its R1 model demonstrated ChatGPT-level reasoning at significantly lower training costs. Now that DeepSeek-V3.1 integrates reasoning capabilities, it's unclear whether they still plan to release a standalone DeepSeek-R2 model. Learn about <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/the-complete-guide-to-deepseek-models-from-v3-to-r1-and-beyond">the latest DeepSeek model series</a>.Why should you use DeepSeek-V3.1:<ul><li>Hybrid thinking mode: DeepSeek-V3.1 supports both thinking and non-thinking modes. You can switch between fast responses and deeper reasoning simply by changing the chat template. This makes it highly adaptable for different types of chat and agentic tasks.</li><li>Efficient reasoning performance: The V3.1-Think variant achieves reasoning quality on par with DeepSeek-R1-0528 but responds faster. DeepSeek’s internal evaluations show that with chain-of-thought compression training, it reduces output tokens by 20–50% while maintaining similar performance.</li><li>Advanced tool use: Post-training optimization has improved tool usage. V3.1 outperforms both DeepSeek-V3-0324 and DeepSeek-R1-0528 in benchmarks for code agents and search agents. This makes it an ideal choice for building LLM agents.</li><li>Fully open-source: Released under the permissive MIT License, DeepSeek-V3.1 is free to use for commercial, academic, and personal projects. It's an attractive option for teams building self-hosted LLM deployments, especially those looking to avoid vendor lock-in.</li></ul>Also note that DeepSeek-V3.1 requires substantial compute resources. Running it efficiently requires multi-GPU setups, like 8 NVIDIA H200 (141GB of memory) GPUs. This level of infrastructure is cost-prohibitive for smaller teams or individual developers.<h2>gpt-oss-120b</h2><a target="_blank" rel="noopener noreferrer" href="https://huggingface.co/openai/gpt-oss-120b">gpt‑oss‑120b</a> is OpenAI’s most capable open-source LLM to date. With 117B total parameters and a Mixture-of-Experts (MoE) architecture, it rivals proprietary models like o4‑mini. More importantly, it’s fully open-weight and available for commercial use.OpenAI trained the model with a mix of reinforcement learning and lessons learned from its frontier models, including o3. The focus was on making it strong at reasoning, efficient to run, and practical for real-world use. The training data was mostly English text, with a heavy emphasis on STEM, coding, and general knowledge. For tokenization, OpenAI used an expanded version of the tokenizer that also powers o4-mini and GPT-4o.The release of gpt‑oss marks OpenAI’s first fully open-weight LLMs since GPT‑2. It has already seen adoption from early partners like Snowflake, Orange, and AI Sweden for fine-tuning and secure on-premises deployment.Why should you use gpt‑oss‑120b:<ul><li>Excellent performance: gpt‑oss‑120b matches or surpasses o4-mini on core benchmarks like AIME, MMLU, TauBench, and HealthBench (even outperforms proprietary models like OpenAI o1 and GPT‑4o).</li><li>Efficient and flexible deployment: Despite its size, gpt‑oss‑120b can run on a single 80GB GPU (e.g., <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/nvidia-data-center-gpus-explained-a100-h200-b200-and-beyond">NVIDIA H100</a> or <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/amd-data-center-gpus-mi250x-mi300x-mi350x-and-beyond">AMD MI300X</a>). It's optimized for local, on-device, or cloud inference via partners like vLLM, llama.cpp and Ollama.</li><li>Adjustable reasoning levels: It supports low, medium, and high reasoning modes to balance speed and depth.<ul><li>Low:&nbsp;Quick responses for general use.</li><li>Medium:&nbsp;Balanced performance and latency</li><li>High:&nbsp;Deep and detailed analysis.</li></ul></li><li>Permissive license: gpt‑oss‑120b is released under the Apache 2.0 license, which means you can freely use it for commercial applications. This makes it a good choice for teams building custom LLM inference pipelines.</li></ul><h2>Qwen3-235B-A22B-Instruct-2507</h2>Alibaba has been one of the most active contributors to the open-source LLM ecosystem with its Qwen series. Qwen3 is the latest generation, offering both dense and MoE models across a wide range of sizes. At the top of the lineup is <a target="_blank" rel="noopener noreferrer" href="https://huggingface.co/Qwen/Qwen3-235B-A22B-Instruct-2507">Qwen3-235B-A22B-Instruct-2507</a>, an updated version of the earlier Qwen3-235B-A22B’s non-thinking mode.This model has 235B parameters, with 22B active per token, powered by 128 experts (8 active). Note that it only supports non-thinking mode and does not generate <code>&lt;think&gt;&lt;/think&gt;</code> blocks. You can try <a target="_blank" rel="noopener noreferrer" href="https://huggingface.co/Qwen/Qwen3-235B-A22B-Thinking-2507">Qwen3-235B-A22B-Thinking-2507</a> for more complex reasoning tasks.Why should you use Qwen3-235B-A22B-Instruct-2507:<ul><li>State-of-the-art performance: The model sees significant gains in instruction following, reasoning, comprehension, math, science, coding, and tool use. It outperforms models like GPT-4o and DeepSeek-V3 on benchmarks including GPQA, AIME25, and LiveCodeBench.</li><li>Ultra-long context: It features a context length of 262,144 natively and extendable up to over 1 million tokens. This makes it a perfect choice for systems like AI agents, RAG, and long-term conversations. Keep in mind that to process sequences at this scale, you need around 1000 GB of GPU memory (model weights, KV-cache storage, and peak activation memory demands).</li><li>Multilingual strength: Instruct-2507 supports 100+ languages and dialects, with better coverage of long-tail knowledge and stronger multilingual instruction-following than previous Qwen models.</li></ul>The Qwen team does not stop with Instruct-2507. They note a clear trend: scaling both parameter count and context length for building more powerful and agentic AI. Their answer is the Qwen3-Next series, which focuses on improved scaling efficiency and architectural innovations.The first release, Qwen3-Next-80B-A3B, comes in both <a target="_blank" rel="noopener noreferrer" href="https://huggingface.co/Qwen/Qwen3-Next-80B-A3B-Instruct">Instruct</a> and <a target="_blank" rel="noopener noreferrer" href="https://huggingface.co/Qwen/Qwen3-Next-80B-A3B-Thinking">Thinking</a> versions. The instruct variant performs on par with Qwen3-235B-A22B-Instruct-2507 on several benchmarks, while showing clear advantages in ultra-long-context tasks up to 256K tokens.Since Qwen3-Next is still very new, there’s much more to explore. We’ll be sharing more updates later.&nbsp;<hr>&nbsp;Now let’s take a quick look at some of the FAQs around LLMs.<h2>Why should I choose open-source LLMs over proprietary LLMs?</h2>The decision between open-source and proprietary LLMs depends on your goals, budget, and deployment needs. Open-source LLMs often stand out in the following areas:<ul><li>Customization. You can fine-tune open-source LLMs for your own data and workloads. Additionally, you can apply inference optimization techniques such as speculative decoding, prefix caching and prefill-decode disaggregation for your performance targets. Such custom optimizations are not possible with proprietary models.</li><li>Data security. Open-source LLMs can be run locally, or within a private cloud infrastructure, giving users more control over data security. By contrast, proprietary LLMs require you to send data to the provider’s servers, which can raise privacy concerns.</li><li>Cost-effectiveness. While open-source LLMs may require investment in infrastructure, they eliminate recurring API costs. With proper LLM inference optimization, you can often achieve a better price-performance ratio than relying on commercial APIs.</li><li>Community and collaboration. Open-source projects benefit from broad community support. This includes continuous improvements, bug fixes, new features, and shared best practices driven by global contributors.</li><li>No vendor lock-in. Using open-source LLMs means you don’t rely on a single provider’s roadmap, pricing, or availability.</li></ul><h2>How can I optimize LLM inference performance?</h2>One of the biggest benefits of self-hosting open-source LLMs is the flexibility to apply inference optimization for your specific use case. Frameworks like vLLM and SGLang already provide built-in support for inference techniques such as <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/static-dynamic-continuous-batching">continuous batching</a> and <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/speculative-decoding">speculative decoding</a>.But as models get larger and more complex, single-node optimizations are no longer enough. The KV cache grows quickly, GPU memory becomes a bottleneck, and longer-context tasks such as agentic workflows stretch the limits of a single GPU.That’s why <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/the-shift-to-distributed-llm-inference">LLM inference is shifting toward distributed architectures</a>. Optimizations like <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/prefix-caching">prefix caching</a>, <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/kv-cache-offloading">KV cache offloading</a>, <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/data-tensor-pipeline-expert-hybrid-parallelism">data/tensor parallelism</a>, and <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/prefill-decode-disaggregation">prefill–decode disaggregation</a> are increasingly necessary. While some frameworks support these features, they often require careful tuning to fit into your existing infrastructure. As new models are released, these optimizations may need to be revisited.At Bento, we help teams build and scale AI applications with these optimizations in mind. You can bring your preferred inference backend and easily apply the optimization techniques for best price-performance ratios. Leave the infrastructure tuning to us, so you can stay focused on building applications.<h2>What should I consider when deploying LLMs in production?</h2>Deploying LLMs in production can be a nuanced process. Here are some strategies to consider:<ol><li>Model size: Balance accuracy with speed and cost. Smaller models typically deliver faster responses and lower GPU costs, while larger models can provide more nuanced reasoning and higher-quality outputs. Always benchmark against your workload before committing.</li><li>GPUs: LLM workloads depend heavily on GPU memory and bandwidth. For enterprises to self-host LLMs (especially in data centers), NVIDIA A100, H200, B200 or AMD MI300X, MI350X, MI355X are common choices. Similarly, benchmark your model on the hardware you plan to use. Tools like <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/announcing-llm-optimizer">llm-optimizer</a> can quickly help find the best configuration.</li><li>Scalability: Your deployment strategy should support <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/scaling-ai-model-deployment">autoscaling</a> up or down based on demand. More importantly, it must happen with fast cold starts or your user experience suffers.</li><li>LLM-specific observability: Apart from traditional monitoring, logging and tracing, also track <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/llm-inference-metrics">inference metrics</a> such as Time to First Token (TTFT), Inter-Token Latency (ITL), and token throughput.</li></ol><h2>Final thoughts</h2>The rapid growth of open-source LLMs has given teams more control than ever over how they build AI applications. They are closing the gap with proprietary ones while offering unmatched flexibility.At Bento, we help AI teams unlock the full potential of self-hosted LLMs. By combining the best open-source models with tailored inference optimization, you can focus less on infrastructure complexity and more on building AI products that deliver real value.To learn more about self-hosting LLMs:<ul><li><a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/">Read our LLM Inference Handbook</a></li><li>Benchmark and optimize LLM performance with <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/announcing-llm-optimizer">llm-optimizer</a></li><li>Join&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-navigating-the-world-of-large-language-models">the BentoML Slack community</a> to connect with other builders</li><li>Sign up for&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/sign-up-from-blog-navigating-the-world-of-large-language-models">our inference platform</a> and deploy your first LLM in the cloud</li><li><a target="_blank" rel="noopener noreferrer" href="https://link.bentoml.com/contact-us-from-blog-navigating-the-world-of-large-language-models">Schedule a call with us</a> to discuss your LLM use case</li></ul>

Explore the top open-source LLMs and find answers to common FAQs about performance, inference optimization, and self-hosted deployment.

oss-llms.png

Top-Rated LLMs for Chat in 2025

NVIDIA has long been the default choice for GPUs in AI. Still, AMD is working to carve out space in high-performance computing (HPC) and enterprise AI. For teams exploring alternatives to NVIDIA, the AMD MI-series GPU accelerators offer strong hardware capabilities and impressive memory bandwidth.The main challenge lies in the AMD ecosystem. The NVIDIA CUDA platform remains the industry standard, while AMD’s ROCm software stack is still maturing. That said, with the launch of the MI300X and other CDNA-based GPUs, AMD has become a serious contender worth evaluating.In this post, we’ll break down the GPU lineups of AMD, focusing on data center GPUs, and then compare models from the MI100 to the MI300X for different AI use cases.<h2>AMD GPU lineup</h2>Similar to NVIDIA, AMD organizes GPUs into three main categories:<h3>Radeon (Consumer/Gaming)</h3>Radeon GPUs are designed for gaming, graphics, and general-purpose computing. Some developers also experiment with them for AI models, but they’re not suitable for large-scale inference or enterprise workloads. Recent models include the Radeon RX 9070 XT, RX 9070, and RX 9060 XT.<h3>Radeon Pro (Professional)</h3>Radeon Pro GPUs target professional creators, engineers, developers and AI professionals. They power workloads like 3D rendering, video editing, and CAD. While they are not typically deployed in big data centers, they can be used for small-scale AI inference workloads or workstation environments. Current products include the Radeon Pro R9000 series (32 GB of memory; RDNA 4) and W7000 series (up to 48 GB of memory; RDNA 3).<h3>Instinct MI-Series (AMD Data Center GPUs)</h3>The Instinct MI-series is AMD’s line of GPUs built for enterprise-scale AI, HPC, and cloud computing. AMD builds its data center GPUs on a dedicated architecture called CDNA (Compute DNA). Unlike RDNA, which powers gaming and workstation cards, CDNA targets HPC and AI workloads. The focus is on raw compute performance, memory bandwidth, and scaling across multiple accelerators rather than graphics rendering.Notable products include the MI210, MI250, MI300X and MI325X. The latest MI350 series (MI350X, MI355X), launched in June 2025, features 288 GB of HBM3E memory and offers day-zero support for major AI frameworks, libraries, and cutting-edge models.In short: Radeon is for gaming, Radeon Pro is for professional creators, and the Instinct MI-series is AMD’s answer to <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/nvidia-data-center-gpus-explained-a100-h200-b200-and-beyond">NVIDIA data center GPUs</a>.<h2>What is AMD ROCm?</h2>One of the biggest differences between AMD and NVIDIA isn’t just the hardware; it’s the software ecosystem. NVIDIA has CUDA, which has become the industry standard for GPU programming. AMD’s answer is ROCm (Radeon Open Compute Platform).ROCm is an open-source software stack that supports the CDNA architecture. It provides drivers, libraries, and tools that enable developers to run HPC and AI workloads on AMD GPUs. With ROCm, frameworks like PyTorch and TensorFlow can use AMD hardware. This is similar to how they work with CUDA.While ROCm has matured significantly, it still trails CUDA in ecosystem size and polish. As mentioned previously, this gap has been one of the biggest challenges for AMD in competing with NVIDIA.<h2>AMD data center GPU naming conventions</h2>The naming system for AMD data center GPUs is more straightforward than NVIDIA’s.<ul><li>Prefix: Instead of letters tied to architectures (like A100 for Ampere), AMD uses the MI prefix, short for Machine Intelligence.</li><li>Numbers: The number following “MI” indicates the generation:<ul><li>MI100 → 1st generation (CDNA)</li><li>MI200 → 2nd generation (CDNA 2)</li><li>MI300 → 3rd generation (CDNA 3)</li><li>MI350 → 4th generation (CDNA 4)</li></ul>Within each generation, higher model numbers (like MI250 vs. MI210) generally mean more powerful hardware, additional memory, or a different performance tier.</li><li>Suffix: AMD often adds suffixes like X (e.g., MI250X, MI300X, MI350X) to indicate higher-performance versions with more memory or computing power than the base model.</li></ul><h2>AMD GPU comparison: MI250X vs. MI300X vs. MI325X vs. MI350X</h2>Here are some of the most popular AMD data center GPUs for AI inference:<figure class="table"><table style="border-collapse:collapse;border-color:hsl(0, 0%, 0%);border-width:1.5px;text-align:left;"><thead><tr><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:12%;">GPU</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:15%;">Architecture</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:18%;">Memory</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:20%;">Peak Memory Bandwidth</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:35%;">Best For</th></tr></thead><tbody><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">MI100</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">CDNA</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">32 GB HBM2</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">1.2 TB/s</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Entry-level HPC</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">MI250X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">CDNA 2</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">128 GB HBM2e</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">3.2 TB/s</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Mid-range AI inference</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">MI300X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">CDNA 3</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">192 GB HBM3</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">5.3 TB/s</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">High-performance LLM training &amp; inference, HPC</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">MI300A</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">CDNA 3</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">128 GB HBM3 (unified)</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">5.3 TB/s</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Integrated AI/HPC workloads</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">MI325X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">CDNA 3</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">256 GB HBM3E</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">6 TB/s</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Advanced LLM training &amp; inference, FP8</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">MI350X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">CDNA 4</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">288 GB HBM3E</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">8 TB/s</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Ultra-large models, long-context inference, next-gen AI</td></tr></tbody></table></figure>&nbsp;In practice, availability and software support (via ROCm) will play a big role in determining which GPU is the best fit for your team.<h2>How much do AMD MI-Series GPUs cost?</h2>You can find AMD GPUs on several GPU cloud providers and public cloud platforms. However, not all providers carry the full range of AMD data center GPUs, and pricing can differ significantly depending on region, provider, and commitment length.Here is the latest pricing information for the AMD MI325X and MI300X GPUs:<figure class="table"><table style="border-collapse:collapse;border-color:hsl(0, 0%, 0%);border-width:1.5px;text-align:left;"><thead><tr><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:20%;">Provider</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:25%;">GPU</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:30%;">Billing Model</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:25%;">Price</th></tr></thead><tbody><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Vultr</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI325X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">On-demand</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$4.615/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Vultr</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI325X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">36-month prepaid</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$2.00/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Vultr</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI300X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">On-demand</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$3.99/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Vultr</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI300X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">24-month prepaid</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$1.85/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Oracle Cloud</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI300X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">On-demand</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$6.00/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">DigitalOcean</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI300X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">On-demand</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$1.99/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">DigitalOcean</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI300X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">12-month commitment</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$1.49/GPU/hr</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">DigitalOcean</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">AMD MI325X</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">12-month commitment</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$1.69/GPU/hr</td></tr></tbody></table></figure>&nbsp;<blockquote>Note: Pricing data was collected from <a target="_blank" rel="noopener noreferrer" href="https://www.vultr.com/pricing/">Vultr</a>, <a target="_blank" rel="noopener noreferrer" href="https://www.oracle.com/cloud/price-list/">Oracle Cloud</a>, and <a target="_blank" rel="noopener noreferrer" href="https://www.digitalocean.com/pricing/gpu-droplets">Digital Ocean</a> on September 4, 2025, and may change over time.</blockquote>Unlike NVIDIA T4, A100, or H100 GPUs, standardized on-demand pricing for AMD GPUs is harder to find. Still, the MI300X and MI350 series are widely seen as direct competitors to NVIDIA H100 and H200. They often offer a lower cost per unit of memory bandwidth. For enterprise buyers, the total cost of ownership (TCO) may be more favorable with AMD, especially for long-term workloads that benefit from large HBM3/HBM3E memory pools.&nbsp;<hr>&nbsp;Now let’s take a look at some of the most common questions about AMD data center GPUs.<h2>What is the best AMD GPU?</h2>There’s no single “best” AMD GPU. It depends on your workload. For smaller-scale HPC or AI inference, the MI210 or MI250 may be sufficient. For large-scale training and long-context LLM inference, the MI300X (192 GB HBM3) and the MI350X (288 GB HBM3E) are AMD’s top-end options. The best AMD GPU is the one that balances performance, memory, and cost for your specific use case.<h2>Is AMD better than NVIDIA?</h2>Whether AMD or NVIDIA is “better” depends on your priorities:<ul><li>NVIDIA GPUs (like the A100, H100, and H200) dominate in software support, thanks to the CUDA ecosystem and deep framework integration.</li><li>AMD GPUs (MI300X, MI350X) often provide more memory at a lower cost per GPU. This makes them attractive for memory-bound AI workloads such as LLMs with long context windows.</li></ul>In practice, NVIDIA is still the most widely adopted in AI, but AMD is increasingly competitive in HPC and enterprise AI inference.<h2>MI300X vs. H100</h2>The AMD Instinct MI300X and NVIDIA H100 are often compared because they target similar high-performance AI workloads:<ul><li>Memory: MI300X offers 192 GB HBM3, while H100 provides 80 GB HBM2e (with the H200 extending this to 141 GB). This makes MI300X particularly strong for long-context LLMs.</li><li>Ecosystem: H100 has the advantage of CUDA and broad adoption across cloud providers. MI300X relies on ROCm, which has matured but is still catching up in ecosystem support.</li><li>Performance: Benchmarks vary by workload. However, the MI300X is a strong competitor, especially for memory-heavy AI tasks.</li></ul>Before choosing a GPU for AI inference in production, it’s essential to benchmark against your own workloads and goals. This is especially important for optimization with advanced distributed inference techniques such as <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/prefix-caching">prefix caching</a>, <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/kv-cache-offloading">KV cache offloading</a>, or <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/inference-optimization/prefill-decode-disaggregation">prefill–decode disaggregation</a>.<h2>Conclusion</h2>AMD is no longer just a challenger in the GPU market. It’s becoming an essential part of the conversation for AI infrastructure. For teams limited by the supply or pricing of NVIDIA GPUs, the AMD MI300X and MI350 series provide a credible and cost-effective alternative.The real question isn’t “AMD or NVIDIA?” Instead, it is how to build an inference stack that can flexibly adapt to changing models, frameworks, and optimization techniques. Whether or not this inference layer can help you smoothly run workloads with these new technologies may be the most strategic choice of all.At <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/">Bento</a>, our unified inference platform helps enterprises do exactly that. AI teams can seamlessly tap into the most suitable NVIDIA or AMD GPUs at the best rates and availability. Also, they can apply custom inference optimizations to get optimal performance with speed and ease for their unique use cases.Learn more:<ul><li>Read our <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/">LLM Inference Handbook</a> for practical optimization strategies</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-amd-data-center-gpus">Join our Slack community</a> to connect with other AI practitioners</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-amd-data-center-gpus">Schedule a call with our experts</a> if you need tailored advice on GPU inference</li></ul>

Explore AMD GPUs for AI inference. Learn about MI250X, MI300X, MI350X, pricing, performance, and how they compare to NVIDIA for AI and HPC.

amd-gpu-cover-image.png

AMD Data Center GPUs Explained: MI250X, MI300X, MI350X and Beyond

For AI teams that want to self-host Generative AI (GenAI) models like LLMs, one of the most important choices is which GPU to use.In the GPU industry, NVIDIA has established itself as the undisputed leader, especially for AI workloads. It offers a wide range of GPUs that can run AI workloads of different sizes. With so many options, it can be difficult to compare performance and cost, and making the wrong choice can be costly.This is particularly true for workloads like <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/inference-platform-the-missing-layer-in-on-prem-llm-deployments">on-prem LLM deployments</a>. Once you invest in the hardware, it’s hard to undo the decision. Nobody wants to sink money into GPUs that don’t deliver the expected value.In this post, we’ll break down NVIDIA’s GPU product lines, focusing on data center GPUs for AI inference. We’ll compare the most common ones and explain how to weigh performance, memory, and cost for your use case.<h2>What are NVIDIA data center GPUs</h2>When people talk about GPUs for AI inference, they usually refer to NVIDIA data center GPUs. These cards are the backbone of modern AI infrastructure and you’ll often find them in cloud servers and enterprise data centers. They are optimized for large-scale AI workloads and can be shared across teams or scaled to massive clusters.NVIDIA updates its data center lineup every one to three years. Each new generation improves memory, throughput, and efficiency. Well-known examples include the T4, L4, A100, H100, H200, and the new B200. These GPUs dominate AI inference benchmarks and show up on almost every GPU comparison chart for LLMs and GenAI use cases.Many people confuse data center GPUs with other NVIDIA products:<ul><li>GeForce (Consumer/Gaming). Graphic cards like the RTX 5090 or 4090 are built for gaming and general use. They perform well, and some users do run GenAI workloads on them. However, they aren’t made for enterprise-scale AI deployment.</li><li>RTX (Professional). Formerly branded as Quadro, these GPUs target creative professionals in fields like visualization, architecture, and 3D design. They’re built for stability and certified software support, but they’re not aimed at large-scale AI training or inference.</li></ul>In short, GeForce is for gamers, RTX is for professional creators, and data center GPUs are for AI and large-scale computing. If your goal is to train or serve GenAI models, data center GPUs are the right choice.<h2>GPU architectures: Turing, Ampere, Hopper, Lovelace, Blackwell</h2>Each time NVIDIA launches a new GPU generation, it brings a new <a target="_blank" rel="noopener noreferrer" href="https://www.nvidia.com/en-us/technologies/">architecture</a> that improves performance, efficiency, and support for AI workloads. The latest Blackwell architecture packs 208 billion transistors, built on TSMC’s custom 4NP process. Blackwell GPUs feature two reticle-limited dies connected by a 10 TB/s chip-to-chip interconnect, allowing them to operate as a unified single GPU.A quick way to identify NVIDIA data center GPUs is through their names. The naming convention follows a simple pattern that reveals key information about the chip:<ul><li>First letter: Indicates the architecture generation. NVIDIA names each generation after a well-known scientist or mathematician, like Ada Lovelace and Grace Hopper.<ul><li>Turing (T4)</li><li>Ampere (A10, A100)</li><li>Hopper (H100, H200)</li><li>Lovelace (L4)</li><li>Blackwell (B200)</li></ul></li><li>Numbers: The number following the letter usually indicates the model’s relative position in the lineup. Within the same generation, higher numbers generally mean more powerful or feature-rich GPUs.</li><li>Memory suffix: Some models include memory capacity directly in the name, such as the A100 80GB, which helps distinguish variants.</li></ul><h2>Best NVIDIA GPUs for AI inference: A100, H100, H200, B200 compared</h2>Not all NVIDIA GPUs are created for the same purpose. Within each architecture, NVIDIA offers several models aimed at different price, performance, and power targets. In general, higher-numbered models provide more compute power, memory, and features, but they also come at a higher cost.Here are some of the most common NVIDIA data center GPUs used for AI today:<figure class="table"><table style="border-collapse:collapse;border-color:hsl(0, 0%, 0%);border-width:1.5px;text-align:left;"><thead><tr><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:15%;">GPU</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:20%;">Architecture</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:15%;">Memory</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:50%;">Best For</th></tr></thead><tbody><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">T4</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Turing</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">16 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Entry-level inference</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">L4</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Lovelace</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">24 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Energy-efficient inference</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">A10</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Ampere</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">24 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Mid-range inference, AI training</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">A100</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Ampere</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">40 &amp; 80 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">High-performance LLM training &amp; inference, HPC</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">H100</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Hopper</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">80 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Advanced LLM training &amp; inference, FP8</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">H200</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Hopper</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">141 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Ultra-large models, long-context inference</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">B100</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Blackwell</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">192 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Next-gen AI training, inference, HPC</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">B200</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Blackwell</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">192 GB</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">Frontier-scale AI, multi-trillion parameter models</td></tr></tbody></table></figure><h3>GPU benchmarks and comparisons</h3>When choosing between GPUs, benchmark data is one of the most useful points of reference. For LLM inference, the most common metrics are throughput (e.g., Tokens Per Second) and latency (e.g., Time to First Token). NVIDIA publishes general performance numbers for each generation, but they don’t always reflect the nuances of real-world GenAI workloads.That’s why independent GPU comparisons can be especially useful. Benchmarking platforms and inference frameworks (e.g., vLLM and SGLang) often measure GPUs against specific LLMs or inference scenarios. These results can help you see how different compute accelerators perform under practical conditions.<h3>GPU price considerations (T4 vs. A100 vs. H100)</h3>Performance is only part of the equation, and pricing is another key factor. GPU costs can vary widely depending on the provider and purchase model. Many vendors offer on-demand, 1-year, and 3-year committed plans, with large discounts for longer commitments.For example, here’s how the cost of a T4 vs. A100 vs. H100 compares on Google Cloud (us-central1):<figure class="table"><table style="border-collapse:collapse;border-color:hsl(0, 0%, 0%);border-width:1.5px;text-align:left;"><thead><tr><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:35%;">GPU</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:20%;">On-Demand</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:22.5%;">1-Year Commitment</th><th style="background-color:hsl(0, 0%, 90%);border-bottom-style:solid;border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;width:22.5%;">3-Year Commitment</th></tr></thead><tbody><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">NVIDIA T4 (16 GB)</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$255.50/mo</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$160.60/mo</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$116.80/mo</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">NVIDIA A100 (40 GB) — 1× A100 in <code>a2-highgpu-1g</code> VM</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$2,681.57/mo</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$1,689.37/mo</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$938.57/mo</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">NVIDIA A100 (80 GB) — 1× A100 in <code>a2-ultragpu-1g</code> VM</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$3,700.22/mo</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">N/A</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">N/A</td></tr><tr><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">NVIDIA H100 (80 GB) — 8× H100s in <code>a3-highgpu-8g</code> VM</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$64,597.70/mo (≈$8,074.71 per GPU)</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$44,810.08/mo (≈$5,601.26 per GPU)</td><td style="border-color:hsl(0, 0%, 0%);border-width:1.5px;padding:8px;">$28,371.00/mo (≈$3,546.38 per GPU)</td></tr></tbody></table></figure>&nbsp;<blockquote>Note: Pricing was collected on August 27, 2025, and may change. For the latest details, check <a target="_blank" rel="noopener noreferrer" href="https://cloud.google.com/products/calculator?hl=en">Google Cloud's pricing calculator</a>.</blockquote>These numbers make the contrast clear. An entry-level NVIDIA T4 GPU costs just a few hundred dollars per month; in contrast, a high-end H100 cluster can exceed $60,000/month. Ultimately, choosing the right GPU is about balancing performance requirements and cost efficiency, especially for long-term AI deployments.<h3>Why GPU memory matters</h3>When running LLM inference, GPU memory (VRAM) often matters more than raw compute power. One of the biggest reasons is the <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/llm-inference-basics/how-does-llm-inference-work">KV cache</a>. It stores attention keys and values for every token in the input sequence. This way, the model doesn’t need to recalculate them at each decoding step. The result is faster inference, but at the cost of high memory usage.The KV cache size increases linearly with sequence length. This means that long-context scenarios can quickly use up available GPU memory, turning VRAM into the main bottleneck. The amount of GPU memory you have directly determines the size of the models and context windows you can support. For example:<ul><li>H200 (141 GB): Large enough to handle extended context windows without offloading the KV cache to external memory systems.</li><li>T4 and A10 (16–24 GB): Ideal for smaller inference jobs, but they can struggle when sequences get longer.</li></ul>Because of these constraints, the AI community is actively exploring ways to get around memory limits, such as <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefill-decode-disaggregation">prefill-decode disaggregation</a>, <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/kv-cache-offloading">KV cache offloading</a>, and <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/pagedattention">memory-efficient attention</a> techniques.In short, if your workloads involve long prompts or large batch inference, GPU memory capacity is often just as important as raw compute power when choosing a graphic card.<h2>AMD GPU alternatives</h2>While NVIDIA currently dominates the AI GPU market, it’s not the only option. AMD’s MI-series accelerators have made steady progress and now offer competitive performance for certain tasks, particularly in AI training and inference. The challenge for AMD is less about hardware capability and more about software support. The NVIDIA CUDA ecosystem has become the default standard for AI development, with broad framework integration and community adoption.We covered the MI-series GPUs in more detail <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/amd-data-center-gpus-mi250x-mi300x-mi350x-and-beyond">in a separate blog post</a>.<hr>&nbsp;Now let’s take a quick look at some of the common questions about NVIDIA data center GPUs.<h2>What is the best NVIDIA GPU for data centers?</h2>The “best” GPU depends on your workload. For entry-level inference, the T4 or L4 may be sufficient. For fast, high-throughput inference, the A100 and H100 remain industry standards. The H200 and B200 are more advanced and ideal for long-context LLMs and frontier-scale AI models.<h2>What are the GPU data center companies?</h2>NVIDIA supplies data center GPUs to all major cloud providers (AWS, Google Cloud, Microsoft Azure) and to enterprise customers building their own clusters. Other companies like AMD (MI-series GPUs) and Intel (Gaudi accelerators) also offer data center GPUs or accelerators. However, NVIDIA currently dominates the market with the broadest ecosystem and adoption.<h2>Should I build my own GPU data center for AI inference?</h2>Building your own GPU data center can give you more control and potentially lower costs at scale. However, it also means complexity in deployment, scaling, and operations. If you’re considering this path, check out these deep dives:<ul><li><a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/how-to-beat-the-gpu-cap-theorem-in-ai-inference">How to Beat the GPU CAP Theorem in AI Inference</a></li><li><a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/inference-platform-the-missing-layer-in-on-prem-llm-deployments">On-Prem LLM Deployments</a></li></ul><h2>Conclusion</h2>NVIDIA data center GPUs cover a wide spectrum, from entry-level inference on the T4 to frontier-scale inference on the B200. We hope this post gives you a clearer view of the product line and the key considerations when choosing GPUs.At Bento, we offer a wide range of GPU options across regions and cloud providers for AI inference. Our inference platform automatically matches your workloads with the best available GPUs at the most competitive rates, and scales resources up or down as your traffic changes.Learn more:<ul><li>Read our <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/">LLM Inference Handbook</a> to learn practical strategies for faster, cheaper inference.</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-nvidia-data-center-gpus">Join our Slack community</a> and connect with other AI teams working on GPU inference.</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-nvidia-data-center-gpus">Schedule a call with our experts</a> to discuss the right GPU strategy for your workloads.</li></ul>

Understand NVIDIA data center GPUs for AI inference. Compare T4, L4, A100, H100, H200, and B200 on use cases, memory, and pricing to choose the right GPU.

nvidia-data-center-gpus.jpg

NVIDIA Data Center GPUs Explained: From A100 to B200 and Beyond

Understand the differences between DeepSeek-V3, R1, V3.1, and distilled models. Learn how to choose the right model and deploy them securely with BentoML.

deepseek-models.png

The Complete Guide to DeepSeek Models: From V3 to R1 and Beyond

Aaron Pham

Frost Ming

Larme Zhao

LLMs are powerful, but they’re slow during inference. That’s because they’re trained with an autoregressive pattern: generating the next token based on all the previous ones. During inference, this means every new token requires a full forward pass through the model, followed by sampling and then appending that token to the input for the next step. This process is inherently sequential, meaning the model can’t compute future tokens ahead even if the GPU is idle. This leads to high <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/llm-inference-metrics">Inter-Token Latency (ITL)</a> and poor GPU utilization.Speculative decoding offers a solution. By having a small draft model predict several tokens in advance, and letting a larger target model verify them in parallel, you can accelerate the token generation process.In practice, however, we found speculative decoding only delivers the expected speedup if the draft model’s distribution matches closely with the target model. The key is using the right draft model for your workload, which in many real-world cases means training one on your own data.In this post, we’ll walk through:<ul><li>How speculative decoding works and when it helps</li><li>Why acceptance rate is the performance bottleneck</li><li>Our benchmarks with vLLM, SGLang, and EAGLE 3</li><li>Why training a custom draft model is helpful for real-world speedups</li></ul><h2>What is speculative decoding</h2>Speculative decoding is an inference-time optimization technique that speeds up LLM token generation without sacrificing output quality. It’s inspired by the concept of speculative execution, where operations are computed in parallel ahead of time and discarded if unneeded.This technique builds on <a target="_blank" rel="noopener noreferrer" href="https://research.google/blog/looking-back-at-speculative-decoding/">two key observations about LLM inference</a>:<ol><li>LLM inference is memory-bound. Hardware like GPUs can perform hundreds of trillions of operations per second, but their memory bandwidth is much lower. That means these chips often have unused compute capacity while waiting on memory. For transformer-based LLMs, they can only perform a few operations per byte of memory read during inference, which means compute is underutilized.</li><li>Some tokens are easier to predict than others. Many next tokens are obvious from context and can be easily handled by a small model.</li></ol>To take advantage of these facts, speculative decoding uses a draft-then-verify paradigm:<ul><li>Draft model:&nbsp;A smaller, faster model proposes a draft sequence of tokens.</li><li>Target model:&nbsp;The original larger model verifies the draft’s tokens at once and decides which to accept.</li></ul><blockquote>Note: This draft-then-verify idea was first introduced by <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/abs/1811.03115">Stern et al. (2018)</a>, and later extended into a statistically grounded technique called speculative sampling by <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/pdf/2302.01318">DeepMind</a>. Speculative decoding is the application of speculative sampling to inference from autoregressive models, like transformers.</blockquote>Here is how it works in more details:<figure class="image image_resized" style="text-align:center;width:75%;"><img src="/uploads/specculative_decoding_flow_5c2970a026.png" alt="specculative-decoding-flow.png" srcset="/uploads/xsmall_specculative_decoding_flow_5c2970a026.png 64w, /uploads/thumbnail_specculative_decoding_flow_5c2970a026.png 161w, /uploads/small_specculative_decoding_flow_5c2970a026.png 500w, /uploads/medium_specculative_decoding_flow_5c2970a026.png 750w, /uploads/large_specculative_decoding_flow_5c2970a026.png 1000w, /uploads/xlarge_specculative_decoding_flow_5c2970a026.png 1920w" sizes="100vw" width="1920"></figure><ol><li>The draft model proposes the next <code>k</code> tokens based on the current context.</li><li>The target model then verifies these tokens in parallel.<ul><li>If it agrees with the draft model’s prediction at position <code>i</code>, the token is accepted.</li><li>If not, the token is rejected, and all later tokens in the draft are discarded.</li></ul></li><li>The target model generates the next token after the last accepted one, and the cycle continues.</li></ol>This technique parallelizes the expensive part (i.e. the forward pass) and replaces many slow sequential steps with a single verification, thus reducing ITL. It is helpful to interactive and latency-sensitive applications, such as:<ul><li>AI chatbots: Faster token generation means quicker replies, more natural conversations, and better user experience.</li><li>Code completion tools: Developers expect instant suggestions. Even a slight delay per token can disrupt flow and reduce usability.</li><li>AI agents and multi-turn reasoning: Agents often make multiple calls per task. Reducing ITL at each step speeds up decision-making end-to-end.</li><li>Speech-to-text pipelines: These models decode audio in long sequences. Lower ITL directly improves perceived latency and output speed.</li></ul><h2>Why acceptance rate is important to speculative decoding performance</h2>Speculative decoding promises faster LLM inference, but only when it works well. And its effectiveness depends on a critical factor: how often the target model accepts the draft model’s predictions.This is known as the acceptance rate (α). It is not a fixed number and can vary based on several factors like decoding strategy (e.g., nucleus vs. random sampling) and application domains.<ul><li>High α means:<ul><li>More tokens accepted per speculative round</li><li>Fewer target model forward passes</li><li>Lower latency, higher throughput, better GPU utilization</li></ul></li><li>Low α means:<ul><li>Many draft tokens are rejected</li><li>Time and compute wasted on both generating and verifying unused tokens</li><li>Falling back to sequential decoding more frequently, which defeats the point of speculative acceleration</li></ul></li></ul><h3>Simulate the effect of acceptance rate</h3>To understand how acceptance rate impacts performance, we patched <a target="_blank" rel="noopener noreferrer" href="https://github.com/vllm-project/vllm">vLLM</a> to simulate speculative decoding using theoretical acceptance rates. We bypassed the draft model and tested different speculative token counts (the number of tokens proposed by the draft model each step).Here’s how we set it up:<ul><li>Target model: Llama-3.1-8B-Instruct</li><li>Acceptance rates (α): 0.2, 0.4, 0.6, 0.8</li><li>Speculative token counts (γ): 3, 5, 7, 9</li><li>Baseline E2E latency (E2EL) without speculative decoding: 4065.42 ms</li></ul>We evaluated the following metrics:<ul><li>Output throughput (Output Tokens Per Second/TPS)</li><li>E2EL in milliseconds</li><li>Speedup relative to baseline</li><li>Acceptance length (τ): The average number of tokens accepted per round of decoding. According to the paper <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/pdf/2211.17192">Fast Inference from Transformers via Speculative Decoding</a>, theoretically, it is calculated with the formula:<figure class="image"><img src="/uploads/acceptance_length_formula_spec_decoding_5cbf21f17f.png" alt="acceptance-length-formula-spec-decoding.png" srcset="/uploads/xsmall_acceptance_length_formula_spec_decoding_5cbf21f17f.png 64w, /uploads/thumbnail_acceptance_length_formula_spec_decoding_5cbf21f17f.png 245w, /uploads/small_acceptance_length_formula_spec_decoding_5cbf21f17f.png 500w, /uploads/medium_acceptance_length_formula_spec_decoding_5cbf21f17f.png 750w, /uploads/large_acceptance_length_formula_spec_decoding_5cbf21f17f.png 1000w" sizes="100vw" width="1000"></figure></li></ul>Here are the results:<figure class="image"><img src="/uploads/simulated_speculative_decoding_d4d5f52a19.png" alt="simulated-speculative-decoding.png" srcset="/uploads/xsmall_simulated_speculative_decoding_d4d5f52a19.png 64w, /uploads/thumbnail_simulated_speculative_decoding_d4d5f52a19.png 157w, /uploads/small_simulated_speculative_decoding_d4d5f52a19.png 500w" sizes="100vw" width="500"></figure>Key takeaways:<ol><li>The higher the acceptance rate (α), the greater the speedup.</li><li>Speculative token counts (γ) should be increased only when the acceptance length is high. Otherwise, performance may be negatively affected.</li><li>Latency drops and throughput rises almost linearly with α.</li><li>At α ≥ 0.6 and γ ≥ 5, we observed 2–3× speedups over baseline decoding.</li></ol>But how do you actually achieve a high acceptance rate in the real world?<h2>Why the draft model makes or breaks speedup</h2>In the previous section, we showed that speculative decoding can offer up to 3× speedups, but only in theory. Those results were based on simulated acceptance rates, not actual draft model performance.To understand how this works in practice, we ran real-world benchmarks using both vLLM and SGLang with and without their respective EAGLE 3 draft models.<blockquote>Note: <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/pdf/2503.01840">EAGLE</a> improves on vanilla speculative decoding. It reuses the top-layer features of the target model (the features before the LM head). It trains the draft model to predict the next feature and then uses the target model’s LM head to obtain the draft token. By leveraging the rich information from the target model, EAGLE achieves significantly better acceleration compared to vanilla speculative sampling.</blockquote>Here is our test setup:<ul><li>Target model: Llama-3.1-8B-Instruct</li><li>Speculative token count (γ): 3</li><li>Datasets: MT-Bench, HumanEval, CNN/DailyMail</li><li>Baseline: Regular decoding without EAGLE 3</li><li>Compared against: EAGLE 3-enabled draft models</li></ul>Here are the measured results:<figure class="image"><img src="/uploads/speculative_decoding_results_in_practice_7bdf31c614.png" alt="speculative-decoding-results-in-practice.png" srcset="/uploads/xsmall_speculative_decoding_results_in_practice_7bdf31c614.png 64w, /uploads/thumbnail_speculative_decoding_results_in_practice_7bdf31c614.png 166w, /uploads/small_speculative_decoding_results_in_practice_7bdf31c614.png 500w" sizes="100vw" width="500"></figure>Despite achieving ~2× speedups, we found that real-world acceptance lengths (τ) were lower than ideal. Based on the test results in the previous section, the acceptance rates (α) were likely in the 0.6–0.8 range, not the near-perfect values used in theory.We believe two major factors limit acceptance rates when using out-of-the-box EAGLE 3 draft models:<ul><li>Task domain mismatch: The datasets we used above are generic. If your dataset has specific characteristics, which is often the case in practice, the acceptance rate could be lower and the speedup might be worse.</li><li>Context length mismatch: EAGLE 3 draft heads were not optimized for long contexts. If your use case involves long prompts, acceptance rates drop due to lack of alignment.</li></ul>Based on these findings, our conclusion is:<ul><li>To consistently achieve high acceptance rates and up to 3x performance gains, you need to have the right draft model. For this purpose, you can train a custom draft model on your own data. This ensures it learns the patterns of your specific workload, leading to higher acceptance rates and faster inference.</li><li>However, if your current model already yields a good acceptance rate for your use case, you don’t need extra training. Speculative decoding will still deliver decent speedups.</li></ul><h2>How to train your own draft model</h2>To validate our conclusion and test speculative decoding in practice, we trained a custom EAGLE 3 draft model using the official <a target="_blank" rel="noopener noreferrer" href="https://github.com/SafeAILab/EAGLE">EAGLE repository</a>.<ul><li>Dataset: A combined one of UltraChat-200k and ShareGPT</li><li>Hardware: Training with 8 H200 GPUs</li><li>Result: Achieved an acceptance rate (α) of 3.02 with 5 speculative tokens (γ = 5)</li></ul>We successfully replicated EAGLE 3 and observed the hypothetical speedup in downstream inference benchmarks.Here is how we did it.<h3>Prepare the dataset</h3>The EAGLE repo provides a script to build a training dataset by mixing UltraChat-200k and ShareGPT. Run the <a target="_blank" rel="noopener noreferrer" href="https://github.com/aarnphm/EAGLE/blob/main/eagle/train/eagle3/prepare.py">script</a> to convert both datasets to a shared ShareGPT-style format:<pre><code class="language-bash">python eagle/train/eagle3/prepare.py</code></pre>Note that:<ul><li>The default configuration is used for training on a single GPU. If you have 8 H200 GPUs, set <code>gradient_accumulation_steps = 8</code>. This helps fully utilize available VRAM and accelerates the epoch. If you're using fewer GPUs, adjust this value accordingly.</li><li>For long-context support (e.g. 8k+ tokens), some customization is required in DeepSpeed to ensure proper context window handling.</li><li>Optionally, set up wandb for tracking. If you don’t want to use it, comment out the wandb logic in the training code.</li></ul><h3>Evaluate the trained model</h3>Once configured, training can be launched. After 10 epochs, you’ll be ready to validate your draft model.<ol><li>Copy your trained config into the state directory:<pre><code class="language-bash">cp config.json output_dir/state_&lt;epoch&gt;/config.json</code></pre></li><li>Run vLLM with EAGLE 3:<pre><code class="language-bash">VLLM_USE_V1=1 VLLM_LOGGING_LEVEL=DEBUG \
vllm serve meta-llama/Llama-3.1-8B-Instruct \
 --max-model-len 8192 \
 -tp 1 \
 --speculative-config '{"method": "eagle3", "model": "path/to/state_dir", "num_speculative_tokens": 5, "draft_tensor_parallel_size": 1}'</code></pre></li><li>In a separate terminal, benchmark the setup and here is an example command:<pre><code class="language-bash">vllm bench serve \
 --save-result \
 --sharegpt-output-len 1024 \
 --dataset-name sharegpt \
 --endpoint-type openai \
 --ramp-up-strategy linear \
 --ramp-up-start-rps 1 \
 --ramp-up-end-rps 2 \
 --label eagle3-2048-o1024-tp1 \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --dataset-path ~/path/to/your/datasets \
 --endpoint-type openai-chat \
 --endpoint "/v1/chat/completions"</code></pre></li></ol><h2>Conclusion</h2>Speculative decoding is a powerful technique to speed up LLM inference. It’s also a fast-moving research area. Other methods like <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/pdf/2404.16710">LayerSkip</a> and <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/pdf/2502.09419v1">MTP</a> are being actively explored and may offer further gains in the future.Through both simulation and real-world benchmarks, we showed that:<ul><li>High acceptance rates are necessary to realizing meaningful gains, often 2–3× in throughput and latency.</li><li>Generic, out-of-the-box draft models fall short when used in domain-specific or long-context workloads.</li><li>Training your own draft model on your own data is helpful to aligning the draft model with your use case and achieving optimal performance.</li></ul>If your LLM application is latency-sensitive, don’t just plug in speculative decoding as a drop-in solution. Benchmark it. Tune it. Train your draft model if necessary.Still have questions?<ul><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-speculative-decoding">Join our Slack community</a> to learn from others and discuss speculative decoding</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-speculative-decoding">Schedule a call</a> with our inference experts</li><li><a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/">Read our LLM Inference Handbook</a> to learn more inference optimization techniques</li></ul>

Learn what speculative decoding is, how it speeds up LLM inference, why draft model choice matters, and when training your own delivers up to 3× performance gains.

spec-decoding.png

Get 3× Faster LLM Inference with Speculative Decoding Using the Right Draft Model

Chaoyu Yang

At Bento, we work closely with enterprises across industries like healthcare, finance, and government. Many of them choose to move LLM workloads into on-prem environments, and for good reasons:<ul><li>Data privacy &amp; compliance. LLMs now power critical applications like AI agents and RAG pipelines. These systems often need direct access to sensitive data, making privacy and compliance non-negotiable. Running inference on-prem keeps both data and models entirely within a controlled environment.</li><li>Consistent and reliable performance. Dedicated resources ensure low-latency, predictable responses, without relying on external APIs or shared cloud infrastructure. AI teams can fully control, customize, fine-tune, and integrate models with internal systems.</li><li>Cost reduction. While initial setup requires high investment, on-prem deployments can become far more cost-effective than usage-based cloud APIs in the long run.</li></ul>But here’s the catch: setting up an on-prem LLM stack isn’t just about buying GPUs and running vLLM on Kubernetes. The real challenge lies in everything that comes after: scaling workloads, maximizing GPU utilization, optimizing performance, and serving models reliably in production.And that’s where most AI teams discover a missing piece in the stack.<h2>The modern on-prem stack for LLM deployments</h2>To run LLMs on-prem, you need to orchestrate a reliable, scalable, and efficient inference stack, which entails three core layers working together:<ol><li>Infrastructure layer: This is the physical foundation that powers your system, including servers, GPUs, networking, storage, power, and cooling.</li><li>Container orchestration layer: Platforms like Kubernetes and OpenShift manage containerized workloads, schedule jobs, and balance resource usage across nodes. This layer abstracts the underlying hardware and provides deployment primitives for your system.</li><li>Inference platform layer: This is the often-overlooked part where things fall short. It:<ul><li>Manages model deployments and iterations</li><li>Optimizes inference performance, with <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/getting-started/choosing-the-right-inference-framework">different runtimes</a> and distributed serving strategies, like <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefill-decode-disaggregation">prefill-decode disaggregation</a> and <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefix-caching">KV aware routing</a></li><li>Handles autoscaling and optimizes cold starts &amp; resource utilization</li><li>Provides observability for LLM performance metrics and costs</li></ul></li></ol><figure class="image image_resized" style="width:75%;"><img src="/uploads/on_prem_llm_deployment_stack_e54655d0eb.png" alt="on-prem-llm-deployment-stack.png" srcset="/uploads/xsmall_on_prem_llm_deployment_stack_e54655d0eb.png 64w, /uploads/thumbnail_on_prem_llm_deployment_stack_e54655d0eb.png 185w, /uploads/small_on_prem_llm_deployment_stack_e54655d0eb.png 500w, /uploads/medium_on_prem_llm_deployment_stack_e54655d0eb.png 750w, /uploads/large_on_prem_llm_deployment_stack_e54655d0eb.png 1000w" sizes="100vw" width="1000"></figure>Most organizations already have layers 1 and 2 in place. Layer 3 matters for long-term scaling but it’s often missing or built ad hoc.<h2>Risks of on-prem LLM deployments and how an inference platform can help</h2>Moving LLMs on-prem promises better control and cost efficiency, but it also shifts more responsibility to your infrastructure/platform team. Let’s break down the most common pain points and how an inference platform helps solve them.<h3>1. Slow time to market</h3>LLMs are evolving rapidly. New frontier models and inference optimization techniques are released constantly. As a result, AI teams are under pressure to evaluate and deploy them quickly. But turning experiments into production-ready services often gets bogged down by manual infrastructure work:<ul><li>Packaging models and building container images</li><li>Integrating with the right inference backend</li><li>Tuning performance for specific latency/throughput targets</li><li>Setting up autoscaling, observability, and reliability guarantees</li><li>Implementing custom serving logic or <a target="_blank" rel="noopener noreferrer" href="https://docs.bentoml.com/en/latest/get-started/model-composition.html">multi-model chaining</a> for advanced agentic systems</li></ul>If a model needs to be optimized for a specific use case, such as distributed inference or benchmarking, it can add weeks or months to the timeline.AI teams should be able to ship fast, not dealing with infrastructure issues for every model.A strong inference platform removes these roadblocks:<ul><li>Standardized workflows to deploy and iterate on new models in minutes or hours, not weeks</li><li>SOTA open-source models pre-packaged with different optimization options, deployable with a few clicks</li><li>Built-in support for performance tuning, autoscaling, and observability</li><li>Developer-friendly tools and abstractions for implementing custom logic</li></ul>Without this layer, projects get stuck in limbo, which means missed market opportunities. Speed is a competitive edge, and an inference platform helps you move faster.<h3>2. Poor cost visibility and GPU utilization</h3>Many teams turn to on-prem deployments with the goal of reducing long-term costs. However, those cost savings only materialize if you’re using your compute efficiently.On-prem GPUs are a fixed resource. If they’re sitting idle, or worse — running zombie workloads that no one’s monitoring — you’re burning capital without generating value.To truly realize the cost benefits of on-prem, you need two things:<ul><li>Fast autoscaling to respond to actual traffic patterns. During spikes, workloads should scale up to handle new requests. When idle, they should scale down so resources can be reused for other tasks to maximize ROI.</li><li>Clear visibility into GPU utilization and costs. This ensures you know whether your infrastructure is working efficiently and whether you’re getting the savings you expect.</li></ul>This is where an inference platform plays a critical role. It provides the autoscaling logic and real-time metrics needed to maximize GPU usage and reduce waste.The first two layers weren’t designed to handle GenAI workloads like LLMs. They don’t support fast autoscaling for multi-gigabyte LLM container images, or intelligent scheduling based on KV cache availability (higher cache hit rates means better use of techniques like <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefix-caching">prefix caching</a> to reduce compute costs). The inference layer fills that gap.<h3>3. Performance bottlenecks</h3>As LLM context windows expand and use cases grow more complex, single-node inference optimizations quickly hit a wall. Techniques like continuous batching can help squeeze more out of a single GPU, but they’re no longer enough.Modern LLM inference is <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/the-shift-to-distributed-llm-inference">shifting toward distributed architectures</a>:<ul><li>Prefill and decode require different resources. Prefill is compute-intensive, while decode is memory-bandwidth bound and token-by-token. Co-locating both on the same hardware leads to contention and waste. They need separate resources to deliver the optimal performance and scale independently.</li><li>KV caches create memory pressure. Long-context models or agentic systems rely heavily on techniques like <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefix-caching">prefix caching</a> to accelerate inference and reduce costs. However, storing tons of KV caches consumes significant GPU memory.</li><li>Model sizes exceed single-GPU limits. A 70B parameter model in FP16 needs over 140 GB of memory (not to mention overhead for runtime or KV caches). To serve models at this scale, you need techniques like <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/data-tensor-pipeline-expert-hybrid-parallelism">tensor parallelism and expert parallelism</a> (for MoE models) to split and distribute workloads across multiple GPUs.</li></ul>Solving these problems means building a distributed inference stack, including <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefill-decode-disaggregation">disaggregated serving</a>, <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/prefix-aware-routing">intelligent routing</a>, and <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/kv-cache-offloading">KV cache offloading</a>. However, most AI teams don’t have the time to solve them from scratch in on-prem environments.This is where a modern inference platform becomes essential. Ideally, it should support the latest distributed inference optimizations out of the box and make them accessible to developers, without needing to reinvent complex infrastructure.<h3>4. Observability challenges</h3>For LLM workloads in production, especially those with strict SLAs and uptime guarantees, you must have deep, inference-specific observability. But traditional monitoring stacks, which are built for web services and microservices, don’t offer the visibility to operate and optimize LLM workloads.To ensure reliable inference at scale, you need visibility into LLM-specific metrics and behavior, such as:<ul><li><a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/llm-inference-metrics">Time to First Token (TTFT), Time per Output Token (TPOT), and Token Generation Time</a> for understanding latency characteristics across different stages of token generation</li><li>Prefix cache hit rate to measure the effectiveness of KV cache reuse and inform routing decisions</li><li>Cost per request or token to analyze and optimize compute cost per unit of work</li><li>Usage tracking and cost analysis broken down by team or project to ensure accountability and identify optimization opportunities</li><li>Prompt filtering, output anomalies, and model behavior drift to monitor output quality and unexpected behavior</li></ul>These metrics don’t live at the infrastructure or orchestration layers; they live at the inference layer. Without them, teams are left guessing where bottlenecks are or how to tune performance.A modern inference platform provides LLM-specific observability that helps AI teams optimize performance and maintain reliability over time.<h3>5. Operational inefficiency</h3>As organizations scale their AI initiatives, <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/what-is-inference-ops">inferenceOps</a> quickly become a major source of complexity.It’s no longer just about serving a single LLM. Enterprises today deploy <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/a-guide-to-compound-ai-systems">compound AI systems</a> that combine multiple models: LLMs, embedding models, SLMs, and reasoning models. They power agentic workflows, RAG pipelines, and decision-making tools, which lead to heterogenous AI workflows.This also means heterogeneous compute requirements. Some models are GPU-bound, others are CPU- or IO-heavy. Managing these different workloads on a shared cluster requires a carefully orchestrated architecture to avoid bottlenecks and maximize efficiency.But here’s the problem: maintaining these systems and compute resources manually is a massive tax on engineering teams. It diverts attention from core product development and slows down innovation.What’s needed is a standardized layer that abstracts away the complexity. An inference platform fills that gap. It offers:<ul><li>Consistent workflows for deploying and updating models</li><li>Tooling for managing multi-model, multi-team workloads</li><li>Built-in scheduling and resource allocation logic to handle heterogeneous pipelines across multiple on-prem clusters</li></ul>InferenceOps isn’t just an infrastructure problem; it’s a productivity one. A good inference platform gives teams the tools to ship faster with less friction.<h2>Bento On-Prem: The inference platform layer for modern LLM workloads</h2>The five risks we outlined above are the biggest blockers for on-prem LLM success. They all stem from one missing piece: the inference platform layer.That’s exactly where Bento On-Prem comes in.<ul><li>Let AI teams move fast with production-ready workflows for deploying, scaling, and managing LLMs.</li><li>Get optimal performance with built-in support for fast autoscaling, distributed serving, and inference-specific observability</li><li>Seamlessly integrate with your existing infrastructure and container orchestration layers</li><li>Keep all data and models fully within your private on-prem environment</li></ul>Built for speed, simplicity and control, Bento On-Prem lets AI teams move fast without additional complexity to your stack.Running LLMs on-prem? We’d love to help.<ul><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-on-prem-llms">Contact us</a> today to see how Bento On-Prem can help you deploy secure, scalable LLM inference entirely within your control.</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-on-prem-llms">Join our Slack community</a> to connect with other teams and chat about secure, scalable LLM deployments.</li><li>Check out our <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/">LLM Inference Handbook</a> to learn everything about inference.</li></ul>

Learn why an inference platform is the missing layer in on-prem LLM deployments and how it helps optimize inference performance, reduce compute cost, and guarantee reliability.

on-prem-llms.png

Inference Platform: The Missing Layer in On-Prem LLM Deployments

Explore the top open-source embedding models and find answers to some FAQs about them.

embedding-models.png

A Guide to Open-Source Embedding Models

Explore the top open-source VLMs and find answers to some FAQs about them.

vision-language-models.png

Multimodal AI: A Guide to Open-Source Vision Language Models

Explore the top open-source TTS models and find answers to some FAQs about them.

tts-models.png

Exploring the World of Open-Source Text-to-Speech Models

Understand open-source image generation models and find answers to frequently asked questions about them.

image-generation-models.png

A Guide to Open-Source Image Generation Models

You built an LLM-powered application. The demo went great. Leadership is impressed. Applause. Green lights. Your team is ready to ship.But fast forward a few weeks:<ul><li>Your GPU usage is climbing fast. Costs are spiking. How do you secure enough compute, optimize cost, and ensure reliability?</li><li>You are exploring different distributed inference strategies, but can’t tell which parallelism strategy or inference setup best fits your use case.</li><li>A new frontier open model just dropped. Can you immediately launch a deployment and start experimenting or are you stuck waiting on infrastructure support?</li><li>A model misfires in production. Can you trace, debug, and fix it, without slowing your team down?</li></ul>These aren’t edge cases. They’re the new normal when inference scales. The problem isn’t just missing tools. It’s a deeper operational gap.That’s where a mindset shift is needed and we call it InferenceOps. In this post, we’ll break down what it means, why it’s increasingly important, and how a comprehensive InferenceOps platform helps enterprises build reliable and scalable LLM applications in production.<h2>InferenceOps: A mindset shift</h2>InferenceOps is a set of best practices and operational principles for running, scaling, and managing inference reliably and efficiently in production.It represents a mindset shift: from treating inference as an afterthought to managing it as a critical layer of the modern AI stack. This includes but is not limited to:<ul><li>Continuously and rapidly iterating on models and inference code</li><li>Optimizing inference performance and cost across varied workloads</li><li>Ensuring reliability across heterogeneous models and distributed compute environments</li></ul>This shift empowers AI teams to move faster and build differentiated AI systems to better serve their customers.<figure class="image image_resized" style="width:75%;"><img src="/uploads/what_is_inferenceops_de47b631f8.png" alt="what-is-inferenceops.png" srcset="/uploads/xsmall_what_is_inferenceops_de47b631f8.png 64w, /uploads/thumbnail_what_is_inferenceops_de47b631f8.png 190w, /uploads/small_what_is_inferenceops_de47b631f8.png 500w, /uploads/medium_what_is_inferenceops_de47b631f8.png 750w, /uploads/large_what_is_inferenceops_de47b631f8.png 1000w, /uploads/xlarge_what_is_inferenceops_de47b631f8.png 1920w" sizes="100vw" width="1920"></figure><h2>Why InferenceOps matters now more than ever?</h2>AI is no longer optional; it’s eating the world. Every business that wants to compete today needs AI at its core. While choosing the right model is crucial, it’s your inference layer that actually delivers that model’s value to users. A strategy built solely on third-party LLM APIs can get you started quickly, but it won’t sustain a differentiated, production-grade system.Why relying on external LLM APIs falls short:<ul><li>Data privacy &amp; compliance: You can’t send sensitive or regulated data off-premises.</li><li>Noisy neighbor effects: If another large customer saturates the shared endpoint, your latency and availability suffer.</li><li>No custom or fine-tuned models: LLM APIs only provide general-purpose models, preventing you from customizing models to your proprietary data and domain.</li><li>Zero control over the model: You can’t lock in a specific model version, roll back, or meet strict audit requirements.</li><li>Limited performance tuning: You can’t apply inference optimizations uniquely tailored to your SLAs or workload characteristics, align with your specific latency, throughput, and concurrency requirements.</li><li>Cost inefficiency at scale: Shared-API pricing and opaque billing make it impossible to optimize per-request costs.</li></ul>For a deeper breakdown, see <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/serverless-vs-dedicated-llm-deployments">Serverless vs. Dedicated LLM Deployments: A Cost-Benefit Analysis</a>.And that lack of customization hamstrings your ability to build lasting advantage:<ol><li>Compound AI systems are where you win — chaining &amp; composing models into richer workflows. See <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/a-guide-to-compound-ai-systems">A Guide to Compound AI Systems</a> for details.</li><li>Tailored inference stacks let you architect for precise SLAs and cost targets across different workloads.</li><li>Fine-tuning and custom models drive domain-specific accuracy and intellectual property capture.</li></ol>Ultimately, inference quality is product quality. Mission-critical AI systems demand rock-solid performance, predictable costs, and airtight security, which only owning your inference infrastructure can deliver.<h2>What are the core pillars of InferenceOps?</h2>Like DevOps, InferenceOps isn’t defined by a single tool or role; it’s a set of operational principles. At its core, it shares many familiar foundations with DevOps, including:<ul><li>Automation and CI/CD pipelines</li><li>System observability, monitoring and alerting</li><li>Reliability with versioning, rollbacks, and safe deployments</li></ul>These common practices are just the baseline. InferenceOps comes with unique requirements, especially for running and scaling LLMs in production.<h3>Heterogeneous workflow management</h3>In practice, enterprise AI is rarely powered by just one model. Different teams, products, and use cases often require different LLMs, each with distinct configurations and optimizations for optimal performance. One use case may need long-context summarization, and yet another may rely on high-throughput batch processing.And it doesn’t stop at LLMs. You’ll often see small language models (SLMs), embedding models, fine-tuned models, and custom models running alongside LLMs in modern AI systems.This results in a complex web of inference workflows around LLMs, which can quickly become operational sprawl.A unified InferenceOps platform should provide a standardized way to manage diverse inference workflows. That means:<ul><li>Coordinating deployments across diverse model types</li><li>Collectively optimizing their compute resources</li><li>Managing different inference setups</li><li>Centralizing visibility into cost, usage, and performance</li></ul>As your LLM inference scales, this kind of unification becomes more important. Without it, each new use case adds operational debt. With it, teams can scale responsibly, innovate faster, and maintain control.<figure class="image image_resized" style="width:75%;"><img src="/uploads/inferenceops_workflow_9145194132.png" alt="inferenceops-workflow.png" srcset="/uploads/xsmall_inferenceops_workflow_9145194132.png 64w, /uploads/thumbnail_inferenceops_workflow_9145194132.png 245w, /uploads/small_inferenceops_workflow_9145194132.png 500w, /uploads/medium_inferenceops_workflow_9145194132.png 750w, /uploads/large_inferenceops_workflow_9145194132.png 1000w, /uploads/xlarge_inferenceops_workflow_9145194132.png 1920w" sizes="100vw" width="1920"></figure><h3>Unified compute across any infrastructure</h3>Different LLMs require different types of compute to deliver optimal performance. Some workloads are compute-bound, others memory-bound. Some benefit from high-throughput batching on A100s, while others demand low-latency responses on edge devices. Many AI teams even combine CPUs, GPUs, and I/O-heavy workloads in the same inference pipeline for complex AI systems.To balance availability and cost, as well as to avoid vendor lock-in, AI teams often spread inference workloads across multiple cloud regions/providers and on-prem GPU vendors. This is especially true when dealing with GPU scarcity, region-specific latency requirements, or high GPU pricing to ensure performance and control cost.But with flexibility comes complexity. A compute-agnostic InferenceOps platform should enable AI teams to:<ul><li>Run, scale, and manage inference seamlessly across hybrid compute environments</li><li>Optimize GPU cost and dynamically match workloads to the most suitable hardware to maximize efficiency</li><li>Avoid vendor lock-in while maintaining velocity and cost efficiency in acquiring and scaling compute</li></ul><h3>Inference workload optimization</h3>Running LLM inference isn’t just about launching a model server. It’s an ongoing optimization effort in engineering for better performance and cost-efficiency.The first challenge starts at build time. Many models require compilation or runtime optimization before serving, using tools like TensorRT-LLM and TorchScript. Each model architecture comes with its own quirks. Getting this right takes effort and skipping it leaves performance on the table.Then there’s scaling complexity. LLM workloads are not like typical web apps. They involve provisioning compute, pulling large container images, and loading model into GPUs, which makes cold starts slow and painful. See <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/scaling-ai-model-deployment">Scaling AI Models Like You Mean It</a> for details.As traffic grows and inference workloads get heavier, teams often begin with horizontal scaling, spinning up more GPU instances, but even that is far from enough when you’re serving large models across a multi-GPU cluster. That’s why leading AI teams are moving towards <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/blog/the-shift-to-distributed-llm-inference">distributed LLM inference strategies</a>, such as:<ul><li>Prefill-decode disaggregation</li><li>Prefix and KV cache aware routing</li><li>KV cache management</li><li>Tensor, pipeline, and expert parallelism techniques</li></ul>They bring better resource allocation, smarter GPU usage, lower token latency, and reduced cost per token.However, distributed LLM inference is complex by nature. Simply spinning up more Pods on Kubernetes won’t cut it. You need purpose-built infrastructure for distributed LLM workloads. Done poorly, it leads to an over-provisioned, under-optimized system, wasting expensive GPUs while delivering sub-par performance.A developer-friendly InferenceOps platform should abstract away the complexity and provide out-of-the-box support for these advanced optimizations.<h3>Fast iteration without compromising reliability</h3>From real-time chatbots to coding assistants, LLM inference now sits on the hot path of user-facing systems. That means production-grade reliability isn’t optional. You need:<ul><li>Strict SLAs and uptime guarantees, especially for latency-sensitive workloads</li><li>LLM-specific observability, going beyond generic system metrics to include:<ul><li>Time to First Token (TTFT) and Time per Output Token (TPOT)</li><li>Tokens per Second (TPS) and Requests per Second (RPS)</li><li>Cost per request/token</li><li>Prompt filtering, output anomalies, model behavior drift</li></ul></li><li>Robust and automated pipelines, so your team can ship new models and code updates with zero downtime</li></ul>But reliability often slows down velocity. Building this kind of infrastructure from scratch is slow, expensive, and error-prone. It requires specialized knowledge in GPU orchestration, observability stacks, and distributed inference systems. This means engineers have to spend more time fighting infrastructure than experimenting or shipping new ideas.A comprehensive InferenceOps platform resolves this tension by providing:<ul><li>Native support for LLM-specific observability and monitoring</li><li>Easy way to launch benchmark load testing to identify performance bottlenecks</li><li>Optimized CI/CD for updates to models, adapters, and inference logic</li><li>Built-in safeguards for deployments, rollbacks, and canary releases</li></ul>With operational burdens offloaded, AI teams can move faster without compromising efficiency, reliability, and security.<h2>Conclusion</h2>InferenceOps is emerging as a critical foundation for enterprise LLM strategy. With the right practices and platform in place, you can:<ul><li>Unify management of diverse models and inference workflows</li><li>Run and scale inference reliably across heterogeneous compute environments</li><li>Continuously optimize performance and cost with workload-specific techniques</li><li>Accelerate iteration from development to production without sacrificing reliability</li></ul>At <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/">Bento</a>, we help enterprises run LLMs on their terms. With a distributed architecture and tailored inference optimization, our Bento Inference Platform enables you to deploy, scale, and manage any LLM from a single, unified interface.<ul><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-what-is-inference-ops">Talk to us</a> about bringing InferenceOps into your LLM strategy</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-what-is-inference-ops">Join our Slack community</a> to connect with others building custom LLM applications</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/signup-from-blog-what-is-inference-ops">Sign up</a> to try the Bento Inference Platform and start running production-grade inference today</li><li>Learn more about inference in our <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/">LLM Inference Handbook</a></li></ul>

Learn what InferenceOps is, why it matters, and how leading AI teams scale, optimize, and manage LLM inference for production-grade performance and reliability.

inferenceops-blog-cover-image.jpg

What is InferenceOps?

Bo Jiang

The landscape of LLM inference is rapidly evolving, with a clear shift toward distributed serving.What’s happening? Single-node GPU optimizations like dynamic batching, paged attention, and CUDA tweaks are starting to show limitations as LLM inference scales. Larger models like DeepSeek-R1 and tasks with longer context, such as reasoning or agentic use cases, stretch the limits even further.Today, inference optimization is no longer just about squeezing more out of a single node, but rethinking how to distribute inference across a cluster of workers. If you’re working to deploy and scale LLM services, this is a trend you can’t afford to ignore. It heralds a new era, one that brings better resource allocation, smarter GPU usage, lower token latency, and reduced cost per generated token.Leading AI teams and open-source communities are already pioneering distributed inference strategies. We’ve seen optimization efforts converge on three key areas:<ul><li>Prefill-decode (PD) disaggregation</li><li>KV cache utilization-aware load balancing</li><li>Prefix-aware routing</li></ul>In this blog post, we’ll walk through each of these and highlight the active progress to address the challenges they present.<h2>PD disaggregation</h2>To understand PD disaggregation, let’s start with how LLM inference actually works.For transformer-based LLMs, every time you send a prompt, the model goes through two key steps:<ul><li>Prefill: Processes the entire sequence in parallel and store key and value vectors from the attention layers in a KV cache. This helps the model efficiently output new tokens later without recomputing everything from scratch. Because it’s handling all the tokens at once, prefill is compute-bound, but not too demanding on GPU memory.</li><li>Decode: Generates the output tokens, one at a time, by reusing the KV cache built earlier. Different from prefill, decode requires fast memory access but lower compute.</li></ul><figure class="image image_resized" style="width:75%;"><img src="/uploads/llm_inference_diagram_d1439d26f5.png" alt="llm-inference-diagram.png" srcset="/uploads/xsmall_llm_inference_diagram_d1439d26f5.png 64w, /uploads/thumbnail_llm_inference_diagram_d1439d26f5.png 245w, /uploads/small_llm_inference_diagram_d1439d26f5.png 500w, /uploads/medium_llm_inference_diagram_d1439d26f5.png 750w, /uploads/large_llm_inference_diagram_d1439d26f5.png 1000w, /uploads/xlarge_llm_inference_diagram_d1439d26f5.png 1920w" sizes="100vw" width="1920"><figcaption>Prefill and decode in LLM inference</figcaption></figure>For a long time, the standard way of doing inference was to run these two steps together. On the surface, this might seem straightforward.In practice, you’ll often have multiple requests arriving at once. Each one has its own prefill and decode needs, but only one phase can run at a time. When the GPU is occupied with compute-heavy prefill tasks, decode tasks must wait, which increases ITL, and vice versa.Since prefill primarily determines the TTFT and decode impacts ITL, collocating them makes it difficult to optimize both metrics simultaneously.<figure class="image"><img src="/uploads/collocating_prefill_and_decode_16b8fb3c90.png" alt="collocating-prefill-and-decode.png" srcset="/uploads/xsmall_collocating_prefill_and_decode_16b8fb3c90.png 64w, /uploads/thumbnail_collocating_prefill_and_decode_16b8fb3c90.png 245w, /uploads/small_collocating_prefill_and_decode_16b8fb3c90.png 500w" sizes="100vw" width="500"><figcaption>Latency increase by collocating prefill and decode. Source: <a target="_blank" rel="noopener noreferrer" href="https://arxiv.org/pdf/2401.09670">DistServe Paper</a></figcaption></figure><h3>Why disaggregation makes sense</h3>The idea of PD disaggregation is simple: separate these two very different tasks so they don’t get in each other’s way. Key benefits include:<ul><li>Dedicated resource allocation: Prefill and decode can be scheduled and scaled independently on different hardware. For example, if your workload has lots of prompt overlap (like multi-turn conversations or agentic workflows), it means much of your KV cache can be reused. As a result, there’s less compute demand on prefill and you can put more resources on decode.</li><li>Parallel execution: Prefill and decode phases don’t interfere with each other anymore. You can run them more efficiently in parallel, which means better concurrency and throughput.</li><li>Independent tuning: You can implement different optimization techniques (like tensor or pipeline parallelism) for prefill and decode to better meet your goals for TTFT and ITL.</li></ul>Several open-source frameworks and projects are actively exploring PD disaggregation, including <a target="_blank" rel="noopener noreferrer" href="https://github.com/sgl-project/sglang/issues/4655">SGLang</a>, <a target="_blank" rel="noopener noreferrer" href="https://docs.vllm.ai/en/latest/features/disagg_prefill.html">vLLM</a>, <a target="_blank" rel="noopener noreferrer" href="https://docs.nvidia.com/dynamo/latest/architecture/disagg_serving.html">Dynamo</a>, and <a target="_blank" rel="noopener noreferrer" href="https://docs.google.com/document/d/1FNN5snmipaTxEA1FGEeSH7Z_kEqskouKD1XYhVyTHr8/edit?pli=1&amp;tab=t.0">llm-d</a>.<h3>Disaggregation isn’t always a silver bullet</h3>As promising as PD disaggregation sounds, it’s not a one-size-fits-all fix.<ul><li>Thresholds matter: If your workload is too small, or your GPU setup isn’t tuned for this approach, performance can drop (by 20-30% in our tests).</li><li>Local prefill can be faster: For shorter prompts or when the decode engine has a high prefix cache hit, running prefill locally on the decode worker is often faster and simpler.</li><li>Data transfer cost: Disaggregation requires moving KV caches rapidly and reliably between prefill and decode workers. This means your solution must support fast, low-latency communication protocols that are both hardware- and network-agnostic. Unless the performance gains from disaggregation outweigh the data transfer cost, overall performance can actually degrade. Existing methods for data transfer for your reference: <a target="_blank" rel="noopener noreferrer" href="https://github.com/ai-dynamo/nixl">NVIDIA Inference Xfer Library (NIXL)</a>, CXL, NVMe-oF.<figure class="image image_resized" style="width:75%;"><img src="/uploads/kv_cache_transfer_process_e2f1ee49a6.png" alt="kv-cache-transfer-process.png" srcset="/uploads/xsmall_kv_cache_transfer_process_e2f1ee49a6.png 64w, /uploads/thumbnail_kv_cache_transfer_process_e2f1ee49a6.png 245w, /uploads/small_kv_cache_transfer_process_e2f1ee49a6.png 500w, /uploads/medium_kv_cache_transfer_process_e2f1ee49a6.png 750w, /uploads/large_kv_cache_transfer_process_e2f1ee49a6.png 1000w" sizes="100vw" width="1000"></figure></li></ul><h2>KV cache utilization-aware load balancing</h2>For traditional web applications, load balancing is usually pretty simple. Requests are small, responses are quick, and any backend instance can handle any request equally well. Load balancers can use simple strategies like round-robin to distribute traffic evenly.But things are completely different for LLM inference. A major factor here is the KV cache built during the prefill phase.Traditional load balancers treat LLM workers like identical black boxes. They don’t see what’s going on inside each worker, including:<ul><li>How much GPU memory is consumed by the KV cache</li><li>How long the request queue is</li></ul><figure class="image image_resized" style="width:75%;"><img src="/uploads/kv_cache_util_lb_adeb63e5f4.png" alt="kv-cache-util-lb.png" srcset="/uploads/xsmall_kv_cache_util_lb_adeb63e5f4.png 64w, /uploads/thumbnail_kv_cache_util_lb_adeb63e5f4.png 245w, /uploads/small_kv_cache_util_lb_adeb63e5f4.png 500w, /uploads/medium_kv_cache_util_lb_adeb63e5f4.png 750w, /uploads/large_kv_cache_util_lb_adeb63e5f4.png 1000w, /uploads/xlarge_kv_cache_util_lb_adeb63e5f4.png 1920w" sizes="100vw" width="1920"></figure>When a load balancer can’t see these details, it starts making bad decisions, leading to:<ul><li>Missed cache reuse: New requests with similar prefixes can't leverage existing cached computations (more details in the next section).</li><li>Increased latency: Conversations routed to wrong replicas lose their KV cache, requiring expensive re-computation.</li><li>Load imbalance: Some workers process many long conversations while others remain idle.</li></ul>The open-source community is already working on smarter solutions. For example, the <a target="_blank" rel="noopener noreferrer" href="https://github.com/kubernetes-sigs/gateway-api-inference-extension">Gateway API Inference Extension</a> project uses an endpoint picker (EPP) to collect information on KV cache utilization, queue length, and LoRA adapters on each worker, and routes requests to the optimal replica for better inference.<h2>Prefix-aware routing</h2>The term "KV cache" originally described caching within a single inference request. As mentioned above, LLMs work autoregressively during decode as they output the next new token based on the previously generated tokens (i.e. reusing their KV cache). Without the KV cache, they need to recompute everything for the previous tokens in each decode step, which would be a huge waste of resources.When extending this caching concept across multiple requests, it’s more accurate to call it prefix caching.Imagine you have a chatbot system with a prompt like this:<pre><code class="language-bash">You are a helpful AI writer. Please write in a professional manner.</code></pre>This system prompt doesn’t change from one conversation to the next. When new messages come in, the model can reuse the stored prefix cache, only processing the new part of the prompt.Here’s the challenge: How can a new request be routed to the worker that already has the right prefix cached? How does the router know what’s in each worker’s cache?<figure class="image image_resized" style="width:75%;"><img src="/uploads/prefix_caching_aware_routing_be934fc6b1.png" alt="prefix-caching-aware-routing.png" srcset="/uploads/xsmall_prefix_caching_aware_routing_be934fc6b1.png 64w, /uploads/thumbnail_prefix_caching_aware_routing_be934fc6b1.png 245w, /uploads/small_prefix_caching_aware_routing_be934fc6b1.png 500w, /uploads/medium_prefix_caching_aware_routing_be934fc6b1.png 750w, /uploads/large_prefix_caching_aware_routing_be934fc6b1.png 1000w, /uploads/xlarge_prefix_caching_aware_routing_be934fc6b1.png 1920w" sizes="100vw" width="1920"></figure>Different open-source projects are exploring their own approaches:<ul><li>Worker-reported prefix status<a target="_blank" rel="noopener noreferrer" href="https://github.com/ai-dynamo/dynamo">Dynamo</a> has workers actively report which prefixes they’ve cached. The router then uses this real-time data to make smart routing decisions.</li><li>Router-predicted cache status<a target="_blank" rel="noopener noreferrer" href="https://github.com/sgl-project/sglang">SGLang</a> maintains an approximate radix tree for each worker based on past requests. This helps the router predict which worker is most likely to have the needed prefix, without constant updates from the workers.</li><li>Hybrid efforts<ul><li>The Gateway API Inference Extension project is <a target="_blank" rel="noopener noreferrer" href="https://github.com/kubernetes-sigs/gateway-api-inference-extension/issues/498">exploring multiple strategies to implement a routing algorithm on EPP</a>:<ul><li>Prefix affinity consistent hashing: Group requests with similar prefixes to the same worker.</li><li>Approximate prefix cache on the router: Let the router maintain an approximate lookup cache of the prefix caches on all the backend servers.</li><li>Accurate prefix cache on the router: Gather KV cache information reported by model servers.</li></ul></li><li>The <a target="_blank" rel="noopener noreferrer" href="https://github.com/llm-d/llm-d">llm-d</a> project uses a component called Inference Scheduler to implement filtering and scoring algorithms, and makes routing decisions based on a combination of factors like cache availability, prefill/decode status, SLA and load.</li></ul></li></ul><h2>Conclusion</h2>Distributed inference is becoming essential for deploying and scaling LLMs at larger scales. If an enterprise wants to truly optimize for metrics like latency or throughput, distributed LLM inference is the only real path forward. This goes far beyond what serverless API endpoints can achieve.At Bento, we’re working to ensure our customers and users can tap into these latest LLM inference optimizations. As we’ve seen in our initial experiments, there’s no one-size-fits-all solution. The best approach depends on your specific workloads, models, and what matters most to you (e.g., latency, throughput, or cost).We’ll be sharing more about distributed LLM inference with detailed benchmarks and best practices in future posts. If you want to collaborate or stay in the loop, feel free to reach out!<ul><li>Follow us on <a target="_blank" rel="noopener noreferrer" href="https://www.linkedin.com/company/bentoml/">LinkedIn</a> and <a target="_blank" rel="noopener noreferrer" href="https://x.com/bentomlai">X</a></li><li>Read our <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/">LLM Inference Handbook</a></li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-the-shift-to-distributed-llm-inference">Schedule a call with our experts</a> to discuss how these advanced inference optimizations could fit into your workloads.</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-the-shift-to-distributed-llm-inference">Join our Slack community</a> to connect with other builders and get the latest information on LLM inference.</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/signup-from-blog-the-shift-to-distributed-llm-inference">Sign up for our unified inference platform</a> to deploy and scale cutting-edge LLMs like Magistral Small, DeepSeek-R1, Llama 4 and Gemma 3.</li></ul>

Explore 3 key strategies — prefill/decode disaggregation, KV cache utilization-aware load balancing, and prefix-aware routing — to optimize distributed LLM inference at scale.

distributed-llm-inference.png

The Shift to Distributed LLM Inference: 3 Key Technologies Breaking Single-Node Bottlenecks

Fog Dong

At Bento, we work to help AI teams deploy and scale models with tailored optimization. That means giving them the ability to tune performance for their specific use cases with ease and speed, so they can achieve better price-performance ratios.As part of that effort, we’re excited to introduce <a target="_blank" rel="noopener noreferrer" href="https://github.com/bentoml/llm-optimizer">llm-optimizer</a>, an open-source tool for benchmarking and optimizing LLM inference. It works across multiple inference frameworks and supports any open-source LLM.Unlike traditional benchmarking tools that only generate raw numbers, llm-optimizer allows you to define constraints, such as “TTFT under 200ms” or “P99 ITL below 10ms.” This makes it easy to quickly identify the configurations that meet your specific requirements without endless trial and error.At the same time, we’re launching the <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm-perf/">LLM Performance Explorer</a>, a companion website powered by llm-optimizer. It lets you browse LLM benchmark results directly without running experiments yourself. You can compare different configurations, apply constraints, and quickly see which setup works best for your specific use case.<figure class="image"><img></figure><figure class="image"><img src="/uploads/llm_perf_explorer_7131fbb216.png" alt="llm-perf-explorer.png" srcset="/uploads/xsmall_llm_perf_explorer_7131fbb216.png 64w, /uploads/thumbnail_llm_perf_explorer_7131fbb216.png 245w, /uploads/small_llm_perf_explorer_7131fbb216.png 500w, /uploads/medium_llm_perf_explorer_7131fbb216.png 750w, /uploads/large_llm_perf_explorer_7131fbb216.png 1000w, /uploads/xlarge_llm_perf_explorer_7131fbb216.png 1920w" sizes="100vw" width="1920"></figure><h2>Motivation</h2>When it comes to self-hosting LLMs, performance tuning can be very tricky. There are so many factors to balance:<ul><li>Server&nbsp;parameters: <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/data-tensor-pipeline-expert-hybrid-parallelism">Parallelism strategies (e.g., data, tensor, pipeline)</a>, batch sizes, <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/kv-cache-offloading">caching</a> strategies, etc.</li><li>Client parameters: Request rates, concurrency&nbsp;levels,&nbsp;number of prompts, etc.</li><li>Framework&nbsp;differences: Each&nbsp;<a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/getting-started/choosing-the-right-inference-framework">inference&nbsp;framework</a>&nbsp;(vLLM,&nbsp;SGLang, TensorRT-LLM, etc.) has&nbsp;its own optimization&nbsp;strategies and tuning knobs.</li><li>Workload variations: Different models, input&nbsp;lengths, and request patterns require different optimizations.</li></ul>For most AI teams, the only way to figure it out has been trial and error: endless tests, parameter tweaks, and results that are hard to compare. It’s tedious, time-consuming, and often error-prone.This led us to build llm-optimizer. We want to provide engineers a systematic way to test configurations, and give them a clear view of what really works with just a few commands. More importantly, it must support constraint filtering, so that engineers don’t need to sift through mountains of raw result data. This means they can focus on the right parameters for their specific optimization goals. Ultimately, engineers spend less time tuning and more time building.<h2>Key features</h2>llm-optimizer was built to take the tedious manual work out of LLM performance optimization. You can run structured experiments, apply constraints, and visualize results in one place - all with a few commands.<h3>Systematic parameter testing</h3>llm-optimizer supports systematic tests of different combinations of server and client parameters across multiple inference frameworks. It works with any open-source LLM. Simply provide the Hugging Face model tag.Here is an example with vLLM:<pre><code class="language-bash">llm-optimizer \
 --framework vllm \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --server-args "tensor_parallel_size=[1,2];max_num_batched_tokens=[4096,8192]" \
 --client-args "max_concurrency=[32,64];num_prompts=1000;dataset_name=sharegpt" \
 --output-json vllm_results.json</code></pre>Parameters like <code>tensor_parallel_size</code> and <code>max_num_batched_tokens</code> come directly from the respective frameworks (currently support vLLM and SGLang). If you’re familiar with other native parameters, you can add them as well.Here is another example with SGLang:<pre><code class="language-bash">llm-optimizer \
 --framework sglang \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --server-args "tp_size*dp_size=[(1,4),(2,2),(4,1)];chunked_prefill_size=[2048,4096]" \
 --client-args "max_concurrency=[32,64,128];num_prompts=[500,1000]" \
 --output-dir optimization_results \
 --output-json results.json \
 --continue \
 --rest 10 \
 --warmup-requests 3</code></pre>This command generates 36 unique test runs:<ul><li>3 tensor/data parallelism combinations × 2 prefill sizes = 6 server configs</li><li>3 concurrency values × 2 prompt counts = 6 client configs</li><li>6 × 6 = 36 total configurations, each with 3 warmup requests and a 10-second rest between runs</li></ul>This means 36 results you can analyze or filter further using constraints.<h3>Constraint settings</h3>Not every benchmark result is useful. What really matters is finding the configuration that meets your performance goals, especially when you have specific SLOs for inference. Without filtering, large test runs can generate too much noise and make it harder to analyze results.With llm-optimizer, you can:<ul><li>Filter results to only include configurations that meet your requirements</li><li>Identify optimal setups for latency or throughput targets</li></ul>The following is a typical use case where you can optimize for chatbots or other low-latency workloads.<pre><code class="language-bash">llm-optimizer \
 --framework vllm \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --server-args "tensor_parallel_size*data_parallel_size=[(1,2),(2,1)];max_num_seqs=[16,32,64]" \
 --client-args "max_concurrency=[8,16,32];num_prompts=500" \
 --constraints "ttft&lt;200ms;itl:p99&lt;10ms" \
 --output-json chat_optimized.json</code></pre>This command will only return results where:<ul><li>Time to First Token (TTFT) is below&nbsp;200ms</li><li>99% of Inter-Token Latency (ITL)&nbsp;are below 10ms</li></ul><h3>Comprehensive benchmarking results</h3>Benchmarks are only useful if the results tell you something actionable. llm-optimizer provides detailed inference-specific metrics, giving you a clear view of how your model behaves under different conditions.For LLMs, performance is best measured at the token level. <a target="_blank" rel="noopener noreferrer" href="https://bentoml.com/llm/inference-optimization/llm-inference-metrics">Key metrics</a> include:<ul><li>Time to First Token (TTFT): How long it takes for the first response token to appear after a request is sent</li><li>Inter-Token Latency (ITL): The average time between tokens in a response.</li><li>Input/Output Token Throughput: How many tokens are processed/generated per second during the benchmark.</li></ul>In addition, you also get traditional request-level metrics such as end-to-end latency, request throughput, and optimal concurrency. These measurements combined help you make trade-offs for your performance goals.Results are output in JSON, easy to filter and compare. Here’s a simplified example:<pre><code class="language-yaml language-json">[
 {
 "config": {
 "client": {
 "max_concurrency": 8,
 "num_prompts": 1000,
 "dataset_name": "sharegpt",
 "sharegpt_output_len": 256
 },
 "server": {
 "tensor_parallel_size": 1,
 "max_num_batched_tokens": 4096,
 "max_num_seqs": 16
 },
 "server_args": [
 "--tensor-parallel-size=1",
 "--max-num-batched-tokens=4096",
 "--max-num-seqs=16"
 ]
 },
 "results": {
 "backend": "vllm",
 "dataset_name": "sharegpt",
 "max_concurrency": 8,
 "total_input_tokens": 296523,
 "total_output_tokens": 256000,
 "total_output_tokens_retokenized": 255910,
 "request_throughput": 2.323720163971585,
 "input_throughput": 689.0364741813463,
 "output_throughput": 594.8723619767258,
 "mean_e2e_latency_ms": 3441.463320413,
 "median_e2e_latency_ms": 3413.3226294999304,
 "std_e2e_latency_ms": 130.47813647173385,
 "p99_e2e_latency_ms": 4003.9951376500244,
			...
 },
 "cmd": "vllm serve meta-llama/Llama-3.1-8B-Instruct --host 127.0.0.1 --port 8000 --tensor-parallel-size=1 --max-num-batched-tokens=4096 --max-num-seqs=16"
 },
 
// More results below</code></pre><h3>Performance estimation</h3>Sometimes you want to understand how a model will perform before running a full benchmark. Maybe you don’t have the required hardware, your time is limited, or you just want a quick estimate of what to expect. llm-optimizer supports performance estimation that analyzes a model and generates theoretical results without running live tests.Here is an example:<pre><code class="language-bash">llm-optimizer estimate \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --input-len 1024 \
 --output-len 512 \
 --gpu A100 \
 --num-gpus 2</code></pre>This command:<ul><li>Analyzes the 8B Llama model on 2x A100 GPUs</li><li>Estimates performance for 1024 input + 512 output tokens</li><li>Shows best latency and throughput configurations</li><li>Provides roofline analysis and identifies bottlenecks</li><li>Generates the commands to run actual benchmarks with SGLang and vLLM</li></ul>Expected output:<pre><code class="language-bash">=== Configuration ===
Model: meta-llama/Llama-3.1-8B-Instruct
GPU: 2x A100
Precision: fp16
Input/Output: 1024/512 tokens
Target: throughput

Fetching model configuration...
Model: 8029995008.0B parameters, 32 layers

=== Performance Analysis ===
Best Latency (concurrency=1):
 TTFT: 43.1 ms
 ITL: 2.6 ms
 E2E: 1.39 s

Best Throughput (concurrency=512):
 Output: 18873.3 tokens/s
 Input: 23767.8 tokens/s
 Requests: 14.24 req/s
 Bottleneck: Memory

=== Roofline Analysis ===
Hardware Ops/Byte Ratio: 142.5 ops/byte
Prefill Arithmetic Intensity: 52205.5 ops/byte
Decode Arithmetic Intensity: 50.9 ops/byte
Prefill Phase: Compute Bound
Decode Phase: Memory Bound

=== Concurrency Analysis ===
KV Cache Memory Limit: 688 concurrent requests
Prefill Compute Limit: 8 concurrent requests
Decode Capacity Limit: 13 concurrent requests
Theoretical Overall Limit: 8 concurrent requests
Empirical Optimal Concurrency: 16 concurrent requests

=== Tuning Commands ===

--- SGLANG ---
Simple (concurrency + TP/DP):
 llm-optimizer --framework sglang --model meta-llama/Llama-3.1-8B-Instruct --gpus 2 --host 127.0.0.1 --server-args "tp_size*dp_size=[(1, 2), (2, 1)]" --client-args "num_prompts=1000;dataset_name=sharegpt;random_input=1024;random_output=512;num_prompts=1000;max_concurrency=[256, 512, 768]" --output-dir tuning_results --output-json tuning_results/config_1_sglang.json
Advanced (additional parameters):
 llm-optimizer --framework sglang --model meta-llama/Llama-3.1-8B-Instruct --gpus 2 --host 127.0.0.1 --server-args "tp_size*dp_size=[(1, 2), (2, 1)];chunked_prefill_size=[1434, 2048, 2662];schedule_conservativeness=[0.3, 0.6, 1.0];schedule_policy=fcfs" --client-args "num_prompts=1000;dataset_name=sharegpt;random_input=1024;random_output=512;num_prompts=1000;max_concurrency=[256, 512, 768]" --output-dir tuning_results --output-json tuning_results/config_1_sglang.json

--- VLLM ---
Simple (concurrency + TP/DP):
 llm-optimizer --framework vllm --model meta-llama/Llama-3.1-8B-Instruct --gpus 2 --host 127.0.0.1 --server-args "tensor_parallel_size*data_parallel_size=[(1, 2), (2, 1)]" --client-args "num_prompts=1000;dataset_name=sharegpt;random_input=1024;random_output=512;num_prompts=1000;max_concurrency=[256, 512, 768]" --output-dir tuning_results --output-json tuning_results/config_1_vllm.json
Advanced (additional parameters):
 llm-optimizer --framework vllm --model meta-llama/Llama-3.1-8B-Instruct --gpus 2 --host 127.0.0.1 --server-args "tensor_parallel_size*data_parallel_size=[(1, 2), (2, 1)];max_num_batched_tokens=[1024, 1177, 1331]" --client-args "num_prompts=1000;dataset_name=sharegpt;random_input=1024;random_output=512;num_prompts=1000;max_concurrency=[256, 512, 768]" --output-dir tuning_results --output-json tuning_results/config_1_vllm.json</code></pre>If you’re not sure what parameters to provide, you can use the interactive mode. It walks you through the setup step by step and generates the same results as if you had provided them directly:<pre><code class="language-bash">$ llm-optimizer estimate --interactive

=== LLM Performance Estimation (Interactive Mode) ===

🤖 Model Selection
Popular options: meta-llama/Llama-3.2-1B, meta-llama/Meta-Llama-3-8B, meta-llama/Meta-Llama-3-70B
HuggingFace model ID: meta-llama/Llama-3.2-1B

📏 Sequence Length Configuration
Typical values: 512 (short), 1024 (medium), 2048 (long), 4096 (very long)
Input sequence length (tokens) [1024]: 512
Output sequence length (tokens) [512]: 512

## More options...</code></pre><figure class="image"><img src="/uploads/interactive_demo_14433d2ba1.gif" alt="interactive-demo.gif" srcset="/uploads/xsmall_interactive_demo_14433d2ba1.gif 64w, /uploads/thumbnail_interactive_demo_14433d2ba1.gif 245w, /uploads/small_interactive_demo_14433d2ba1.gif 500w, /uploads/medium_interactive_demo_14433d2ba1.gif 750w, /uploads/large_interactive_demo_14433d2ba1.gif 1000w" sizes="100vw" width="1000"></figure><h3>Interactive user interface</h3>Raw numbers are useful, but they’re much easier to interpret when you can see patterns and trade-offs. llm-optimizer offers a visualization tool that turns benchmark results into interactive dashboards.After running benchmarks, you don’t have to parse JSON by hand. Simply launch a local dashboard and explore your results visually:<pre><code class="language-bash"># Visualize results with Pareto frontier analysis
llm-optimizer visualize --data-file results.json --port 8080

# Combine multiple result files
llm-optimizer visualize --data-file "sglang_results.json,vllm_results.json" --port 8080</code></pre>The dashboard will be served at <code>http://localhost:8080/pareto_llm_dashboard.html</code>.<blockquote>Note: <span style="background-color:rgb(255,255,255);color:rgb(31,35,40);font-family:-apple-system, &quot;system-ui&quot;, &quot;Segoe UI&quot;, &quot;Noto Sans&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;;font-size:16px;"><span style="-webkit-text-stroke-width:0px;display:inline !important;float:none;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:400;letter-spacing:normal;orphans:2;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-decoration-thickness:initial;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;">This feature is still experimental, and we’ll continue improving it in the coming days. For visualized results, check out the <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm-perf/"><a style="-webkit-text-stroke-width:0px;background-color:rgb(255, 255, 255);box-sizing:border-box;color:rgb(9, 105, 218);font-family:-apple-system, &quot;system-ui&quot;, &quot;Segoe UI&quot;, &quot;Noto Sans&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;;font-size:16px;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:400;letter-spacing:normal;orphans:2;text-align:start;text-indent:0px;text-transform:none;text-underline-offset:0.2rem;white-space:normal;widows:2;word-spacing:0px;" rel="nofollow">LLM Performance Explorer</a></a><span style="background-color:rgb(255,255,255);color:rgb(31,35,40);font-family:-apple-system, &quot;system-ui&quot;, &quot;Segoe UI&quot;, &quot;Noto Sans&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;;font-size:16px;"><span style="-webkit-text-stroke-width:0px;display:inline !important;float:none;font-style:normal;font-variant-caps:normal;font-variant-ligatures:normal;font-weight:400;letter-spacing:normal;orphans:2;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-decoration-thickness:initial;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;">.</blockquote><h2>Getting started</h2>Install llm-optimizer:<pre><code class="language-bash">git clone https://github.com/bentoml/llm-optimizer.git
pip install -e .</code></pre>Run a quick estimation:<pre><code class="language-bash">llm-optimizer estimate \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --gpu A100 \
 --num-gpus 4 \
 --input-len 1024 \
 --output-len 512</code></pre>Run your first benchmark (make sure you have enough GPU resources):<pre><code class="language-bash">llm-optimizer \
 --framework vllm \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --server-args "tensor_parallel_size*data_parallel_size=[(1,4),(2,2),(4,1)]";max_num_seqs=[16,32,64]" \
 --client-args "max_concurrency=[8,16,32];num_prompts=500" \
 --constraints "ttft&lt;200ms;itl:p99&lt;10ms" \
 --output-json latency_optimized.json</code></pre>LLM inference optimization doesn’t have to mean endless trial and error. llm-optimizer makes it easy to benchmark different configurations, apply constraints, estimate performance, and visualize results — all with a few commands.More resources:<ul><li>View the benchmark results of top open-source LLMs on the <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm-perf/">LLM Performance Explorer</a></li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/join-slack-from-blog-announcing-llm-optimizer">Join our Slack community</a> to connect with other AI engineers and share feedback</li><li>Read our <a target="_blank" rel="noopener noreferrer" href="https://www.bentoml.com/llm/">LLM Inference Handbook</a> for deeper dives into performance optimization</li><li><a target="_blank" rel="noopener noreferrer" href="https://l.bentoml.com/contact-us-from-blog-announcing-llm-optimizer">Schedule a call</a> with our experts to discuss your use case and performance goals</li></ul>

Benchmark and optimize LLM inference performance with SLO constraints across frameworks like vLLM and SGLang.

large_llm-optimizer-cover-image.png

medium_llm-optimizer-cover-image.png

small_llm-optimizer-cover-image.png

thumbnail_llm-optimizer-cover-image.png

xsmall_llm-optimizer-cover-image.png

llm-optimizer-cover-image.png

llm-optimizer: An Open-Source Tool for LLM Inference Benchmarking and Performance Optimization

📢 Introducing [llm-optimizer](/blog/announcing-llm-optimizer) & [LLM Performance Explorer](/llm-perf/) — benchmark and optimize LLM inference with ease.

Bento Blog

llm-optimizer: An Open-Source Tool for LLM Inference Benchmarking and Performance Optimization