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

Empieza con el ciclo. El texto se convierte en tokens. Los tokens se mueven a través de un Transformer. La atención decide qué tokens anteriores son relevantes. El runtime mantiene una 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 piensan los modelos 1 token a la vez y cómo ejecutarlos localmente.

Una vez que ese ciclo se entiende, las decisiones sobre hardware y software se vuelven más fáciles de razonar. La VRAM, la cuantización, la longitud de contexto, las plantillas de chat, el decodificado, el RAG, los motores de servicio y la selección de modelos son consecuencias de la misma mecánica.

Empieza con el ciclo: Tokens de entrada, probabilidades de salida, un siguiente token a la vez. Los pesos le indican al modelo qué patrones aprendió. El contexto le dice lo que está viendo ahora. La caché KV es la memoria de trabajo que hace que el ciclo sea 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, primero, hacer que la mecánica de los LLMs locales sea intuitiva 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, prellenado, decodificado, controles de decodificado, paquetes de modelos, plantillas de chat, tipos de modelos, contexto largo, RAG, agentes, ajuste fino y modelos multimodales.

Después, pasa a la capa de implementación 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, resolución de problemas, puntos de referencia, rutas de configuración y casos de uso prácticos.

Ese orden importa. 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 decodificado 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 cómo implementar LLMs autoalojados / IA local:

Las dos primeras piezas explican la capacidad del hardware y las matemáticas del ancho de banda. 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 te remite a esas capas de implementación una vez que la mecánica esté clara.

Lo Que Un LLM Realmente Hace

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

Convierte tu texto en tokens.
Introduce esos tokens en el modelo.
Calcula puntuaciones para cada posible siguiente token.
Elige un token con una política de decodificado.
Agrega 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 escribe 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 next_token

Donde:

theta significa los pesos del modelo.
secuencia significa el prompt más los tokens generados hasta ahora.
Los logits son las puntuaciones brutas antes del softmax.
Las probabilidades son las puntuaciones normalizadas después del softmax.
El decodificado convierte esas probabilidades en un token seleccionado.

Esta es la razón por la que 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 la caché KV y continúa.

La percepción importa aquí. Un prellenado largo significa una pausa larga antes de que aparezca la primera palabra. Un decodificado lento significa que la respuesta se transmite lentamente. Quienes construyen sistemas locales a menudo se obsesionan con la velocidad de decodificado porque es lo que los usuarios sienten, pero el tiempo de prellenado 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", "nacion", "alización"
Un signo de puntuación
Una cadena con prefijo de espacio en blanco
Un respaldo a nivel de byte
Un marcador de control especial como <|user|>, <|assistant|>, , o

El tokenizador mapea el texto a IDs de token y los IDs de token de vuelta a texto. Las familias de tokenizadores comunes 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 embeddings y la proyección de salida. Esta es una de las razones por las 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 la caché KV.
Cuánta latencia pagas durante el procesamiento del prompt.
Si el texto multilingüe o con mucho código es eficiente.
Si el modelo ve correctamente los marcadores especiales de chat.

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 locales comunes van desde contextos de 8K y 32K hasta 128K, 256K e incluso contextos de 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 hasta casi detenerse en 64K y perder coherencia en 100K. Siempre prueba las longitudes de contexto que realmente planeas usar.

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

Ejercicio útil: Prueba mi aplicación de demostración del 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 que está por encima de este punto, incluidos tokens, pesos, configuración y plantillas de chat, es la preparación para el motor real que está debajo. El Transformer es el esqueleto que mueve los números.

Una capa simplificada de Transformer 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 las representaciones de tokens anteriores y decide qué es relevante.
Bloque MLP / feed-forward: Una computación no lineal densa que expande y comprime representaciones. Una gran fracción de los parámetros vive aquí.
Normalización de capa y conexiones residuales: Estas estabilizan las 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 remodelan la representación, RoPE mantiene la posición en orden 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 son relevantes 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 clásica (atención multi-cabeza) almacena estado clave/valor separado para muchas cabezas. Le da flexibilidad al modelo, pero hace que la 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 multi-cabeza completa. Puede ser potente, pero el contexto largo se vuelve costoso rápidamente.

