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.

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.

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

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

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

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

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.

Informe · Octubre de 2026

Resumen ejecutivo

Para entrenar los movimientos de un robot, la herramienta de NVIDIA más usada es Isaac Lab, que corre sobre el simulador Isaac Sim. El robot se entrena en una simulación, en una PC con GPU NVIDIA, y después la red neuronal ya entrenada se copia al robot real. Esa red es chica, así que el robot no necesita una placa NVIDIA.

• Isaac Sim es el simulador; Isaac Lab es el framework de entrenamiento. Son los que usan empresas como Boston Dynamics y Agility Robotics.
• GR00T, Cosmos y OSMO están pensados para humanoides y equipos grandes. Para un pato de escritorio no hacen falta al principio.
• El entrenamiento ocurre en la PC de desarrollo. Una Raspberry Pi o similar alcanza, en principio, para ejecutar una política de marcha chica; un Arduino solo sirve como controlador de motores.
• La arquitectura más razonable para un robot barato es de dos cerebros: un microcontrolador para los motores en tiempo real y una placa Linux para visión, voz y conversación.
• Lo que NVIDIA no resuelve: la conversación (se hace con un LLM) y el costo de los motores y sensores, que suele ser el rubro más pesado.
• Antes de vender el robot hay que verificar las licencias de las herramientas para uso comercial.

La información sobre las herramientas proviene de fuentes públicas, en su mayoría de 2024 y 2025. Las versiones y la disponibilidad pueden haber cambiado, y conviene confirmarlas en la documentación oficial. No se verificaron precios.

1. Qué significa entrenar un robot

Un robot que camina no sigue una lista fija de órdenes. Lo habitual es que una red neuronal pequeña, llamada política, reciba lo que miden los sensores (inclinación del cuerpo, posición de cada motor) y devuelva qué debe hacer cada motor en ese instante.

Esa política se aprende de dos maneras principales:

• Aprendizaje por refuerzo: el robot virtual prueba movimientos por ensayo y error, y recibe un premio cuando camina bien y un castigo cuando se cae. Hacerlo con un robot real sería lento y rompería piezas, así que se hace en simulación.
• Aprendizaje por imitación: se le muestran demostraciones (movimientos de una persona, animaciones o trayectorias) y la política aprende a reproducirlas.

Según NVIDIA, el robot se puede entrenar por demostración o por prueba y error en una simulación realista. Después la política se evalúa en simulación y, ya validada, se despliega en el robot real.

Una diferencia importante con el mundo de los modelos de lenguaje: acá no se entrena un modelo de miles de millones de parámetros. Una política de marcha es una red mucho más chica, y por eso puede correr en hardware modesto.

2. El ecosistema de NVIDIA para robots

Los socios industriales muestran qué se usa en la práctica: Agility Robotics, Boston Dynamics, Fourier, Mentee Robotics, NEURA Robotics y XPENG Robotics entrenan sus robots con Isaac Sim e Isaac Lab. NVIDIA también comunicó que Isaac Sim e Isaac Lab estarían disponibles en plataformas abiertas como GitHub.

Hugging Face LeRobot, un proyecto aparte, ofrece herramientas para compartir datos, entrenar modelos y armar entornos de simulación, junto con kits de bajo costo, y funciona con Isaac Lab. Es una opción interesante para presupuestos chicos.

3. El flujo de punta a punta

1. Diseño mecánico: el robot se diseña en 3D (el mismo modelo que se imprime).
2. Modelo de simulación: ese diseño se convierte a un formato de descripción de robots (por ejemplo URDF) con las masas, las articulaciones y los límites de cada motor, y se importa a Isaac Sim.
3. Entrenamiento: en Isaac Lab se define la tarea (caminar, girar, mantener el equilibrio) y el sistema corre miles de copias del robot en paralelo.
4. Validación: se prueba la política en escenarios nuevos dentro de la simulación.
5. Exportación: la política entrenada se guarda como un archivo pequeño.
6. Despliegue: el archivo se carga en el robot real, donde lee los sensores y manda órdenes a los motores.
7. Ajuste real: se mide la diferencia entre simulación y realidad y se corrige.

