Informe · Octubre de 2026

Resumen ejecutivo

Entrenar un modelo base con datos de minería o petróleo da ventajas reales, pero acotadas: dominio de la jerga, formato constante, menor costo en tareas repetitivas y control de los datos. No da conocimiento actualizado y no reemplaza a un buen RAG.

• Entrenar son tres cosas distintas (desde cero, preentrenamiento continuado y fine-tuning), con costos muy diferentes.
• La ventaja principal está en el comportamiento (jerga, formato, criterio) y en el costo de tareas repetitivas. No está en memorizar hechos.
• Los hechos que cambian (precios, reservas, normativa, proyectos) van por RAG.
• Lo habitual y más económico: un buen modelo general, más RAG y, si hace falta, un ajuste liviano con LoRA.
• Preentrenar desde cero casi nunca se justifica para una empresa de un sector.
• Todo modelo ajustado envejece cuando aparece una base mejor, así que hace falta un conjunto de evaluación propio para decidir cuándo repetir el trabajo.

Las cifras de este informe son órdenes de magnitud, no presupuestos.

1. Tres formas de entrenar

La palabra entrenar cubre trabajos muy distintos. Conviene separarlos antes de hablar de ventajas.

Opción	Qué hace	Datos	Cómputo	Cuándo tiene sentido
Preentrenar desde cero	Entrena todos los pesos desde valores aleatorios	Del orden de billones de tokens	Clústeres de miles de GPU durante semanas o meses	Prácticamente nunca para una empresa de un sector
Preentrenamiento continuado	Sigue entrenando todos los pesos de una base con un corpus del sector	Miles de millones a cientos de miles de millones de tokens del dominio	Muchas GPU durante días o semanas	Hay un corpus grande y de calidad, con jerga poco cubierta por los modelos generales
Fine-tuning supervisado (SFT)	Ajusta el modelo con ejemplos de entrada y respuesta ideal	Cientos a decenas de miles de ejemplos curados	Una o pocas GPU; con LoRA o QLoRA, a veces una sola de gama alta para modelos medianos	Tareas concretas con formato y criterio definidos
Ajuste por preferencias	Enseña cuál de dos respuestas es mejor	Pares de respuestas comparadas por expertos	Similar al SFT	Pulir criterio y tono cuando el SFT ya funciona

LoRA merece una aclaración, porque es la técnica más usada. En vez de modificar los miles de millones de pesos de la base, entrena unas matrices pequeñas (adaptadores) que se suman a las originales. Se actualiza una fracción muy chica de los parámetros, así que es más barato, más rápido y el adaptador se puede guardar, cambiar o apagar sin tocar la base. QLoRA hace lo mismo sobre una base cuantizada para ahorrar memoria.

2. Qué ventajas tiene el modelo resultante

2.1 Jerga y formato

El sector tiene vocabulario, unidades y estructuras propias. En minería: informes técnicos tipo NI 43-101 o JORC, ley en gramos por tonelada, onzas, diferencia entre recursos y reservas. En petróleo y gas: barriles y barriles equivalentes de petróleo, clasificación de reservas (1P, 2P, 3P), informes de pozo y registros.

Un modelo ajustado respeta esa terminología y esa estructura sin que haya que repetirlas en cada prompt. Eso mejora la consistencia y además acorta el prompt final: menos tokens de instrucciones en cada consulta significa menos costo y menos latencia.

2.2 Tareas acotadas, más baratas y rápidas

Para tareas repetitivas y bien definidas (extraer campos de informes técnicos, clasificar documentos, resumir con una plantilla fija), un modelo chico ajustado puede igualar a uno general mucho más grande. Un modelo de 70.000 millones de parámetros a 4 bits ocupa unos 35 GB, y uno de 7.000 millones, unos 3,5 GB. Menos memoria implica menos hardware, menos latencia y menor costo por documento procesado.

2.3 Privacidad y control

Un modelo propio puede correr en servidores propios. Los datos de exploración, contratos e informes internos no salen hacia una API externa. Además, la versión del modelo no cambia de golpe, a diferencia de un servicio al que el proveedor puede actualizar o retirar.

2.4 El corpus propio como activo

Los datos curados y etiquetados por expertos del sector son lo más difícil de copiar. Sirven para entrenar, para evaluar y para volver a ajustar sobre una base mejor en el futuro.

3. Lo que el entrenamiento no resuelve

• Hechos que cambian. Precios de commodities, reservas, normativa, proyectos y licencias se actualizan todo el tiempo. Reentrenar cada vez no es práctico. Hay investigación que sugiere que enseñar hechos nuevos por fine-tuning puede aumentar las alucinaciones, y un RAG con fuentes citables es más fácil de auditar.
• Cifras exactas y cálculos. El modelo predice texto, no calcula con garantías. Conversiones de unidades, valuaciones y promedios conviene hacerlos con herramientas de cálculo.
• Pérdida de capacidad general. Un ajuste agresivo puede degradar lo que el modelo hacía bien antes (olvido catastrófico).
• Envejecimiento. Cuando sale una base mejor, hay que repetir el trabajo. Según lo que conozco, y sin haberlo verificado en esta sesión, Bloomberg presentó en 2023 un modelo propio para finanzas de unos 50.000 millones de parámetros, y estudios posteriores mostraron que modelos generales más nuevos lo igualaban o superaban en varias tareas del sector.
• Razonamiento técnico. Que un modelo haya leído muchos informes geológicos no garantiza que razone bien sobre un yacimiento. Hay que medirlo.
• Evaluación. Sin un conjunto de pruebas propio no se sabe si el ajuste mejoró algo.

