Moonshot abre los pesos de Kimi K3.1 Pro: 1,56 TB que reabren el debate sobre autoalojar IA

Esta semana la novedad con más consecuencias prácticas es la publicación de los pesos de Kimi K3.1 Pro, que reabre el debate sobre autoalojar modelos potentes. Además, Snowflake amplía su oferta de datos compartidos y gobierno de IA, pandas corrige una regresión delicada con fechas y GitHub Actions avisa de un cambio de seguridad que afecta a los flujos públicos.

IA generativa: Kimi K3.1 Pro ya se puede descargar

Qué ha pasado

Moonshot AI ha cumplido el plazo que se había marcado y ha publicado los pesos de Kimi K3.1 Pro en Hugging Face (se abre en pestaña nueva). Llegaron el 4 de noviembre, según Startup Fortune (se abre en pestaña nueva), unos días después de estrenarse en la API. El modelo es multimodal, usa una arquitectura de mezcla de expertos con 2,8 billones de parámetros (104.000 millones activos) y admite un contexto de 1.048.576 tokens.

La descarga no es trivial: el repositorio ocupa 1,56 TB (se abre en pestaña nueva). Startup Fortune calcula unas ocho GPU NVIDIA B300 y 2,3 TB de memoria de GPU para ejecutarlo. En las pruebas que publica la propia Moonshot (se abre en pestaña nueva), Kimi logra un 65,7 % en Terminal-Bench 4.0, frente al 66,4 % de Claude Opus 5.5 y el 58,2 % de GPT-6 Astra. Son datos del fabricante: llms.blog (se abre en pestaña nueva) no encontró réplicas independientes de esos resultados. Como referencia externa, Startup Fortune sitúa al modelo en 55 puntos en el índice de Artificial Analysis, por 58 de Opus 5.5.

La licencia (se abre en pestaña nueva) es propia. Permite usar, modificar, afinar y redistribuir, pero quien ofrezca el modelo como servicio y supere 20 millones de dólares de ingresos en 12 meses necesita un acuerdo aparte con Moonshot. El uso interno que no llegue a terceros queda exento de esa condición.

Por qué importa

Elegir un modelo muy capaz suele implicar depender de una API ajena. Eso tiene un coste operativo: el 2 de noviembre, Google marcó como obsoletos 0 y 1 (se abre en pestaña nueva), que se redirigirán a otros modelos el 1 de diciembre con cambios incompatibles. Con pesos propios decides cuándo cambias de versión y dónde se quedan los datos. A cambio, asumes el coste de infraestructura, la seguridad y la responsabilidad de evaluar el modelo.

Para seguridad y compliance hay dos puntos más. Moonshot retiró contenido de ciberseguridad (se abre en pestaña nueva) del entrenamiento, pero el modelo publicado aún resuelve el 81 % de su banco interno de exploits, frente al 33,3 % de K3. Y si afinas el modelo, las directrices de la Comisión (se abre en pestaña nueva) solo te convierten en proveedor en casos excepcionales: cuando la modificación consume más de un tercio del cómputo de entrenamiento original.

Tampoco conviene dar por buena ninguna protección sin probarla, ni propia ni ajena. El 5 de noviembre, Check Point detalló (se abre en pestaña nueva) cómo saltarse el modo Lockdown de ChatGPT mediante la vista previa de HTML. OpenAI lo había corregido el 18 de septiembre.

Qué hacer en tu empresa

• Revisa la licencia con tu equipo legal antes de cualquier piloto, sobre todo si vas a exponer el modelo a clientes o a empresas del grupo.
• Calcula el coste real de autoalojar (GPU, operación, guardias) frente a la API, con tu volumen de tokens y no con una estimación genérica.
• Evalúa con tus propios casos y datos: no decidas con pruebas del fabricante.
• Audita el código del repositorio antes de ejecutarlo, fija el commit exacto y evita trust_remote_code=True fuera de un entorno aislado.
• Anota en tu inventario de IA el origen del modelo, la versión, los usos permitidos y qué cómputo empleas al afinarlo.