Kernels modernos como FlashAttention y las 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.

Esta es la razón por la que dos modelos de 7B pueden comportarse de manera muy diferente con contexto largo. El conteo de parámetros no es toda la historia. Un modelo MHA de 7B con contexto de 128K puede agotar una GPU de 24 GB, mientras que un modelo GQA de 7B 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 conteo de parámetros.

Caché KV

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

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

tokens x capas x cabezas_kv x dimensión_cabeza x precisión x 2

La x 2 es para claves y valores.

Una regla general útil para modelos MHA de 7B similares a Llama más antiguos es aproximadamente 0.5 MiB por token en caché KV FP16. Eso significa que 4K tokens pueden costar alrededor de 2 GiB solo para la caché KV. En 32K tokens, podrías estar viendo 16 GiB solo de caché KV.

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

No trates la caché KV por debajo de 8 bits como un valor predeterminado. Sistemas de investigación como KIVI, KVQuant y kernels de caché comprimida más nuevos muestran que la 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 KV Q4 en un runtime de escritorio. Por debajo de 8 bits, haz pruebas comparativas exhaustivas, especialmente para codificación, llamadas a herramientas, JSON, recuperación de contexto largo y tareas donde los tokens anteriores exactos importan.

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

Esta es la razón por la que un modelo puede caber con un prompt vacío pero fallar cuando cargas un documento largo. Los pesos caben. La memoria de trabajo no.

Prellenado Y Decodificado

La inferencia de LLM tiene dos regímenes de rendimiento diferentes: prellenado y decodificado.

El prellenado 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. El prellenado es relativamente paralelizable, por lo que las GPU pueden manejarlo de manera eficiente, pero aún puede ser costoso.

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

El decodificado genera nuevos tokens uno a la vez. Cada token generado depende de la secuencia hasta ahora, por lo que el decodificado es mucho más secuencial. Aquí es de donde proviene 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 prellenado. Las respuestas largas castigan el decodificado. Las conversaciones largas castigan ambos porque la caché KV crece.

En una sesión de chat, cada turno se agrega a la caché. Si dejas que una conversación llegue a 16K tokens, estás pagando el costo de memoria de los 16K tokens en cada nuevo token generado. Esta es la razón por la que las interfaces de chat que mantienen un historial infinito eventualmente se ralentizan o fallan.

Decodificado

Después de que el modelo produce los logits, aún no ha escrito nada. Solo ha puntuado cada posible siguiente token. El decodificado es la política que convierte esas puntuaciones en un token real, agrega ese token al contexto y repite el ciclo.

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 reducido 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 opciones no cambian los pesos del modelo, pero cambian la voz del modelo, su determinismo, creatividad, perfil de riesgo y tendencia a repetirse.

Los parámetros importantes responden a tres preguntas prácticas:

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

Para trabajo preciso, comienza de forma restrictiva: temperatura baja, límites de tokens máximos cortos, secuencias de parada explícitas y decodificado restringido 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 codificación, mantén la primera pasada conservadora, luego muestrea alternativas solo cuando estés explorando intencionalmente.

El decodificado voraz no siempre es más preciso. A menudo es frágil. Un decodificador voraz puede quedarse atascado 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 solo archivo de peso grande. Un paquete de modelo generalmente incluye:

Arquitectura/config: Número de capas, tamaño oculto, tipo de atención, configuración 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 los 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 lo que 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 la caché KV. <|assistant|>

Otro modelo puede esperar:

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

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

Usar el formato incorrecto puede causar galimatías, confusión de roles, prompts de sistema ignorados, prompts repetidos, rarezas en el rechazo, llamadas a herramientas rotas, malos resultados en evaluaciones comparativas y conclusiones de que el modelo es tonto cuando la plantilla es el error real.

