Ingesta on lo0 — Blog Técnico

Ingesta documental end-to-end: del PDF al chunk indexado

Thu, 11 Jun 2026 09:00:00 +0000

Cuarta pieza de una serie operativa sobre exprimir un cluster LLM on-premise genérico de 4×H100 SXM 80 GB. Las hermanas de esta tanda: servir embeddings y rerankers con TEI en producción detalla la pieza de inferencia que esta ingesta alimenta; GitOps del stack de inferencia con Flux versiona y despliega todo este pipeline; y hardening y secretos del stack soberano protege el corpus y las credenciales que la ingesta toca. El consumidor final de lo que aquí construimos —un asistente soberano end-to-end— se monta en una entrega posterior.

TL;DR

Un sistema RAG hereda la calidad de su corpus, y el corpus hereda la calidad de la ingesta que lo fabricó. Es el garbage-in/garbage-out del retrieval: un chunk mal extraído de una tabla, un encabezado de página repetido mil veces, un PDF escaneado del que solo sacaste ruido OCR —todo eso se embebe, se indexa y reaparece como contexto envenenado en la respuesta del modelo. La ingesta documental no es un script de una tarde, es un pipeline de seis etapas con decisiones de ingeniería en cada una: (1) extraer/parsear —aquí se decide casi todo: layout-aware (Docling, que con Granite-Docling-258M preserva tablas, fórmulas y estructura, y según IBM evita el OCR clásico hasta ~30× más rápido) frente a extracción de texto plano (PyMuPDF), con OCR o un VLM para escaneos—; (2) limpiar/normalizar —quitar boilerplate, normalizar Unicode, reconstruir párrafos rotos—; (3) trocear —y aquí 2026 ha movido el consenso: un benchmark de febrero de 2026 puso el recursive a 512 tokens en cabeza (69% de acierto) por delante del chunking semántico (54%), y el late chunking aporta contexto global sin coste extra de almacenamiento—; (4) enriquecer metadatos —fuente, página, sección, timestamp, ACL/tenant: para retrieval filtrado, citación y auditabilidad—; (5) embeber —vía un servidor de embeddings tipo TEI—; (6) indexar —en pgvector o Qdrant, con payload, dense + sparse—. Entre medias, deduplicación exacta (hash) y near-dup (MinHash/LSH o coseno con umbral), porque los near-duplicados degradan el recall y la diversidad del retrieval. La parte numérica importa: un corpus de $N_{docs}\times$ páginas $\times$ tokens/página da los tokens totales y, a un throughput de CPU dado, el tiempo de ingesta; y $N_{chunks}\times d\times\text{bytes}$ da el tamaño del índice, que en int8 cae 4× frente a fp32. Lectura para el 4×H100: la ingesta es trabajo de CPU —enlaza con la pieza de RAG en CPU—; la GPU solo entra si parseas con un VLM (Granite-Docling) o usas un embedder de 7B.

La analogía: la cadena de catalogación de un archivo

Imagina el departamento de catalogación de un gran archivo documental. No es una persona metiendo papeles en cajas; es una cadena de estaciones de trabajo, cada una con un oficio distinto y un criterio de calidad propio. Un documento entra por un extremo en bruto y sale por el otro convertido en una ficha localizable en segundos. Si una estación hace mal su trabajo, las de abajo heredan el error y lo amplifican.

La primera estación es recepción y lectura. Llega una caja heterogénea: informes mecanografiados, fotocopias torcidas, tablas dobladas, microfichas. Un archivero experto lee de verdad cada pieza: distingue el cuerpo del texto de los márgenes, reconstruye una tabla que ocupa dos páginas, transcribe a mano lo que el escáner no leyó. Un archivero novato, en cambio, fotocopia todo en plano y entrega un churro de texto donde las columnas de las tablas se entrelazan sin sentido. Esa es exactamente la diferencia entre parsing layout-aware y extracción de texto plano, y es donde se gana o se pierde casi toda la calidad.

La segunda estación es el expurgo. Antes de archivar, alguien retira los duplicados —tres copias del mismo memo, dos versiones casi idénticas de un informe— y limpia las marcas inútiles: sellos de “COPIA”, pies de página repetidos en cada hoja, manchas de café. Si no expurgas, el archivo se llena de copias que, cuando alguien busca, devuelven el mismo documento seis veces y entierran lo diverso. Esto es la deduplicación y la limpieza.

La tercera estación trocea en fichas. Un libro de 400 páginas no se cataloga como una sola ficha gigante; se descompone en entradas manejables —por capítulo, por sección— de un tamaño que un lector pueda consultar de un vistazo. Demasiado grande y la ficha mezcla temas; demasiado pequeña y pierde el contexto. Esto es el chunking, y el tamaño de la ficha es la decisión que más condiciona el retrieval.

La cuarta estación etiqueta. Cada ficha lleva signatura, fecha, fondo de procedencia, nivel de acceso (¿esto lo puede ver cualquiera o solo el departamento jurídico?). Sin esas etiquetas no puedes filtrar una búsqueda ni decir de qué documento salió una afirmación. Son los metadatos: fuente, página, sección, timestamp, ACL.

La quinta y sexta estaciones colocan la ficha en la estantería indexada: la traducen al lenguaje del catálogo —un vector— y la colocan en el cajón correcto del fichero, de modo que una consulta encuentre las fichas afines sin recorrerlo entero. Es el embedding y la indexación en el vector store.

La moraleja recorre todo el post: el RAG no puede recuperar mejor de lo que la cadena de catalogación archivó. Si la primera estación troceó mal una tabla, ningún reranker la arreglará después. La ingesta es la estación de calidad del sistema entero, y casi toda ella —como el archivo, lleno de gente paciente trabajando sin que nadie les cronometre— es trabajo de fondo que cabe en CPU.

El pipeline de seis etapas

La tentación de tratar la ingesta como “leer el PDF y trocearlo” es la fuente del 80% de los RAG mediocres. Cada etapa tiene un criterio de calidad y un fallo característico, y los fallos se encadenan hacia abajo: si parseas mal, limpiar no recupera lo perdido; si troceas mal, embeber fija el error en el vector; si no etiquetas, no podrás filtrar ni citar. El resto del post recorre las seis estaciones con sus decisiones.

Etapa 1 — Parsear: layout-aware vs texto plano

Aquí se gana o se pierde casi todo. Un PDF no es texto: es un conjunto de instrucciones de dibujo de glifos sobre un lienzo. “Extraer el texto” de un PDF es reconstruir un orden de lectura que el formato no garantiza, y las tablas, las columnas y las figuras lo rompen sistemáticamente.

Hay dos filosofías, y la elección condiciona el resto del pipeline.

Extracción de texto plano. Herramientas como PyMuPDF (rápida, robusta, sin dependencias pesadas) leen el flujo de texto del PDF y lo vuelcan. Para documentos de una sola columna, prosa corrida y sin tablas, es perfecto: rapidísimo, fiel y barato en CPU. Su límite aparece con la estructura: una tabla de dos columnas sale con las celdas entrelazadas, un documento a doble columna mezcla el final de una con el principio de otra, y una factura escaneada no sale en absoluto porque no hay capa de texto. PyMuPDF también sabe segmentar por la tabla de contenidos (TOC) cuando el PDF la trae, lo que ayuda a un troceado por secciones (Omdena, Document Parsing for RAG: A Complete Guide for 2026).