Para profundizar: Adopción de IA generativa

SQL y modelado de datos

Snowflake abre sus tablas Iceberg a clientes externos. Open Data Sharing (se abre en pestaña nueva) alcanzó disponibilidad general el 2 de noviembre. Permite compartir datos en vivo y de solo lectura, guardados en tablas Iceberg gestionadas por Snowflake, con consumidores de fuera de la plataforma mediante las API estándar de Iceberg REST Catalog, sin mover datos ni montar ETL. La versión final añade compartición entre regiones, en AWS y Azure, y autenticación por federación de identidad. En la práctica, puedes servir un mismo listado a usuarios de Snowflake y a clientes abiertos. Conviene revisar antes qué región queda asignada a cada consumidor, porque se fija al crearlo.

Las vistas semánticas de Snowflake calculan a otro nivel de detalle. Desde el 2 de noviembre están en preview las expresiones LOD (se abre en pestaña nueva), que calculan una métrica a un grano distinto del de la consulta con FIXED DIMENSIONS, INCLUDE DIMENSIONS y EXCLUDE DIMENSIONS. Un ejemplo es el ingreso medio de cada cliente dentro de su región. Esto acerca al modelo semántico lógica que solía vivir en herramientas de BI. Eso sí, Cortex Analyst y Cortex Agents todavía no las admiten, así que no sirven aún para consultas en lenguaje natural.

Cortex AI Gateway centraliza el acceso a modelos. Snowflake dejó disponibles en general (se abre en pestaña nueva), el 3 de noviembre, la inferencia, la observabilidad y la gestión de costes de su pasarela. Ofrece un único punto de acceso gobernado, con trazas por petición, presupuestos por equipo y cuotas por usuario que pueden bloquear al llegar al límite. Para quien ya trabaje en Snowflake, es una forma de atribuir el gasto de IA sin construir esa capa por su cuenta.

Python y R para datos

pandas 3.1.1 corrige una regresión que altera fechas. La versión publicada el 4 de noviembre (se abre en pestaña nueva) llega dos semanas después de 3.1.0. Sus notas de cambios (se abre en pestaña nueva) incluyen un fallo delicado: al convertir a timestamp de PyArrow con astype() o convert_dtypes(dtype_backend="pyarrow"), las fechas ausentes se sobrescribían con la época Unix. También arregla que Series.map() devolviera series de solo lectura con valores de tipo fecha, y que ffill() y bfill() compartieran memoria con el original en columnas PyArrow sin nulos. Si usaste 3.1.0 en procesos con PyArrow, actualiza y comprueba si alguna tabla recibió fechas de 1970 en lugar de nulos.

MLOps en Amazon SageMaker AI

GitHub Actions bloqueará pull_request_target el 2 de diciembre. GitHub ha retrasado un mes (se abre en pestaña nueva) este cambio, que afecta a repositorios públicos: el evento se ejecuta en el contexto del repositorio base, con acceso a sus secretos, y puede exponerlos ante código no fiable de un fork. Antes habrá dos cortes de prueba, el 9 y el 16 de noviembre, de 16:00 a 18:00 UTC, en los que esos flujos fallarán. Los repositorios privados e internos no se ven afectados. Si publicas código de ML en abierto, revisa ya qué flujos dependen de este evento y autoriza solo los imprescindibles.

Voz de baja latencia en un endpoint de SageMaker AI. AWS explicó el 3 de noviembre cómo desplegar Sonic 3.6, de Cartesia (se abre en pestaña nueva), como paquete de AWS Marketplace en un endpoint en tiempo real dentro de tu VPC. Según el artículo, los datos de inferencia se quedan en tu cuenta. Es útil para centros de contacto con requisitos de residencia, aunque el modelo de transcripción Ink no está disponible por esta vía: se contrata mediante la API de Cartesia.

Para profundizar: Formación en MLOps

---

Si una sección no aparece es porque esta semana no ha habido novedades relevantes.

Este contenido es informativo y no constituye asesoramiento jurídico.