Pioneers Insight Method Research Author
Everything you need to run Mission Critical Inference (ft. DeepSeek v3 + SGLang)
Back to Episodes

Everything you need to run Mission Critical Inference (ft. DeepSeek v3 + SGLang)

Summary

  • DeepSeek V3 made frontier-quality open weights commercially relevant, but only for operators able to absorb a 671B-parameter systems problem. At recording time it ranked seventh on LM Arena at 1319, above Claude 3.5 Sonnet and o1-mini; Yineng Zhang said he thought the 256-expert MoE was a “game changer for open-source AI.”
  • Demand was coming less from Llama users upgrading than from Claude customers seeking lower prices, fewer rate limits, faster time to first token, or control over the model instead of relying on an API provider that could change it. That made DeepSeek V3 relevant to proprietary-model users with specific production constraints, not merely open-model experimenters.
  • The immediate bottleneck was memory and precision. Yineng said eight H100s provide 640GB but still could not serve the model; in that explanation he estimated the FP8 weights at “I think, 71 gigabytes” plus KV-cache memory. Baseten chose H200s or multi-node deployments, while block-wise FP8 required kernels that ordinary CUDA or cuBLAS paths did not support.
  • Baseten’s commercial differentiation is dedicated, consumption-priced inference rather than shared token endpoints. Customers specify latency, throughput, P95/P99, security, compliance, and geography—not a preferred GPU SKU—and Baseten says it will not quantize models behind customers’ backs when quality must remain unchanged.
  • SGLang combines better performance than vLLM in common use cases with better usability than TensorRT-LLM. Its DeepSeek-specific MLA, data-parallel attention, and block-wise FP8 work helped make it DeepSeek’s recommended engine, while radix caching and cache-aware routing attack latency across repeated prompts and many replicas.
  • Amir Haghighat’s core call is that mission-critical inference requires three individually necessary pillars: model-level performance, rapid multi-region horizontal scaling, and workflow-oriented developer tooling. “vLLM equals production” is the misconception; production also means recovering from crashes, absorbing bursts, preserving tail latency, avoiding noisy neighbors, and finding GPU capacity across clouds.
  • Neither speculative decoding nor fine-tuning becomes turnkey merely because a framework exposes the feature. Draft models and Medusa or EAGLE heads still need training for high acceptance rates, while Amir’s uncertainty on fine-tuning—“in the short term, no; in the long term, maybe”—met the host’s skepticism that reasoning models will eliminate the need for customization.

Deep dive

1. DeepSeek V3 made open weights a credible proprietary-model substitute

  • DeepSeek V3 arrived right after Christmas as a 671B-parameter, 256-expert fine-grained MoE trained on 15 trillion tokens with native FP8 mixed-precision training, multi-token prediction, multi-head latent attention from DeepSeek V2, and synthetic reasoning data distilled from DeepSeek R1. Yineng said, “I think it’s a game changer for open-source AI.”

  • At recording time, its LM Arena score of 1319 placed it seventh globally—below full o1, Gemini 2, and the latest GPT-4o, but above o1-mini, Grok 2, Gemini 1.5 Pro, and Claude 3.5 Sonnet. The host framed it as January 2025’s leading open-weight model.

  • The host placed the launch in a broader Chinese open-weights trend, noting Tencent’s Hunyuan Large in November and Hailuo’s MiniMax Text in January, both over 400B parameters.

  • Amir’s commercially important observation was that interest generally was not coming from teams upgrading from a particular open-source model. It was coming from Claude users facing some combination of rate limits, high prices, latency or time-to-first-token requirements, and discomfort with an API provider potentially changing the underlying model.

  • The host suggested that Llama 405B’s inference gains often did not justify its cost. Amir’s response described DeepSeek interest as coming chiefly from proprietary-model users with those production pains, while some of the interest remained exploratory rather than deployed.