Mejores prácticas:

Usa el método 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 de 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 probando realmente el modelo que crees que estás probando.

Tipos De Modelos

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 instruct/chat reciente en un tamaño que quepa cómodamente en la memoria.

No empieces 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, ajuste fino 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 extra y verificación.
Modelo ajustado para herramientas: Bueno cuando las llamadas estructuradas, JSON o el uso de funciones son importantes.

Lo Que Local Realmente Significa

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 alta gama.
Un modelo MoE disperso ejecutándose en una o más GPUs de centro de datos.
Una implementación privada usando vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio o una pila PyTorch personalizada.

El punto clave: local no significa automáticamente fuera de línea, privado, seguro, barato o de código abierto. Solo significa que tú mismo estás ejecutando el modelo. Una aplicación local aún puede enviar datos 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 la memoria pero responder mal.

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

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 una precisión más baja 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 referencia para la evaluación.
Q8 / INT8: Casi sin pérdida para muchas tareas, pero aún grande. Bueno cuando tienes VRAM y quieres una pérdida de calidad mínima.
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 hacer que quepa 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 de la caché KV. La cuantización de pesos reduce el tamaño del modelo. La cuantización de la caché KV reduce la memoria del contexto en vivo.

Para la 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.

La falla de cuantización se manifiesta primero en matemáticas, razonamiento de múltiples pasos, corrección de código, confiabilidad 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 conteo de parámetros. Un modelo de 7B en Q6 puede vencer a un modelo de 13B en Q2 en tareas de razonamiento usando menos memoria y ejecutándose más rápido.

Formatos De Archivo Y Seguridad De Carga

safetensors es un formato de serialización seguro de tensores diseñado para almacenar tensores sin el comportamiento pickle de Python. Usa safetensors cuando sea posible, especialmente para modelos 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 la implementación estandarizada y la aceleración específica del hardware, especialmente fuera de la pila PyTorch habitual. Si estás implementando en NPUs de Intel, dispositivos ARM o aceleradores personalizados, ONNX suele ser el camino de menor resistencia.

TensorRT-LLM es la ruta de inferencia de alto rendimiento de NVIDIA para implementaciones 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 runtimes de LLM local es maduro, útil y fragmentado.

Para una sola persona que experimenta 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 implementación 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 de servicio prácticos.

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

Equipo o API privada significa un endpoint compatible con OpenAI en una estación de trabajo o servidor. vLLM, SGLang, TensorRT-LLM y el 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 servir en producción es otro trabajo. Ahora la conversación incluye batching continuo, caché de prefijos, decodificación especulativa, atención paginada, paralelismo de tensores, paralelismo de pipelines, servicio cuantizado, salidas estructuradas, balanceo de carga, utilización de GPU, percentiles de latencia, caché de prompts, control de admisión, registro (logging), 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 manera confiable bajo tráfico real?

Matemáticas de VRAM para modelos locales

Hay tres consumidores principales de memoria:

Pesos del modelo
Caché KV
Sobrecarga del runtime

La fórmula aproximada de memoria para pesos es:

memoria_pesos ~= parámetros x bytes_por_parámetro

Aproximaciones útiles:

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

Luego suma:

Sobrecarga del runtime: Buffers 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, cabezas borrador o estructuras de verificación adicionales no son gratis.
Memoria de adaptadores: Los adaptadores LoRA son pequeños, pero siguen siendo reales.

Los modelos MoE añaden una complejidad adicional. Un modelo puede activar solo una fracción de sus parámetros por token, pero los expertos inactivos generalmente todavía 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_del_runtime + sobrecarga_de_lote_o_concurrencia + margen_de_seguridad

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

Deja entre un 10 y un 20 por ciento de margen. Ejecutar al 99% de utilización de VRAM es pedir a gritos errores de falta de memoria y fallos por fragmentación.

