Optimizando la Inferencia Local de LLM para Tareas de Etiquetado y Aumentacion de Datos

La inferencia local de LLM transforma la preparacion de datos de un proceso completamente manual a un flujo de trabajo con humano en el ciclo. En lugar de etiquetar cada documento desde cero, un ingeniero de ML o experto de dominio revisa y corrige pre-anotaciones generadas por IA. La calidad de esas pre-anotaciones — y la velocidad a la que se generan — depende de lo bien que este configurado el stack de inferencia local.

Esta guia cubre la optimizacion practica para usar LLMs locales en etiquetado y aumentacion de datos: que modelos elegir, como la cuantizacion afecta la precision del etiquetado, como estructurar prompts para salidas consistentes y donde estan los cuellos de botella de rendimiento.

---

Seleccion de Modelo para Tareas de Preparacion de Datos

No todos los modelos son igualmente adecuados para trabajo de preparacion de datos. Los requisitos difieren de la IA conversacional:

• Seguimiento de instrucciones: El modelo debe seguir instrucciones de salida estructurada de forma consistente. Si pides JSON con claves especificas, debe producir JSON con esas claves — siempre, no el 95% de las veces.
• Salidas cortas y estructuradas: La mayoria de las tareas de etiquetado producen salidas de 10-200 tokens (una etiqueta, un objeto JSON, una extraccion breve). Los modelos optimizados para generacion de texto largo se desperdician aqui.
• Vocabulario del dominio: El modelo debe manejar terminologia tecnica sin parafrasearla. Codigos medicos, citas legales y terminos de ingenieria necesitan pasar tal cual.

Modelos Recomendados por Tarea

El punto optimo de 7B: Para la mayoria de las tareas de clasificacion y extraccion, los modelos de 7B con instrucciones entregan el 90-95% de la precision de modelos mas grandes a 2-3x el rendimiento. Comienza con 7B. Pasa a 14B solo cuando midas una brecha de precision en tu tarea especifica.

---

Compensaciones de Cuantizacion

La cuantizacion reduce la precision del modelo de punto flotante de 16 bits a anchos de bits mas bajos, reduciendo el tamano del modelo y aumentando la velocidad de inferencia. La compensacion es la precision.

Niveles de Cuantizacion Comparados

Recomendaciones de Cuantizacion para Preparacion de Datos

Tareas de clasificacion (binaria, multi-clase): Q4_K_M esta bien. Las salidas de clasificacion son cortas y restringidas. El modelo elige la categoria correcta o no — y Q4 preserva suficiente precision para esta decision.

Extraccion de entidades: Se prefiere Q5_K_M o Q8_0. La extraccion requiere que el modelo identifique y reproduzca cadenas especificas de la entrada. Una cuantizacion mas baja puede causar errores sutiles a nivel de token (errores ortograficos, entidades truncadas) que son costosos de detectar en la revision.

Generacion de datos sinteticos: Q5_K_M como minimo. La calidad del texto generado se degrada notablemente por debajo de Q5 — las oraciones se vuelven menos coherentes, la terminologia tecnica se distorsiona y la salida requiere mas edicion humana.

Recomendacion general: Comienza con Q4_K_M para pruebas iniciales. Si la precision en tu tarea especifica es aceptable, quedate ahi por rendimiento. Si ves problemas de calidad, sube a Q5_K_M o Q8_0. No bajes de Q4_K_M para trabajo de preparacion de datos.

---

Backends de Inferencia: Ollama vs llama.cpp vs vLLM

Ollama

Mejor para: La mayoria de las configuraciones de preparacion de datos. Gestion facil de modelos, API compatible con OpenAI, deteccion automatica de GPU.

Ollama envuelve llama.cpp con un registro de modelos y un servidor HTTP. La sobrecarga es minima — una solicitud/respuesta HTTP agrega menos de 1ms por llamada de inferencia, lo cual es despreciable comparado con los 100ms-10s que la inferencia en si toma.

Configuracion para preparacion de datos:

# Establece el limite de solicitudes concurrentes (por defecto es 1)
OLLAMA_NUM_PARALLEL=4 ollama serve

# Descarga un modelo
ollama pull mistral:7b-instruct-v0.3-q4_K_M

# O descarga una cuantizacion especifica
ollama pull qwen2.5:14b-instruct-q5_K_M

Configuracion clave: OLLAMA_NUM_PARALLEL controla cuantas solicitudes Ollama procesa concurrentemente. Para preparacion de datos, establece esto en 2-4 si tu GPU tiene suficiente VRAM. Cada solicitud paralela carga una ventana de contexto adicional en VRAM.

