Los modelos de peso abierto se han vuelto lo suficientemente potentes como para manejar tareas complejas, como flujos de trabajo agentes de varios pasos, razonamiento avanzado y codificación a largo plazo. Sin embargo, a medida que estos modelos crecen en capacidad, también crecen en tamaño y albergar arquitecturas de parámetros multimillonarios requiere una infraestructura especialmente diseñada, computación GPU de alta gama y marcos de servicio optimizados. El 27 de julio de 2026, Moonshot AI lanzó Kimi K3, un modelo de mezcla de expertos (MoE) de 2,8 billones de parámetros que representa el primer sistema de peso abierto que alcanza la clase de parámetros de 3 billones. Kimi K3 ofrece inteligencia de vanguardia y al mismo tiempo pone sus pesos a disposición del público, para que las organizaciones puedan alojar uno de los modelos más capaces que existen en su propia infraestructura.
Esta publicación explica la implementación de Kimi K3 en AWS utilizando dos enfoques: Amazon SageMaker HyperPod y el clúster de Amazon Elastic Kubernetes Service (Amazon EKS).
Kimi K3 se basa en una arquitectura diferenciada que incluye Kimi Delta Attention (KDA), Gated Multi Head Latent Attention (MLA) y un marco Stable LatentMoE. El modelo distribuye sus 2,8 billones de parámetros entre 896 expertos especializados, activando sólo 16 por token. Esto significa que aproximadamente 104 mil millones de parámetros están activos durante cualquier paso hacia adelante, lo que produce una mejora de 2,5 veces en la eficiencia de escalado con respecto a su predecesor, Kimi K2.
Valor del atributo Parámetros totales 2,8 billones de parámetros activos por token 104 mil millones Arquitectura Mezcla de expertos (MoE) Recuento de expertos 896 (16 activados por token) Ventana de contexto 1 millón de tokens Modalidad Nativo Multimodal (Texto + Visión) Fecha de lanzamiento 27 de julio de 2026
Kimi K3 sobresale en tareas de codificación a largo plazo, flujos de trabajo agentes y razonamiento complejo. Admite llamadas de herramientas nativas, resultados estructurados y un modo de pensamiento siempre activo para la resolución de problemas de varios pasos.
Los pesos abiertos para Kimi K3 están disponibles en Hugging Face con el identificador de modelo moonshotai/Kimi-K3. Los pesos se distribuyen en formato MXFP4 (Microscaling Floating Point 4-bit), que proporciona un equilibrio eficaz entre la calidad del modelo y la eficiencia de la memoria para implementaciones de inferencia a gran escala.
Dada la arquitectura y el tamaño del modelo, servir a Kimi K3 requiere un contenedor de inferencia de día 0 vLLM para Kimi K3. Al momento de escribir este artículo, las confirmaciones de vllm para Kimi K3 están en vllm/vllm-openai:kimi-k3. Esperamos que se fusionen con el contenedor vllm principal en las próximas versiones. vLLM proporciona soporte nativo para arquitecturas MoE, paralelismo tensorial y el formato de cuantificación MXFP4, lo que lo convierte en el motor de servicio recomendado para este modelo.
La implementación de un modelo de esta escala requiere una computación GPU sustancial. Kimi K3 requiere una instancia p6-b300 (ml.p6-b300.48xlarge), que proporciona 8 GPU NVIDIA B300 Blackwell Ultra con interconexiones de gran ancho de banda necesarias para una inferencia tensorial paralela eficiente en todo el grupo de expertos.
AWS ofrece dos mecanismos principales para adquirir esta capacidad:
Planes de capacitación flexibles (para SageMaker HyperPod): proporcione reservas de capacidad comprometidas que se puedan asignar a su clúster HyperPod, de modo que los recursos de GPU estén disponibles para cargas de trabajo de inferencia sostenidas. Bloques de capacidad: le permiten reservar instancias de GPU EC2 por un período definido, brindando acceso garantizado a la capacidad p6-b300 sin compromisos a largo plazo. Las cargas de trabajo de Amazon EKS consumen estas reservas al apuntar a la capacidad reservada.
Amazon SageMaker HyperPod con el operador de inferencia proporciona la ruta más sencilla para implementar Kimi K3. El operador de inferencia se instala automáticamente como parte de la creación del clúster y abstrae la complejidad de la orquestación de contenedores, la carga de modelos y la gestión de puntos finales.
Requisitos previos
Antes de implementar el modelo, complete los siguientes dos pasos previos para configurar su infraestructura.
Paso 1: cree un clúster de SageMaker HyperPod con orquestación EKS
Antes de implementar el modelo, debe aprovisionar un clúster HyperPod. Navegue hasta la consola de Amazon SageMaker AI y siga el flujo de trabajo de creación del clúster:
Abra la consola de SageMaker AI y seleccione Clústeres de HyperPod > Administración de clústeres > Crear clúster de HyperPod. Elija Orquestado por Amazon EKS de la lista. Seleccione Configuración rápida para aprovisionar un clúster con redes, almacenamiento y recursos de IAM predeterminados, o elija Configuración personalizada para integrarlo con VPC, subredes y grupos de seguridad existentes. En Orquestación, cree un nuevo clúster EKS o adjunte uno existente. Verifique que la opción Usar complementos y gráficos de Helm predeterminados esté seleccionada para que el operador de inferencia y otros operadores necesarios se instalen automáticamente. En Grupos de instancias, agregue un grupo de trabajadores configurado con el tipo de instancia ml.p6-b300.48xlarge. Revise la configuración y elija Enviar para comenzar el aprovisionamiento.
Para obtener el tutorial completo, consulte la documentación Creación de un clúster HyperPod de SageMaker con orquestación de Amazon EKS.
Paso 2: Adquirir capacidad mediante un plan de capacitación flexible
El tipo de instancia ml.p6-b300.48xlarge requiere capacidad reservada. Un plan de capacitación flexible proporciona una reserva de capacidad comprometida para sus nodos GPU Blackwell, lo que garantiza que las instancias p6-b300 estén disponibles para su clúster sin competencia del grupo general bajo demanda. Vaya a SageMaker Console, seleccione un bloque FTP según su línea de tiempo y el recuento de instancias. Para crear o adjuntar un plan de formación:
En la configuración del grupo de instancias, elija Plan de capacitación como fuente de capacidad. Seleccione un plan existente que cubra la capacidad ml.p6-b300.48xlarge o cree una nueva reserva especificando el número de instancias y la duración que desee. Configure la zona de disponibilidad objetivo para que coincida con la zona donde está asignada la capacidad de su plan de entrenamiento.
Una vez que el clúster alcance un estado Activo con nodos p6-b300 en buen estado, estará listo para implementar el modelo.
Implementando el modelo
Para implementar Kimi K3 en HyperPod, aplique el siguiente manifiesto InferenceEndpointConfig a su clúster:
Este yaml también se proporciona en el repositorio de GitHub. Aplique esta configuración con:kubectl apply -f kimi-k3.yaml
El operador de inferencia maneja la descarga de modelos desde Hugging Face, la programación de contenedores, las comprobaciones de estado y la preparación de los terminales. Una vez que el punto final pasa a un estado listo, expone una API compatible con OpenAI en la ruta de invocación configurada.
Para los equipos que prefieren administrar su propia infraestructura de Kubernetes, pueden implementar Kimi K3 en un clúster independiente de Amazon EKS y adquirir capacidad de GPU a través de bloques de capacidad EC2, que le permiten reservar instancias p6-b300 por un período definido sin compromisos a largo plazo.
Pasos clave de implementación
El proyecto AI on EKS proporciona una receta de clúster lista para inferencias que automatiza el aprovisionamiento de un extremo a otro. A alto nivel, el despliegue implica las siguientes etapas:
1. Aprovisionar el clúster EKS
Utilice los módulos Terraform proporcionados para crear un clúster EKS optimizado para GPU. Esto incluye redes de VPC, grupos de nodos administrados y las funciones y políticas de IAM necesarias para cargas de trabajo de GPU.
2. Reserve capacidad de GPU con bloques de capacidad
Cree una reserva de bloque de capacidad para instancias p6-b300.48xlarge en su zona de disponibilidad de destino. Los bloques de capacidad garantizan que los nodos GPU solicitados estarán disponibles durante el período de tiempo reservado. Una vez que la reserva se activa, las instancias se unen a su clúster EKS como nodos trabajadores.
3. Instale los controladores de GPU y el complemento del dispositivo
La receta instala el complemento de dispositivo NVIDIA y los controladores de GPU en el grupo de nodos, para que Kubernetes pueda descubrir y programar las GPU disponibles.
4. Implementar el servidor de inferencia vLLM
Un gráfico de Helm o un manifiesto de Kubernetes implementa el contenedor vLLM con argumentos específicos de Kimi K3, incluido el tamaño de tensor paralelo de 8, el formato de carga MXFP4 y la configuración de backend de MoE. El identificador del modelo apunta al repositorio de Hugging Face o, como alternativa, puede sincronizar los pesos del modelo con Amazon Simple Storage Service (Amazon S3) para una carga del modelo más rápida. Los argumentos de servicio reflejan los que se muestran en la configuración de HyperPod anterior.
5. Exponer el punto final de inferencia
Un servicio Kubernetes (tipo LoadBalancer o mediante un controlador Ingress) expone el servidor vLLM en el puerto 8000, proporcionando el punto final /v1/chat/completions compatible con OpenAI para sus aplicaciones.
6. Validar
Confirme la implementación enviando una solicitud de prueba al punto final y verificando una respuesta exitosa del modelo.
Para obtener el tutorial de implementación completo, incluidos los módulos de Terraform, los valores de Helm y las instrucciones paso a paso, consulte la receta de IA en EKS Kimi K3.
Una vez implementado, el punto final Kimi K3 expone una API de finalización de chat compatible con OpenAI. Puede invocarlo utilizando el SDK de OpenAI Python o un simple comando curl.
Usando el SDK de OpenAI Python
Usando rizo
Reemplácelo con el punto final de servicio expuesto por su operador de inferencia HyperPod o la configuración de ingreso de EKS.
Para evitar cargos continuos, elimine los recursos que creó durante este tutorial cuando ya no los necesite. Para implementaciones de SageMaker HyperPod:
Elimine InferenceEndpointConfig ejecutando kubectl delete -f kimi-k3.yaml. En la consola de SageMaker AI, navegue hasta HyperPod Clusters, seleccione su clúster y elija Eliminar. Libera o cancela tu reserva del Plan de Formación Flexible si ya no es necesario.
Para implementaciones de Amazon EKS:
Elimine la implementación de vLLM y los servicios de Kubernetes asociados. Termine el grupo de nodos de GPU o elimine el clúster EKS usando Terraform (destrucción de terraform). Libere su reserva de Bloque de capacidad si aún no ha caducado. Para obtener detalles sobre los precios de las instancias p6-b300 y las reservas de bloques de capacidad, consulte la página de precios de Amazon EC2.
Kimi K3 representa una nueva frontera en las capacidades del modelo de peso abierto y AWS proporciona la infraestructura y los servicios administrados para implementarlo a escala. Ya sea que elija la ruta optimizada del operador de inferencia HyperPod o la flexibilidad de un clúster EKS autoadministrado, la combinación de instancias de GPU p6-b300, servicio vLLM y pesos cuantificados MXFP4 ofrece una implementación con comprobaciones de estado integradas, recuperación automática y verificación de preparación de endpoints para el modelo abierto más grande del mundo. Para comenzar, aquí hay algunos enlaces
Ejemplo de IA de SageMaker HyperPod Kimi K3 en EKS Receta de Kimi K3 Creación de un clúster de SageMaker HyperPod (documentación de AWS) Kimi K3 en Hugging Face Documentación de vLLM
Sobre los autores
Erez Zarum es arquitecto senior de soluciones de startups en AWS. A Erez le apasionan los contenedores y el panorama de IA/ML, y su enfoque único permite a las empresas emergentes acelerar las cargas de trabajo de IA/ML en Amazon EKS.
Vivek Gangasani es líder mundial en arquitectura de soluciones, SageMaker Inference. Dirige la arquitectura de soluciones, la comercialización técnica (GTM) y la estrategia de productos salientes para SageMaker Inference. También ayuda a empresas y nuevas empresas a implementar y optimizar modelos GenAI y a crear flujos de trabajo de IA con SageMaker y GPU. Actualmente, se centra en desarrollar estrategias y contenidos para optimizar el rendimiento de la inferencia y casos de uso, como flujos de trabajo Agentic, RAG, etc. En su tiempo libre, Vivek disfruta hacer senderismo, ver películas y probar diferentes cocinas.