The easiest way to misread DeepSeek is to stop at the model card. The more durable AI-China signal is now one layer lower: DeepSeek is publishing parts of the runtime substrate that made its large MoE and sparse-attention models practical. FlashMLA, DeepEP, and DeepGEMM are not consumer products. They are kernel-level artifacts, aimed at the places where attention, expert routing, and low-precision matrix multiplication decide whether a model is merely impressive or actually deployable.

That makes this a stack-and-supply-chain update rather than another benchmark note. Chinese AI competition is usually narrated through model names: Qwen, DeepSeek, GLM, Kimi, Hunyuan, ERNIE, InternLM. But production adoption increasingly depends on the hidden layers that sit below those names. A sparse-attention model needs specialized attention kernels. A mixture-of-experts model needs communication paths that can move tokens to experts without wasting the whole GPU. An FP8-heavy serving stack needs matrix kernels that can survive unusual shapes, grouped layouts, warmup behavior, and hardware-specific constraints. DeepSeek's useful signal is that it is exposing those pieces as reusable infrastructure instead of leaving them sealed inside one training run.

The attention layer is becoming a product boundary

FlashMLA is the clearest entry point because it names the attention problem directly. DeepSeek describes it as a library of optimized attention kernels powering DeepSeek-V3 and DeepSeek-V3.2-Exp, with sparse and dense implementations for prefill and decoding.[3] The sparse side matters because V3.2-Exp introduces DeepSeek Sparse Attention, a long-context efficiency move built around selecting fewer token interactions instead of paying the full dense-attention bill every time.[4]

The performance figures should be read carefully. The FlashMLA repository reports H800 SXM5 results such as up to 3000 GB/s for dense MLA decoding in a memory-bound configuration, up to 660 TFLOPS in a compute-bound configuration, and 410 TFLOPS for token-level sparse MLA decoding with FP8 KV cache under its stated CUDA setup.[3] Those are first-party kernel claims, not a universal deployment guarantee. Still, the strategic point does not require treating every number as portable. It is enough that DeepSeek is treating attention behavior as a kernel distribution problem.

That is a meaningful shift for AI-China. If a model's advantage depends on an attention variant that only works in one private stack, the model is harder for outside teams to validate, serve, or adapt. If the relevant kernels are public, the adoption question changes. Engineers can inspect the assumptions, test the hardware boundary, compare against their own serving path, and decide whether the model's efficiency claim survives outside DeepSeek's own environment.

Expert parallelism is where MoE becomes operational

DeepEP targets the less glamorous but equally important MoE problem: getting tokens to experts and combining the outputs without burning too much time or too many streaming multiprocessor resources on communication. The repository presents DeepEP as a high-performance communication library for machine-learning training and inference, focused on expert parallelism, with all-to-all GPU kernels for MoE dispatch and combine plus low-precision support including FP8.[2]

The V2 notes are the interesting part. DeepEP says the refactor moves to a lighter NCCL Gin backend, unifies high-throughput and low-latency APIs into an ElasticBuffer interface, supports scale-up and scale-out domains up to EP2048, and reduces SM usage for V3-like legacy training from 24 to 4-6 while maintaining equivalent or better performance.[2] Again, that is first-party positioning. But the shape of the claim is the point: DeepSeek is trying to make expert parallelism less like a bespoke training trick and more like a library boundary with named APIs, buffers, and resource tradeoffs.

This matters because MoE models are easy to admire and hard to operate. The headline parameter count hides the routing cost. A 671B-total-parameter model with 37B activated per token, as described in the DeepSeek-V3 technical report, only becomes economically interesting if the active experts can be reached efficiently and predictably.[5] DeepEP is the supply-chain component that tries to make that routing behavior legible.

DeepGEMM closes the loop at the matrix-kernel layer