4. Conocimiento y comportamiento: dónde va cada cosa

La regla práctica es que el conocimiento va por RAG y el comportamiento va por fine-tuning.

Necesidad	Herramienta	Por qué
Datos actualizados (precios, reservas, normativa, proyectos)	RAG o herramienta con datos del día	Cambian a diario, se actualizan sin reentrenar y se pueden citar
Documentos internos y archivo propio	RAG	Trazabilidad: se sabe de qué fuente salió cada dato
Estilo, estructura y terminología	Instrucciones fijas en el prompt o LoRA liviano	Es comportamiento, no conocimiento
Cálculos y conversiones	Herramientas de cálculo	El modelo no garantiza exactitud numérica
Extracción masiva de campos de PDFs técnicos	Modelo chico ajustado, más validación	Menor costo por documento
Privacidad total	Modelo propio en servidores propios	Los datos no salen
Jerga muy especializada que el modelo general no entiende	Preentrenamiento continuado	Solo con un corpus grande y de calidad

5. Cómo encaja en el mapa de niveles

En el esquema de cuatro niveles del manual para principiantes, entrenar toca un solo nivel.

• Nivel 3, el modelo: cambian los pesos, o se le suman adaptadores LoRA. El resultado sigue siendo un archivo de matrices, y los pesos siguen siendo datos pasivos.
• Nivel 1, el arnés: no cambia. El RAG sigue entrando por el prompt final como texto.
• Nivel 2, el motor de inferencia: no cambia en lo esencial. Muchos motores permiten cargar la base una sola vez y aplicar distintos adaptadores según la tarea.
• Nivel 4, el hardware: lo define el tamaño de la base. Entre 7.000 y 70.000 millones de parámetros alcanza con una o pocas GPU. Un modelo de billones de parámetros ya es de datacenter.
• Tokens: el ajuste no cambia el tokenizador de la base. Los términos técnicos raros (nombres geológicos, siglas, compuestos) se parten en varios tokens y ocupan más contexto, y eso no se corrige entrenando.

6. Qué datos hacen falta

Tipo de dato	Ejemplos	Para qué sirve
Documentos técnicos	Informes NI 43-101 o JORC, estudios de factibilidad, informes de pozo, reportes de reservas, normativa	Preentrenamiento continuado, o RAG
Pares de entrada y salida curados por expertos	Informe más la ficha de campos correcta	Fine-tuning supervisado
Respuestas comparadas	Dos resúmenes con cuál es mejor y por qué	Ajuste por preferencias
Conjunto de evaluación	50 a 200 casos con respuesta de referencia	Siempre, antes y después

Puntos a cuidar:

• La calidad pesa más que la cantidad: pocos ejemplos buenos rinden más que muchos ruidosos.
• Extraer bien las tablas, los mapas y los PDFs escaneados suele ser el cuello de botella.
• Verificar derechos de uso y confidencialidad de cada documento.
• Fechar los datos, para no mezclar información vieja con vigente.

7. Plan paso a paso para empezar sin gastar de más

1. Definir una tarea concreta y la métrica de éxito (por ejemplo, porcentaje de campos extraídos correctamente).
2. Armar el conjunto de evaluación con casos reales y respuestas de referencia, y no tocarlo durante el entrenamiento.
3. Medir primero un modelo general bueno con instrucciones claras y RAG. Esa es la línea de base.
4. Si falta formato, estilo o criterio, hacer fine-tuning liviano con LoRA sobre ejemplos curados.
5. Evaluar contra la línea de base y decidir con números, no con impresiones.
6. Considerar preentrenamiento continuado solo si hay un corpus muy grande y la jerga sigue fallando.
7. Mantener: reevaluar cada vez que aparezca una base mejor, y repetir el ajuste si conviene.

8. Riesgos

Riesgo	Qué pasa	Cómo mitigarlo
Alucinaciones con apariencia técnica	El modelo escribe cifras plausibles pero falsas	Exigir fuentes, validar cada número contra los documentos y usar RAG para datos
Datos desactualizados	Responde con información vieja como si fuera vigente	Mantener la información vigente fuera de los pesos
Pérdida de capacidad general	El ajuste degrada otras habilidades	Ajuste liviano y evaluación amplia
Datos confidenciales en el entrenamiento	El modelo podría reproducirlos	Curar el corpus y controlar quién usa el modelo
Derechos de autor y licencias	Uso de documentos sin permiso	Revisar la procedencia de cada fuente
Obsolescencia de la base	Una base nueva supera al modelo ajustado	Conservar los datos y el set de evaluación para repetir el ajuste

9. Decisión rápida

Conviene ajustar un modelo si:

• la tarea es repetitiva y de alto volumen;
• el formato y el criterio importan más que los datos del día;
• hay datos curados y expertos que los validen;
• la privacidad o el costo por documento justifican infraestructura propia.

Conviene empezar por RAG y un modelo general si:

• los datos cambian a diario;
• hace falta citar fuentes;
• no hay todavía un conjunto de ejemplos curados ni de evaluación;
• se quiere validar la idea antes de invertir en entrenamiento.

Lo más frecuente es combinar ambos: RAG para el conocimiento vigente y un ajuste liviano para el estilo y la estructura.

10. Glosario

Término	Significado
Modelo base	Modelo preentrenado sobre el que se construye; todavía no sigue bien instrucciones
Preentrenamiento	Entrenamiento inicial sobre enormes volúmenes de texto
Preentrenamiento continuado	Seguir entrenando una base con un corpus de un dominio
Fine-tuning (SFT)	Ajuste supervisado con ejemplos de entrada y respuesta ideal
LoRA / QLoRA	Técnica que entrena adaptadores pequeños en lugar de todos los pesos; QLoRA lo hace sobre una base cuantizada
Adaptador	Conjunto chico de matrices que se suma a los pesos de la base
Olvido catastrófico	Pérdida de habilidades previas por un ajuste excesivo
RAG	Recuperar información y agregarla al prompt, sin cambiar los pesos
Conjunto de evaluación	Casos de prueba con respuesta de referencia para medir el modelo
Línea de base	Resultado del modelo general sin ajustar, contra el que se compara

Anexo: casos reales en el sector petrolero

Este anexo reúne lo que se encontró en fuentes públicas hasta octubre de 2026. Casi todo es información que comunican las propias empresas o sus proveedores, sin auditorías independientes, así que las cifras sirven de orientación.

A.1 Shell: adaptar un modelo base abierto

Shell tomó un modelo abierto (Llama) y lo adaptó con el framework NVIDIA NeMo. Combinó dos de las opciones de la sección 1: preentrenamiento continuado (en la terminología de la empresa, DAPT) y fine-tuning supervisado (SFT). Lo hizo además del RAG, no en su lugar.

• Curó primero los datos: armar un corpus de alta calidad fue la base del proyecto.
• Generó datos sintéticos, que después hubo que verificar. Descubrió que mezclar SFT con DAPT mejoraba mucho la incorporación de conocimiento.
• Armó benchmarks propios para comprobar que el modelo captara bien sus dominios técnicos.
• Resultado reportado: 26 % más de precisión que los modelos Llama sin ajustar y 30 % de mejora en comprensión del dominio en los benchmarks de Shell. Son mediciones sobre pruebas internas.
• Motivo: necesitaba capacidades de personalización que los productos del mercado no ofrecían.

A.2 YPF: agentes y monitoreo en tiempo real

• Centro de monitoreo en tiempo real (RTIC): usa analítica avanzada e IA para optimizar el upstream y hacer ajustes operativos de forma remota. La prensa regional reporta que monitorea más de 2.000 pozos de Vaca Muerta.
• Plaza Huincul: en diciembre de 2025 inauguró una sala integrada de control operativo con cinco agentes de IA entrenados para resolver consultas técnicas, optimizar procesos y dar datos a los operadores.
• Cadena de suministro: junto con Globant lanzó Digital Suppl.AI, una plataforma con 46 agentes de IA en ocho soluciones agénticas para abastecimiento, inventarios, contratos y proveedores.
• Comercial: la App YPF se potencia con IA como parte de su transición a billetera interoperable.

Las fuentes no aclaran si hay fine-tuning de un modelo base o agentes configurados sobre un modelo general. No se puede afirmar cuál de las dos cosas es.

A.3 Otras petroleras

Empresa	Qué se reporta	Estado de la evidencia
Aramco	Metabrain, lanzado en marzo de 2024 y presentado como LLM industrial: 7.000 millones de parámetros y 90 años de datos de la compañía. En enero de 2025 se anunció el desarrollo de uno de 1 billón de parámetros	No se confirmó que el modelo mayor esté terminado ni si Metabrain parte de una base ajustada
ExxonMobil	Perforación automatizada en Guyana con Halliburton, con 33 % menos de tiempo de maniobras; busca especialistas en IA generativa para subsuelo y operaciones de pozo	Cifra comunicada por la compañía y su socio
BP	Fue de las primeras en probar Copilot de Microsoft	Uso de un modelo de terceros
Tecpetrol	En Fortín de Piedra bajó la perforación de 40 a 16 días y duplicó las etapas de fractura por jornada, con IA, machine learning y un centro de operaciones en tiempo real	Cifra de la empresa; no aísla el aporte de la IA

Tendencia general: según un análisis de BMI, la adopción de IA es despareja. Lideran las grandes petroleras y algunas estatales, con apoyo de socios como SLB, Halliburton, Microsoft y NVIDIA, mientras que el 57 % de las exploradoras y productoras chicas ni la usa ni planea usarla (31 % en las grandes). El sector también reporta falta de especialistas en IA. Una nota de la SPE (JPT) de principios de 2024 ya señalaba que las petroleras apuntaban al fine-tuning de modelos base, muchas de forma silenciosa.

