Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Inferencia local
La inferencia local ejecuta el modelo en hardware que controlas directamente. En vez de enviar la request a un proveedor externo, un runtime como LM Studio o llama.cpp carga los pesos y genera la respuesta en el equipo local.
El reto práctico es hacer que el modelo, el contexto y el estado del runtime quepan en la memoria disponible sin reducir demasiado la velocidad.
Pesos, formatos y cuantización
Los pesos contienen los parámetros aprendidos del modelo. El número de parámetros da una primera idea del tamaño, pero la precisión utilizada para representarlos cambia mucho la memoria necesaria.
Un modelo de 27B almacenado a 16 bits necesita del orden de 54 GB solo para los pesos. Una GPU de 16 GB no puede cargar esa representación completa. La cuantización reduce la precisión de los valores y permite distribuir el mismo modelo en ficheros mucho menores.
Nombres como Q4_K_M o Q3_K_XL identifican esquemas concretos del ecosistema del runtime. Una cuantización menor suele ahorrar memoria y puede afectar a calidad o velocidad. El efecto real se comprueba con las tareas que se quieren ejecutar; el nombre por sí solo no dice si la pérdida será aceptable.
GGUF es el formato utilizado por llama.cpp para guardar tensors y metadata del modelo. No es una cuantización: un fichero GGUF puede contener pesos con distintos esquemas.
VRAM, RAM y offload
Que el fichero de pesos mida menos que la VRAM no garantiza que la configuración completa vaya a cargar. También necesitan memoria la KV cache, los buffers del runtime y el propio sistema.
Cuando el modelo no cabe entero en VRAM, llama.cpp puede repartir capas entre GPU y CPU mediante GPU offload. Esto permite ejecutar modelos mayores, pero la RAM no funciona como una ampliación gratuita de la VRAM. Si una parte importante del cálculo queda en CPU o cruza continuamente el bus, la generación puede hacerse mucho más lenta.
El experimento de Qwen3.8-27B con OpenCode lo mostró claramente. El Q4 de unos 16,8 GB solo permitía 54/65 unidades de offload y generaba alrededor de 9 tokens/s. Un Q3 de unos 13,4 GB dejaba margen para mantener la carga completa en GPU y las requests cortas pasaron a unos 40–45 tokens/s.
Eso no demuestra que Q3 sea cinco veces más rápido que Q4. Cambiaron a la vez la cuantización y el reparto CPU/GPU. La conclusión útil es que eliminar el offload parcial resolvió el cuello de botella principal de esa configuración.
Contexto y KV cache
Una ventana de contexto mayor también consume más memoria. Durante prefill y decode, el runtime mantiene una KV cache con estado calculado para los tokens anteriores. Al aumentar el contexto, esa cache crece y deja menos margen para pesos y buffers.
En LM Studio se puede ajustar la longitud cargada y, para modelos compatibles, la precisión o ubicación de K y V. Cuantizar la cache puede recuperar VRAM, pero es otro compromiso que puede afectar a calidad o rendimiento.
En el experimento Qwen, pasar K y V a Q4_0 permitió mantener una sesión grande con full GPU offload. La memoria dedicada llegó aproximadamente a 15,4 de 16 GB. Ese margen era suficiente para trabajar, pero dejaba claro que aumentar el contexto tenía un coste físico aunque el modelo anunciase una ventana mucho mayor.
No conviene cargar siempre el máximo. El objetivo es disponer del contexto que necesita la tarea dejando margen para el runtime.
Runtime y ajustes
LM Studio proporciona una interfaz sobre llama.cpp para descargar, cargar y servir modelos. llama.cpp también ofrece herramientas como llama-cli y llama-server.
Los ajustes que más han cambiado mis pruebas son:
- GPU offload: cuánto trabajo puede permanecer en GPU.
- Context length y KV cache: cuánto contexto cabe y cuánta VRAM consume.
- Threads: relevantes cuando existe trabajo importante en CPU.
- Flash Attention: optimización del runtime que puede reducir memoria o mejorar velocidad en configuraciones compatibles.
Los parámetros de batch también pueden afectar al procesamiento del prompt, pero no hace falta ajustarlos hasta identificar que el cuello de botella está ahí. Cambiar varios sliders a la vez hace difícil saber qué produjo la mejora.
Speculative decoding
Speculative decoding utiliza una ruta más barata, a menudo otro modelo pequeño, para proponer varios tokens que el modelo principal verifica. Puede acelerar decode si muchos candidatos se aceptan.
También puede no aportar nada si el draft model añade overhead o acierta poco. Es una optimización para probar y medir después de estabilizar memoria, contexto y reparto CPU/GPU; no una mejora automática.
API local
LM Studio y llama-server pueden exponer endpoints HTTP OpenAI-compatible. Una aplicación puede reutilizar un SDK o un agente cambiando el base_url para apuntar al servidor local.
Esto separa dos piezas que a veces se confunden. LM Studio ejecuta la inferencia. OpenCode, Codex u otro cliente puede aportar el harness, las tools y el loop. El modelo local no adquiere acceso al filesystem o a la shell solo por estar servido mediante API.
El servidor puede escuchar en la LAN. En el experimento Qwen, LM Studio utilizaba la GPU del host Windows mientras OpenCode y las tools de pentesting se ejecutaban en una Kali virtualizada. La inferencia seguía siendo local aunque el cliente estuviera en otra máquina.
APIs de modelos cubre el formato de esas requests y los límites de la compatibilidad.
Benchmarking
Un benchmark local sirve cuando permite comparar configuraciones y repetir la prueba. Como mínimo conviene registrar:
- Modelo y cuantización exactos.
- Runtime, hardware y GPU offload.
- Longitud de contexto y configuración de la KV cache.
- Tamaño del prompt y del output.
- Tokens/s de generación y, cuando importe, tiempo de prefill o TTFT.
- Uso máximo de VRAM y RAM.
Una prueba con un prompt corto no representa necesariamente una sesión de agente con 50K tokens activos. En el artículo de Qwen, las generaciones cortas del Q3 rondaban 40–45 tokens/s, mientras la prueba de contexto largo generó alrededor de 21 tokens/s. Ambas cifras son correctas para sus condiciones.
También hay que indicar si el tiempo incluye cargar el modelo o si el servidor ya estaba warm.
Ajuste práctico
La secuencia que resulta más fácil de interpretar es:
- Elegir un tamaño de modelo razonable para la tarea.
- Escoger una cuantización que deje margen de memoria.
- Mantener en GPU todo lo posible y medir el efecto del offload.
- Cargar un contexto realista, no el máximo por defecto.
- Revisar el consumo de la KV cache y los buffers.
- Medir prefill, tokens/s y memoria con el uso real.
- Ajustar threads, batch o speculative decoding solo si atacan el cuello de botella observado.
La mejor configuración no es la que maximiza un slider. Es la que mantiene suficiente calidad y contexto con una velocidad utilizable en el hardware disponible.