¿Qué LLM local puedes ejecutar? Guía de llmfit para tu hardware

llmfit responde la pregunta que debería preceder a cualquier descarga de un modelo local: ¿qué funcionará bien en este equipo? La herramienta gratuita detecta RAM, CPU, GPU y VRAM y clasifica cientos de modelos por ajuste de memoria, velocidad, calidad y contexto útil. La velocidad puede ser una medición local, un resultado comunitario equivalente, una estimación calibrada localmente o una estimación de fórmula. También selecciona la cuantización de mayor calidad que espera que quepa.

Puede ahorrarte una descarga de 20 GB y una tarde perdida. No demuestra que el modelo tenga suficiente precisión, una licencia válida para tu producto o velocidad bajo carga real. Usa llmfit para crear una preselección y después prueba esa lista con tu runtime y tu carga.

llmfit en 60 segundos

Instala y pide una recomendación antes de descargar pesos

El proyecto recomienda su tap de Homebrew con binario precompilado para macOS o Linux. La fórmula de Homebrew Core también existe, pero puede compilar desde el código fuente si no hay una botella disponible. En Windows puedes usar Scoop. Si ya trabajas con uv, uvx ejecuta llmfit sin una instalación persistente.

# macOS o Linux
brew install AlexsJones/llmfit/llmfit

# Windows
scoop install llmfit

# Una ejecución mediante uv
uvx llmfit

El comando llmfit abre la interfaz interactiva. Para un proceso reproducible de decisión, estos comandos de CLI son más útiles:

# Confirma el hardware detectado
llmfit system

# Devuelve cinco recomendaciones para programación
llmfit recommend --json --use-case coding --limit 5

# Revisa los supuestos de un candidato
llmfit info "NOMBRE DEL MODELO"

# Estima hardware para un contexto de 8K
llmfit plan "NOMBRE DEL MODELO" --context 8192 --json

La referencia oficial de CLI y automatización incluye overrides de hardware, límites de contexto y una API REST local. Por eso llmfit también sirve para scripts y planificación de nodos.

Cómo decide llmfit qué modelo cabe

Primero identifica el backend de aceleración, como CUDA, Metal, ROCm, SYCL o CPU. Después compara el catálogo con la memoria disponible y una jerarquía de cuantización desde Q8_0 hasta Q2_K. Intenta conservar la opción de mayor calidad que cabe. Si el contexto completo no entra, puede recalcular con uno menor.

La combinación cambia según el caso de uso. Programación puede favorecer a un especialista pequeño sobre un generalista mayor. Razonamiento da más peso a calidad y chat a velocidad. Es mejor que ordenar por parámetros, pero sigue siendo una heurística. Tu conjunto de aceptación decide.

La velocidad ya no siempre procede de una fórmula. El orden de confianza actual es una medición propia, una medición comunitaria en hardware equivalente, una mediana de localmaxxing para un preset equivalente y, por último, la estimación de fórmula. Los benchmarks locales aptos también pueden calibrar otras estimaciones en el mismo equipo. Revisa la confianza y la base de la estimación antes de comparar todos los valores de tokens por segundo como si tuvieran la misma evidencia.

Por qué importa el soporte MoE

Los modelos Mixture-of-Experts publican muchos parámetros totales, pero solo activan una parte por token. Una calculadora pensada para modelos densos puede producir una estimación engañosa. llmfit lee metadatos MoE, distingue parámetros activos y modela una ruta con expertos activos en VRAM e inactivos descargados a RAM.

Eso no significa que solo los parámetros activos necesiten memoria. Todos los pesos deben existir en algún punto del serving, normalmente RAM, almacenamiento o ambos. El cambio de expertos, el offload a CPU y el tráfico PCIe afectan la velocidad. La documentación del modelo de puntuación es un mejor punto de partida que la aritmética densa, pero no sustituye el benchmark.

Cuantización: que quepa no significa que sirva

La cuantización reduce memoria al almacenar pesos con menor precisión. llmfit recorre sus niveles hasta encontrar una configuración viable. Para producción debes añadir dos límites:

• Usa el contexto real. Un modelo puede caber a 4K y desbordarse a RAM a 32K por el crecimiento de la caché KV.
• Define un mínimo de calidad. Un modelo Q2 que carga no tiene por qué ser suficiente para código, varios idiomas o JSON fiable.

Ejecuta llmfit plan con el contexto previsto y compara al menos dos cuantizaciones vecinas sobre un conjunto fijo. Si la mejor opción casi cabe, quizá debas cambiar de hardware o usar una API en vez de comprimir más.

Dónde verificar la detección de hardware

La matriz oficial de plataformas explica los overrides --memory, --ram y --cpu-cores. Un override cambia el cálculo, pero no añade soporte a un runtime que no lo tenga.

Cinco comprobaciones entre un ajuste verde y producción

1. Confirma el equipo detectado. Guarda llmfit system --json con la decisión y corrige valores ausentes o compartidos.
2. Filtra por la tarea real. Elige programación, razonamiento, chat, multimodal o embeddings.
3. Fija contexto y concurrencia. Modela entradas y peticiones simultáneas reales, no una demo individual.
4. Prueba el runtime. Mide tokens por segundo, tiempo hasta el primer token, procesamiento del prompt, pico de memoria y fallos. llmfit guarda localmente las ejecuciones correctas; compartirlas como pull request de GitHub es opcional.
5. Revisa todo el despliegue. Incluye licencia, datos, observabilidad, actualizaciones, fallback, seguridad y coste total.

Un modelo puede encajar perfectamente y ser una mala decisión comercial. Compara ingeniería y capacidad ociosa con el gasto de API mediante nuestro marco de break-even entre modelos locales y APIs. Si eliges un nuevo sobremesa de Apple, nuestra guía de compra del Mac mini M6 y Mac Studio M5 asigna modelo, contexto y concurrencia al nivel de memoria adecuado. Para un caso actual con 128 GB de memoria unificada, nuestro análisis de DeepSeek V4 Flash 0731 en un solo PC separa que el modelo cargue de que esté listo para producción. El análisis de Colibri GLM 5.2 en hardware de consumo muestra cómo memoria, ancho de banda y carga cambian la respuesta.

Cuándo basta llmfit y cuándo empieza la ingeniería

El camino comercial limpio es progresivo. Descarta candidatos malos con llmfit, invierte tiempo de benchmark solo en los dos o tres mejores y elige self-hosting cuando calidad, latencia, riesgo y coste medidos superen a la opción gestionada.

Límites que deben constar en la decisión

• Un valor de velocidad puede ser medido, calibrado o estimado. La confianza y la base de la estimación importan tanto como la cifra.
• El catálogo está integrado en el binario. Actualiza llmfit para recibir nuevos modelos.
• La calidad por tarea usa benchmarks de familias y heurísticas, no tu conjunto privado.
• Sumar VRAM de varias GPU no iguala tarjetas, interconexiones ni anchos de banda.
• Que un modelo cargue no valida licencia, seguridad, precisión de dominio ni preparación operativa.

Fuentes y límites de las afirmaciones

Instalación, comandos, runtimes, privacidad y licencia MIT proceden del repositorio de llmfit. Detección, cuantización, MoE, niveles de ajuste, puntuación y confianza de velocidad proceden de la documentación técnica. Los límites de plataforma están en la referencia de soporte. El flujo actual de benchmarks locales, comunitarios y calibrados está en la referencia de benchmarks de la CLI. Datos verificados el 2 de septiembre de 2026. Wavect no reprodujo de forma independiente las mediciones ni estimaciones para este artículo.