LLMs 101: Una guía práctica (Edición 2026)

Comienza con el bucle. El texto se convierte en tokens. Los tokens atraviesan un Transformer. La atención decide qué tokens anteriores importan. El runtime mantiene un caché KV para que el modelo no tenga que recomputar toda la conversación cada vez. Luego el modelo elige el siguiente token y repite el proceso.

Una guía práctica sobre cómo funcionan los LLMs, cómo los modelos piensan un token a la vez y cómo ejecutarlos localmente.

Una vez que ese bucle se entiende, las decisiones sobre hardware y software se vuelven más fáciles de analizar. VRAM, cuantización, longitud de contexto, plantillas de chat, decodificación, RAG, motores de inferencia y selección de modelos surgen todos de la misma mecánica.

Comienza con el bucle: tokens de entrada, probabilidades de salida, un siguiente token a la vez. Los pesos indican al modelo qué patrones ha aprendido. El contexto le dice lo que está viendo en este momento. El caché KV es la memoria de trabajo que mantiene el bucle utilizable. El hardware, los runtimes y la selección de modelos solo tienen sentido después de entender la memoria, el contexto y las reglas de formato que el modelo está siguiendo.

El objetivo es hacer que la mecánica de los LLMs locales sea intuitiva primero, y luego darte un camino práctico hacia el hardware, los runtimes, el servicio y la investigación actual de LLMs al 21 de mayo de 2026.

Enfoque

Esta es una guía centrada en el modelo. Comienza con la mecánica: inferencia, tokens, Transformers, atención, caché KV, prefill, decode, controles de decodificación, paquetes de modelos, plantillas de chat, tipos de modelos, contexto largo, RAG, agentes, fine-tuning y modelos multimodales.

Después de eso, pasa a la capa de despliegue local: qué significa realmente local, cuantización, matemáticas de VRAM, niveles de hardware, opciones de runtime, modos de servicio, licencias, selección de modelos, privacidad, solución de problemas, benchmarks, rutas de configuración y casos de uso prácticos.

Ese orden es importante. Debes entender por qué un prompt largo cuesta memoria antes de elegir una GPU. Debes entender por qué las plantillas de chat importan antes de juzgar un modelo. Debes entender por qué el decode es secuencial antes de preocuparte por los tokens por segundo.

Para el camino más profundo de hardware y software, tengo una serie de tres partes sobre LLMs autoalojados / IA local:

Las dos primeras piezas explican las matemáticas de capacidad y ancho de banda del hardware. La tercera explica la capa de software que convierte ese hardware en inferencia utilizable. Este artículo te da primero la base del lado del modelo, y luego apunta hacia esas capas de despliegue una vez que la mecánica está clara.

Lo Que Realmente Hace un LLM

Ejecutar un modelo se llama inferencia. Para un LLM estándar solo-decodificador, la inferencia es el mismo bucle repetido una y otra vez:

Convierte tu texto en tokens.
Alimenta esos tokens al modelo.
Calcula puntuaciones para cada posible siguiente token.
Elige un token con una política de decodificación.
Añade ese token a la secuencia.
Repite hasta que el modelo se detenga, el usuario lo detenga, o se alcance un límite de tokens.

El modelo no está escribiendo una respuesta completa de una sola vez. Está generando un token a la vez. Cada nuevo token se convierte en parte de la secuencia que influye en el siguiente token.

Matemáticamente, el modelo es una función aprendida:

f(theta, secuencia) -> distribución de probabilidad sobre el siguiente_token

Donde:

theta significa los pesos del modelo.
secuencia significa el prompt más los tokens generados hasta ahora.
Logits son las puntuaciones brutas antes de softmax.
Probabilidades son las puntuaciones normalizadas después de softmax.
Decodificación convierte esas probabilidades en un token seleccionado.

Por eso la velocidad de generación local se mide en tokens por segundo. Tu sistema ejecuta repetidamente un pase hacia adelante, elige o muestrea un token, actualiza el caché KV y continúa.

La percepción importa aquí. Un prefill largo significa una pausa larga antes de que aparezca la primera palabra. Un decode lento significa que la respuesta fluye lentamente. Los constructores locales a menudo se obsesionan con la velocidad de decode porque es lo que los usuarios sienten, pero el tiempo de prefill es lo que duele cuando pegas un documento de 10K tokens.

Tokens

Los LLMs no ven el texto sin procesar como palabras. Ven tokens: pequeños fragmentos de texto representados internamente como IDs enteros.

Un token puede ser:

Una palabra completa: "hola"
Un fragmento de palabra: "inter", "nacio", "nalización"
Un signo de puntuación
Una cadena con prefijo de espacio en blanco
Un fallback a nivel de byte
Un marcador de control especial como <|user|>, <|assistant|>, , o

El tokenizador mapea texto a IDs de token y los IDs de token de vuelta a texto. Las familias comunes de tokenizadores incluyen tokenizadores de estilo BPE y tokenizadores de estilo SentencePiece. Diferentes familias de modelos usan diferentes tokenizadores, y eso importa. Un documento de 4,000 palabras puede ser 5,000 tokens en un tokenizador y 7,500 tokens en otro.

El tamaño del vocabulario también importa. Un tokenizador con un vocabulario más grande puede comprimir algo de texto en menos tokens, pero también cambia el tamaño de las proyecciones de embedding y salida. Esta es una razón por la que los tokens por segundo no son perfectamente comparables entre familias de modelos.

Los tokens importan porque determinan:

Cuánto texto cabe en la ventana de contexto.
Qué tan grande se vuelve el caché KV.
Cuánta latencia pagas durante el procesamiento del prompt.
Si el texto multilingüe o de código es eficiente.
Si el modelo ve correctamente los marcadores de chat especiales.

La ventana de contexto de un modelo es el número máximo de tokens a los que puede atender a la vez. En 2026, los modelos comunes capaces de ejecución local van desde contextos de 8K y 32K hasta 128K, 256K e incluso 1M de tokens en sistemas de clase servidor.

Pero la longitud de contexto soportada no es lo mismo que un contexto barato, rápido o igualmente preciso. Un modelo que técnicamente puede manejar 128K tokens puede ralentizarse drásticamente a 64K y perder coherencia a 100K. Siempre prueba las longitudes de contexto que planeas usar realmente.

Los tokens son la unidad de trabajo. Una vez que entiendes esto, el contexto largo deja de parecer mágico y empieza a parecer una factura que puedes estimar.

Ejercicio útil: Prueba mi aplicación demo de tokenizador para ver cómo el texto se divide en tokens en tiempo real.

Transformers

La mayoría de los LLMs modernos se basan en la arquitectura Transformer. La mayoría de los LLMs de chat locales son Transformers solo-decodificador: predicen el siguiente token mientras miran hacia atrás a los tokens anteriores.

Todo lo anterior a este punto, incluyendo tokens, pesos, configuración y plantillas de chat, es preparación para el verdadero motor subyacente. El Transformer es el esqueleto que mueve los números.

Una capa de Transformer simplificada contiene:

Embeddings de tokens: los IDs de token se convierten en vectores.
Información posicional: el modelo necesita el orden de los tokens. Muchos LLMs modernos usan RoPE (Rotary Position Embeddings), que codifica la posición rotando representaciones.
Autoatención: cada representación de token mira hacia atrás a representaciones de tokens anteriores y decide qué importa.
Bloque MLP / feed-forward: una computación densa no lineal que expande y comprime representaciones. Una gran fracción de los parámetros vive aquí.
Normalización de capa y conexiones residuales: estabilizan redes profundas y ayudan a que la información fluya a través de muchas capas.
Proyección de salida: el estado oculto final se convierte en logits sobre el vocabulario.

Apila esta receta docenas o cientos de veces y obtienes un modelo de lenguaje.

Resumen del Transformer: los tokens se convierten en vectores, la atención conecta la secuencia, los MLPs reforman la representación, RoPE mantiene la posición clara, y la proyección final convierte el último estado oculto en logits del siguiente token.