Parsing layout-aware. Herramientas como Docling (proyecto open source impulsado por IBM Research) y unstructured.io primero entienden el layout —identifican títulos, párrafos, tablas, figuras, listas, fórmulas— y solo después extraen el contenido respetando esa estructura. Docling captura la estructura de las tablas (filas, columnas, encabezados multinivel) y, en su evolución de 2026, lo hace con un VLM: Granite-Docling-258M, liberado por IBM en enero de 2026 bajo Apache 2.0, un modelo visión-lenguaje compacto (~258M parámetros, backbone Granite 3 + encoder visual SigLIP2) que convierte páginas —PDF, diapositivas, escaneos— directamente a un formato estructurado llamado DocTags, preservando tablas, código, matemáticas inline y de bloque, y la jerarquía del documento (IBM, Granite-Docling: End-to-end document understanding; model card en Hugging Face; repo Docling). IBM afirma que la vía VLM evita el OCR clásico y que eso “reduce errores y acelera la solución hasta 30×” frente a un pipeline OCR tradicional —cifra de IBM Research, la cito y la trato como orientativa, no como un benchmark independiente reproducido aquí.

unstructured.io ofrece estrategias de partición graduadas según la complejidad del documento: fast (texto plano, rápido), hi_res (identifica el layout, recomendada cuando importa clasificar bien tablas y elementos), VLM y auto, equilibrando velocidad, coste y precisión (Unstructured, PDF Parsing Strategies for RAG). La regla práctica: fast para prosa, hi_res o VLM para documentos con tablas y estructura.

OCR para escaneos

Cuando el documento no tiene capa de texto —un escaneo, una foto, una microficha digitalizada—, hay que reconocer los caracteres. Tres vías:

OCR clásico (Tesseract, PaddleOCR, EasyOCR —con el que Docling integra cuando se necesita OCR explícito). Maduro, CPU-friendly, bueno con texto limpio; sufre con tablas, manuscritos y layouts complejos.
VLM end-to-end (Granite-Docling y similares). El modelo “mira” la página y emite estructura directamente, sin la etapa OCR separada. Mejor con layout complejo; aquí sí entra la GPU si el VLM es grande o el volumen alto.
Híbrido: OCR para la transcripción de caracteres, modelo de layout para la estructura.

El criterio honesto: para un corpus de PDFs nativos con texto, PyMuPDF o unstructured fast resuelven en CPU y barato. Para un corpus con tablas densas, formularios o escaneos, Docling/Granite-Docling layout-aware paga su coste en calidad de chunk —y es la única etapa del pipeline donde la GPU puede justificarse.

Caso de documento	Herramienta recomendada	Silicio
PDF nativo, una columna, prosa	PyMuPDF / unstructured `fast`	CPU
PDF con tablas, doble columna, jerarquía	Docling / unstructured `hi_res`	CPU (modelos de layout)
Escaneo, formulario, manuscrito, layout complejo	Granite-Docling (VLM) o OCR+layout	GPU si VLM grande / alto volumen
HTML, DOCX, PPTX	Docling (multi-formato) / parsers nativos	CPU

Etapa 2 — Limpiar, normalizar y deduplicar

El texto recién parseado viene sucio. Limpiar es retirar lo que no aporta y normalizar lo que se representa de mil formas:

Boilerplate: encabezados y pies de página repetidos en cada hoja, números de página, marcas de agua, menús de navegación en HTML, banners de cookies. Si no los quitas, se embeben mil veces y contaminan tanto el índice como las respuestas.
Normalización Unicode (NFC/NFKC), espacios y guiones: el mismo carácter representado de varias formas rompe el matching exacto y ensucia los embeddings.
Reconstrucción de párrafos: deshacer los saltos de línea duros que el PDF metió a mitad de frase, sin fusionar párrafos que sí debían quedar separados.

Deduplicación: por qué importa

El RAG sufre dos males de los duplicados. El exacto —el mismo documento subido tres veces— hincha el índice y hace que una búsqueda devuelva la misma respuesta repetida, desperdiciando los top-k slots de contexto. El near-duplicado —dos versiones casi idénticas de un informe, un documento y su borrador— es peor: parecen distintos al hash pero dicen lo mismo, y degradan el recall y la diversidad del retrieval. No es teoría: en la colección MS MARCO V2 se ha documentado un solapamiento sustancial de near-duplicados que, sin tratar, degrada la precisión de recuperación y reduce la diversidad de documentos recuperados (Ragnarök / TREC RAG 2024).

Dos niveles de dedup, complementarios:

Exacto (hash). Calcula un sha256 del contenido normalizado de cada documento (o chunk) y descarta los que coinciden. Coste $O(N)$, trivial. Atrapa duplicados byte a byte.
Near-dup (MinHash + LSH, o coseno de embeddings con umbral). Para los que difieren un poco pero significan lo mismo. MinHash comprime cada documento en una firma compacta tal que la probabilidad de que dos firmas coincidan en una posición iguala la similitud de Jaccard de los conjuntos de shingles originales; combinado con Locality-Sensitive Hashing (LSH) encuentra todos los pares near-duplicados sin comparar todos contra todos, reduciendo un problema cuadrático a casi lineal (Brenndoerfer, MinHash, Jaccard, LSH). Es la técnica dominante en la limpieza de corpus de entrenamiento de LLM (C4, RefinedWeb la usan) y aplica igual al corpus de un RAG (Zilliz, Data Deduplication at Trillion Scale). La alternativa —coseno de embeddings con un umbral (p. ej. > 0.97)— atrapa duplicados semánticos que MinHash no ve (parafraseo), pero exige ya tener los embeddings y es más cara.

La regla práctica: hash exacto siempre (es gratis); MinHash/LSH para corpus grandes con versiones; coseno con umbral si el parafraseo es un problema real. Y deduplica antes de embeber: re-embeber un duplicado es gastar cómputo en basura que luego habrá que filtrar.

Etapa 3 — Trocear (chunking)

El chunking es la decisión que más condiciona el retrieval, y la que más mitos arrastra. El trade-off es triple: tamaño de chunk ↔ granularidad de retrieval ↔ coste de contexto.

Chunks grandes: cada uno contiene más contexto y menos riesgo de cortar una idea por la mitad, pero la búsqueda es menos precisa (un vector representa demasiados temas) y, al recuperar, metes más tokens en el prompt del LLM —más coste y más riesgo de diluir lo relevante.
Chunks pequeños: retrieval muy granular y preciso, pero cada chunk pierde contexto (un fragmento de 43 tokens puede no significar nada fuera de su sección) y necesitas recuperar más para cubrir una respuesta.

Las estrategias, de menos a más sofisticada:

Tamaño fijo + overlap. Cortar cada $N$ tokens con un solapamiento de $k$ tokens entre chunks consecutivos para no partir una frase en seco. Simple, predecible, baseline razonable. El overlap es el seguro contra cortar una idea justo en la frontera.
Recursivo (RecursiveCharacterTextSplitter de LangChain). Intenta cortar por separadores en orden de prioridad —párrafo, luego frase, luego palabra— para respetar lo más posible la estructura natural antes de caer al corte duro. Es el caballo de batalla.
Semántico. Embebe frases y corta donde la similitud entre frases consecutivas cae por debajo de un umbral, agrupando por coherencia de significado. Suena mejor sobre el papel; en la práctica de 2026 ha decepcionado (ver abajo).
Structure/layout-aware (por headings). Aprovecha la jerarquía que el parser layout-aware ya extrajo: un chunk por sección o subsección. unstructured ofrece la estrategia by_title, que abre un chunk nuevo cuando aparece un elemento de tipo título, evitando mezclar texto de secciones distintas (Unstructured docs). Si parseaste con Docling/hi_res, esta estrategia es casi gratis y suele ser la mejor para documentos bien estructurados.
Late chunking. El giro de 2024–2026: en vez de trocear y luego embeber cada chunk por separado, embebe el documento entero primero (con un encoder de contexto largo) y luego aplica las fronteras de chunk haciendo mean-pooling de los embeddings de token dentro de cada span. El resultado: cada chunk conserva el contexto global del documento —un pronombre o una referencia que solo se entiende por el párrafo anterior queda codificada en el vector— y todo sin coste extra de almacenamiento, porque acabas con un vector por chunk igual que siempre (Jina AI, Late Chunking; arXiv:2409.04701).

Qué dicen los benchmarks de 2026 (y por qué el semántico decepciona)

Conviene ser escéptico con la moda. Un benchmark de Vecta de febrero de 2026 sobre 7 estrategias en 50 papers académicos colocó al recursive a 512 tokens en primer lugar con 69% de acierto, mientras que el chunking semántico quedó en 54%, en parte porque producía fragmentos minúsculos —de media 43 tokens— demasiado pequeños para significar algo (Firecrawl, Best Chunking Strategies for RAG in 2026). Un análisis sistemático de enero de 2026 identificó además un “context cliff” en torno a los 2.500 tokens, donde la calidad de respuesta cae al meter contextos demasiado largos —argumento extra contra los chunks gigantes ([ídem]). La lectura honesta: el recursive de tamaño moderado con overlap sigue siendo el baseline difícil de batir; el late chunking es la mejora con mejor relación coste/beneficio cuando el modelo lo soporta; el semántico promete más de lo que entrega.

Ejemplo numérico de chunking

Pongamos un documento técnico de 30 páginas, ~500 tokens de prosa útil por página tras limpiar (las tablas y figuras se trocean aparte). Son $30 \times 500 = 15{.}000$ tokens de texto. Troceamos con recursive a 512 tokens y un 20% de overlap ($0.20 \times 512 \approx 102$ tokens). El “paso” efectivo entre el inicio de un chunk y el siguiente es:

$$\text{paso} = \text{tamaño} - \text{overlap} = 512 - 102 = 410 \text{ tokens}$$

El número de chunks del documento es entonces, aproximadamente:

$$N_{chunks} \approx \left\lceil \frac{T_{doc} - \text{overlap}}{\text{paso}} \right\rceil = \left\lceil \frac{15{.}000 - 102}{410} \right\rceil \approx \lceil 36.3 \rceil = 37 \text{ chunks}$$

Sin overlap habrían sido $\lceil 15{.}000 / 512 \rceil = 30$ chunks; el 20% de overlap nos cuesta 7 chunks extra (~23% más) a cambio de no partir ideas en las fronteras. Ese es el precio concreto del overlap: más vectores que embeber, indexar y almacenar, a cambio de robustez en el retrieval. Para el dimensionado del corpus completo usaremos este factor.

Etapa 4 — Enriquecer con metadatos

Un chunk sin metadatos es una ficha sin signatura: existe pero no sirve. A cada chunk se le adjunta un payload con, al menos:

Fuente y localización: document_id, nombre/URI del documento, número de página, sección/heading (que el parser layout-aware ya te dio). Imprescindible para citar: poder decir “esto sale del documento X, página 12, sección 3.2” es lo que separa un RAG auditable de uno que alucina sin trazabilidad.
Timestamp: cuándo se ingestó y la fecha del documento. Permite filtrar por frescura y detectar contenido obsoleto.
ACL / tenant: quién puede ver este chunk. Es crítico y se aplica como filtro en el retrieval: un usuario del departamento A no debe recuperar chunks marcados solo para el B. Sin esto, el RAG es una fuga de datos esperando a ocurrir.
Versión del modelo de embedding (model_version): para saber con qué embedder se generó cada vector y poder migrar sin mezclar espacios incompatibles.

Estos metadatos no son decoración: habilitan retrieval filtrado (buscar solo en lo que el usuario puede ver, o solo en documentos posteriores a una fecha), citación (reconstruir el origen de cada afirmación) y auditabilidad (saber qué se recuperó, de dónde y cuándo). Todo vive en el payload del punto en el vector store.

Etapas 5 y 6 — Embeber e indexar

Las dos últimas estaciones traducen el chunk a un vector y lo colocan en la estantería.

Embeber. Los chunks se envían en batch a un servidor de embeddings —típicamente TEI (Text Embeddings Inference) de Hugging Face, que expone el contrato OpenAI /v1/embeddings y corre en CPU o GPU—. Es trabajo throughput-bound, sin SLA de latencia: el sitio natural es la CPU con un encoder pequeño en int8 (la pieza hermana de esta tanda, servir embeddings y rerankers con TEI, detalla el cómo). Conviene emitir dense + sparse a la vez: el vector denso captura la semántica, el sparse (SPLADE/BM25-like) el solapamiento léxico exacto, y juntos hacen el retrieval híbrido más robusto.

Indexar. Los vectores, con su payload, se hacen upsert en el vector store. Dos opciones de referencia, ambas vigentes en 2026:

pgvector (extensión de PostgreSQL). Su gran virtud es vivir dentro de Postgres: transacciones ACID, joins con los metadatos relacionales, una sola base de datos que operar. La versión 0.8 añadió halfvec (vectores en media precisión, 2× menos almacenamiento) y la 0.9 (principios de 2026) sumó soporte de vectores sparse y mejoras de velocidad. Su límite conocido: no trae cuantización int8 nativa, así que los embeddings de alta dimensión consumen RAM de forma lineal (Encore, pgvector vs Qdrant 2026; Katz, Scalar and binary quantization for pgvector).
Qdrant (motor vectorial dedicado). Soporta cuantización escalar int8 (float32 → int8, 4× menos memoria) y product quantization, vectores sparse nativos y fusión RRF para híbrido. Es más eficiente en memoria y en cuantización; el coste es operar un sistema más además de Postgres (Markaicode, pgvector vs Qdrant 2026).

La regla práctica: pgvector si ya tienes Postgres y el corpus cabe en RAM cómodamente (una sola base que operar y respaldar); Qdrant si la eficiencia de memoria y la cuantización int8 son críticas por el tamaño del corpus. La sincronización entre la verdad relacional (Postgres) y el índice (Qdrant) cuando se usan los dos se detalla en PostgreSQL + Qdrant en microservicios.

Etapa transversal — Ingesta incremental e idempotencia

Un corpus vivo cambia: se añaden documentos, se editan, se borran. Re-indexar todo cada noche es caro y provoca ventanas de indisponibilidad. La alternativa es ingesta incremental con dos pilares:

Idempotencia por doc-id + hash. Cada chunk se identifica de forma determinista ({doc_id}_{chunk_index}) y cada documento lleva un hash de contenido. Al re-procesar, si el hash no cambió, no se re-embebe: se ahorra el cómputo. Si cambió, se borran los chunks viejos de ese doc_id y se hace upsert de los nuevos. El upsert con id determinista es idempotente: reprocesar un evento dos veces no genera duplicados.
CDC (Change Data Capture). En vez de hacer polling, Debezium lee el WAL de PostgreSQL y propaga altas, ediciones y borrados al índice en tiempo casi real. Un borrado en Postgres dispara el borrado de los chunks de ese documento en el vector store, evitando los “documentos fantasma” que contaminan el retrieval. El deep dive está en PostgreSQL + Qdrant en microservicios y en el de Debezium y CDC.

