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/

Amx on lo0 — Blog Técnico