Ayer Moonshot AI, la empresa china detrás de Kimi, hizo algo que casi ninguna compañía de tecnología se atreve a hacer: pausar las nuevas suscripciones porque sus GPUs están al límite. Así, sin eufemismos. En un comunicado en X dijeron que en las últimas 48 horas la demanda de Kimi K3 —su modelo de 2,5 billones de parámetros lanzado hace poco— casi supera la capacidad total de su infraestructura.
Y aquí viene lo interesante: en vez de bajarle la calidad al servicio, meter a todos en una cola eterna o degradar las respuestas como hacen otros, decidieron cerrar la llave. Los suscriptores actuales siguen igual, pero si querías entrar ahora, mala suerte, espera sentado.
El problema feliz que nadie quiere tener
Mira que es irónico. Hace dos semanas escribí sobre Kimi K3 y su arquitectura masiva de parámetros activos. La comunidad lo recibió bien, los benchmarks le dieron buenas notas, y la gente empezó a migrar. ¿El resultado? La infraestructura de Moonshot no estaba preparada para el tsunami. Es el clásico problema feliz de las startups, pero con un twist: aquí no estamos hablando de servidores web que escalan con un click en AWS, sino de clusters de GPUs que cuestan millones y que no se consiguen de un día para otro.
Lo que más me llamó la atención fue el anuncio paralelo: van a dividir la membresía en dos planes. Uno para uso general (web, app, trabajo) y otro específico para Kimi Code, su herramienta de programación. Esto no es menor. Significa que detectaron que los usuarios de coding consumen muchísimo más cómputo que el usuario promedio de chat, y necesitan cobrar y provisionar de forma distinta.
Mi experiencia con el rate limiting
Yo he estado probando Kimi K3 para algunas pegas de scripting y análisis de logs. La verdad, anda fino cuando funciona. Pero ya había notado que en horarios peak las respuestas se ponían lentas, y un par de veces me tiró errores de timeout. Ahora entiendo por qué. No era mi conexión ni un bug puntual: era el sistema aguantando con alfileres.
Como ingeniero de sistemas, valoro caleta la transparencia. ¿Cuántas veces hemos visto servicios degradarse silenciosamente? AWS con sus “aumentos de latencia”, OpenAI con sus “estamos experimentando alta demanda”, Google con sus errores 503 genéricos. Aquí al menos te dicen: “no nos alcanzan las GPUs, estamos comprando más, y mientras tanto priorizamos a los que ya pagan”.
¿Señal de éxito o de mala planificación?
Las dos cosas, po. Es éxito porque lograron que la gente realmente quiera usar su producto. Pero también es una señal de que subestimaron el impacto. En el mundo de la IA generativa, el costo marginal no es cero: cada token que generas consume electricidad, memoria y tiempo de GPU. Si tu modelo es bueno y barato, la gente lo va a usar hasta reventarlo.
La pregunta que queda es si esto le pasa solo a Moonshot o si es el síntoma de algo más grande. Con Alibaba lanzando Qwen3.8 Max y prometiendo pesos abiertos pronto, con Anthropic y OpenAI peleando por la frontera, y con todos los fabricantes de chips tratando de sacar alternativas a CUDA, el cuello de botella ya no es el software: es el silicio.
Al final, si estás construyendo algo sobre estas APIs, tenís que tener planes de contingencia. No puedes depender de un solo proveedor. La lección de hoy no es técnica, es de arquitectura de negocio: la redundancia no es un lujo, es supervivencia.
Fuente de inspiración: Moonshot AI pauses new subscriptions, saying that over the past two days Kimi K3 demand nearly passed the limit of its capacity, and also reworks its plan tiers