Las matemáticas: dimensionar el corpus y el índice

Dos cálculos que hay que saber hacer antes de aprovisionar nada.

Dimensionado del corpus y tiempo de ingesta

Supongamos un corpus corporativo de $N_{docs} = 50{.}000$ documentos, de media 20 páginas y 500 tokens útiles por página tras limpiar. Los tokens totales del corpus:

$$T_{corpus} = N_{docs} \times \text{páginas} \times \text{tokens/página} = 50{.}000 \times 20 \times 500 = 5 \times 10^{8} \text{ tokens}$$

Quinientos millones de tokens. Aplicando el factor de overlap del ejemplo de chunking (~1.23×, el 23% extra de chunks por el 20% de overlap) y un tamaño efectivo de 512 tokens/chunk, el número de chunks es:

$$N_{chunks} \approx \frac{T_{corpus}}{\text{paso}} = \frac{5 \times 10^{8}}{410} \approx 1.22 \times 10^{6} \text{ chunks}$$

Es decir, ~1,22 millones de chunks que embeber. A un throughput de embedding CPU conservador de 3.000 tok/s por servidor Xeon en int8 —la misma cifra que usamos en la pieza de RAG en CPU—, el tiempo de ingesta del primer corpus completo en una caja es:

$$t_{ingesta} = \frac{T_{corpus}}{\text{throughput}} = \frac{5 \times 10^{8}}{3{.}000} \approx 1.67 \times 10^{5} \text{ s} \approx 46 \text{ horas}$$

46 horas en una sola caja suena mal, pero la ingesta es vergonzosamente paralela: el corpus se reparte. Con 8 servidores CPU baja a ~6 horas, holgadamente dentro de una ventana de fin de semana para la carga inicial; y las ingestas incrementales posteriores (solo lo que cambió) son minutos. El parsing layout-aware añade su propio coste —Docling con VLM es más lento que PyMuPDF—, pero también es batch y paraleliza igual.

Tamaño del índice vectorial

Cada vector tiene dimensión $d = 1024$ (la de bge-m3). En float32 (4 bytes/dimensión), cada vector ocupa:

$$\text{bytes}_{fp32} = d \times 4 = 1024 \times 4 = 4096 \text{ B} = 4 \text{ KB}$$

Para los 1,22 M de chunks, solo los vectores densos en fp32:

$$\text{tamaño}{fp32} = N{chunks} \times d \times 4 = 1.22 \times 10^{6} \times 4096 \text{ B} \approx 5.0 \text{ GB}$$

En int8 (1 byte/dimensión), cada vector ocupa 1 KB y el total cae 4×:

$$\text{tamaño}{int8} = N{chunks} \times d \times 1 = 1.22 \times 10^{6} \times 1024 \text{ B} \approx 1.25 \text{ GB}$$

A esto hay que sumar el índice HNSW (~1.2× el tamaño de los vectores para $m=16$) y el payload (metadatos + texto del chunk, ~500 B/chunk → ~0,6 GB). En números redondos:

Configuración	Vectores	HNSW (~1.2×)	Payload	Total
fp32	~5,0 GB	~6,0 GB	~0,6 GB	~11,6 GB
int8	~1,25 GB	~1,5 GB	~0,6 GB	~3,4 GB

La lectura: un corpus de 50.000 documentos cabe en RAM de un solo nodo incluso en fp32, y en int8 (Qdrant) entra con holgura, lo que mantiene la latencia de búsqueda en milisegundos de un dígito. La cuantización int8 es casi siempre el punto de equilibrio —ahorra 4× con una pérdida de recall típicamente por debajo del 1%. (Estos números son de orden de magnitud, con las constantes y supuestos declarados; sirven para dimensionar, no para clavar una factura.)

Aplicado al cluster genérico 4×H100

Bajemos esto al cluster de la serie: 4×H100 SXM 80 GB más una flota CPU genérica (Xeon con AMX, NUCs). El reparto correcto de la ingesta es casi todo CPU, con la GPU como excepción puntual:

Limpieza, dedup, chunking, metadatos, embedding de ingesta e indexado → flota CPU. Todo esto es trabajo batch, throughput-bound, sin SLA de latencia. Es exactamente el “plano de datos” del que habla la pieza RAG en CPU: ninguna H100 debería gastar un ciclo troceando documentos o construyendo un índice HNSW (que siempre fue CPU por diseño). El re-indexado incremental nocturno de un corpus que cambia a ritmo de horas es el caso de libro de “trabajo de CPU sin prisa”.
La GPU solo entra en dos puntos. Primero, en el parsing con VLM: si el corpus tiene escaneos, tablas densas o formularios y eliges Granite-Docling-258M u otro modelo visión-lenguaje, ese parsing puede acelerarse en GPU —aunque a 258M parámetros es ligero y, en volúmenes moderados, corre en CPU sin drama. Segundo, en el embedder grande: si la calidad de recuperación exige un embedder de 7B (gte-Qwen2, NV-Embed) en lugar de bge-m3 (568M), ese embedder vuelve a ser un modelo LLM-class y vive donde viven los 7B, en la GPU.
Las 4×H100 se reservan para generar. Como en toda la serie, el silicio caro y escaso se guarda para lo latency-bound —el LLM produciendo la respuesta— y, como mucho, para los picos de parsing VLM o embedding 7B que la CPU no absorba. Para hacerse una idea del techo: un nodo 4×H100 sirviendo bge-m3 vía TEI ronda los ~2.000 chunks/s, frente a los miles de tok/s de un Xeon en int8; pero usar las H100 para la ingesta diaria es gastar el recurso por el que se pelea toda la organización en un trabajo que la flota CPU hace de noche sin que nadie la eche en falta.

La frase que resume el reparto: la ingesta es la cadena de catalogación del archivo, y casi toda se hace con personal paciente y barato (CPU); el redactor estrella (GPU) solo se molesta cuando hay que leer una página que ningún OCR clásico descifra.

Cierre: la calidad se decide arriba

El error recurrente del RAG mediocre no está en el reranker ni en el prompt: está en una ingesta que parseó mal una tabla, no expurgó los duplicados o troceó con un tamaño que destruye el contexto. Garbage-in, garbage-out: ningún componente de abajo arregla lo que la ingesta estropeó arriba. Invertir en la cadena de catalogación —parsing layout-aware donde haga falta, dedup de verdad, chunking medido, metadatos completos— es lo que más mueve la aguja de la calidad del sistema, y casi todo cabe en la flota CPU. La GPU, como el redactor estrella, solo debería tocar el corpus cuando de verdad hace falta su cabeza.

Ver también

Multimodal on-premise: servir un VLM con vLLM (visión + lenguaje) — el VLM como alternativa al OCR clásico para parsear documentos con layout, tablas o manuscritos.
Servir embeddings y rerankers con TEI en producción — la pieza hermana: el servidor de inferencia que esta ingesta alimenta en la etapa de embedding.
Llevar el RAG a la CPU: plano de datos vs plano de generación — por qué toda esta ingesta es trabajo de CPU y no debe tocar la GPU.
PostgreSQL + Qdrant en la ingestión RAG — la sincronización, el upsert idempotente y el CDC de la ingesta incremental, en detalle.
El corpus curado que esta ingesta debe construir — los fundamentos de curación y filtrado que preceden y guían a la ingesta.
Reranking e hybrid retrieval: fundamentos — qué hace el sistema con los chunks dense + sparse que esta ingesta indexó.
Embeddings 2026: dense, sparse y multivector — el embedder que traduce cada chunk a vector y cuándo justifica un modelo de 7B en GPU.
Evaluar el RAG con RAGAS y un golden dataset — cómo medir si la ingesta realmente mejoró el retrieval, en vez de creerlo.