2. A 671B MoE turns memory, precision, and kernels into product constraints

  • Baseten was described as the first inference neocloud startup to get DeepSeek V3 online, helped by its H200 clusters, collaboration with the DeepSeek team, and early SGLang support. The host said eight H200s, each with 141GB of VRAM and 4.8TB/s of bandwidth, can run FP8 inference while accounting for KV-cache needs.

  • Yineng said eight H100s provide 640GB but still cannot serve the model. In the same explanation, he estimated the FP8 weights at “I think, 71 gigabytes” and said additional memory was needed for KV cache. Baseten therefore chose H200s or multiple nodes; DeepSeek V3 was the first model of this size they had encountered.

  • The released weights used block-wise FP8, whereas the default path was BF16. Yineng said even CUDA or cuBLAS did not support that block-wise format, pushing implementers toward Triton or CUTLASS kernels; he also said TensorRT-LLM did not then support FP8. Debugging was difficult because loading the very large model took so long, though Amir characterized that as slowness rather than conceptual complexity.

  • Yineng reported a GSM8K score near 94.6 for the FP8 version, which he said was higher than other open-source LLMs in his comparison, including Llama 405B. Amir expected native lower-precision training to spread, while tentatively citing an ablation in which benefits persisted toward six-bit precision and smaller formats might go too far.

  • The hosts kept the MoE countercase alive: Mixtral had seemed to herald an MoE wave, yet much of the following year remained dense. Yineng expected MoE inference optimization to become essential, citing similar internal architectures at Baidu and ByteDance. He speculated that the Llama team had tried and failed to train an MoE, and said its benchmark score was lower than a dense model, explaining why no Llama MoE was released.

3. Dedicated inference prices service guarantees, not tokens

  • Baseten intentionally does not sell shared endpoints for popular models. Its median customer brings custom or open weights but wants dedicated resources, predictable latency, regional flexibility, and freedom from noisy neighbors. Calling a popular model behind a per-token API fits a different customer than one whose product depends on dedicated inference.

  • Customers typically specify quality, latency, throughput, time to first token, and cost rather than asking for H200s by name. GPU SKUs are tools for hitting a price per million tokens or images and sustaining P95/P99 performance during traffic bursts—not inventory to advertise for its own sake.

  • Model fidelity is part of that contract. Amir said Baseten would not quantize the model behind the user’s back; quantization tooling and evaluations are instead used jointly with customer engineers. Baseten’s speculative-decoding methods are attractive because they guarantee unchanged output, unlike quantization.

  • Pricing follows resource consumption in two forms: Baseten-hosted infrastructure across multiple public clouds, or managed inference inside a customer’s AWS, GCP, or other cloud environment. Customers can combine committed capacity across clouds, horizontally replicate one model across it, and optionally overflow into Baseten’s capacity when their commitments run out.

4. SGLang is winning where performance must remain hackable

  • SGLang began around August 2023 as a front-end language for LLM programs. Radix caching followed in January 2024, constrained decoding and jump-forward in February, and a push around June or July to become a complete inference engine. Yineng summarized the operating cadence simply: “We just built and shipped.”

  • The design gap was clear: vLLM was easy to use but, in the team’s view, harder to extend cleanly and then slower; TensorRT-LLM was “blazing fast” but difficult for secondary development. SGLang aimed to combine performance with maintainability, and a mid-2024 comparison reportedly showed roughly three times vLLM’s throughput before vLLM subsequently refactored.

  • For DeepSeek, SGLang added MLA optimization, data-parallel attention in version 0.4, zero-overhead CPU scheduling, cache-aware routing, and a block-wise FP8 kernel later adopted by vLLM. Those investments made SGLang the engine recommended by the DeepSeek team rather than merely another compatible backend.

  • Yineng’s framework hierarchy remained conditional: TensorRT-LLM for especially latency-sensitive workloads, SGLang when teams also need to customize and optimize, and vLLM for its mature community. SGLang grew from roughly 2,000 to more than 7,000 GitHub stars after July; its creators’ roles at xAI helped explain adoption there.

  • Baseten’s Truss packages and deploys models across TensorRT-LLM, vLLM, and SGLang. Amir said Baseten had also built its own Triton Inference Server variant for performance and reliability, while treating the frameworks as interchangeable tools rather than locking customers to one.