A.4 Lecciones para este informe

• Quien ajusta modelos base de forma documentada (Shell) tiene un corpus enorme de décadas, equipos de datos y un benchmark propio.
• Ni siquiera Shell abandona el RAG: ajusta el modelo y además recupera información.
• La mayoría de los casos públicos son agentes, centros de monitoreo y modelos de uso general sobre datos propios, más que modelos entrenados por la empresa.
• Lo que permitió medir la mejora fue un conjunto de evaluación propio, algo que el plan de la sección 7 pone como segundo paso.
• Conviene leer con cuidado las cifras de mejora: casi todas las comunican las empresas o sus proveedores.

A.5 Fuentes consultadas

NVIDIA (caso de estudio de Shell con NeMo), Weights & Biases (caso de Shell), JPT de la SPE, iProfesional, Más Energía de LM Neuquén, Forbes Argentina y Revista Economía (Digital Suppl.AI), Energy Today (análisis de BMI), Sharikat Mubasher (Aramco) y Fortune.

De tu pregunta a la respuesta, paso a paso · Edición de octubre de 2026

Cómo usar este manual

Este manual explica, sin conocimientos previos, qué ocurre desde que se escribe una pregunta hasta que aparece la respuesta de un modelo de lenguaje grande (LLM, por large language model). Se lee en orden: cada paso se apoya en el anterior.

Todo el recorrido sigue una sola pregunta de prueba:

¿Cuánta memoria necesita Kimi K3 (2,8 billones de parámetros) a 4 bits?

Dos avisos antes de empezar:

• En castellano, un billón es 10¹² (un millón de millones)
• Las cifras de modelos son de octubre de 2026, tomadas de fuentes públicas, y cambian rápido. Los modelos cerrados no publican su tamaño.

1. El mapa general

Un LLM no trabaja solo. Alrededor del modelo hay cuatro niveles, y cada uno resuelve un problema distinto.

Nivel	Qué es	Ejemplos	Qué decide
1. Arnés u orquestador	Software de aplicación que coordina todo	LangChain, LangGraph, LlamaIndex	Qué texto se le manda al modelo y qué más hay que hacer
2. Motor de inferencia	Software que ejecuta el modelo	vLLM, SGLang, TensorRT-LLM	Qué se calcula, en qué orden y qué se reutiliza
3. Modelo (LLM)	Un archivo de números: matrices de pesos	Kimi K3, GLM, Qwen	La probabilidad del próximo token
4. Hardware	GPU, memoria y conexiones	Clústeres de GPU	Quién hace físicamente las multiplicaciones

El esquema completo, con ida y vuelta:

Tu prompt (texto humano)                    La respuesta (texto humano)
        ↓ ida                                      ↑ vuelta
Arnés: arma el prompt final (texto)         valida el texto de la respuesta
        ↓                                          ↑
Motor: convierte el texto en tokens         convierte tokens en texto
        ↓                                          ↑
Modelo: tokens → vectores → matrices        probabilidad de cada token
        ↓                                          ↑
Hardware: las GPU multiplican               resultados numéricos

Regla para recordar: lo que baja se vuelve cada vez más numérico, y lo que sube vuelve a ser texto. El arnés es la capa de aplicación; el motor, el modelo y el hardware son la capa de ejecución.

2. Paso 1: leer los números (billones, mil millones y siglas)

Los nombres de los modelos llevan una sigla con la cantidad de parámetros. La letra viene del inglés:

Sufijo	En inglés	En castellano	Ejemplo
M	million	millones	350M = 350 millones
B	billion	mil millones	70B = 70.000 millones
T	trillion	billones	2,8T = 2,8 billones

Por eso un modelo de 2.8B tiene 2.800 millones de parámetros, mil veces menos que uno de 2,8T. Kimi K3 es un modelo de 2,8T.

También cambia la puntuación: el inglés usa punto decimal (1.4 TB) y el castellano usa coma (1,4 TB).

Totales y activos. Muchos modelos son MoE (mezcla de expertos, Paso 8) y muestran dos números. En Qwen3-30B-A3B, el 30B es el total (30.000 millones) y el A3B son los parámetros activos por token (3.000 millones). El total define cuánta memoria se necesita; los activos definen cuánto cómputo se gasta por token.

3. Paso 2: qué es un LLM

Un LLM es, en esencia, una pila de miles de matrices (más precisamente, tensores) llenas de números, con algunas operaciones simples entre ellas. Esos números son los parámetros o pesos. Los 2,8 billones de Kimi K3 son 2,8 billones de números guardados en un archivo.

Cuatro ideas que conviene tener claras:

• El archivo no contiene texto, reglas ni frases guardadas. Solo números ajustados durante el entrenamiento.
• Los pesos son datos pasivos. No se multiplican solos: los multiplica una GPU, dirigida por el motor de inferencia.
• Los pesos están congelados durante una consulta. El modelo no aprende nada de lo que se le pregunta.
• El modelo no tiene memoria entre consultas. Cada llamada arranca de cero; lo que parece recordar es texto que se le vuelve a enviar.

Hay dos tipos de memoria: la de largo plazo, que son los pesos, y la de trabajo, que es el contexto de la consulta actual.

