Kimi K3 turns GPU capacity into an AI decision

Moonshot AI has released Kimi K3 as an open model with 2.8 trillion parameters. AWS now shows a concrete deployment path through SageMaker HyperPod and Amazon EKS. For enterprises, this is less a model announcement than an infrastructure decision: anyone who wants to self-host frontier models must clarify GPU capacity, operating model and cost exposure before the use case goes live.

What changes

According to AWS, Kimi K3 is a Mixture-of-Experts model with 896 experts, 16 of which are activated per token. The model card lists native multimodality, a 1-million-token context window and about 104 billion active parameters per forward pass. That moves open models into a scale that no longer runs casually on existing standard infrastructure.

AWS describes a ml.p6-b300.48xlarge instance with 8 NVIDIA B300 Blackwell Ultra GPUs for operation. As capacity paths, AWS names Flexible Training Plans for SageMaker HyperPod and EC2 Capacity Blocks, which reserve defined GPU capacity for a period of time. Technically, SageMaker HyperPod with the Inference Operator and a self-managed Amazon EKS cluster are the two recommended routes.

Why it matters

Open weight initially sounds like more control. In practice, it creates a new sourcing question: Do you buy model access as an API, reserve GPU capacity yourself, or run a hybrid approach by data class and latency requirement?

For CIOs and CFOs, the difference is material. API costs scale with usage. Self-hosting shifts the risk toward utilization, platform operations, patching, observability, model updates and skills. The economic question is therefore not only: Is Kimi K3 capable? It is: Which workloads justify reserved capacity?

DACH perspective

For DACH companies, self-hosting can be attractive when sensitive documents, long contexts or sector-specific models should not permanently run through external APIs. At the same time, new evidence requirements appear: where data is processed, who operates the GPU clusters, how model weights are updated, and what cost arises per completed business transaction.

A pragmatic starting point is a capacity profile: data class, expected tokens per task, latency target, GPU reservation, utilization assumption, exit path to an API and ownership for operations and security. Only then does open weight become a robust enterprise architecture.