llama.cpp (Directo)

Mejor para: Entornos aislados donde el registro de modelos de Ollama es inalcanzable, o cuando necesitas control detallado sobre los parametros de inferencia.

El llama-server de llama.cpp proporciona un endpoint compatible con OpenAI sin la capa de gestion de modelos de Ollama. Lo apuntas directamente a un archivo GGUF.

# Inicia el servidor con modelo especifico y parametros ajustados
llama-server \
  --model ./models/mistral-7b-instruct-v0.3.Q4_K_M.gguf \
  --ctx-size 4096 \
  --n-gpu-layers 99 \
  --parallel 4 \
  --batch-size 512

Parametros clave:

• --ctx-size: Tamano de la ventana de contexto. Para etiquetado de documentos, 4096 tokens maneja la mayoria de las tareas de un solo documento. Aumenta a 8192 o 16384 para documentos largos.
• --n-gpu-layers: Numero de capas del modelo a descargar en la GPU. Establece en 99 para descargar todo. Reduce si te quedas sin VRAM.
• --parallel: Ranuras de solicitudes concurrentes. Cada ranura reserva memoria de contexto.
• --batch-size: Tokens procesados por lote durante la evaluacion del prompt. Valores mas altos aceleran el procesamiento del prompt pero usan mas memoria.

vLLM

Mejor para: Procesamiento por lotes de alto rendimiento con multiples solicitudes concurrentes. El mecanismo PagedAttention de vLLM maneja muchas solicitudes concurrentes de forma mas eficiente que llama.cpp.

Compensaciones: Instalacion mas pesada (Python + PyTorch + CUDA). Configuracion mas compleja. Menos adecuado para flujos de trabajo de etiquetado interactivo donde procesas un documento a la vez. Excesivo para la mayoria de los escenarios de preparacion de datos a menos que estes ejecutando inferencia por lotes en mas de 100K documentos.

Recomendacion para la mayoria de los proveedores de servicios: Usa Ollama. Es el camino mas simple a inferencia local funcional. Cambia a llama.cpp directo si estas en un entorno aislado. Considera vLLM solo si el rendimiento de lotes es un cuello de botella medido.

---

Estrategias de Inferencia por Lotes

El etiquetado y la aumentacion de datos se prestan naturalmente al procesamiento por lotes. Tienes N documentos para etiquetar — procesalos de la manera mas eficiente posible.

Procesamiento Secuencial de Un Solo Documento

Procesa un documento a la vez. Simple, facil de depurar, facil de reanudar si se interrumpe.

Rendimiento: Para un modelo 7B Q4 generando ~50 tokens por etiqueta, espera 30-50 etiquetas por minuto en una RTX 4070. Eso es 1,800-3,000 etiquetas por hora.

Procesamiento Paralelo por Lotes

Envia multiples solicitudes de inferencia concurrentemente. OLLAMA_NUM_PARALLEL de Ollama o --parallel de llama.cpp habilita esto.

Mejora de rendimiento: 2-4 solicitudes paralelas tipicamente mejoran el rendimiento 1.5-3x (no lineal, porque el computo de GPU se comparte). Con 4 solicitudes paralelas en una RTX 4070, espera 4,500-8,000 etiquetas por hora.

Costo en VRAM: Cada ranura paralela reserva memoria de contexto. Con un tamano de contexto de 4096, cada ranura consume ~200-400 MB de VRAM (varia por modelo). Asegurate de tener margen.

Agrupacion de Prompts (Multiples Documentos por Solicitud)

Incluye multiples documentos cortos en un solo prompt, pidiendo al modelo que etiquete todos. Esto amortiza la sobrecarga por solicitud.

Label each document with one of: [contract, invoice, correspondence, report].
Respond with JSON array.

Document 1: "Dear Sir, we are writing to confirm..."
Document 2: "Invoice #4521 - Amount Due..."
Document 3: "Q3 Performance Summary..."

Compensacion: Mayor rendimiento (menos solicitudes), pero manejo de errores mas complejo. Si el modelo alucina en un documento del lote, necesitas identificarlo y reprocesarlo. Mejor para tareas de clasificacion simple donde los errores son faciles de detectar.

---

Gestion de la Ventana de Contexto

El etiquetado de documentos frecuentemente requiere el texto completo del documento como contexto de entrada. Esto crea una tension: los documentos mas largos necesitan ventanas de contexto mas grandes, pero las ventanas de contexto mas grandes ralentizan la inferencia.

Tamano de Contexto vs. Velocidad