Atención

La atención es cómo un token decide qué tokens anteriores importan para la siguiente predicción. También es una de las razones por las que la inferencia local es tan sensible a la memoria.

La MHA (multi-head attention) clásica almacena estados clave/valor separados para muchas cabezas. Le da flexibilidad al modelo, pero hace que el caché KV sea grande.

Los modelos locales modernos a menudo usan diseños de atención más eficientes:

MQA: múltiples cabezas de consulta comparten una cabeza clave/valor. Es eficiente en memoria, pero puede ser menos expresiva.
GQA: grupos de cabezas de consulta comparten cabezas clave/valor. Es el término medio común en muchos modelos locales actuales.
MHA: atención completa de múltiples cabezas. Puede ser fuerte, pero el contexto largo se vuelve costoso rápidamente.

Kernels modernos como FlashAttention e implementaciones de estilo SDPA reducen el tráfico de memoria de atención y mantienen la GPU más ocupada. Un runtime con buenos kernels de atención puede ser dramáticamente más rápido que uno sin ellos, incluso en el mismo modelo y hardware.

Por eso dos modelos de 7B pueden comportarse de manera muy diferente en contexto largo. El número de parámetros no es toda la historia. Un modelo de 7B MHA con contexto de 128K puede agotar una GPU de 24 GB, mientras que un modelo de 7B GQA con el mismo contexto anunciado puede caber con espacio de sobra.

Al comparar modelos, mira el tipo de atención, las cabezas KV, la longitud de contexto y el soporte del runtime, no solo el número de parámetros.

Caché KV

El caché KV es la memoria de trabajo del modelo durante la generación. Almacena estados de atención clave/valor de tokens anteriores para que el modelo no tenga que recomputar toda la historia desde cero en cada token generado.

Sin un caché KV, la generación sería brutalmente ineficiente. Con un caché KV, la generación es utilizable, pero el caché consume memoria proporcional a:

tokens x capas x cabezas_kv x dim_cabeza x precisión x 2

El x 2 es para claves y valores.

Una regla general útil para modelos antiguos similares a Llama de 7B MHA es aproximadamente 0.5 MiB por token en caché KV FP16. Eso significa que 4K tokens pueden costar alrededor de 2 GiB solo para el caché KV. A 32K tokens, puedes estar mirando 16 GiB solo de caché KV.

Los modelos GQA/MQA más nuevos reducen esto sustancialmente. Algunos runtimes también soportan caché KV en FP8 o INT8. Ese suele ser el piso de compresión práctico que recomendaría para usuarios locales en 2026.

No trates el caché KV por debajo de 8 bits como opción predeterminada. Sistemas de investigación como KIVI, KVQuant y kernels de caché comprimido más nuevos muestran que KV de 2 a 4 bits puede funcionar con algoritmos cuidadosos, calibración y kernels personalizados. Eso no es lo mismo que activar casualmente un toggle Q4 KV en un runtime de escritorio. Por debajo de 8 bits, haz benchmarks exhaustivos, especialmente para programación, llamadas a herramientas, JSON, recuperación de contexto largo y tareas donde los tokens anteriores exactos importan.

Tampoco confundas la cuantización del caché KV con la decodificación especulativa. DFlash y DDTree, a menudo abreviados informalmente como DTree, atacan la latencia de decode redactando tokens futuros y verificándolos. Pueden mejorar la velocidad, pero no borran la factura de memoria del caché KV.

Por eso un modelo puede caber con un prompt vacío pero fallar cuando cargas un documento largo. Los pesos caben. La memoria de trabajo no.

Prefill y Decode

La inferencia de LLM tiene dos regímenes de rendimiento diferentes: prefill y decode.

Prefill procesa el prompt que le diste al modelo. Si pegas un documento de 20,000 tokens, el modelo debe procesar esos 20,000 tokens antes de poder producir el primer token de respuesta. Prefill es relativamente paralelizable, por lo que las GPUs pueden manejarlo eficientemente, pero aún puede ser costoso.

El tiempo que esperas a que aparezca el primer token suele ser el tiempo de prefill.

Decode genera nuevos tokens uno a la vez. Cada token generado depende de la secuencia hasta ahora, por lo que decode es mucho más secuencial. Aquí es donde viene el efecto de escritura en streaming, y suele ser la fase que determina si un modelo se siente rápido o lento.

Los prompts largos castigan el prefill. Las respuestas largas castigan el decode. Las conversaciones largas castigan ambos porque el caché KV crece.

En una sesión de chat, cada turno se añade al caché. Si dejas que una conversación llegue a 16K tokens, estás pagando el costo de memoria de todos los 16K tokens en cada nuevo token generado. Por eso las interfaces de chat que mantienen un historial infinito eventualmente se ralentizan o fallan.

Decodificación

Después de que el modelo produce logits, aún no ha escrito nada. Solo ha puntuado cada posible siguiente token. La decodificación es la política que convierte esas puntuaciones en un token real, añade ese token al contexto y repite el bucle.

El runtime, o motor de inferencia, puede elegir tokens de varias maneras. Puede elegir el token de mayor probabilidad cada vez. Puede muestrear de un conjunto restringido de tokens probables. Puede penalizar la repetición. Puede detenerse en un delimitador. Puede usar una semilla fija para que el mismo prompt se comporte de manera reproducible.

Estas elecciones no cambian los pesos del modelo, pero cambian la voz, determinismo, creatividad, perfil de riesgo y tendencia a repetirse del modelo.

Los controles importantes responden a tres preguntas prácticas:

Aleatoriedad: ¿Cuánta variación se permite?
Alcance de cola: ¿Hasta dónde puede llegar el muestreador en tokens de baja probabilidad?
Límites: ¿Qué evita bucles, divagaciones, rupturas de esquema o salidas descontroladas?

Para trabajo preciso, comienza estrecho: temperatura baja, límites de tokens máximos cortos, secuencias de parada explícitas y decodificación restringida cuando la salida debe coincidir con JSON o un esquema. Para trabajo creativo, dale más espacio al muestreador con temperatura más alta, top-p y múltiples candidatos clasificados después. Para programación, mantén la primera pasada conservadora, luego muestrea alternativas solo cuando estés explorando intencionalmente.

La decodificación greedy no siempre es más precisa. A menudo es frágil. Un decodificador greedy puede atascarse en bucles o producir respuestas genéricas porque nunca explora alternativas. Para evaluaciones, usa configuraciones deterministas. Para ideación, deja que el modelo respire.

Lo Que Contiene un Paquete de Modelo

Un LLM local ejecutable es más que un gran archivo de pesos. Un paquete de modelo generalmente incluye:

Arquitectura/config: número de capas, tamaño oculto, tipo de atención, configuraciones de RoPE, tamaño del vocabulario, tokens especiales y longitud de contexto.
Pesos: los parámetros aprendidos, a menudo almacenados como safetensors, GGUF, GPTQ, AWQ, EXL2 u otro formato específico del runtime.
Tokenizador: las reglas que convierten texto en IDs de token y los IDs de token de vuelta a texto.
Plantilla de chat: el marcado exacto para mensajes de sistema, usuario, asistente, herramienta y razonamiento.
Configuración de generación: valores predeterminados para temperatura, top-p, tokens de parada, penalizaciones de repetición y tokens máximos.
Licencia y tarjeta del modelo: las instrucciones legales y operativas sobre cómo se puede usar el modelo.

Los pesos son el archivo más grande, pero no son todo el modelo. Si el tokenizador, la configuración o la plantilla de chat son incorrectos, los mismos pesos pueden sentirse rotos.

La sección del paquete te dice qué tiene que viajar junto. La siguiente sección explica por qué la plantilla de chat es la parte que la gente más a menudo rompe.

Plantillas de Chat

Un modelo de chat fue entrenado con un formato de conversación específico. Por ejemplo, puede esperar algo como:

<|system|> Eres un asistente útil. <|user|> Explica el caché KV. <|assistant|>

Otro modelo puede esperar:

[BOS] [INST] Explica el caché KV. [/INST]

Otro puede usar marcadores de estilo ChatML. Otro puede requerir tokens de razonamiento especiales. Otro puede necesitar envolturas XML o JSON para llamadas a herramientas.

Usar el formato incorrecto puede causar galimatías, confusión de roles, ignorar el prompt del sistema, repetición de prompts, rarezas en rechazos, llamadas a herramientas rotas, malos resultados de benchmarks y conclusiones de que el modelo es tonto cuando la plantilla es el verdadero error.

Mejores prácticas:

Usa apply_chat_template del tokenizador cuando uses Transformers.
Usa plantillas específicas del modelo en frontends respaldados por Harbor, llama.cpp, LM Studio, vLLM o SGLang.
Verifica si el modelo es base, instruct, chat, razonamiento o ajustado para herramientas.
Asegúrate de que los tokens BOS/EOS sean correctos.
Mantén los prompts del sistema cortos a menos que necesiten ser largos.
Para uso de herramientas, sigue el esquema exacto esperado por el modelo/runtime.

Si estás construyendo una aplicación que permite a los usuarios cambiar de modelo, también necesitas cambiar las plantillas. Codificar un formato de plantilla y luego cargar un modelo que espera otro es una fuente común de malas evaluaciones de modelos locales.

Trata la plantilla como un contrato de API. Si te equivocas, no estás realmente probando el modelo que crees que estás probando.

Tipos de Modelo

No todos los LLMs están ajustados para el mismo comportamiento.

Para la mayoría de los usuarios, el punto de partida predeterminado debería ser un modelo reciente instruct/chat-ajustado en un tamaño que quepa cómodamente en la memoria.

No comiences con un modelo base a menos que sepas por qué. Los modelos base completan tu prompt en lugar de responderlo. Son útiles para investigadores, ajustadores finos y personas que construyen pipelines personalizados. Son frustrantes para todos los demás.

Si le preguntas a un modelo base "¿Cuál es la capital de Francia?", podría continuar con "¿y cuál es la población de París?" en lugar de responder "París".

La división práctica es simple:

Modelo base: Bueno para investigación de preentrenamiento, fine-tuning y pipelines personalizados.
Modelo instruct: Bueno para seguir instrucciones directas.
Modelo chat: Bueno para diálogo de múltiples turnos con formato de roles.
Modelo de razonamiento: Bueno cuando la tarea se beneficia de tokens de pensamiento adicionales y verificación.
Modelo ajustado para herramientas: Bueno cuando importan las llamadas estructuradas, JSON o el uso de funciones.

Lo Que Realmente Significa Local

Un LLM local es un modelo cuyos pesos y runtime de inferencia están bajo tu control. Tú decides qué modelo se ejecuta, cómo se ejecuta, qué datos ve y qué sucede con las salidas.

Esa libertad viene con trabajo. Ahora eres el equipo de operaciones. Tú manejas las descargas, actualizaciones, compatibilidad, límites de memoria y seguridad. Cuando algo se rompe, no hay un ticket de soporte que presentar. Solo estás tú, los registros y la documentación.

Local puede significar:

Un modelo de 2B parámetros ejecutándose en un teléfono.
Un modelo de 7B a 14B ejecutándose en una GPU de consumo.
Un modelo de 30B a 70B ejecutándose en una estación de trabajo de gama alta.
Un modelo MoE disperso ejecutándose en una o más GPUs de centro de datos.
Un despliegue privado usando vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio o una pila PyTorch personalizada.

El punto clave: local no significa automáticamente offline, privado, seguro, barato o de código abierto. Solo significa que estás ejecutando el modelo tú mismo. Una aplicación local aún puede hacer llamadas a casa. Un modelo puede ser de pesos abiertos pero no de código abierto. Un modelo puede ser local pero inseguro de cargar. Un modelo cuantizado puede caber en memoria pero responder mal.

La compensación vale la pena cuando necesitas privacidad, baja latencia, comportamiento personalizado, operación sin conexión o control de costos a escala. No vale la pena cuando necesitas la mejor calidad de modelo absoluta y no tienes el hardware para igualarla. En ese caso, una API alojada es la herramienta correcta.

Los LLMs locales son prácticos cuando entiendes una ecuación:

Éxito de LLM local = ajuste del modelo + formato de prompt correcto + buen runtime + evaluaciones realistas.

Todo lo demás son detalles. Los detalles importan.

Cuantización

La cuantización almacena los pesos en menor precisión para reducir la memoria y, a veces, mejorar el rendimiento.

La regla general de 2026 para usuarios locales:

FP16/BF16: Mejor calidad cuando la memoria es abundante. Úsalo como línea base para evaluación.
Q8 / INT8: Casi sin pérdidas para muchas tareas, pero aún grande. Bueno cuando tienes VRAM y quieres una pérdida mínima de calidad.
Q6 / Q5: Excelente calidad con ahorros moderados. Este es un punto medio sólido.
Q4: El punto óptimo de consumo predeterminado para muchos flujos de trabajo de chat y documentos.
Q3 / Q2: Solo cuando debes ajustar un modelo más grande. Las matemáticas, el código, la salida estructurada y el uso de herramientas se degradan primero.

La cuantización de pesos no es lo mismo que la cuantización del caché KV. La cuantización de pesos reduce el tamaño del modelo. La cuantización del caché KV reduce la memoria de contexto activa.

Para el caché KV, trata FP16/BF16 como la línea base limpia y FP8/INT8 como el piso de compresión local práctico. Por debajo de 8 bits es intensivo en investigación y sensible a la carga de trabajo. Úsalo solo después de medir la calidad en tus prompts reales.

El fracaso de la cuantización se muestra primero en matemáticas, razonamiento de múltiples pasos, corrección de código, fiabilidad en el uso de herramientas, adherencia a JSON/esquemas, seguimiento de instrucciones sutiles y recuperación de contexto largo.

Un modelo más pequeño con mayor precisión puede vencer a un modelo más grande aplastado en muy pocos bits. No adores el número de parámetros. Un modelo de 7B en Q6 puede vencer a un modelo de 13B en Q2 en tareas de razonamiento mientras usa menos memoria y se ejecuta más rápido.

Formatos de Archivo y Seguridad de Carga

safetensors es un formato de serialización de tensores seguro diseñado para almacenar tensores sin el comportamiento de pickle de Python. Usa safetensors cuando sea posible, especialmente para modelos de PyTorch/Transformers.

Evita archivos .bin aleatorios de fuentes no confiables. La carga basada en pickle de PyTorch puede ejecutar código arbitrario durante la deserialización. Regla número uno de seguridad de IA local: no dejes que el archivo de modelo de un desconocido se convierta en la ejecución de código de un desconocido.

GGUF es el formato de modelo binario del ecosistema llama.cpp. Usa GGUF cuando quieras llama.cpp, inferencia en CPU, inferencia en Apple Silicon, servidores locales simples, modelos cuantizados portátiles o herramientas de escritorio como LM Studio.

ONNX es útil para despliegue estandarizado y aceleración específica de hardware, especialmente fuera de la pila habitual de PyTorch. Si estás implementando en NPUs de Intel, dispositivos ARM o aceleradores personalizados, ONUX suele ser el camino de menor resistencia.

TensorRT-LLM es la ruta de inferencia de alto rendimiento de NVIDIA para despliegues de GPU en producción. Es potente, pero más complejo que llama.cpp o Harbor. Normalmente conviertes un checkpoint a motores TensorRT, lo que lleva tiempo y memoria de GPU, pero produce un excelente rendimiento una vez construido.

Los formatos EXL2 / GPTQ / AWQ son comunes en comunidades de inferencia local centradas en GPU, especialmente para comprimir modelos más grandes en una sola GPU.

La elección del formato de archivo no es cosmética. Determina qué runtimes pueden cargar el modelo, qué cuantización puedes usar y qué tan rápido se ejecuta.

Runtimes y Modos de Servicio

