Contexto técnico
Revisé estos cálculos sobre Kimi K3 y enseguida surgió la pregunta clave: ¿estamos hablando de una prueba de laboratorio o de una integración de IA real para producción? Son presupuestos muy distintos y no se pueden confundir.
Para un modelo de la clase 2.5–2.8T en BF16, la estimación de 32 GPUs B300 no parece descabellada. Realmente se requieren terabytes de HBM, un KV-cache enorme, buffers, además de alimentación y refrigeración que ya es un proyecto de ingeniería por sí mismo, no solo “comprar hardware”.
Pero luego se pone interesante. Con Kimi K3, el debate no es solo el tamaño total del modelo, sino el formato de los pesos y la arquitectura real de servicio. Si la inferencia nativa se ejecuta en MXFP4 o MXFP8, la imagen cambia drásticamente: ya se puede considerar 1–2 DGX B300 no como una broma, sino como un compromiso práctico para escenarios de baja concurrencia.
Sin embargo, no vendería la idea de “un DGX y todo funciona” demasiado alegremente. Sobre el papel, 2.3 TB de HBM en un DGX B300 parece suficiente, pero en la práctica la memoria se consume no solo por los pesos. Necesitas espacio para caché, buffers de servicio, enrutamiento de expertos y un margen de seguridad, de lo contrario el sistema vive al límite.
Por eso estimaciones como $600–700k por un solo DGX B300 para uso privado suenan plausibles solo como escenario de investigación. Mientras que 2× DGX B300 por $1.25–1.45M se acerca más al límite inferior de un despliegue on-prem razonable con batching, peticiones concurrentes y sin una lucha constante por cada gigabyte.
Entiendo perfectamente el debate entre BF16 y cuantización. Si necesitas “calidad sin concesiones”, BF16 es lógico. Pero entonces el presupuesto se dispara a una zona donde muchos se dan cuenta de repente: la API no era tan cara.
Impacto empresarial y automatización
Para los negocios, tres conclusiones. Primero: un modelo abierto gigante no significa automatización de IA barata. El hardware, la interconexión y las operaciones pueden fácilmente ser más caras que la idea misma.
Segundo: si tienes un escenario privado limitado, I+D o un sistema de conocimiento interno, 1–2 nodos pueden justificarse. Si necesitas un SLA estable, contextos largos y muchos usuarios simultáneos, ahorrar en el clúster se traduce en dolor de latencia.
Tercero: muchos equipos sobrevaloran “tener todo on-prem” e infravaloran la arquitectura híbrida de IA. En Nahornyi AI Lab resolvemos justamente estas disyuntivas para clientes: dónde conviene más la API, dónde se necesita una instancia privada y cuándo es más inteligente construir automatización de IA sobre un modelo más pequeño sin esa factura millonaria.
Si ahora te enfrentas a un dilema similar entre on-prem, API y arquitectura personalizada, analicémoslo con cifras reales, no con impresiones de foros. En Nahornyi AI Lab suelo calcular rápidamente dónde la implementación de inteligencia artificial realmente se amortiza y dónde es mejor no comprar una costosa ilusión de control.