Que sea solo matrices describe el mecanismo, no el límite de lo que puede hacer. Que de esas multiplicaciones salgan razonamiento, código o traducciones es un resultado del entrenamiento a esta escala, y cómo lo logra por dentro sigue siendo un tema de investigación (interpretabilidad).

4. Paso 3: los tokens

Un token no es una palabra: es una pieza de texto. Puede ser una palabra completa, un pedazo de palabra, un signo de puntuación o un espacio. El tokenizador tiene un vocabulario fijo y corta el texto en las piezas más largas que encuentra en él.

• Las palabras comunes suelen ser un solo token.
• Las palabras largas, raras o técnicas se parten en varios.
• Los números, el código y los saltos de línea también gastan tokens.

En inglés, 1 token equivale aproximadamente a 0,75 palabras. En castellano hace falta más de un token por palabra, porque los tokenizadores se entrenan sobre todo con inglés y el castellano tiene palabras largas, con acentos y conjugaciones. Como orden de magnitud, 1 millón de tokens son unas 600.000 a 700.000 palabras en castellano (estimación, varía según el modelo).

Todo se mide en tokens: la ventana de contexto, la velocidad de generación, la memoria que ocupa el KV cache y el precio de las APIs.

La ventana de contexto es el máximo de tokens que el modelo puede mirar a la vez, sumando el prompt y la respuesta. Los modelos de frontera están hoy en torno al millón de tokens. Que entre no significa que lo aproveche bien: con contextos muy largos, lo que queda en el medio suele usarse peor, y el costo en memoria y tiempo crece.

5. Paso 4: tu prompt y el prompt final

Hay dos cosas que se llaman prompt:

• Tu prompt: lo que escribís vos, en lenguaje humano.
• El prompt final: lo que el arnés le manda realmente al modelo. Incluye las instrucciones del sistema, los fragmentos que trajo el RAG, el historial de la conversación y tu mensaje.

Tu prompt es una parte del prompt final. Un ejemplo ilustrativo para la pregunta de prueba:

[Sistema] Respondé en castellano, con precisión y sin inventar cifras.
[Contexto del RAG] Kimi K3 tiene 2,8 billones de parámetros totales
y 104.000 millones activos; sus pesos suman unos 1,56 TB.
[Historial] (vacío en la primera consulta)
[Usuario] ¿Cuánta memoria necesita Kimi K3 (2,8 billones de parámetros) a 4 bits?

Punto clave: el prompt final todavía es texto. La conversión a tokens ocurre después, en el motor de inferencia, por obra del tokenizador. Algunos sistemas tokenizan antes, del lado del cliente, solo para contar tokens, pero lo que viaja al modelo es el mismo texto convertido.

6. Paso 5: RAG, o qué sabe el sistema

RAG (Retrieval-Augmented Generation, generación aumentada por recuperación) busca información relevante en documentos, páginas web o bases de datos y la agrega al prompt. Las respuestas salen más precisas y actualizadas sin reentrenar el modelo.

El LLM no sabe que existe un RAG. Para él, los fragmentos recuperados y tu pregunta son una sola secuencia de tokens.

El RAG tiene dos fases:

1. Ingesta (se hace antes, una vez): limpiar los documentos, cortarlos en fragmentos (chunking), convertir cada fragmento en un vector con un modelo de embeddings y guardarlos en una base vectorial.
2. Consulta (cada vez): convertir la pregunta en vector, buscar los fragmentos más parecidos, combinar con búsqueda por palabras clave (BM25) para siglas y cifras, y usar un reranker, un modelo chico que reordena y se queda con los mejores 5 a 20 fragmentos.

Lo que hay que recordar:

• El modelo de embeddings y el reranker son modelos distintos del LLM.
• Si el retrieval trae mal, el tamaño del LLM no lo arregla: responde con lo que tiene en los pesos y aparecen las alucinaciones.
• El RAG solo sabe lo que está en su archivo. Para datos del día hace falta una herramienta (Paso 6).
• Los datos caducan: conviene filtrar por fecha, o se pueden mezclar cifras de hace meses con las de hoy.

7. Paso 6: el arnés u orquestador

El orquestador es la capa de software que coordina el circuito. No es un producto único: puede ser un framework o código propio. El arnés (harness) es todo el andamiaje que rodea al modelo, y el orquestador es su núcleo.

Sus tareas:

• Recibir la pregunta y llamar al RAG.
• Armar el prompt final: decidir qué entra, en qué orden y con qué instrucciones.
• Mantener la memoria: como el modelo no recuerda nada entre llamadas, el arnés reenvía el historial como texto.
• Dar acceso a herramientas (APIs, bases de datos, código).
• Aplicar guardrails: filtros, validación del formato y verificación de que la respuesta se apoye en las fuentes.
• Registrar todo (observabilidad): trazas, costos y evaluación.

Frameworks conocidos:

Categoría	Ejemplos	Para qué sirven
Orquestación y RAG	LangChain, LlamaIndex, Haystack	Conectar modelo, datos y herramientas; indexar y recuperar
Agentes	LangGraph, CrewAI, SDK de agentes de los laboratorios	Flujos con estado y bucles con herramientas
Optimización de prompts	DSPy	Ajustar prompts de forma programática