Referencias

IBM — Granite-Docling: End-to-end document understanding (Granite-Docling-258M, Apache 2.0, DocTags, enero 2026). https://www.ibm.com/new/announcements/granite-docling-end-to-end-document-conversion
ibm-granite — granite-docling-258M model card (VLM ~258M, Granite 3 + SigLIP2). https://huggingface.co/ibm-granite/granite-docling-258M
Docling project — Docling: Get your documents ready for gen AI (layout, tablas, multi-formato). https://github.com/docling-project/docling
Unstructured — PDF Parsing Strategies for RAG (fast / hi_res / VLM / auto; chunking by_title). https://unstructured.io/blog/mastering-pdf-transformation-strategies-with-unstructured-part-2 · https://docs.unstructured.io/
Omdena — Document Parsing for RAG: A Complete Guide for 2026 (PyMuPDF, TOC, pipeline). https://www.omdena.com/blog/document-parsing-for-rag
Firecrawl — Best Chunking Strategies for RAG (and LLMs) in 2026 (benchmark Vecta feb-2026: recursive 512 → 69%, semántico 54%; context cliff ~2.500 tok). https://www.firecrawl.dev/blog/best-chunking-strategies-rag
Günther, M., et al. — Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models. arXiv 2409.04701. https://arxiv.org/abs/2409.04701 · Jina AI: https://jina.ai/news/late-chunking-in-long-context-embedding-models/
Brenndoerfer, M. — MinHash: Jaccard Similarity, LSH, and Near-Duplicate Detection. https://mbrenndoerfer.com/writing/minhash-algorithm-jaccard-similarity-lsh-deduplication
Zilliz — Data Deduplication at Trillion Scale (MinHash LSH dominante en limpieza de corpus). https://zilliz.com/blog/data-deduplication-at-trillion-scale-solve-the-biggest-bottleneck-of-llm-training
Ragnarök / TREC RAG 2024 — near-duplicados en MS MARCO V2 degradan recuperación y diversidad. https://arxiv.org/pdf/2406.16828
Encore — pgvector vs Qdrant in 2026 (halfvec, sparse, límites de cuantización de pgvector). https://encore.dev/articles/pgvector-vs-qdrant
Markaicode — pgvector vs Qdrant (2026 Benchmarks) (Qdrant int8 scalar quantization 4×). https://markaicode.com/vs/pgvector-vs-qdrant/
Katz, J. — Scalar and binary quantization for pgvector. https://jkatz05.com/post/postgres/pgvector-scalar-binary-quantization/
Hugging Face — Text Embeddings Inference (TEI), backends CPU/GPU, endpoints OpenAI-compatibles. https://github.com/huggingface/text-embeddings-inference

Llevar el RAG a la CPU: separar el plano de datos del plano de generación

Thu, 11 Jun 2026 03:20:00 +0000

Tercera pieza de una serie operativa sobre exprimir un cluster LLM on-premise genérico de 4×H100 SXM 80 GB. Las hermanas: compartir una GPU entre cargas (time-slicing, MPS, MIG) y servir varios modelos en una GPU (swap + sleep) atacan el reparto dentro de la GPU. Este ataca el reparto fuera: qué partes del RAG no tienen por qué tocar la GPU nunca. El cierre de la serie, el asistente soberano end-to-end (cuarta entrega, en preparación), monta el sistema completo donde estas piezas encajan.

TL;DR

Un sistema RAG no es una cosa, son tres fases con perfiles de cómputo opuestos, y meterlas todas en la GPU “porque es IA” es un error de reparto. (1) Construcción/ingesta —embeber el corpus y construir el índice— es trabajo batch, throughput-bound, sin SLA de latencia: su sitio natural es la CPU. (2) Retrieval en tiempo de consulta —embeber la query, búsqueda HNSW, fusión RRF, rerank ligero— es mayoritariamente CPU, con matices solo en el rerank pesado; la búsqueda vectorial siempre fue CPU, incluso en stacks que se venden como “GPU”. (3) Generación —el LLM produciendo la respuesta— es latency-bound y ahí la GPU es irremplazable: un 7B en CPU da un time to first token de segundos, inaceptable para chat. La clave técnica de por qué (1) y (2) caben en CPU: el embedder no es un LLM. bge-m3 son ~568M parámetros (un encoder XLM-RoBERTa), no 7B+; en int8 ocupa ~580 MB y activa rutas de cómputo entero rápidas (Intel AVX-512 + VNNI + AMX en Xeon de 4ª gen en adelante; NEON SDOT/UDOT en ARM). Hay runtimes listos: TEI con backend CPU (mismo API OpenAI /v1/embeddings y /rerank), fastembed de Qdrant (ONNX-CPU), bge-m3 en ONNX int8 con sus tres cabezas (dense/sparse/ColBERT). El blog de Intel + Hugging Face con Optimum Intel y fastRAG reporta hasta ~10× en indexación para BGE-large int8 sobre un Xeon de 4ª gen (cifra de su benchmark, encoding-only; la cito y la matizo abajo). La conclusión operativa: separa el plano de datos (CPU) del plano de generación (GPU). En el cluster 4×H100, ninguna H100 debería gastarse en re-indexar un corpus que cambia una vez al día —eso va a la flota CPU genérica (Xeon AMX, NUCs)— y las H100 se reservan para generar y, como mucho, para picos de rerank o embedders grandes de 7B. Lo que no baja a CPU: generación interactiva, reranking masivo a alto QPS, re-indexación con SLA estricto en tiempo real y embedders de 7B (gte-Qwen2, NV-Embed).

La analogía: la biblioteca y el bibliotecario

Imagina una biblioteca de investigación seria. Hay tres trabajos distintos, hechos por personas distintas, con relojes distintos.

El primero es la catalogación. Llegan cajas de libros nuevos; alguien los abre, los clasifica, les asigna signatura, los indexa en el catálogo y los coloca en la estantería correcta. Es trabajo paciente, de fondo, que se hace de noche o entre horas. Nadie está esperando con un cronómetro a que termines de catalogar el lote de hoy: lo que importa es que mañana esté hecho y bien hecho. Es throughput puro: cuántos libros catalogas por hora, no cuánto tardas en catalogar uno concreto. Esto es la ingesta.

El segundo es atender una consulta en el mostrador. Un lector llega y pregunta por un tema. El bibliotecario va al catálogo —que ya está construido—, localiza media docena de signaturas relevantes, las va a buscar a la estantería y le pone los libros encima del mostrador. Es rápido, ligero, y consiste en buscar en un índice que ya existe, no en construirlo. Esto es el retrieval.

El tercero es redactar un informe razonado a partir de esos libros. El lector —o un experto al que se lo encargas— lee los seis libros, los compara, sintetiza, escribe una respuesta argumentada con citas. Esto es lento, exige una cabeza muy entrenada, y el lector está esperando: aquí sí hay un cronómetro humano. Esto es la generación, el LLM.