Un runtime es el software que carga el modelo y realiza la inferencia. En 2026, el ecosistema de runtime para LLMs locales es maduro, útil y fragmentado.

Para una sola persona experimentando localmente, comienza con Harbor, LM Studio o llama.cpp. Harbor es la mejor opción cuando quieres una pila local completa con frontends, backends y servicios de soporte conectados. LM Studio es la ruta de escritorio más fácil. llama.cpp es el caballo de batalla portátil de bajo nivel.

Para un equipo o servicio privado, mira vLLM o SGLang. Para el máximo rendimiento de producción en NVIDIA, investiga TensorRT-LLM. Para despliegue en navegador o móvil, mira MLC o WebLLM.

La elección del runtime a menudo te bloquea en un ecosistema de formato. llama.cpp significa GGUF. vLLM y SGLang generalmente significan safetensors o checkpoints de Hugging Face. TensorRT-LLM significa ONNX o motores optimizados. Elige el runtime primero, luego busca modelos en el formato correcto.

Hay tres modos prácticos de servicio.

Local para un solo usuario significa una aplicación de escritorio, pila CLI o servidor de línea de comandos para una persona. Harbor, LM Studio, servidor llama.cpp, ExLlama/TabbyAPI y scripts pequeños de Transformers encajan aquí. El objetivo es iteración rápida: comparar comportamiento, velocidad, uso de memoria y formatos de prompt sin construir una plataforma de operaciones.

API de equipo o privada significa un endpoint compatible con OpenAI en una estación de trabajo o servidor. vLLM, SGLang, TensorRT-LLM y servidor llama.cpp aparecen aquí dependiendo del tamaño del modelo y las necesidades de rendimiento. Una vez que varias personas o trabajos comparten un modelo, necesitas monitoreo, gestión de prompts/versiones, enrutamiento y mediciones de latencia realistas.

El servicio de producción es un trabajo diferente. Ahora la conversación incluye procesamiento por lotes continuo, almacenamiento en caché de prefijos, decodificación especulativa, atención paginada, paralelismo de tensores, paralelismo de tuberías, servicio cuantizado, salidas estructuradas, balanceo de carga, utilización de GPU, percentiles de latencia, almacenamiento en caché de indicaciones, control de admisión, registro, conmutación por error, privacidad y controles de costos.

A escala de producción, ¿puedo cargar el modelo? es la pregunta fácil. La pregunta difícil es ¿puedo servirlo de forma confiable bajo tráfico real?

Cálculos de VRAM para modelos locales

Hay tres consumidores principales de memoria:

Pesos del modelo
Caché KV
Sobrecarga del tiempo de ejecución

La fórmula aproximada de memoria para pesos es:

memoria_pesos ~= parámetros x bytes_por_parámetro

Aproximaciones útiles:

FP16/BF16: Alrededor de 2 bytes por parámetro.
INT8/Q8: Alrededor de 1 byte por parámetro.
Q4: Alrededor de 0.5 bytes por parámetro, más la sobrecarga del formato.

Luego agrega:

Sobrecarga del tiempo de ejecución: Búferes del framework, sobrecarga de CUDA, fragmentación de memoria y tensores temporales.
Caché KV: Crece con cada token en el contexto activo.
Memoria de lote/concurrencia: Cada solicitud concurrente necesita su propio caché.
Memoria del codificador de visión: Las imágenes también se convierten en tokens.
Memoria de decodificación especulativa: Los modelos borrador, las cabezas borrador o las estructuras de verificación adicionales no son gratuitas.
Memoria de adaptadores: Los adaptadores LoRA son pequeños, pero siguen siendo reales.

Los modelos MoE añaden otra complejidad. Un modelo puede activar solo una fracción de sus parámetros por token, pero los expertos inactivos generalmente aún deben residir en algún lugar de la memoria. Los parámetros activos afectan el costo computacional. Los parámetros totales aún afectan la carga y la planificación de capacidad.

Una estimación realista se ve así:

memoria_total = pesos_cuantizados + caché_KV_para_contexto + sobrecarga_tiempo_ejecución + sobrecarga_lote_concurrencia + margen_seguridad

Aquí está la trampa: Un modelo de 13B en Q4 puede caber fácilmente con contexto de 8K, luego fallar con 32K porque el caché KV se cuadruplicó. Los pesos no cambiaron. El contexto sí.

Deja un 10 a 20 por ciento de margen. Ejecutar al 99 por ciento de utilización de VRAM es estar pidiendo errores de memoria insuficiente y fallos de fragmentación.

Niveles de hardware en la práctica

Estas son reglas generales prácticas para 2026, asumiendo inferencia cuantizada y longitudes de contexto razonables. Los resultados exactos dependen del tiempo de ejecución, la cuantización, la arquitectura del modelo, el tipo de atención, la longitud del contexto y la sobrecarga del sistema operativo/controlador.

Para la mayoría de los usuarios locales serios en 2026, 16 GB es el nivel mínimo cómodo de GPU, 24 GB es el mejor nivel de valor para entusiastas y 48 GB+ es donde se abre el mundo local más potente.

El rendimiento depende del ancho de banda de la memoria, los FLOPs de la GPU, la capacidad de VRAM, el tamaño del caché KV, la implementación de la atención, la cuantización, el tamaño del lote, la longitud de la indicación, la longitud generada y la madurez del tiempo de ejecución.

La decodología a menudo está limitada por el ancho de banda de la memoria: La GPU transmite los pesos repetidamente mientras realiza relativamente poco cómputo por byte. La precarga tiene más límite computacional porque puede procesar la indicación en paralelo. Es por eso que dos tarjetas con la misma capacidad de VRAM pueden tener velocidades de token muy diferentes si una tiene un ancho de banda de memoria mucho mayor.

La configuración local más dolorosa es aquella donde el modelo casi cabe y derrama capas a la CPU. Puede funcionar técnicamente, pero la velocidad de token puede colapsar. La descarga a la CPU es aceptable para experimentación. No es una estrategia de rendimiento.

Elige un modelo que quepa

La pregunta práctica no es ¿cuál es el mejor modelo? Es ¿cuál es el modelo más pequeño que gana tu carga de trabajo real en tu hardware?

Comienza con un modelo instruct/chat reciente que quepa cómodamente con la longitud de contexto que realmente necesitas. Si tienes 8 GB a 12 GB de VRAM o memoria unificada, comienza con algo pequeño. Si tienes 16 GB a 24 GB, prueba primero modelos de clase 7B a 14B. Si tienes 48 GB o más, los modelos densos más grandes y los modelos MoE se vuelven realistas.

Usa esta verificación de memoria antes de enamorarte de un punto de control:

pesos + caché KV + sobrecarga de tiempo de ejecución <= 80 a 90 por ciento de la memoria disponible

Luego ejecuta las mismas 20 a 50 indicaciones entre los candidatos. Incluye tus tareas reales: Ediciones de código, preguntas y respuestas sobre documentos, salida JSON, resúmenes, llamadas a herramientas, contexto largo, o lo que realmente necesites. Mide la calidad de la respuesta, la latencia, el uso de memoria, la confiabilidad de la plantilla y los modos de fallo.

Una elección práctica de modelo generalmente se reduce a cinco verificaciones:

Adecuación a la tarea: Chat, código, documentos, agentes, multimodal, edge o ajuste fino.
Adecuación de memoria: Pesos, caché KV, sobrecarga de tiempo de ejecución y margen de seguridad.
Adecuación de interfaz: Tokenizador, plantilla de chat, tokens de parada, esquema de herramientas y modo de razonamiento.
Adecuación del tiempo de ejecución: ¿Tu tiempo de ejecución soporta bien esta arquitectura, cuantización, longitud de contexto y modo de servicio?
Adecuación de licencia: ¿Puedes usarlo realmente donde planeas usarlo?

Los rankings son útiles para descubrimiento. No son un sustituto de tus propias evaluaciones. Tu carga de trabajo es el punto de referencia que importa.