5. Cache reuse and constrained decoding turn repeated structure into speed

  • RadixCache is SGLang’s prefix-caching mechanism, using a block size of one rather than the block size of 32 used by vLLM and other frameworks. Yineng’s causal claim was straightforward: finer-grained matching raises the cache hit rate, particularly when a dedicated customer repeatedly sends a finite family of system prompts or shared prefixes.

  • Caching alone was insufficient once one model had dozens of replicas, each holding different KV-cache state. Baseten therefore added cache-aware load balancing: requests are routed using likely prefix reuse alongside queue depth and replica location. Amir said this materially improved customer latency.

  • For structured outputs, SGLang can translate a JSON schema into a finite-state machine through Outlines or XGrammar. If the allowed path makes several tokens predictable, jump-forward can replace multiple decoding steps with one prefill. Yineng preferred XGrammar on performance grounds and noted that TensorRT-LLM had also integrated it.

  • The host’s pushback—if jump-forward improves both speed and structural validity, why is it not universal?—met an answer about maintenance complexity. It interacts awkwardly with CPU overlap and other optimizations, so SGLang disables it by default. Its API speculative-execution feature is a front-end control-flow abstraction, not a back-end decoding optimization.

6. Production inference rests on three separate pillars

  • Amir’s first pillar is model-level performance: kernels, serving frameworks, MLA, and techniques such as draft-model, Medusa, or EAGLE speculative decoding. Framework choice matters here, but it covers only one model on one set of hardware. “Each of them individually is necessary but not sufficient.”

  • The second pillar begins when traffic overwhelms that replica. Scaling from one instance to five, ten, or 100 is “not an ML problem” and “not a PyTorch problem”; it is infrastructure. A single model might demand 200 replicas, each consuming two or four H100s—or a full node—beyond one region’s available capacity.

  • Baseten consequently built cross-region and cross-cloud replication beyond a single Kubernetes cluster. Amir described models with 50 replicas in GCP East, 80 in AWS West, and additional replicas in Oracle’s London region. Kubernetes’ autoscaler alone, he argued, does not deliver the speed or reliability these workloads require.

  • The third pillar is enabling complex, multistep, multimodel workflows through a strong developer experience. Amir said the market was moving toward these workloads and that the framework was only one part of the first pillar.

7. A library alone is not a mission-critical inference product

  • Yineng explicitly distinguished open-source libraries such as vLLM, SGLang, LightLLM, and TensorRT-LLM from a product solution. Amir’s shorthand was that “vLLM equals production” is false: production also requires reliable recovery from crashes, rapid scaling, and sustained P95/P99 latency under bursts.

  • Amir cited an AI phone-call example as a multistep, multimodel workload requiring low-latency coordination. More generally, customers care about whether inference remains reliable, repeatable, secure, HIPAA-compliant where needed, within the required geography, and unaffected by another customer’s traffic.

  • His definition of mission-critical was strict: if inference is slow or down, “the main product of our customer is slow or down.” In emerging real-time applications, routing decisions matter because 50 or 100 milliseconds matter; infrastructure, compliance, and geography therefore become model-product features.

8. Optimization still requires training, and fine-tuning may not disappear

  • EAGLE, Medusa, and draft-target speculative decoding are not one-flag accelerations. Yineng said SGLang and other open-source frameworks supported state-of-the-art EAGLE performance, while TensorRT-LLM supported EAGLE-1 but not EAGLE-2. Customers must still train the draft model or added heads to mimic the target; throughput gains ultimately depend on the resulting token-acceptance rate.

  • Traditional customization also remains visible in production: Amir cited Whisper fine-tuned for medical jargon and LLMs trained on human-in-the-loop data for medical-document extraction. More capable reasoning models might reproduce such behavior from a few examples, but he had not seen current fine-tuning demand decline.

  • Amir’s uncertainty survived intact: reasoning could reduce the need for fine-tuning, but “in the short term, no, in the long term, maybe,” with cost-effectiveness unresolved. The host was more skeptical, arguing that easier prompt changes do not imply that full or parameter-efficient fine-tuning will disappear.

  • The operating conclusion was pragmatic rather than predictive: “Let’s solve today’s problems.” Even if a market vanishes in two years, onboarding its customers teaches the provider about tomorrow’s requirements and creates the chance to build ahead of them.

Verification Notes

  • The transcript itself pairs Yineng’s statement that eight H100s cannot serve the model with his estimate of “I think, 71 gigabytes” for FP8 weights. This digest preserves both claims rather than replacing the transcript’s figure with an inferred value.