Guía para desarrolladores sobre modelos de pesos abiertos

Un modelo de pesos abiertos (open-weight) es un modelo cuyos pesos entrenados —los parámetros aprendidos y guardados en un archivo— se publican para su descarga, normalmente junto con el código de inferencia necesario para ejecutarlos, pero sin los datos de entrenamiento ni el pipeline de entrenamiento que los produjo.

Si has estado llamando a una API alojada y te preguntas si podrías descargar el modelo y ejecutarlo como quien instala un paquete, la respuesta tiene dos partes: sí, puedes descargarlo; no, eso no significa que puedas ejecutarlo. Esta guía cubre qué contiene una publicación de pesos abiertos, por qué la licencia importa más que la etiqueta, qué comprobar antes de construir sobre uno de estos modelos, qué implica realmente servir un modelo de frontera y las tres vías que un desarrollador de aplicaciones sin GPU puede tomar de forma realista.

¿Qué te ofrece realmente un modelo de pesos abiertos?

Una publicación de pesos abiertos contiene los pesos, normalmente el código de inferencia y un archivo de configuración que describe la arquitectura, y rara vez algo sobre cómo se entrenó el modelo. Los pesos son el modelo: miles de millones de números, almacenados en un formato numérico como floats de 16 bits o un tipo cuantizado de 4 bits, organizados en los tensores que la arquitectura espera. El código de inferencia carga esos tensores y ejecuta un forward pass. Todo lo que está aguas arriba —el corpus de entrenamiento, el filtrado de datos y los scripts de entrenamiento— se queda con el publicador.

Esa omisión es lo que separa los pesos abiertos del código abierto. La Open Source AI Definition publicada por la Open Source Initiative exige más que un archivo de pesos: los parámetros, el código que entrena y ejecuta el sistema, y una descripción de los datos de entrenamiento lo bastante completa como para que un ingeniero competente pueda reconstruir algo equivalente. El dataset en bruto en sí no está en esa lista. Una publicación que solo incluye pesos y código de inferencia no alcanza ese listón, por muy permisiva que sea su licencia.

Por qué la etiqueta no te dice nada y la licencia te lo dice todo

La etiqueta “pesos abiertos” describe lo que se publicó, no lo que se te permite hacer con ello. La licencia adjunta a los pesos fija los términos, y estos van desde el uso comercial sin restricciones hasta el uso exclusivo para investigación, siendo habituales las licencias personalizadas redactadas por el propio publicador. Dos modelos pueden ser descargables desde el mismo hub y conllevar obligaciones completamente distintas.

Kimi K3 es un caso concreto. Moonshot distribuye sus pesos y el código que los acompaña bajo una licencia redactada por ella misma en lugar de una estándar. El archivo de licencia de Kimi K3 permite el uso comercial, la modificación y la redistribución, pero añade un umbral de ingresos para operadores de modelo como servicio y un requisito de atribución para despliegues que superen un umbral de ingresos mensuales o de usuarios activos mensuales. Nada de eso se deduce de la palabra “abierto”. Lo descubres leyendo el archivo.

¿Qué deberías comprobar en una licencia de pesos abiertos?

Antes de construir sobre un modelo de pesos abiertos, revisa su licencia buscando cuatro cosas: si se permite el uso comercial, si puedes redistribuir los pesos, si puedes hacer fine-tuning y publicar derivados, y qué prohíbe la política de uso aceptable.

1. Uso comercial. Algunas licencias lo permiten sin más, otras lo restringen por encima de un umbral de ingresos o de usuarios, y otras lo prohíben. Comprueba si existe alguna obligación que se active al escalar.
2. Redistribución. ¿Puedes incluir los pesos dentro de tu propio producto o imagen de contenedor, o solo dirigir a los usuarios a la descarga del publicador?
3. Fine-tuning y derivados. Confirma que puedes modificar los pesos, y comprueba qué licencia debe llevar el derivado y si aplican reglas de nomenclatura.
4. Restricciones de uso aceptable. Muchas licencias incluyen un anexo de política de uso que prohíbe aplicaciones concretas. Léelo pensando en tu producto real, no en la demo.

Trata el archivo de licencia del repositorio como la fuente de verdad. Las etiquetas de metadatos del hub y los resúmenes de terceros se quedan desactualizados.

Descarga libre no es ejecución libre

Poder descargar los pesos de un modelo y poder servirlos son cuestiones distintas, y para un modelo con billones de parámetros la segunda respuesta es un centro de datos, no un portátil.

El resumen del modelo de Kimi K3 indica 2,8 billones de parámetros totales en una arquitectura mixture-of-experts, con 104.000 millones activados por token, 896 expertos de los cuales se seleccionan 16 por token, y una longitud de contexto de 1.048.576 tokens. La misma tabla indica el formato numérico: pesos MXFP4 y activaciones MXFP8, fijados durante el entrenamiento en lugar de aplicados a un modelo ya terminado. Incluso con cuatro bits, 2,8 billones de parámetros suponen almacenamiento a escala de billones: la pestaña Files del repositorio muestra los pesos repartidos en 96 shards de safetensors que suman unos 1,56 TB, con tipos de tensor F32, BF16 y U8. Cada uno de esos bytes tiene que residir en la memoria del acelerador para servir una petición con rapidez, y que “solo 104.000 millones estén activos” no reduce esa huella, porque qué expertos se activan cambia en cada token.

La propia ficha te dice cómo está pensado ejecutarlo. Su sección de despliegue nombra vLLM, SGLang y TokenSpeed como los motores a utilizar y te remite a una API alojada; existe una receta de TokenSpeed específica para este modelo. Nada en la ficha describe una instalación local. Moonshot anunció Kimi K3 el 16 de julio de 2026 y publicó los pesos en Hugging Face el 27 de julio de 2026, la fecha que ese anuncio había fijado.