La moraleja es la del reparto del personal. No pones a tu redactor estrella —caro, escaso, con cola de gente esperando sus informes— a catalogar cajas de libros de madrugada. Catalogar lo hace un equipo numeroso y barato que trabaja por la noche sin prisa. El redactor estrella solo toca lo que de verdad necesita su cabeza: redactar. En nuestro sistema, el redactor estrella es la H100, y catalogar de madrugada es la ingesta del corpus. Gastar la H100 re-indexando es exactamente el error de poner al redactor a etiquetar cajas.

El resto del post es, esencialmente, qué partes del trabajo de biblioteca puede hacer el equipo barato de la CPU (casi todas) y cuál es irrenunciablemente del redactor en GPU (solo la última).

Las tres fases y sus perfiles de cómputo

La confusión de la que vive el sobre-aprovisionamiento de GPU es tratar “el RAG” como un bloque monolítico que “usa IA, luego va a la GPU”. No. El RAG es un pipeline de datos con un modelo generativo enchufado al final. La frontera arquitectónica correcta no separa “lo que usa modelos” de “lo que no” —ambos lados usan modelos—, sino throughput-bound de latency-bound, que es lo mismo que separar el plano de datos del plano de generación.

Por qué la ingesta encaja en CPU: el embedder no es un LLM

El argumento entero descansa en una asimetría de tamaño que se pasa por alto. La gente oye “embeddings” y “generación” y los mete en el mismo saco de “modelos grandes que necesitan GPU”. Pero el encoder de embeddings y el LLM generativo están dos órdenes de magnitud de distancia en parámetros.

bge-m3 —el embedder multilingüe de referencia— es un XLM-RoBERTa de ~568M parámetros (model card, paper arXiv:2402.03216). Su hermano el reranker, bge-reranker-v2-m3, está construido sobre la misma base y ronda los mismos ~568M parámetros (model card). Compáralo con un LLM generativo de gama de entrada: un Llama 3.1 8B tiene ~14× más parámetros, y los grandes de producción andan por 70B+. Un encoder de 568M es, en presupuesto de cómputo, otro animal.

Dos diferencias estructurales hacen que ese encoder sea cómodo en CPU:

Es un encoder, no un decoder autoregresivo. Procesa la secuencia entera en un único forward pass y emite el vector. No hay decode token a token, no hay KV cache que crece, no hay la fase de generación memory-bound que mata a la CPU. Es un pase denso de matrices y se acabó.
Cuantiza a int8 sin apenas pérdida. En int8, bge-m3 ocupa del orden de ~580 MB y, sobre todo, activa las rutas de cómputo entero que la CPU moderna ejecuta deprisa: instrucciones matriciales tipo Intel AMX (Advanced Matrix Extensions, Xeon de 4ª generación en adelante), AVX-512 con VNNI (Vector Neural Network Instructions) en Xeon previos, y NEON SDOT/UDOT en ARM. La pérdida de calidad de pasar FP32 a int8 en estos modelos suele quedar por debajo del 1% de recall de recuperación, prácticamente invisible (Intel + Hugging Face, CPU Optimized Embeddings).

Cuantifiquemos el tamaño del int8. Para $P = 568 \times 10^6$ parámetros a 1 byte cada uno:

$$\text{tamaño}_{\text{int8}} \approx 568 \times 10^6 \text{ params} \times 1 \text{ byte/param} \approx 568 \text{ MB}$$

Es decir, el modelo cabe en la caché y la RAM de cualquier servidor o NUC sin pestañear, y el cuello de botella es de cómputo entero, justo lo que AMX/VNNI aceleran. No hay nada en este perfil que pida una GPU.

Runtimes que ya hacen esto sin esfuerzo

No hay que inventar nada. El ecosistema CPU para el plano de datos está maduro:

Text Embeddings Inference (TEI) de Hugging Face: servidor en Rust con backends CPU vía ONNX Runtime (recomendado) o Intel MKL, y endpoints OpenAI-compatibles (/v1/embeddings) además de /rerank (repo TEI). Es decir, el plano de datos en CPU expone exactamente el mismo contrato HTTP que un servidor GPU; el resto del sistema no se entera de qué silicio hay detrás.
fastembed de Qdrant: librería ligera que carga embedders en ONNX-CPU y genera vectores dense, sparse y ColBERT (repo fastembed). Pensada de origen para correr sin GPU.
bge-m3 en ONNX int8 con sus tres cabezas (dense / sparse-lexical / ColBERT multivector) exportadas y cuantizadas, listas para ONNX Runtime CPU.

El dato de Intel y Hugging Face que ancla la viabilidad: en su benchmark con Optimum Intel + fastRAG sobre un Xeon de 4ª generación (8480+, 56 cores, 1 socket), la variante int8 de BGE-large alcanza hasta ~10× de throughput de indexación frente a FP32 (HF blog, Haystack/deepset). Hay que leer la letra pequeña y la leo: ese ~10× es encoding-only (tokenización excluida), a secuencia 256, comparando int8 contra FP32 en la misma CPU —no es “CPU 10× más rápido que GPU”, es “int8 10× más rápido que FP32 en CPU”—. Sigue siendo el dato relevante: te dice que con cuantización la CPU pasa de inviable a perfectamente útil para ingesta batch.

Tabla de viabilidad: ¿CPU para cada componente?

Esta es la tabla operativa. La columna que importa es la del matiz, porque “sí” y “no” a secas mienten.

Componente	¿CPU viable?	Matiz
Chunking (trocear el corpus)	Sí, siempre	Es regex, parsing y ventanas; nunca tuvo nada que ver con GPU.
Embedding ingesta `bge-m3` dense	Sí, su mejor caso	Batch nocturno, int8 + AMX/VNNI. Es exactamente para lo que la CPU brilla.
Cabeza sparse / SPLADE / BM25	Sí, nativo CPU	El léxico es inverted-index puro; la GPU no aporta nada aquí.
Construir índice HNSW (Qdrant, pgvector)	Sí, siempre CPU	El build del grafo HNSW es CPU por diseño en estos motores.
Embedding de query (online)	Sí	Un solo texto corto; decenas de ms en CPU, sobra para chat.
Búsqueda dense + sparse + RRF	Sí	La búsqueda vectorial siempre fue CPU, incluso en stacks “GPU”. RRF es ordenar listas.
Reranker cross-encoder `bge-reranker-v2-m3` top-20/50	Sí, con cuidado	Un cross-encoder evalúa $k$ pares query-doc: coste $\propto k$. Sobre 20-50 candidatos va; sobre cientos a alto QPS, no.
ColBERT late-interaction	Marginal en CPU	El producto de matrices token-a-token de la interacción tardía es pesado; viable en volúmenes bajos, sufre con QPS.
Generación LLM	No, en la práctica	Un 7B en CPU da TTFT de segundos. Latencia interactiva = GPU.

Dos filas merecen subrayado porque desmontan mitos.

“La búsqueda vectorial necesita GPU.” Falso de origen. El índice HNSW —el grafo navegable de pequeño mundo que usan Qdrant, pgvector con vector/halfvec, Milvus en su modo CPU y casi todo lo demás— siempre se construyó y se recorrió en CPU. Incluso los stacks que se anuncian como “GPU-accelerated RAG” hacen el embedding en GPU pero la búsqueda ANN sigue en CPU en la inmensa mayoría de despliegues; las variantes GPU del índice (CAGRA y similares) son la excepción cara, no la norma, y se justifican solo con miles de millones de vectores y QPS extremo. Para un corpus corporativo de millones de chunks, HNSW en CPU resuelve en single-digit milisegundos.