Regla de oro: la simulación nunca coincide del todo con el mundo real. A esa diferencia se la llama brecha entre simulación y realidad, y es el principal dolor de cabeza de todo el proceso.

4. Aplicado al pato robótico

El robot de referencia es un pato de escritorio de unos 25 cm y 780 g, con 15 motores, una placa Rockchip RK3566, cámara y un conjunto de 8 micrófonos. El objetivo es replicarlo con componentes de mercado más baratos y sin perder funcionalidad.

Cada capacidad del pato se resuelve con una tecnología distinta:

Las 15 articulaciones implican una política con muchas salidas, pero sigue siendo una red pequeña. Un punto crítico es que la simulación necesita un modelo fiel de los motores: su torque máximo, su velocidad y su juego mecánico. Con servos baratos eso se mide en la práctica y se carga en el simulador.

5. Hardware: dónde corre cada cosa

La recomendación de este informe, que es criterio propio y no un dato de las fuentes, es una arquitectura de dos cerebros:

• Un microcontrolador maneja los motores y lee el sensor de inclinación, con respuesta inmediata y bajo costo.
• Una placa Linux corre la política de marcha (si es chica), la cámara, los micrófonos y la comunicación con el modelo de lenguaje.

Un Arduino solo, según lo que conozco, no alcanza para cámara, micrófonos y conversación. Hace falta verificar con pruebas si una Raspberry soporta la política de 15 motores a la velocidad de control requerida.

6. Costos: qué hay que relevar

Este informe no incluye precios porque no se verificaron. Los rubros a cotizar son:

Para el precio de venta hay que sumar el costo unitario de fabricación, el margen deseado, los costos de postventa y, si corresponde, impuestos y certificaciones. Antes de vender conviene verificar las normas de seguridad eléctrica, de baterías y de productos para consumo que apliquen.

7. Plan paso a paso

1. Definir el alcance: qué debe hacer el pato en la primera versión (por ejemplo caminar, girar la cabeza y responder a la voz) y qué queda para después.
2. Diseñar la mecánica pensando en la simulación: masas y articulaciones bien definidas, para que el modelo virtual se parezca al real.
3. Armar un prototipo físico con servos y una placa simple, para medir el torque y el juego real de cada motor.
4. Simular y entrenar la marcha en Isaac Lab, empezando por la tarea más sencilla.
5. Pasar a la realidad: cargar la política, probar con el robot sujeto y recién después suelto, y corregir la brecha.
6. Sumar las capas de visión, voz y conversación.
7. Calcular el costo unitario, el precio de venta y el margen con datos reales, y revisar licencias y normas antes de comercializar.

8. Riesgos

9. Alternativas sin NVIDIA

• Marcha programada de forma clásica: para un pato simple puede alcanzar sin aprendizaje automático, y se ejecuta en un microcontrolador.
• Otros simuladores de código abierto, como MuJoCo, según lo que conozco; no se verificó su estado actual.
• Hugging Face LeRobot: herramientas y kits de bajo costo para aprendizaje por imitación, compatible con Isaac Lab.

Isaac Lab tiene la ventaja de ser el estándar de la industria y de entrenar miles de simulaciones en paralelo, pero exige una GPU NVIDIA en la PC de desarrollo.

10. Glosario

Fuentes consultadas

The Robot Report, el blog de NVIDIA (anuncios del CoRL), Robotics 247, CO/AI, IT Brief UK, Magazin Mehatronika e IT-Online. Los datos del robot de referencia (tamaño, peso, motores, placa y sensores) son los que se plantearon en el proyecto

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.

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:

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:

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

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):

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

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.