Para un asistente local simple, elige un modelo instruct reciente de 7B a 14B, cuantización Q4/Q5, la plantilla de chat correcta, contexto de 8K a 32K, y Harbor, LM Studio o llama.cpp. Prioriza la capacidad de respuesta sobre el tamaño gigante.

Para un asistente de código local, elige un modelo con capacidad de código de 14B a 32B si tienes suficiente VRAM. Usa temperatura baja, recuperación de repositorio, ejecución de pruebas y un flujo de trabajo basado en parches. Un modelo de código sin herramientas es medio producto.

Para un asistente de documentos privado, elige un modelo instruct fuerte, un modelo de embeddings local, un reranker, un pipeline RAG, aplicación de citas y contexto de moderado a largo. No pegues un PDF de 200 páginas y esperes.

Para una configuración de razonamiento, elige un modelo ajustado para razonar, presupuesta tokens extra, usa temperatura baja a media, agrega verificación y usa herramientas para matemáticas, código o búsqueda. Los modelos de razonamiento gastan más tokens. Presupuesta en consecuencia.

Para una configuración de bajos recursos, elige un modelo de 1B a 4B, Q4/Q5, indicaciones cortas, tareas estructuradas, recuperación o herramientas, y un esquema de salida estricto. Los modelos pequeños se vuelven útiles cuando la tarea está limitada.

¿Qué controla la velocidad?

Los tokens por segundo no están controlados por una sola cosa. Es el resultado del tamaño del modelo, el ancho de banda de la memoria, el cómputo, los kernels de atención, la longitud del contexto, la cuantización, el procesamiento por lotes y la calidad del tiempo de ejecución.

Las principales palancas son:

Ancho de banda de memoria: La decodología a menudo transmite los pesos del modelo repetidamente, por lo que el ancho de banda domina la velocidad de token para un solo usuario.
FLOPs de GPU: La precarga y los lotes grandes usan más cómputo paralelo, por lo que los FLOPs importan más allí.
Capacidad de VRAM: Si el modelo o el caché KV se derrama a la CPU, el rendimiento puede colapsar.
Implementación de atención: FlashAttention, SDPA, atención paginada y kernels específicos del tiempo de ejecución cambian tanto la velocidad como el comportamiento de la memoria.
Cuantización: Los pesos más pequeños reducen el movimiento de memoria, pero la cuantización agresiva puede perjudicar la calidad y, a veces, agregar sobrecarga de descuantización.
Tamaño de lote y concurrencia: El procesamiento por lotes mejora el rendimiento, pero cada secuencia activa necesita caché KV.
Longitud de la indicación: Las indicaciones largas aumentan el tiempo de precarga.
Longitud generada: Las respuestas largas exponen la velocidad de decodificación.
Decodificación especulativa: Los métodos estilo EAGLE, MTP, DFlash y DDTree pueden verificar más de un token redactado por pasada de destino cuando son compatibles.

La configuración dolorosa es la configuración de "casi cabe". Un modelo que derrama capas o caché a la CPU puede funcionar técnicamente, pero la velocidad de token puede caer de utilizable a miserable.

Evalúa el tiempo de ejecución exacto, la cuantización, la longitud de contexto, la forma de la indicación y la carga de trabajo que planeas usar. Un número de ranking BF16 no te dice cómo se sentirá tu pila local Q4.

Contexto largo

El contexto largo suena mágico: 128K, 256K o incluso 1M de tokens en una sola indicación. Es útil, pero tiene costos reales.

Más contexto significa más memoria de caché KV, procesamiento de indicaciones más lento, más trabajo de atención, evaluación más difícil y más formas en que el texto irrelevante distraiga al modelo. La calidad también puede degradarse con la distancia. Un modelo puede manejar bien el final de un documento largo mientras pasa por alto detalles críticos enterrados cerca del principio.

Usa el contexto largo para análisis de documentos completos, fragmentos de base de código, revisión legal o técnica, resumen de transcripciones, razonamiento multiarchivo y respaldo RAG cuando la recuperación no encuentre contexto.

No trates el contexto largo como un reemplazo de la recuperación. Es un complemento. Usa RAG para corpus grandes y contexto largo para la evidencia final seleccionada.

Los hábitos prácticos ayudan:

Coloca las instrucciones críticas cerca del principio y cerca del final.
Usa encabezados de sección y delimitadores.
Pide citas vinculadas a fragmentos de origen.
Comprime el historial irrelevante.
Usa memoria de resúmenes en lugar de historial de chat infinito.

Piensa en el contexto largo como atención costosa, no como un cuaderno gratuito.

Multimodalidad

Los modelos locales multimodales aceptan imágenes, y a veces audio o video, además de texto. Los ecosistemas modernos de peso abierto incluyen cada vez más estos modelos.

El costo oculto es que la entrada no textual también se convierte en tokens. Los codificadores de visión agregan memoria. Los parches de imagen consumen contexto. El audio y el video pueden explotar el presupuesto de entrada. Las plantillas multimodales también son más fáciles de equivocar que las plantillas solo de texto.

Una sola imagen de alta resolución puede consumir miles de tokens en la ventana de contexto. Si estás ejecutando un modelo multimodal localmente, cuenta los tokens de imagen de la misma manera que cuentas los tokens de texto. Provienen del mismo presupuesto.

Los VLM pequeños pueden alucinar detalles visuales. La fiabilidad del OCR varía. Los gráficos y las tablas siguen siendo difíciles. Para flujos de trabajo serios de documentos o imágenes, evalúa con muestras reales. No confíes en una demostración de una foto simple para probar la calidad de extracción de facturas.

El panorama de modelos locales en 2026

El panorama de modelos cambia rápido. Al 21 de mayo de 2026, los usuarios de LLM locales deberían pensar en términos de familias y ecosistemas, no en un solo mejor modelo.

Qwen 3.5 / Qwen 3.6 es una familia importante de peso abierto porque cubre toda la pila: Modelos pequeños para portátiles, modelos densos de tamaño mediano para estaciones de trabajo, modelos MoE para servicio multi-GPU, variantes FP8, contexto largo, trabajo multilingüe, codificación, herramientas y flujos de trabajo agentivos. La conclusión práctica es simple: Qwen es una familia predeterminada sólida cuando quieres un ecosistema que abarque desde experimentos en portátiles hasta servicio local serio.

Gemma 4 importa porque Google DeepMind está impulsando la familia hacia una implementación local útil: Modelos eficientes para edge, opciones densas y MoE más grandes, multimodalidad, contexto largo en los modelos más grandes, amplio soporte de idiomas, comportamiento de código/agente más fuerte y licencia Apache 2.0. Esa combinación hace que valga la pena probarla cuando el uso comercial y la implementación en el dispositivo importan.

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax y Mistral también son familias centrales a seguir. Kimi es relevante para codificación de horizonte largo, razonamiento multimodal, uso de herramientas y flujos de trabajo de agentes. GLM es importante para agentes de codificación, tareas de horizonte largo, sistemas MoE y lanzamientos de modelos orientados a la implementación. DeepSeek sigue siendo influyente debido a los grandes sistemas MoE, la atención latente de múltiples cabezas, DeepSeekMoE, las rutas de servicio FP8, la atención dispersa y el autoalojamiento de alto rendimiento. MiniMax vale la pena seguir por cargas de trabajo de agentes prácticas y modelos MoE eficientes en inferencia. Mistral todavía importa porque su línea cubre casos de uso generalistas, de codificación, de razonamiento, multimodales y especializados con un fuerte soporte de implementación.

Nemotron 3 es la familia de modelos abiertos de NVIDIA para sistemas de agentes de grado de producción en hardware NVIDIA. La familia incluye tamaños Nano, Super y Ultra, utiliza diseños MoE híbridos Mamba-Transformer y está estrechamente vinculada a TensorRT-LLM, NIM, Dynamo, las rutas Blackwell NVFP4/FP8 y la implementación de agentes empresariales. Trátala menos como una familia casual de chat de escritorio y más como una señal de hacia dónde NVIDIA quiere que vayan las pilas de servicio de peso abierto.