Enfoque practico: Establece el tamano de contexto para que coincida con las longitudes reales de tus documentos, no con el maximo del modelo. Si el 95% de tus documentos caben en 4096 tokens, establece el contexto en 4096. Para el 5% que son mas largos, trunca (etiqueta basandote en los primeros N tokens) o procesalos por separado con un contexto mas grande.

Fragmentacion para Documentos Largos

Los documentos que exceden la ventana de contexto necesitan fragmentacion. Para tareas de etiquetado:

1. Divide el documento en fragmentos con superposicion (ej., 3000 tokens con 500 tokens de superposicion)
2. Etiqueta cada fragmento independientemente
3. Fusiona las etiquetas, resolviendo conflictos en las regiones de superposicion

Esto funciona bien para extraccion de entidades y clasificacion pero mal para tareas que requieren comprension global del documento (como resumen o sentimiento a nivel de documento).

---

Ingenieria de Prompts para Etiquetas Consistentes

La preparacion de datos exige consistencia. Un prompt de clasificacion que produce "Contrato" para un documento y "contrato" para un documento identico crea problemas posteriores.

Prompts de Salida Estructurada

You are a document classifier. Classify the following document into exactly one category.

Categories: contract, invoice, correspondence, report, other

Rules:
- Output ONLY the category name in lowercase
- No explanation, no punctuation, no additional text
- If uncertain, output "other"

Document:
{document_text}

Category:

Salida JSON para Etiquetas Complejas

Extract entities from the following document. Output valid JSON only.

Schema:
{"parties": [string], "date": string|null, "amount": string|null, "type": string}

Rules:
- Use null for missing fields
- Dates in ISO 8601 format (YYYY-MM-DD)
- Amounts include currency symbol
- No markdown, no explanation

Document:
{document_text}

JSON:

Principios Clave de Prompts para Preparacion de Datos

1. Restringe el espacio de salida: Lista todas las etiquetas validas explicitamente. El modelo debe elegir de tu lista, no inventar etiquetas.
2. Especifica el formato de salida exactamente: "solo minusculas", "solo JSON", "sin explicacion". Repite la restriccion.
3. Proporciona 2-3 ejemplos para categorias ambiguas. Los ejemplos few-shot son la forma mas efectiva de mejorar la consistencia de las etiquetas.
4. Establece la temperatura en 0 para tareas de clasificacion y extraccion. Quieres salida deterministica, no variacion creativa.

---

Estimaciones de Rendimiento por Configuracion

Numeros de rendimiento realistas para tareas comunes de preparacion de datos:

Estos asumen procesamiento de un solo documento. La inferencia paralela (2-4 solicitudes concurrentes) mejora estos numeros 1.5-3x.

---

La Compensacion de Precision vs. Velocidad

La pre-anotacion no necesita ser perfecta. Necesita ser lo suficientemente buena para que la revision y correccion humana sea mas rapida que etiquetar desde cero.

El umbral: si las pre-anotaciones tienen mas del 80% de precision, los revisores humanos pasan la mayor parte de su tiempo confirmando etiquetas correctas (rapido) en lugar de corregir las incorrectas (lento). Con mas del 90% de precision, el flujo de trabajo esta dominado por clics de confirmacion.

Implicacion practica: No optimices en exceso la precision a costa del rendimiento. Un modelo 7B Q4 que tiene 85% de precision a 3,000 docs/hora es mas util que un modelo 14B Q8 con 92% de precision a 800 docs/hora — porque el tiempo de revision humana ahorrado por el 7% extra de precision no compensa la reduccion de 3.7x en rendimiento.

Mide la precision en una muestra de tus datos reales antes de comprometerte con una configuracion de modelo.

---

Configuracion en la Practica

Ertas Data Suite integra la inferencia local de LLM como un copiloto incorporado para etiquetado y aumentacion. La aplicacion se comunica con Ollama o llama.cpp ejecutandose en localhost, usando la configuracion de modelo que especifiques. Las plantillas de prompts para clasificacion, extraccion y generacion estan incorporadas, con la opcion de personalizar prompts por proyecto.

La combinacion de una aplicacion de escritorio nativa con un backend de inferencia local significa que no hay salto de red entre la interfaz de etiquetado y el modelo. Haz clic en un documento, ve la pre-anotacion, acepta o corrige — todo sucediendo en hardware local sin que ningun dato salga de la maquina.

Para proveedores de servicios que optimizan su flujo de trabajo de preparacion de datos, la palanca mas grande es la seleccion del modelo y la cuantizacion, no infraestructura exotica. Obtiene el modelo correcto en la cuantizacion correcta en una estacion de trabajo con VRAM adecuada, y el rendimiento sigue.