¿Cómo puedes ejecutar realmente un modelo de pesos abiertos?

Para un desarrollador de aplicaciones, un modelo de pesos abiertos es accesible por tres vías: la API alojada del publicador, un proveedor de inferencia de terceros que ejecute los pesos publicados, o una compilación cuantizada de la comunidad más pequeña, ejecutada localmente mediante una herramienta como Ollama o LM Studio. Descargar los pesos de frontera en bruto no está en la lista, por los motivos anteriores.

Dos matices sobre la tercera fila. Existen cuantizaciones comunitarias de Kimi K3, y Hugging Face lista decenas de derivados cuantizados, pero la mayoría siguen siendo compilaciones podadas de 2,8 billones o de cientos de miles de millones de parámetros, no descargas a escala de portátil. La vía local funciona con modelos dimensionados para ello, y eso es lo que cubren las guías de Ollama y Jan.ai.

La buena noticia es que cambiar de vía consiste, en su mayor parte, en cambiar la base_url. El quickstart de Kimi K3 de Moonshot expone un endpoint compatible con OpenAI, igual que el servidor local de Ollama:

from openai import OpenAI

# Publisher API
client = OpenAI(base_url="https://api.moonshot.ai/v1", api_key="YOUR_KEY")
# Serving provider (check your provider's docs for its endpoint)
# client = OpenAI(base_url="https://<provider>/v1", api_key="YOUR_KEY")
# Local runtime via Ollama
# client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = client.chat.completions.create(
    model="kimi-k3",  # model id differs per route
    messages=[{"role": "user", "content": "Summarise this licence."}],
)
print(response.choices[0].message.content)

Compatible no significa idéntico. Kimi K3, por ejemplo, nunca desactiva el razonamiento, admite un campo reasoning_effort con valores "low", "high" o "max", y devuelve un campo reasoning_content que cada turno posterior de la misma conversación debe arrastrar sin modificar. Consulta la documentación del publicador en busca de campos como estos antes de dar por hecho que se trata de un reemplazo directo.

¿Cómo eliges entre las tres vías?

Elegir entre una API alojada, un proveedor de inferencia de terceros y una compilación cuantizada local se reduce a dónde van tus datos, cuánta latencia puede absorber el producto y si prefieres pagar por token o por hora de hardware que mantienes en marcha. Si los prompts contienen datos que no pueden salir de tu infraestructura, la vía local —o un proveedor con un acuerdo de tratamiento de datos que puedas aceptar— es la restricción que decide todo lo demás. Si la funcionalidad es interactiva, la API del publicador y los proveedores de inferencia te dan el modelo completo a velocidad de centro de datos, mientras que una compilación cuantizada en un portátil sacrifica capacidad y throughput a cambio de cero salida de datos. Si el uso es irregular, la facturación por token es barata al principio y cara a gran volumen; si es constante e intenso, las horas de hardware o el hardware propio aplanan la curva. Responde a esas tres preguntas en ese orden y la vía suele elegirse sola.

Conclusión

Pesos abiertos significa que obtienes los parámetros, no la receta, y tampoco la garantía de que tu hardware pueda hacer algo con ellos. Lee el archivo de licencia del repositorio, lee la sección de despliegue de la ficha del modelo y elige una vía en función de los datos, la latencia y la estructura de costes, no de lo que sea descargable. Si la vía local encaja, empieza por la guía sobre cómo ejecutar modelos de forma privada con Jan.ai, que se apoya directamente en todo lo visto aquí.

Preguntas frecuentes

¿Cuál es la diferencia entre los archivos safetensors y GGUF en Hugging Face?

Safetensors es el formato de almacenamiento de tensores de Hugging Face que los publicadores usan para los pesos originales; almacena únicamente tensores, por lo que la configuración y el tokenizador se distribuyen como archivos aparte, y se carga sin ejecución de código basada en pickle. GGUF es el formato binario creado para llama.cpp y utilizado por Ollama y LM Studio; un único archivo agrupa los tensores cuantizados junto con metadatos estandarizados. Los publicadores suelen lanzar safetensors y la comunidad los convierte a GGUF para los runtimes locales.

¿Puedo llamar a la API alojada de un modelo de pesos abiertos con el SDK de Anthropic en lugar del de OpenAI?

Sí, siempre que el publicador exponga un endpoint compatible con Anthropic, lo cual es una característica de cada proveedor y no una propiedad de los pesos abiertos. Moonshot lo hace: configura la URL base del SDK como https://api.moonshot.ai/anthropic y kimi-k3 responderá en un endpoint de Messages en /anthropic/v1/messages. Se aplican las convenciones de Anthropic, así que max_tokens es obligatorio, el esfuerzo de razonamiento se establece mediante output_config.effort (low, high o max), y cada bloque de thinking, firma incluida, debe devolverse exactamente tal y como llegó.

¿Una compilación cuantizada de la comunidad de un modelo de pesos abiertos conserva la misma licencia que los pesos originales?

Actúa como si así fuera. Una cuantización comunitaria en GGUF o MLX deriva de los pesos del publicador, por lo que en la práctica los términos de licencia del publicador —incluidas las condiciones de uso comercial, las reglas de atribución y cualquier política de uso aceptable— siguen aplicándose junto con lo que añada quien la resubió. La etiqueta de licencia de un repositorio de Hugging Face la fija quien lo subió y puede faltar o ser incorrecta, así que lee el archivo LICENSE original en lugar de los metadatos del derivado.