La IA de peso abierto ya no es solo Llama contra todo lo demás. Estás eligiendo un ecosistema: Pesos, licencia, tokenizador, plantilla, cuantizaciones, soporte de tiempo de ejecución, ruta de servicio, herramientas comunitarias y modos de fallo.

El modelo denso Qwen 27B

Qwen 3.5 / 3.6 27B (Denso) es una de las opciones de peso público más prácticas para usuarios locales que se preocupan por la codificación, el trabajo multilingüe, el uso de herramientas, los modos de pensamiento/no pensamiento y el contexto largo. Las fichas del modelo Qwen 3.5 27B y Qwen 3.6 27B describen rutas de servicio compatibles con OpenAI, valores predeterminados del modo de pensamiento, uso de herramientas y longitudes de contexto de hasta 262,144 tokens, con extensión de contexto más largo a través de YaRN en frameworks compatibles.

Qwen es una opción predeterminada sólida para una configuración de 2x RTX 3090 cuando el tiempo de ejecución está configurado correctamente para codificación, agentes o cobertura multilingüe.

Investigación en inferencia

La frontera de 2026 no es solo la calidad del modelo. También es la eficiencia de la inferencia. PagedAttention ataca el desperdicio de memoria del caché KV en el servicio. El caché KV FP8 es ahora una característica práctica de tiempo de ejecución en sistemas como vLLM. DFlash y DDTree exploran la decodificación especulativa con modelos de difusión de bloque borrador y árboles borrador. NVFP4 también vale la pena seguir en hardware NVIDIA porque cambia la conversación práctica de implementación para pilas compatibles.

Parte de esto está listo para producción. Parte sigue siendo investigación. Parte solo importa si tu tiempo de ejecución lo soporta limpiamente. No trates las aceleraciones de los artículos como una casilla de verificación en una aplicación de escritorio.

Modos de fallo y soluciones

La mayoría de los fallos de los LLM locales no son misteriosos. Generalmente provienen de la memoria, el formato, el soporte del tiempo de ejecución, la configuración de decodificación o la calidad de la recuperación.

Memoria insuficiente: Los pesos, el caché KV, la sobrecarga del tiempo de ejecución o el tamaño del lote no caben. Usa un modelo más pequeño, reduce el contexto, disminuye el lote/concurrencia, elige una mejor cuantización o deja más margen.

Sin sentido o confusión de roles: La plantilla de chat, el tokenizador, el token BOS/EOS, el interruptor de modo de razonamiento o el esquema de herramientas son incorrectos. Verifica la ficha del modelo y la plantilla del tiempo de ejecución antes de culpar a la calidad del modelo.

Primer token lento: La precarga es costosa. Acorta la indicación, usa almacenamiento en caché de prefijos, mejora la recuperación, reduce el contexto o usa un tiempo de ejecución más rápido.

Transmisión lenta: La decodificación es el cuello de botella. Verifica el ancho de banda de la memoria, la cuantización, el derrame a CPU, el backend de atención, el soporte de decodificación especulativa y si el modelo es simplemente demasiado grande para el hardware.

Malas respuestas sobre documentos: Probablemente falló la recuperación. Inspecciona el texto analizado, los límites de los fragmentos, los metadatos, la recuperación top-k, el reranking y la fundamentación de citas.

Malas llamadas JSON o a herramientas: Usa temperatura más baja, decodificación restringida, esquemas más estrictos, mejores ejemplos y un modelo ajustado para el uso de herramientas.

Bucles repetitivos: Reduce la temperatura o el top-p, agrega penalizaciones de repetición, verifica los tokens de parada y asegúrate de que la plantilla no esté haciendo que el modelo vea su propia respuesta como una nueva indicación.

Comienza con las comprobaciones aburridas. Arreglan más problemas que cambiar de modelo.

Cómo hacer crecer la pila

Principiante: La configuración útil más fácil

Usa Harbor o LM Studio, un modelo instruct reciente de 4B a 9B, cuantización Q4, contexto de 8K a 32K y una interfaz de chat integrada. Descarga dos o tres modelos en la misma clase de tamaño y compáralos con las mismas indicaciones.

Objetivo: Aprender a hacer indicaciones, comparar modelos, entender la velocidad y la memoria, y evitar código personalizado al principio.

Intermedio: Configuración para desarrolladores

Usa llama.cpp o Transformers, GGUF o safetensors, un servidor local compatible con OpenAI, un pipeline RAG simple y un pequeño conjunto de evaluación. Llama a tu servidor local desde una aplicación o script real en lugar de solo usar una interfaz de chat.

Objetivo: Crear aplicaciones locales, probar la recuperación, medir la calidad y servir desde localhost.

Avanzado: Configuración de servicio privado

Usa vLLM o SGLang, una o más GPU, una API compatible con OpenAI, monitoreo, gestión de indicaciones/versiones, un conjunto de evaluación, RAG con reranking y sandboxing de herramientas.

Objetivo: Servir a usuarios reales o flujos de trabajo internos, optimizar el rendimiento y la latencia, y mantener la seguridad y la observabilidad.

Experto: Optimización personalizada

Usa TensorRT-LLM, kernels personalizados, tiempos de ejecución especializados, experimentos de cuantización, decodificación especulativa, paralelismo multi-GPU, ajuste fino, destilación y evaluaciones de producción.

Objetivo: Intercambiar tiempo de ingeniería por eficiencia de inferencia, menor costo y mayor calidad a escala.

La privacidad no es automática

Los LLM locales mejoran la privacidad porque las indicaciones y las salidas pueden permanecer en tu hardware. Pero local no significa automáticamente seguro.

Las amenazas incluyen archivos de modelo maliciosos, carga de pesos basada en pickle, trust_remote_code no confiable, inyección de indicaciones en documentos recuperados, abuso de llamadas a herramientas, filtración de secretos a través de registros, telemetría de aplicaciones de escritorio, extensiones de navegador o complementos, alucinaciones del modelo en entornos de alto riesgo, violaciones de licencia y contaminación de datos durante el ajuste fino.

Una línea de base de seguridad de IA local viable tiene cuatro hábitos:

Carga cuidadosa: Prefiere safetensors o GGUF de fuentes reputadas, evita archivos .bin no confiables y no habilites trust_remote_code a la ligera.
Ejecución con límites: Usa un usuario sin privilegios, contenedores o sandboxes para agentes, y acceso a red deshabilitado cuando la privacidad fuera de línea importe.
Protege los secretos: Mantén las credenciales fuera de las indicaciones y los índices RAG, revisa la configuración de telemetría de las aplicaciones de escritorio y valida las llamadas a herramientas antes de ejecutarlas.
Versiona lo que importa: Rastrea las versiones del modelo, la indicación, el adaptador, el tiempo de ejecución y la cuantización, y registra lo suficiente para depurar sin crear un desastre de privacidad.

La seguridad de la IA local es principalmente disciplina operativa aburrida. Así es también como evitas descargar un punto de control aleatorio, ejecutarlo como root y convertir la IA local en un compromiso local.

Los puntos de referencia que importan

Evalúa la pila que realmente ejecutarás. La puntuación de un modelo en el ranking BF16 no es tu realidad local Q4.

Mide la calidad, la latencia, la memoria, la confiabilidad y la adecuación operativa:

Calidad: Corrección en tus tareas reales, no solo en puntos de referencia genéricos.
Latencia: Tiempo hasta el primer token, tokens de decodificación por segundo y tiempo de extremo a extremo.
Memoria: Memoria de pesos, crecimiento del caché KV, VRAM máxima y margen bajo carga.
Formato: Corrección de la plantilla de chat, éxito de JSON/esquema, confiabilidad de llamadas a herramientas y comportamiento de tokens de parada.
Recuperación: Fidelidad de las citas, fundamentación de respuestas, comportamiento ante evidencia faltante e impacto del reranker.
Operaciones: Tiempo de inicio, comportamiento de calentamiento, recuperación de fallos, registro, privacidad y seguimiento de versiones.