Niveles de hardware en la práctica

Estas son reglas generales prácticas para 2026, asumiendo inferencia cuantizada y longitudes de contexto sensatas. Los resultados exactos dependen del runtime, la cuantización, la arquitectura del modelo, el tipo de atención, la longitud del contexto y la sobrecarga del SO/controladores.

Para la mayoría de los usuarios locales serios en 2026, 16 GB es el nivel mínimo de GPU cómodo, 24 GB es el nivel de entusiasta con mejor relación calidad-precio, y 48 GB o más 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 del prompt, la longitud generada y la madurez del runtime.

La decodificación 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. El prellenado (prefill) está más limitado por el cómputo porque puede procesar el prompt en paralelo. Por eso 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. Técnicamente puede funcionar, pero la velocidad de los tokens puede colapsar. La descarga a CPU (CPU offload) 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 entre 8 GB y 12 GB de VRAM o memoria unificada, empieza pequeño. Si tienes entre 16 GB y 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 checkpoint:

pesos + caché KV + sobrecarga del runtime <= 80 al 90 por ciento de la memoria disponible

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

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

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

Los leaderboards son útiles para descubrir. No son un sustituto de tus propias evaluaciones. Tu carga de trabajo es el benchmark 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 codificación local, elige un modelo de 14B a 32B con capacidad de código si tienes suficiente VRAM. Usa temperatura baja, recuperación del 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 privados, elige un modelo instruct potente, 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 adicionales, usa temperatura baja a media, añade 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 recursos limitados, elige un modelo de 1B a 4B, Q4/Q5, prompts cortos, tareas estructuradas, recuperación o herramientas, y un esquema de salida ajustado. Los modelos pequeños se vuelven útiles cuando la tarea está restringida.

¿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 batching y la calidad del runtime.

Las principales palancas son:

Ancho de banda de memoria: La decodificación 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: El prellenado 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 derraman a la CPU, el rendimiento puede colapsar.
Implementación de la atención: FlashAttention, SDPA, atención paginada y kernels específicos del runtime cambian tanto la velocidad como el comportamiento de la memoria.
Cuantización: Los pesos más pequeños reducen el movimiento de memoria, pero una cuantización agresiva puede dañar la calidad y, a veces, añadir sobrecarga de des-cuantización.
Tamaño de lote y concurrencia: El batching mejora el rendimiento, pero cada secuencia activa necesita caché KV.
Longitud del prompt: Los prompts largos aumentan el tiempo de prellenado.
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 paso del modelo objetivo 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 técnicamente funcionar, pero la velocidad de token puede caer de usable a miserable.

Compara con el runtime exacto, la cuantización, la longitud de contexto, la forma del prompt y la carga de trabajo que planeas usar. Un número de leaderboard en BF16 no te dice cómo se sentirá tu stack local en Q4.

Contexto largo

El contexto largo suena mágico: 128K, 256K o incluso 1M de tokens en un solo prompt. Es útil, pero tiene costos reales.

Más contexto significa más memoria de caché KV, procesamiento de prompt 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 decaer 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 contexto largo para análisis de documentos completos, fragmentos de bases de código, revisión legal o técnica, resumen de transcripciones, razonamiento multiarchivo y respaldo de RAG cuando la recuperación no encuentra 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.

Algunos 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 resumen en lugar de un historial de chat infinito.

Piensa en el contexto largo como atención costosa, no como un bloc de notas gratis.

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 añaden 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 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. Vienen del mismo presupuesto.

Los VLM pequeños pueden alucinar detalles visuales. La fiabilidad del OCR varía. Los gráficos y 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 la extracción de facturas.

El panorama de modelos locales en 2026

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

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