DeepGEMM sits at the arithmetic core. DeepSeek describes it as a unified tensor-core kernel library for modern LLM primitives, including FP8, FP4, and BF16 GEMMs, fused MoE with overlapped communication, MQA scoring, and runtime JIT compilation so installation does not require a CUDA build step.[1] Its stated hardware boundary is also explicit: SM90 or SM100 NVIDIA architectures, CUDA-version requirements, PyTorch requirements, and layout rules for FP8 scaling factors.[1]

The important detail is how DeepGEMM connects upward. Its README says masked grouped GEMM can consume output from DeepEP's low-latency kernels, and the vLLM recipe for DeepSeek-V3.2-Exp says DeepGEMM is used in two places: MoE and MQA logits computation.[1][4] That is the stack story in miniature. DeepEP moves tokens across experts. DeepGEMM handles the matrix work shaped by those expert decisions. FlashMLA handles the attention path. vLLM, meanwhile, exposes the production-facing reality: serving V3.2-Exp on supported Hopper or Blackwell data-center GPUs requires concrete install and runtime choices, not just a model download.[4]

The watch item is not whether DeepGEMM beats every tuned library in every workload. It will not. The watch item is whether more Chinese model releases ship with this kind of kernel-level transparency. If Qwen, DeepSeek, GLM, Kimi, Hunyuan, and adjacent families keep moving toward long context, MoE routing, sparse attention, multimodal inputs, and low-precision serving, then the public artifact set has to include more than weights and benchmark tables. It has to include the operational path.

Why this changes the AI-China reading

DeepSeek's kernel releases make China's open-model strategy harder to summarize as "cheap model weights." The real export is a decomposition of efficiency into inspectable parts. FlashMLA says attention efficiency is a kernel problem. DeepEP says expert parallelism is a communication problem. DeepGEMM says low-precision arithmetic is a shape-and-layout problem. vLLM's DeepSeek recipe then shows those parts entering a broader serving ecosystem rather than remaining only in DeepSeek's own codebase.[1][2][3][4]

There is a boundary on the thesis. These artifacts are still specialized. They lean on modern NVIDIA data-center GPUs, low-level CUDA assumptions, and model-specific design choices. They do not automatically solve domestic-accelerator portability, enterprise observability, cost accounting, or reliability under mixed workloads. A team should treat the published performance claims as workload-specific until reproduced inside its own serving envelope.

But the direction is clear. The frontier model is no longer the only object worth watching. In AI-China, the stronger signal is the stack that makes a frontier model usable: kernels, communication libraries, serving recipes, model cards, quantization paths, evaluation harnesses, and hardware-specific runtime support. DeepSeek's kernel layer matters because it turns efficiency from a private claim into an artifact other engineers can test.

Sources

1. deepseek-ai, DeepGEMM GitHub repository - official README covering FP8/FP4/BF16 GEMMs, JIT compilation, Mega MoE, hardware requirements, grouped GEMM layouts, and MIT license.
2. deepseek-ai, DeepEP GitHub repository - official README covering expert-parallel communication, MoE dispatch/combine, JIT compilation, V2 refactor notes, EP2048 scale note, and SM-resource claims.
3. deepseek-ai, FlashMLA GitHub repository - official README covering sparse and dense MLA kernels, DeepSeek-V3 / V3.2-Exp linkage, and stated H800 / B200 kernel performance figures.
4. vLLM Recipes, "DeepSeek-V3.2-Exp Usage Guide" - deployment recipe noting sparse-attention model behavior, DeepGEMM usage in MoE and MQA logits computation, supported GPU class, and serving examples.
5. DeepSeek-AI et al., "DeepSeek-V3 Technical Report" - arXiv paper describing the 671B-total / 37B-activated MoE model, MLA and DeepSeekMoE architecture choices, training-token scale, and H800 GPU-hour claim.
6. Wikimedia Commons, "File:Datacenter Server Racks (22370909788).jpg" - Carl Lender's real 2015 data-center photograph, transferred from Flickr and reviewed as CC BY 2.0.