Crea un pequeño conjunto de evaluación con 30 a 100 indicaciones representativas. Incluye respuestas esperadas o criterios de puntuación, mediciones de latencia y memoria, categorías de fallo, verificaciones de fundamentación RAG específicas, comprobaciones de cumplimiento JSON si es relevante y revisión humana para tareas ambiguas.

Luego compara modelos. No dejes que un ranking elija tu pila local por ti.

Codificación con modelos locales

La codificación es uno de los mejores casos de uso de los LLM locales porque las indicaciones a menudo incluyen código privado, la latencia importa, la iteración es frecuente, los costos de API pueden crecer rápidamente y los modelos locales pueden integrarse con editores, shells, grep, ejecutores de pruebas y flujos de trabajo de parches.

La configuración de codificación local más potente no es un chatbot desnudo. Es un modelo instruct con capacidad de código conectado a contexto de repositorio específico, recuperación sobre la base de código, rutas de archivos, fragmentos relevantes, ejecución de pruebas y un bucle de parches.

Mantén la decodología determinista o con temperatura baja. Pide parches en lugar de consejos vagos. Ejecuta pruebas automáticamente. Mantén un pequeño conjunto de evaluación de errores y tareas reales para saber cuándo un modelo nuevo es realmente mejor.

No dejes que un modelo local reescriba una base de código grande sin revisión. Local no hace que un agente de codificación sea sabio. Solo hace que el contexto sea privado, el bucle más barato y la integración más fácil de controlar.

Los agentes locales necesitan barreras de seguridad

Un LLM local se vuelve mucho más útil cuando puede usar herramientas: Búsqueda de archivos, comandos de shell, automatización del navegador, bases de datos, ejecución de código, calendarios, sistemas de tickets, APIs internas, bases de datos vectoriales, automatización del hogar, robótica o dispositivos periféricos.

El uso de herramientas cambia el modelo de seguridad. Un chatbot que alucina es molesto. Un agente con acceso al sistema de archivos puede eliminar cosas. Un agente con acceso al navegador puede filtrar secretos. Un agente con acceso al shell puede dañar la máquina más rápido de lo que puedes leer los registros.

La seguridad de los agentes locales tiene cuatro capas. Delimita el agente estrechamente, dándole solo los directorios, APIs, acceso a la red y credenciales que realmente necesita. Restringe la ejecución con sandboxes, contenedores, usuarios con mínimos privilegios, confirmaciones para acciones destructivas y argumentos de herramientas validados por esquema. Trata las entradas como hostiles porque los documentos recuperados, páginas web, tickets y correos electrónicos pueden contener inyección de indicaciones. Mantén un registro de auditoría registrando las llamadas a herramientas, las versiones del modelo, las indicaciones y las aprobaciones sin volcar secretos en los registros.

Las salidas estructuradas ayudan, pero no son un límite de seguridad. Los esquemas JSON, la decodificación restringida y las firmas de funciones facilitan la validación de las llamadas a herramientas. No demuestran que el modelo entendió la solicitud, eligió la acción segura o evitó instrucciones inyectadas.

Para uso serio de herramientas, coloca las comprobaciones de política fuera del modelo.

RAG supera a las indicaciones gigantes

RAG significa Generación Aumentada por Recuperación. En lugar de meter toda la información en la indicación, recuperas fragmentos relevantes de una base de conocimiento y le das solo esos fragmentos al modelo.

Un buen sistema RAG local generalmente tiene ingesta de documentos, análisis, fragmentación, embeddings, un índice vectorial, recuperación, reranking, construcción de indicaciones, generación de respuestas, verificación de fundamentación y evaluación. Cada etapa es un punto de fallo.

Un análisis deficiente convierte las tablas en basura. Una mala fragmentación divide la respuesta a través de los límites. Una mala recuperación devuelve párrafos irrelevantes. Un mal reranking entierra la respuesta correcta en el puesto 20. Un buen modelo no puede responder de manera confiable a partir de evidencia que nunca recibió.

La mayoría de los sistemas RAG malos no son malos por el LLM. Son malos por la fragmentación, la recuperación, el reranking y la evaluación.

La estrategia de fragmentación es el asesino silencioso. Los fragmentos de tamaño fijo sin superposición pueden dividir oraciones y perder contexto. La fragmentación semántica o la fragmentación jerárquica con recuperación de documento principal a menudo funciona mejor, pero no hay una respuesta universal. Tienes que evaluar el tamaño del fragmento, la superposición y las reglas de división en tus documentos reales.

Un buen reranker puede rescatar una recuperación mediocre. Ningún reranker puede arreglar fragmentos que perdieron la respuesta durante la ingesta.

Documentos y trabajo de conocimiento

Para documentos privados, los LLM locales brillan: Resúmenes de transcripciones de reuniones, revisión de contratos, preguntas y respuestas sobre documentación técnica, síntesis de notas de investigación, redacción de correos electrónicos, búsqueda de políticas, asistentes de soporte interno y flujos de trabajo de cumplimiento se benefician de mantener el material fuente cerca de la máquina u organización que lo posee.

El flujo de trabajo es simple pero implacable. Analiza los documentos cuidadosamente, conserva los metadatos de página y sección, fragmenta semánticamente, usa embeddings y rerankers, pide citas, separa las respuestas de las fuentes del razonamiento general y evalúa la fidelidad de las citas.

No asumas que el modelo sabe lo que hay en tus documentos. Solo sabe lo que pones en la indicación o recuperas en el contexto.

Para transcripciones de reuniones, conserva las etiquetas de los oradores y las marcas de tiempo. Para revisión de contratos, fragmenta por cláusula o sección en lugar de por un recuento arbitrario de tokens. Para preguntas y respuestas sobre documentación técnica, incluye números de página o anclas de sección en los fragmentos recuperados para que el modelo pueda citar las fuentes con precisión.

Para el trabajo con documentos, tu analizador y recuperador importan tanto como el modelo.

Implementación en el edge

Los modelos pequeños son cada vez más útiles en teléfonos, portátiles, robots, puertas de enlace IoT, dispositivos de fábrica, vehículos, dispositivos médicos, equipos de campo sin conexión y aplicaciones de navegador. El edge no es solo una versión más pequeña de la estación de trabajo. Tiene un conjunto diferente de restricciones.

El despliegue en el edge está regido por limitaciones de memoria, bajo consumo, restricciones térmicas, conectividad intermitente, requisitos de privacidad, latencia en tiempo real, ventanas de contexto pequeñas y un comportamiento de respaldo predecible. En esos dispositivos, un modelo pequeño y confiable supera a uno grande y frágil.

Una configuración práctica para edge suele usar un modelo de 0.5B a 4B, cuantización agresiva de pesos, instrucciones mínimas, esquemas fijos, flujos asistidos por herramientas, embeddings locales, almacenamiento en caché y nada de historial de chat innecesario.

Cuando la conectividad falla, un modelo local que sigue funcionando es más valioso que un modelo más grande que se cae. El futuro de la IA local no son solo modelos gigantes para estaciones de trabajo. También son modelos pequeños que hacen trabajo útil cerca de los datos.

Un Manual de LLM Local

Úsalo como filtro final antes de confiar en un modelo local para trabajo real.

Elige y ajusta: Selecciona una familia de modelos adecuada a la tarea, lee la licencia, confirma los requisitos de hardware, elige un nivel de cuantización y estima el costo total de memoria. No te quedes solo en el tamaño de los pesos. Incluye la caché KV, la sobrecarga del runtime, el lote/concurrencia y un margen de seguridad.

Carga y formatea: Prefiere safetensors o GGUF de fuentes confiables, evita archivos basados en pickle no verificados, verifica el tokenizador y la plantilla de chat, establece la longitud del contexto intencionalmente y elige parámetros de decodificación para la tarea. Si la plantilla es incorrecta, la evaluación no es válida.