Gemma 4 es importante porque Google DeepMind está impulsando la familia hacia una implementación local útil: modelos edge eficientes, opciones densas y MoE más grandes, multimodalidad, contexto largo en los modelos más grandes, soporte de idiomas amplio, comportamiento mejorado de código/agentes y licencia Apache 2.0. Esa combinación hace que valga la pena probarla cuando el uso comercial y la implementación en dispositivos 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 largo alcance, razonamiento multimodal, uso de herramientas y flujos de trabajo de agentes. GLM es importante para agentes de código, tareas de largo alcance, sistemas MoE y lanzamientos de modelos orientados a la implementación. DeepSeek sigue siendo influyente debido a los grandes sistemas MoE, Multi-head Latent Attention, DeepSeekMoE, rutas de servicio FP8, atención dispersa y auto-hospedaje de alto rendimiento. MiniMax vale la pena seguirla por cargas de trabajo de agentes prácticas y modelos MoE eficientes en inferencia. Mistral sigue siendo importante porque su línea cubre casos de uso generalistas, de código, razonamiento, multimodales y especializados con un sólido soporte de implementación.

Nemotron 3 es la familia de modelos abiertos de NVIDIA para sistemas de agentes de nivel de producción en hardware NVIDIA. La familia incluye tamaños Nano, Super y Ultra, utiliza diseños híbridos Mamba-Transformer MoE, y está estrechamente vinculada a TensorRT-LLM, NIM, Dynamo, rutas Blackwell NVFP4/FP8 y la implementación de agentes empresariales. Trátalo menos como una familia casual de chat de escritorio y más como una señal de hacia dónde quiere NVIDIA que vayan los stacks 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 runtime, 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 el código, el trabajo multilingüe, el uso de herramientas, los modos de pensamiento/no pensamiento y el contexto largo. Las tarjetas de modelo de 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 larga 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 runtime está configurado correctamente para código, agentes o cobertura multilingüe.

Investigación en inferencia

La frontera en 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 en FP8 es ahora una característica práctica del runtime en sistemas como vLLM. DFlash y DDTree exploran la decodificación especulativa con modelos borrador de difusión de bloques y árboles borrador. NVFP4 también vale la pena seguir en hardware NVIDIA porque cambia la conversación práctica sobre la implementación para stacks compatibles.

Algo de esto está listo para producción. Algo sigue siendo investigación. Algo solo importa si tu runtime 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 del ajuste de memoria, el formato, el soporte del runtime, la configuración de decodificación o la calidad de la recuperación.

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

Galimatías 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 tarjeta del modelo y la plantilla del runtime antes de culpar a la calidad del modelo.

Primer token lento: El prellenado es costoso. Acorta el prompt, usa caché de prefijos, mejora la recuperación, reduce el contexto o usa un runtime más rápido.

Streaming lento: La decodificación es el cuello de botella. Verifica el ancho de banda de 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.

Respuestas incorrectas sobre documentos: La recuperación probablemente falló. Inspecciona el texto parseado, los límites de los fragmentos, los metadatos, la recuperación top-k, el reranking y la fundamentación de las citas.

JSON o llamadas a herramientas incorrectas: 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, añade penalizaciones por repetición, verifica los tokens de parada y asegúrate de que la plantilla no esté causando que el modelo vea su propia respuesta como un nuevo prompt.

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

Cómo hacer crecer el stack

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 de la misma clase de tamaño y compáralos con los mismos prompts.

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

Intermedio: Configuración de desarrollador

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 usar solo una interfaz de chat.

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

Avanzado: Configuración de servicio privado

Usa vLLM o SGLang, una o más GPUs, una API compatible con OpenAI, monitoreo, gestión de prompts/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, runtimes especializados, experimentos de cuantización, decodificación especulativa, paralelismo multi-GPU, fine-tuning, 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 los prompts 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 prompts en documentos recuperados, abuso de llamadas a herramientas, filtración de secretos a través de registros, telemetría de aplicaciones de escritorio, extensiones o plugins del navegador, alucinaciones del modelo en entornos de alto riesgo, violaciones de licencia y contaminación de datos durante el fine-tuning.

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