“El reranker es un modelo, luego GPU.” El reranker bge-reranker-v2-m3 es un cross-encoder de ~568M: corre en CPU. El matiz es el número de pares. Un cross-encoder no produce un vector reutilizable; evalúa la pareja (query, documento) junta, así que su coste crece linealmente con los candidatos $k$:

$$\text{coste}_{\text{rerank}} \propto k \times \text{forward}(\text{query} + \text{doc})$$

Rerankear el top-20 o top-50 que sale del retrieval híbrido es perfectamente asumible en CPU. Rerankear cientos de candidatos a alto QPS no: ahí el coste lineal se dispara y la GPU gana. La regla práctica: recall amplio barato en el retriever, rerank de precisión sobre pocos candidatos. (El detalle de hybrid retrieval y reranking está en la pieza de fundamentos enlazada abajo.)

Los números, con metodología honesta

Aquí viene la parte donde mucha gente miente por omisión. Voy a dar rangos de throughput, pero son rangos de literatura y de orden de magnitud, no medidas mías en este hardware. Tómalos como tales: la decisión correcta no depende de clavar el número, depende de entender el reparto.

Para bge-m3 dense, secuencia ≈256 tokens, el throughput de embedding se mueve aproximadamente así:

Plataforma	Throughput dense (orden de magnitud)	Lectura
GPU gama alta (5090 fp16, TEI)	~12k tok/s+ (orientativo)	El techo; caro y escaso.
CPU servidor grande (Xeon ~56 cores, int8 ONNX)	banda baja de miles tok/s	~1/5–1/10 de la GPU, pero escalable horizontal y barato.
CPU edge / NUC (4-8 cores, int8)	decenas a bajos cientos tok/s	Suficiente para ingesta nocturna de un corpus local.

La tentación es leer la segunda fila como “CPU es 5-10× más lento, descartado”. Es la lectura equivocada para la ingesta. Para trabajo batch sin SLA, lo que mandan no son los tok/s absolutos sino el throughput por euro y el throughput por vatio —y ahí la cuenta cambia de signo.

Pongamos un ejemplo numérico de reparto. Supón un corpus de 2 millones de chunks de ~256 tokens que hay que re-indexar una vez al día (cambia el corpus, hay que rehacer embeddings). Eso son:

$$2 \times 10^6 \text{ chunks} \times 256 \text{ tok/chunk} \approx 5.1 \times 10^8 \text{ tokens}$$

A un throughput CPU conservador de, digamos, 3000 tok/s por servidor Xeon int8:

$$t_{\text{ingesta}} \approx \frac{5.1 \times 10^8 \text{ tok}}{3000 \text{ tok/s}} \approx 1.7 \times 10^5 \text{ s} \approx 47 \text{ horas en un solo servidor}$$

47 horas en una caja suena mal hasta que recuerdas dos cosas. Primero, esto es vergonzosamente paralelo: el corpus se trocea y se reparte; con 8 servidores CPU baja a ~6 horas, con 16 a ~3 horas, holgadamente dentro de la ventana nocturna. Segundo, y más importante: ese mismo trabajo en la GPU bloquea la GPU. Si la H100 hace 12k tok/s, tarda ~12 horas… pero son 12 horas de la H100, el recurso por el que se pelea toda la organización para generar. Gastar el recurso escaso y caro en re-indexar un corpus que cambia una vez al día es un mal reparto, aunque sea “más rápido”: estás optimizando el tok/s equivocado.

La regla mental: para la ingesta, optimiza throughput/€ y throughput/W; los tok/s absolutos son del plano de generación, donde el cronómetro humano sí corre.

Árbol de decisión: ¿CPU o GPU para esta pieza?

Arquitectura de referencia (a): CPU-only

El primer caso es un nodo sin GPU: un NUC, un Xeon de oficina, un servidor edge soberano en una sucursal o en un entorno aislado. Todo el plano de datos vive ahí; la generación se delega a un endpoint GPU remoto o se hace en batch con un SLM cuando la latencia no apremia.

El stack:

TEI-CPU sirviendo bge-m3 int8 con dense + sparse (mismo contrato OpenAI /v1/embeddings, más /rerank para el reranker).
Qdrant con índice HNSW dense + vectores sparse, fusión RRF nativa.
Reranker bge-reranker-v2-m3 sobre el top-k (vía el /rerank de TEI).
Gateway que orquesta y, para generar, llama a un endpoint externo.

# docker-compose: plano de datos RAG completo en CPU (sin GPU)
services:
 tei-embed:
 image: ghcr.io/huggingface/text-embeddings-inference:cpu-latest
 command: ["--model-id", "BAAI/bge-m3", "--pooling", "cls", "--dtype", "int8"]
 ports: ["8081:80"]
 # backend ONNX/MKL: aprovecha AVX-512+VNNI / AMX si el Xeon lo soporta

 tei-rerank:
 image: ghcr.io/huggingface/text-embeddings-inference:cpu-latest
 command: ["--model-id", "BAAI/bge-reranker-v2-m3", "--dtype", "int8"]
 ports: ["8082:80"]
 # expone /rerank — se invoca SOLO sobre top-20/50, no sobre cientos

 qdrant:
 image: qdrant/qdrant:latest
 ports: ["6333:6333"]
 volumes: ["./qdrant_storage:/qdrant/storage"]
 # HNSW dense + sparse vectors + RRF, todo CPU

Búsqueda híbrida con fusión RRF en Qdrant (dense + sparse en una sola query):

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://qdrant:6333")

# embed de la query: dense y sparse desde el TEI-CPU (omitido el wiring HTTP)
hits = client.query_points(
 collection_name="corpus",
 prefetch=[
 models.Prefetch(query=dense_vec, using="dense", limit=50),
 models.Prefetch(query=sparse_vec, using="sparse", limit=50),
 ],
 query=models.FusionQuery(fusion=models.Fusion.RRF), # RRF nativo
 limit=20,
).points
# -> luego: POST /rerank (TEI) sobre estos 20, te quedas con top-5
# -> luego: el gateway manda query + top-5 al endpoint de GENERACIÓN (GPU)

La generación, en este nodo CPU-only, sale del nodo: el gateway construye el prompt aumentado y lo envía a un endpoint vLLM en el cluster GPU (o, si no hay SLA interactivo, a un SLM en CPU en modo batch, asumiendo TTFT de segundos). El plano de datos entero —lo de arriba— corre sin una sola GPU.

Arquitectura de referencia (b): híbrida recomendada

Esta es la que recomiendo para el caso general con cluster GPU disponible: plano de datos en CPU, plano de generación en GPU, comunicados por contratos HTTP OpenAI-compatibles para que cada lado sea sustituible.

Servidor de generación, mínimo, en GPU:

# vLLM en el cluster GPU — SOLO generación
services:
 vllm-gen:
 image: vllm/vllm-openai:latest
 command: >
 --model meta-llama/Llama-3.1-8B-Instruct
 --dtype bfloat16 --max-model-len 8192
 --gpu-memory-utilization 0.85
 # expone /v1/chat/completions — el gateway le manda query + top-5 ya recuperados
 deploy:
 resources:
 reservations:
 devices: [{driver: nvidia, count: 1, capabilities: [gpu]}]