Suele combinarse un framework de dos categorías; apilar tres o más es señal de sobreingeniería.

MCP (Model Context Protocol) estandariza cómo la IA se conecta con herramientas y sistemas externos. El orquestador actúa como cliente MCP y ejecuta las herramientas que el modelo pide. Se construye una conexión una vez y se reutiliza.

Un agente es un sistema que percibe, razona, llama a herramientas y actúa hacia un objetivo, en varios pasos. Convierte el flujo lineal en un bucle: el modelo pide una herramienta, el orquestador la ejecuta, el resultado vuelve al prompt y el modelo genera de nuevo.

Síntesis: RAG da conocimiento, MCP da acceso y el agente aporta el razonamiento y el objetivo. Si el caso es solo preguntar sobre documentos propios, alcanza con un pipeline lineal: recuperar, armar el prompt, generar y validar.

8. Paso 7: el motor de inferencia

El motor es el software que ejecuta el modelo sobre las GPU. No entiende el texto: compara bloques de tokens, administra memoria y ordena cálculos. El significado aparece solo dentro de las multiplicaciones del modelo.

Sus piezas:

• Tokenizador: convierte texto en tokens a la ida y tokens en texto a la vuelta.
• Planificador: arma lotes con solicitudes de muchos usuarios (continuous batching) para aprovechar la GPU.
• Gestor del KV cache: reserva y libera la memoria donde se guardan los cálculos intermedios.
• Kernels CUDA: las funciones de bajo nivel que realizan las multiplicaciones.
• Paralelismo: reparte el modelo entre varias GPU.
• Sampler: elige cada token según las probabilidades (temperatura, top-p).

El ciclo tiene dos etapas:

1. Prefill: procesa todo el prompt en paralelo y construye el KV cache. Es la etapa más cara cuando el RAG mete mucho texto.
2. Decode: genera un token a la vez. Cada token elegido vuelve a entrar como entrada del siguiente, hasta el token de fin.

KV cache. Son las claves y valores de la atención, ya calculados, guardados en la memoria de la GPU para no repetir cuentas. Dentro de una respuesta, al generar el token 501 solo se calcula lo del token nuevo y se reutiliza lo de los 500 anteriores.

Prefix caching. Entre consultas, el motor divide el prompt en bloques y guarda un índice de dónde está el cálculo de cada uno. Si llega un prompt que empieza igual, reutiliza los bloques idénticos y calcula solo desde donde difiere. Consejo práctico: poner primero lo fijo (instrucciones y estándares), después los fragmentos variables del RAG y al final la pregunta. Si lo variable va al principio, se invalida todo el cache.

Por qué importa tanto el motor: generar un token obliga a leer todos los pesos activos desde la memoria de la GPU, así que el límite suele ser el ancho de banda de memoria y no la capacidad de cálculo. Agrupar muchas solicitudes reparte esa lectura y baja el costo por token.

9. Paso 8: dentro del modelo

Cuando llegan los tokens, el modelo hace esto:

1. Embeddings: cada token pasa a un vector (una fila de una matriz), con información de posición.
2. Atención: en cada capa, cada token puede mirar a los anteriores. Ahí se cruza el contenido de los fragmentos con la pregunta.
3. Feed-forward: una red que transforma cada vector. En los modelos MoE se reemplaza por muchos expertos más chicos y un router.
4. Capa de salida: produce un puntaje por cada token posible del vocabulario, y una función (softmax) lo convierte en probabilidades.

Entre las multiplicaciones hay funciones simples (normalizaciones, activaciones). Sin ellas, apilar cien capas equivaldría a una sola matriz.

MoE (Mixture of Experts, mezcla de expertos). El router elige, por token y por capa, solo unos pocos expertos y deja inactivos al resto. Kimi K3 activa 16 de sus 896 expertos por token. Ventaja: capacidad total enorme con cómputo por token reducido. Costo: todos los expertos tienen que estar cargados en memoria, porque no se sabe de antemano cuáles va a pedir el router, y repartirlos entre GPU exige mucha comunicación.

Dado un mismo prompt, el modelo produce siempre la misma distribución de probabilidades. La variación en las respuestas viene del sampler, que elige un token de esa distribución.

10. Paso 9: el hardware

• GPU: el chip que hace las multiplicaciones, en sus tensor cores. Están hechas para multiplicar matrices.
• Memoria HBM: la memoria de alta velocidad de la GPU, donde viven los pesos y el KV cache.
• Interconexión (NVLink y redes): permite que muchas GPU trabajen como una sola y se pasen datos.

Quién multiplica: los kernels del motor ordenan, los tensor cores de la GPU calculan, y los pesos del modelo son el material. El costo del tamaño se paga en memoria HBM e interconexión entre GPU.

11. Paso 10: el viaje completo de una pregunta

Siguiendo la pregunta de prueba:

1. Escribís tu prompt, en lenguaje humano.
2. El orquestador llama al RAG: convierte la pregunta en vector, busca fragmentos, aplica búsqueda híbrida y reranker.
3. El orquestador arma el prompt final: instrucciones, fragmentos, historial y tu pregunta. Sigue siendo texto.
4. El prompt final se envía al motor de inferencia.
5. El tokenizador lo convierte en tokens, que son números enteros.
6. Prefill: el prompt completo pasa por las capas del modelo y se arma el KV cache.
7. Dentro del modelo, cada token pasa a vector y se multiplica por las matrices (embeddings, atención, feed-forward o MoE). Las GPU hacen las cuentas.
8. La capa de salida devuelve la probabilidad de cada token posible.
9. El sampler elige un token. Ese token vuelve como entrada y se repite el ciclo (decode) hasta el token de fin.
10. El tokenizador convierte los tokens de la respuesta otra vez en texto.
11. El orquestador valida el texto (guardrails), le da formato y lo muestra. Si hay agente, puede volver al paso 2 o llamar a una herramienta.

El RAG actúa antes del modelo y una sola vez; el modelo nunca habla con él. El único ida y vuelta interno es el bucle del paso 9.

12. Paso 11: cuánta memoria hace falta

La cuenta base es:

memoria de los pesos ≈ parámetros × bytes por parámetro

Precisión	Bytes por parámetro	Memoria por cada mil millones de parámetros	Ejemplo con 70B	Ejemplo con 2,8T
FP16	2	2 GB	140 GB	5,6 TB
FP8	1	1 GB	70 GB	2,8 TB
4 bits	0,5	0,5 GB	35 GB	1,4 TB

Respuesta a la pregunta de prueba: Kimi K3 a 4 bits necesita unos 1,4 TB solo para los pesos, más el KV cache, que crece con el largo del contexto (hasta 1 millón de tokens) y puede sumar decenas o cientos de GB. Contá con 1,7 a 2 TB como piso realista. Según las fuentes consultadas, los pesos publicados suman unos 1,56 TB, lo que indica una cuantización de aproximadamente 4 bits. Algunos proveedores lo sirven en FP8, que se acerca a los 2,8 TB.

Y en una computadora local:

• Una PC de escritorio llega hoy a unos 192 a 256 GB de RAM, y las máquinas de consumo con más memoria unificada rondan los 512 GB. No alcanza para un modelo de billones de parámetros.
• Con GPU de datacenter hacen falta unas 20 H100 de 80 GB, o 9 a 12 GPU de 141 a 192 GB. Es un clúster.
• Un servidor con 2 TB de RAM y solo CPU es técnicamente posible, y al ser MoE solo se leen los parámetros activos por token, pero la velocidad queda limitada por el ancho de banda de memoria: pocos tokens por segundo (estimación, sin medir).
• Lo realista en local son modelos de hasta unos 100.000 a 200.000 millones de parámetros totales, en especial MoE chicos y cuantizados. Por ejemplo, Qwen 3.8 Flash Next tiene 125.000 millones de parámetros con 6.000 millones activos, y a 4 bits ocupa unos 65 a 70 GB.
• Para un modelo grande, lo habitual es usarlo por API o alquilar GPU por hora.

13. Paso 12: qué modelos hay hoy

Modelos abiertos, con cifras oficiales (octubre de 2026):

Modelo	Parámetros totales	Activos por token	Nota
Kimi K3 (Moonshot AI)	2,8 billones	104.000 millones	El abierto más grande; 896 expertos; contexto de 1 millón; pesos desde el 27 de julio de 2026
Kimi K2.5	1 billón	32.000 millones	De enero de 2026
GLM-5.2 (Z.ai)	744.000 millones	unos 40.000 millones	Licencia MIT
DeepSeek R1	671.000 millones	n. d.	Referencia de 2025
Qwen 3.8 Flash Next	125.000 millones	6.000 millones	Pensado para correr con menos recursos

Modelos cerrados (GPT, Claude, Gemini): los laboratorios ya no publican la cantidad de parámetros. Lo que circula son estimaciones de terceros no confirmadas, que sirven solo como orden de magnitud.

Más grande no significa más avanzado:

• Kimi K3 es el abierto más grande, y un agregador independiente lo ubicaba entre los puestos 5 y 7 según el índice. Los rankings cambian seguido y cada agregador mide distinto.
• La capacidad depende también de los datos de entrenamiento, el ajuste posterior y el razonamiento en tiempo de respuesta.
• En un MoE, el total engaña un poco: el cómputo por token es el de los parámetros activos.

Modelos en castellano. Hay modelos multilingües que entienden y escriben castellano, como Kimi K3, aunque las fuentes consultadas no detallan qué tan bien lo hace: conviene probarlo con textos propios. Un modelo entrenado solo en castellano a escala de billones no existe, según lo que encontré. Lo más cercano es Latam-GPT, de una alianza liderada por Chile y Colombia: unos 50.000 millones de parámetros (otra fuente habla de más de 70.000 millones), basado en Llama 3 y entrenado con español y portugués. Es entre 40 y 56 veces más chico que Kimi K3.

14. Mini proyecto: tu primer RAG

Para practicar con un archivo propio de notas o artículos:

1. Reunir los textos y limpiarlos (sin menús ni publicidad).
2. Cortarlos en fragmentos. Si las notas son cortas, una nota por fragmento alcanza. Guardar con cada uno su fecha, categoría y fuente.
3. Convertirlos en vectores con un modelo de embeddings multilingüe y guardarlos en una base vectorial.
4. Armar la búsqueda: vectores más palabras clave, y un reranker multilingüe que deje los 5 a 8 mejores fragmentos.
5. Armar el prompt final con instrucciones fijas primero, fragmentos después y la pregunta al final. Incluir reglas como: usar solo cifras de los fragmentos, marcar el dato si falta y citar la fuente.
6. Validar la salida: verificar con código simple que cada número de la respuesta aparezca en los fragmentos.

Orden recomendado: primero ingesta y búsqueda probadas a mano, después generación con validador y recién al final herramientas para datos del día, con agente.

15. Errores frecuentes

• Confundir 2,8 billones con 2.8 billion: son cifras con mil veces de diferencia.
• Creer que el modelo aprende de cada consulta. Los pesos no cambian; lo que cambia es el texto de entrada.
• Creer que el modelo recuerda la conversación anterior. Se le reenvía como texto.
• Creer que un token es una palabra.
• Pensar que más parámetros siempre significa mejor modelo.
• Mirar solo el total en un MoE e ignorar los parámetros activos.
• Culpar al LLM cuando el problema es el retrieval.
• Poner lo variable al principio del prompt y perder el prefix caching.
• Querer correr localmente un modelo de billones de parámetros sin contar el KV cache.

16. Glosario

Término	Significado
LLM	Modelo de lenguaje grande: una pila de matrices de pesos que predice el próximo token
Parámetro / peso	Cada número guardado en las matrices del modelo
Token	Pieza de texto, convertida en un número entero
Ventana de contexto	Máximo de tokens que el modelo puede mirar a la vez
Prompt	Lo que se le manda al modelo; puede ser el del usuario o el prompt final
Embedding	Vector numérico que representa un token o un fragmento de texto
RAG	Recuperar información y agregarla al prompt
Chunking	Cortar documentos en fragmentos para indexarlos
Reranker	Modelo chico que reordena los fragmentos recuperados
Orquestador / arnés	Software que coordina el circuito alrededor del modelo
MCP	Protocolo estándar para conectar la IA con herramientas externas
Agente	Sistema que razona, usa herramientas y actúa en varios pasos
Motor de inferencia	Software que ejecuta el modelo sobre las GPU
Prefill	Procesar todo el prompt de una vez
Decode	Generar la respuesta token por token
KV cache	Cálculos intermedios de la atención guardados para no repetirlos
Prefix caching	Reutilizar el cálculo de prefijos idénticos entre consultas
Sampler	Pieza que elige el próximo token según las probabilidades
MoE	Arquitectura con muchos expertos, de los que se activan pocos por token
Parámetros activos	Los que participan en cada token en un MoE
Cuantización	Guardar los pesos con menos bits para ahorrar memoria
GPU / tensor cores	Chip y unidades que multiplican matrices
HBM	Memoria de alta velocidad de la GPU

17. Autoevaluación

1. ¿Cuántos parámetros tiene un modelo 70B? Respuesta: 70.000 millones.
2. ¿Qué es 2,8T en castellano? Respuesta: 2,8 billones, o 2,8 × 10¹².
3. ¿El modelo sabe que existe un RAG? Respuesta: no; recibe una sola secuencia de tokens.
4. ¿El prompt final es texto o tokens? Respuesta: es texto; lo convierte en tokens el tokenizador del motor.
5. ¿Quién multiplica las matrices? Respuesta: las GPU, dirigidas por el motor de inferencia.
6. ¿Para qué sirve el KV cache? Respuesta: para no recalcular lo ya calculado de los tokens anteriores.
7. ¿Por qué un MoE de 2,8T no necesita el cómputo de un modelo denso de 2,8T? Respuesta: porque por token solo se activan unos pocos expertos.
8. ¿Cuánta memoria piden los pesos de un modelo de 2,8T a 4 bits? Respuesta: unos 1,4 TB, más el KV cache.

Google DeepMind informó que cuatro agentes autónomos basados en Gemini 4 Argon completaron Minecraft, incluyendo la derrota del Ender Dragon, en 27 horas y 14 minutos sin intervención humana. Los agentes escribieron 2.783 programas JavaScript, intercambiaron 229 mensajes y murieron 605 veces, coordinándose de forma espontánea.

A diferencia de AlphaGo o AlphaStar, Argon es un modelo general no entrenado específicamente para el juego. El resultado demuestra capacidades de planificación multiagente, recuperación ante fallos y división de tareas en entornos abiertos. Se suma a otros experimentos recientes de agentes que operan durante horas o días.

El hito refuerza la transición de los modelos de respuesta a sistemas que actúan de forma prolongada. Para la industria, valida la inversión en orquestación de agentes. Para la seguridad, recuerda que sistemas capaces de coordinarse y persistir en entornos complejos también pueden hacerlo fuera de los sandboxes de prueba. La dimensión humana aparece en la pregunta de cuánto control real retenemos cuando los agentes empiezan a resolver problemas que los humanos no programaron explícitamente.

Google DeepMind / AI Briefing y múltiples reportes