Carga con cuidado: Prefiere safetensors o GGUF de fuentes confiables, evita archivos .bin no confiables y no actives trust_remote_code a la ligera.
Ejecuta con límites: Usa un usuario sin privilegios, contenedores o sandboxes para agentes, y acceso a red deshabilitado cuando la privacidad offline sea importante.
Protege los secretos: Mantén las credenciales fuera de los prompts 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.
Controla versiones de lo que importa: Rastrea las versiones del modelo, prompt, adaptador, runtime y 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 como también evitas descargar un checkpoint aleatorio, ejecutarlo como root y convertir la IA local en una vulnerabilidad local.

Benchmarks que importan

Compara el stack que realmente vas a ejecutar. La puntuación de un modelo en un leaderboard BF16 no es tu realidad local en Q4.

Mide la calidad, la latencia, la memoria, la fiabilidad y el ajuste operativo:

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

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

Luego compara modelos. No dejes que un leaderboard elija tu stack local por ti.

Codificación con modelos locales

La codificación es uno de los mejores casos de uso de los LLM locales porque los prompts 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 dirigido, 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 decodificación 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 que puedas saber cuándo un nuevo modelo 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 código 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. Limita el alcance del agente dándole solo los directorios, APIs, acceso a 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 prompts. Mantén un registro de auditoría registrando las llamadas a herramientas, las versiones del modelo, los prompts 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 hacen que las llamadas a herramientas sean más fáciles de validar. No prueban que el modelo entendió la solicitud, eligió la acción segura o evitó instrucciones inyectadas.

Para el uso serio de herramientas, coloca las verificaciones de políticas fuera del modelo.

RAG vence a los prompts gigantes

RAG significa Retrieval-Augmented Generation (Generación Aumentada por Recuperación). En lugar de meter toda la información en el prompt, recuperas fragmentos relevantes de una base de conocimiento y le das solo esos fragmentos al modelo.

Un buen sistema RAG local generalmente tiene ingestión de documentos, parseo, fragmentación, embeddings, un índice vectorial, recuperación, reranking, construcción de prompts, generación de respuestas, verificaciones de fundamentación y evaluación. Cada etapa es un punto de fallo.

Un mal parseo 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. 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 del documento padre a menudo funcionan 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 ingestión.

Documentos y trabajo de conocimiento

Para documentos privados, los LLM locales brillan: Resúmenes de transcripciones de reuniones, revisión de contratos, Q&A de 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 con cuidado, preserva los metadatos de página y sección, fragmenta semánticamente, usa embeddings y rerankers, pide citas, separa la respuesta 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 el prompt o recuperas en el contexto.

Para transcripciones de reuniones, preserva las etiquetas de los hablantes y las marcas de tiempo. Para la revisión de contratos, fragmenta por cláusula o sección en lugar de por un recuento arbitrario de tokens. Para Q&A de 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 parser y tu recuperador importan tanto como el modelo.

Implementación en el borde (edge)

Los modelos pequeños son cada vez más útiles en teléfonos, laptops, robots, gateways IoT, dispositivos de fábrica, vehículos, dispositivos médicos, equipos de campo sin conexión y aplicaciones de navegador. El borde 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 borde está gobernado por memoria limitada, bajo consumo energético, límites térmicos, 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 el borde suele usar un modelo de 0.5B a 4B, cuantización agresiva de pesos, instrucciones mínimas, esquemas fijos, flujos de trabajo asistidos por herramientas, embeddings locales, caché y sin 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 falla. El futuro de la IA local no son solo los modelos gigantes para estaciones de trabajo. También son modelos pequeños haciendo trabajo útil cerca de los datos.

Manual de Uso para un LLM Local

Úsalo como la última verificación antes de confiar en un modelo local para trabajo real.