Evalúa y opera: Prueba con prompts representativos, mide el tiempo hasta el primer token y la velocidad de decodificación, monitorea el pico de memoria, evalúa la recuperación antes de agregar RAG, pon en un entorno aislado las herramientas antes de agregar agentes y ajusta el modelo solo después de que fallen métodos más simples.

Versiona todo lo que importa: Modelo, cuantización, runtime, prompt, plantilla de chat, adaptador, modelo de embeddings, reranker, conjunto de evaluación y perfil de hardware. Los sistemas locales solo son más fáciles de controlar cuando puedes reproducir lo que ejecutaste.

Fine-Tuning

El fine-tuning cambia el comportamiento del modelo entrenándolo con datos adicionales. Para los usuarios locales, los métodos más importantes son LoRA y QLoRA.

LoRA congela el modelo base y entrena pesos de adaptadores de bajo rango pequeños. Esto reduce los parámetros entrenables y te permite mantener múltiples adaptadores ligeros. QLoRA extiende esto ajustando el modelo a través de un modelo cuantizado a 4 bits congelado hacia adaptadores LoRA.

Haz fine-tuning cuando necesites un estilo de escritura consistente, un formato de salida específico para un dominio, comportamiento repetitivo de clasificación o extracción, confiabilidad en el formato de llamada a herramientas, una personalidad de asistente especializada, adaptación a un dominio que RAG no puede resolver o un mejor rendimiento de modelos pequeños en una tarea concreta.

No hagas fine-tuning primero. Prueba este orden: plantilla de chat correcta, mejores prompts, mejor modelo, mejor decodificación, RAG, reranking, ejemplos de pocos disparos y luego fine-tuning.

La mayoría de los problemas que parecen "el modelo no entiende mi dominio" son en realidad "mi prompt es vago", "mi plantilla es incorrecta" o "mi recuperación está fallando".

Un buen plan de fine-tuning incluye datos limpios, divisiones de entrenamiento/validación/prueba, evaluaciones de referencia, comportamiento objetivo claro, revisión de seguridad, verificaciones de sobreajuste, evaluaciones de regresión, versionado de adaptadores, revisión de licencia y un plan de reversión.

Peso Abierto No Significa Código Abierto

En 2026, la frase "modelo abierto" se usa a menudo de manera imprecisa. Debes distinguir entre peso abierto, código fuente disponible, código abierto y compatible con local.

Peso abierto generalmente significa que puedes descargar los pesos. No significa automáticamente que puedas usar el modelo comercialmente, modificarlo libremente, entrenar con sus salidas, implementarlo a cualquier escala o ignorar los requisitos de atribución.

Código fuente disponible significa que el código o los pesos son visibles. No significa necesariamente que la licencia sea de código abierto.

Modelo de IA de código abierto es una afirmación más sólida. La Definición de IA de Código Abierto de OSI trata un sistema de IA como algo que incluye la arquitectura, los parámetros/pesos, el código de inferencia y suficiente información y código de datos para derivar los parámetros. Eso es un estándar mucho más alto que "los pesos están en Hugging Face".

Algunas licencias parecen permisivas pero contienen restricciones: Sin uso competitivo, sin entrenamiento con las salidas, sin implementación por encima de cierta escala, exclusiones geográficas, requisitos de atribución, cláusulas de patentes u obligaciones similares a copyleft sobre derivados.

Regla: lee la tarjeta del modelo y la licencia antes de usar cualquier modelo comercialmente. Un modelo puede ser excelente, descargable y ejecutable localmente, pero aun así ser inadecuado para tus limitaciones legales o de implementación.

Glosario

Términos de Modelos y Ajuste

Parámetros Activos: En un modelo MoE, solo algunos parámetros se usan para un token dado. Un modelo puede tener cientos de miles de millones de parámetros totales pero muchos menos parámetros activos por token.
Adaptador: Un módulo entrenable pequeño añadido a un modelo base, a menudo a través de LoRA.
Modelo Base: Un modelo preentrenado no ajustado específicamente para chat o seguimiento de instrucciones.
Fine-Tuning: Entrenamiento adicional que cambia el comportamiento del modelo para un dominio o estilo de salida objetivo.
Modelo de Instrucciones: Un modelo ajustado para seguir instrucciones.
LoRA / QLoRA: Métodos de fine-tuning eficientes que usan adaptadores de bajo rango, con QLoRA entrenando a través de modelos base cuantizados.
MoE: Mezcla de Expertos. Una arquitectura dispersa donde solo subredes de expertos seleccionadas se activan por token.
Pesos / Parámetros: Los valores numéricos aprendidos dentro del modelo.

Mecánica de Inferencia

BOS / EOS: Tokens de inicio de secuencia y fin de secuencia.
Plantilla de Chat: El formato usado para representar mensajes de sistema, usuario, asistente y herramientas.
Ventana de Contexto: El número máximo de tokens que el modelo puede procesar a la vez.
Decodificar: La fase donde el modelo genera nuevos tokens uno por uno.
DFlash: Un enfoque de decodificación especulativa de 2026 que usa difusión de bloques para el borrador en paralelo.
DDTree / DTree: Un método de decodificación especulativa que construye un árbol de borradores a partir de distribuciones de difusión de bloques y lo verifica eficientemente.
GQA / MQA: Variantes de atención que reducen el tamaño de la caché KV y mejoran la eficiencia de inferencia.
Inferencia: Ejecutar el modelo para producir salidas.
Caché KV: Estados de atención clave/valor almacenados para tokens anteriores.
Prefill: La fase donde el modelo procesa el prompt de entrada antes de generar.
RoPE: Embeddings Posicionales Rotatorios, un método de codificación posicional común en LLMs modernos.
Decodificación Especulativa: Una técnica de velocidad donde un proponente más barato sugiere tokens y el modelo objetivo los verifica.
Tokenizador: El componente que convierte texto en IDs de token y viceversa.
Top-p / Top-k / Temperatura: Controles de muestreo para la generación de tokens.

Recuperación, Archivos y Servicio

AWQ: Cuantización de pesos consciente de la activación.
Modelo de Embeddings: Un modelo que convierte texto en vectores para búsqueda/recuperación.
Caché KV FP8: Un modo práctico de compresión de caché KV de 8 bits compatible en algunos runtimes.
GGUF: Un formato de archivo de modelo muy utilizado por llama.cpp.
PagedAttention: Una técnica de gestión de memoria de caché KV utilizada por el servicio estilo vLLM.
Cuantización: Reducir la precisión numérica para ahorrar memoria y mejorar la eficiencia.
RAG: Generación Aumentada por Recuperación. Recupera contexto externo relevante y proporciónalo al modelo.
Reranker: Un modelo que reordena los pasajes recuperados por relevancia.
Safetensors: Un formato de serialización de tensores más seguro que evita los riesgos de ejecución basados en pickle.

Palabras Finales

El ecosistema local de LLM incluye modelos compactos para edge, modelos robustos de 7B a 32B para consumidores, grandes sistemas MoE de peso abierto, modelos multimodales, modelos de contexto largo, modelos de razonamiento local, runtimes de inferencia maduros y stacks de servicio privado cada vez más capaces.

Pero los fundamentos no han cambiado: el modelo predice un token a la vez, los tokens no son palabras, los pesos no son el modelo completo, las plantillas de chat importan, la caché KV es la factura de memoria oculta, la cuantización es un compromiso, el contexto largo no es gratis, la calidad de RAG depende de la recuperación, el fine-tuning necesita evaluaciones y la privacidad local aún requiere disciplina de seguridad.

No necesitas mitología para ejecutar modelos locales correctamente. Necesitas saber qué cabe en la memoria, qué plantilla espera el modelo, cómo se comporta el runtime y si tus evaluaciones coinciden con el trabajo que te importa.

Los LLM locales son principalmente matemáticas de memoria más formato más evaluación. Domina eso, y el resto del stack se vuelve mucho más fácil de razonar.

Hasta la próxima.

-Ahmad