La virtud del diseño: como ambos lados hablan el contrato OpenAI por HTTP, el plano de datos en CPU y el de generación en GPU escalan por separado y son sustituibles. Si mañana quieres mover el rerank a GPU porque el QPS subió, cambias una URL. Si quieres meter más nodos CPU de ingesta, los añades sin tocar la generación. Todo el stack es OSS y license-clean: bge-m3 y bge-reranker-v2-m3 son MIT (bge-m3, reranker), Qdrant es Apache-2.0, TEI y vLLM son OSS.

Aplicado al cluster genérico 4×H100

Bajemos esto al cluster de la serie: 4×H100 SXM 80 GB más una flota CPU genérica (Xeon con AMX, NUCs). El reparto correcto:

Construcción e indexación → flota CPU. Ninguna H100 debería gastar un ciclo re-embebiendo el corpus. Eso va a los Xeon AMX (servidores grandes, throughput de miles de tok/s en int8) o, para corpus locales pequeños, a los NUCs por la noche. El re-indexado nocturno de un corpus que cambia una vez al día es el caso de libro de “trabajo de CPU sin prisa”.
Las H100 → generación. Las cuatro tarjetas se reservan para lo que solo ellas hacen bien: producir tokens a latencia interactiva. Esto es lo que las piezas hermanas de la serie —compartir GPU y varios modelos en una GPU— ayudan a exprimir: una vez que la ingesta no compite por la GPU, todo el silicio caro queda libre para generar y se reparte mejor entre modelos y tenants.
Las H100, como mucho, → picos de rerank o embedders grandes. Si en algún momento necesitas un embedder de 7B (gte-Qwen2, NV-Embed) para un dominio donde bge-m3 no llega, o un rerank masivo a QPS que la CPU no absorbe, esos picos sí pueden visitar la GPU. Pero son la excepción puntual, no la carga base.

El ángulo de auditabilidad: ENS / NIS2

Hay un argumento de compliance que rara vez se menciona y que el reparto CPU/GPU regala casi gratis.

Un nodo CPU-only sin driver propietario es más fácil de auditar. No hay stack de kernel cerrado de NVIDIA, no hay versiones de CUDA y firmware que casar con la cadena de suministro, no hay superficie de driver propietario que documentar para un ENS o un NIS2. Todo el plano de datos —chunking, embeddings, índice, búsqueda— corre sobre software OSS en CPU genérica con instrucciones estándar. Para un entorno soberano o clasificado, poder decir “el plano que toca el corpus no depende de ningún binario propietario” es un argumento real, no marketing.

Y hay un segundo ángulo de auditabilidad intrínseco al RAG bien hecho: la trazabilidad de fuentes. Un RAG que recupera chunks identificables y los cita es auditable —puedes reconstruir de qué documento salió cada afirmación— frente al context-stuffing o el conocimiento paramétrico opaco del modelo, donde no hay forma de saber de dónde viene un dato. Esa trazabilidad vive en el plano de datos (qué se recuperó, de qué fuente, con qué score), justo el plano que estamos poniendo en CPU auditable. Los dos argumentos se refuerzan: el silicio auditable y la cadena de evidencia auditable son el mismo plano.

Cuándo NO llevarlo a CPU

Por honestidad y para no caer en el espejo del hype contrario, los casos donde la CPU no es la respuesta:

Generación a latencia interactiva. El caso obvio. Un 7B en CPU da TTFT de segundos: inaceptable para chat. Si el usuario espera, la generación va a GPU. Sin excepciones prácticas a día de hoy.
Reranking masivo a alto QPS. Un cross-encoder o ColBERT sobre cientos de candidatos, multiplicado por muchas peticiones por segundo, satura la CPU. El coste $\propto k \times \text{QPS}$ cruza el umbral donde la GPU paga. Mantén el rerank CPU acotado a top-20/50; si necesitas más amplitud a más QPS, sube a GPU.
Re-indexación en tiempo real con SLA estricto. Si el corpus cambia continuamente y la frescura es de segundos (no de horas), el throughput de la CPU puede no alcanzar la ventana. Ahí el embedding de ingesta puede necesitar GPU —pero nota que esto es raro: la mayoría de corpus corporativos cambian a ritmo de horas o días, no de segundos.
Embedders grandes (7B). bge-m3 (568M) es cómodo en CPU; un gte-Qwen2 o NV-Embed de 7B vuelve a ser un LLM-class y arrastra el mismo perfil de coste que la generación. Si tu calidad de recuperación exige un embedder de 7B, ese embedder vive donde viven los 7B: en la GPU.

La frase que resume todo: la CPU es el sitio por defecto del plano de datos; la GPU es la excepción justificada para lo latency-bound y lo masivo-online. Empieza poniendo todo en CPU y sube a GPU solo lo que demuestre que no cabe —no al revés.

Ver también

Ingesta documental end-to-end: del PDF al chunk indexado — el pipeline de ingesta que corre en ese plano de datos CPU.
Servir embeddings y rerankers con TEI en producción — el motor (TEI) que sirve los embeddings y rerankers de ese plano de datos.
Compartir una GPU: time-slicing, MPS y MIG — la pieza hermana sobre el reparto dentro de la GPU; una vez que la ingesta sale de la GPU, esto exprime lo que queda.
Embeddings 2026: dense, sparse y multivector — las tres cabezas de bge-m3 que el plano de datos sirve en CPU, y cuándo justifica un embedder de 7B que sí pide GPU.
Reranking e hybrid retrieval: fundamentos — el detalle de RRF y del rerank cross-encoder cuyo coste lineal decide la frontera CPU/GPU del top-k.
Ingestión con PostgreSQL y Qdrant en microservicios — cómo se estructura el pipeline de ingesta que aquí ponemos en la flota CPU.
Entornos mixtos NVIDIA + Intel: del cluster H100 al NUC — el hardware concreto de la flota CPU (Xeon AMX, NUC) que sostiene el plano de datos.
Caché semántico para RAG — otra capa que vive en el plano de datos en CPU y evita tocar la GPU cuando la query ya se respondió.
RAG agresivo en modelos pequeños — el lado de generación de esta moneda: cómo el plano de datos curado descarga al modelo de la fase generativa.

Referencias

Chen, J., et al. BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings. arXiv 2402.03216. https://arxiv.org/abs/2402.03216
BAAI — BGE-M3 model card (568M params, XLM-RoBERTa, 8192 tokens, MIT). https://huggingface.co/BAAI/bge-m3
BAAI — bge-reranker-v2-m3 model card (cross-encoder sobre bge-m3, ~568M). https://huggingface.co/BAAI/bge-reranker-v2-m3
Intel + Hugging Face — CPU Optimized Embeddings with Optimum Intel and fastRAG (~10× indexación BGE-large int8, Xeon 4ª gen). https://huggingface.co/blog/intel-fast-embedding
deepset / Haystack — CPU-Optimized Embedding Models with fastRAG and Haystack. https://haystack.deepset.ai/blog/cpu-optimized-models-with-fastrag
Hugging Face — Text Embeddings Inference (TEI), backends CPU ONNX/MKL, endpoints OpenAI-compatibles. https://github.com/huggingface/text-embeddings-inference
Qdrant — fastembed (ONNX-CPU, dense/sparse/ColBERT) y Hybrid Search con RRF. https://github.com/qdrant/fastembed · https://qdrant.tech/documentation/beginner-tutorials/hybrid-search-fastembed/