Elige y ajusta: Selecciona una familia de modelos adecuada para 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 limites al 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 pickle no verificados, verifica el tokenizador y la plantilla de chat, establece la longitud de contexto intencionalmente y elige los 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 instrucciones representativas, mide el tiempo hasta el primer token y la velocidad de decodificación, rastrea el pico de memoria, evalúa la recuperación antes de agregar RAG, aísla las herramientas antes de agregar agentes, y ajusta fino solo después de que fallen los métodos más simples.

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

Ajuste Fino

El ajuste fino cambia el comportamiento del modelo al entrenarlo 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 adaptador de bajo rango pequeños. Eso reduce los parámetros entrenables y te permite mantener múltiples adaptadores ligeros. QLoRA extiende esto ajustando fino a través de un modelo base cuantizado a 4 bits congelado en adaptadores LoRA.

Ajusta fino cuando necesites un estilo de escritura consistente, un formato de salida específico del dominio, un comportamiento repetitivo de clasificación o extracción, confiabilidad en el formato de llamada a herramientas, una personalidad de asistente especializada, una adaptación de dominio que RAG no pueda resolver, o un mejor rendimiento de modelos pequeños en una tarea específica.

No ajustes fino primero. Prueba este orden: corregir la plantilla de chat, mejorar las instrucciones, mejorar el modelo, mejorar la decodificación, RAG, reranking, ejemplos de pocas muestras, y luego ajuste fino.

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

Un buen plan de ajuste fino incluye datos limpios, divisiones de entrenamiento/validación/prueba, evaluaciones base, un comportamiento objetivo claro, revisión de seguridad, comprobaciones de sobreajuste, evaluaciones de regresión, versionado del adaptador, revisión de licencia y un plan de reversión.

Pesos Abiertos No Significa Código Abierto

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

Pesos abiertos 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 disponible significa que el código o los pesos son visibles. No implica 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 la OSI considera que un sistema de IA incluye la arquitectura, los parámetros/pesos, el código de inferencia y suficiente información y código de datos utilizados 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: uso competitivo no permitido, entrenamiento con salidas no permitido, implementación por encima de cierta escala no permitida, exclusiones geográficas, requisitos de atribución, cláusulas de patentes u obligaciones tipo copyleft en 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 restricciones legales o de implementación.

Glosario

Términos del Modelo 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.
Ajuste Fino: Entrenamiento adicional que cambia el comportamiento del modelo para un dominio objetivo o estilo de salida.
Modelo de Instrucciones: Un modelo ajustado para seguir instrucciones.
LoRA / QLoRA: Métodos de ajuste fino 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 expertas 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 utilizado para representar mensajes de sistema, usuario, asistente y herramienta.
Ventana de Contexto: El número máximo de tokens que el modelo puede procesar a la vez.
Decodificación: 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 paralelo.
DDTree / DTree: Un método de decodificación especulativa que construye un árbol de borrador 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 la inferencia.
Inferencia: Ejecutar el modelo para producir salidas.
Caché KV: Estados de atención de clave/valor almacenados para tokens anteriores.
Prellenado: La fase donde el modelo procesa la instrucción de entrada antes de generar.
RoPE: Codificaciones Posicionales Rotatorias, un método de codificación posicional común en los LLM modernos.
Decodificación Especulativa: Una técnica de velocidad donde un borrador más barato propone 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 Embedding: 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 con 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 entrégaselo 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 basada en pickle.

Palabras Finales

El ecosistema de LLM local incluye modelos compactos para el borde, modelos de consumo robustos de 7B a 32B, grandes sistemas MoE de pesos abiertos, 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 gratuito, la calidad de RAG depende de la recuperación, el ajuste fino necesita evaluaciones, y la privacidad local aún requiere disciplina de seguridad.

No necesitas mitología para ejecutar bien los modelos locales. 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ática de memoria más formato más evaluación. Domina eso, y el resto del stack se vuelve mucho más fácil de entender.

Hasta la próxima.

-Ahmad