FitLLM Engine

En vivo: https://fitllm.run · Bilingüe · Gratis · Sin anuncios · Sin inicio de sesión

Motor abierto: fitllm-engine (MIT · npm fitllm-engine · npx fitllm)

Cero dependencias. Un archivo legible: engine.js. Probado con vectores de conformidad. MIT.

npx fitllm "GLM-4.7-Flash" --gpu 4090     # ✓ FITS — 21.9/24 GB, free 2.1 GB
npx fitllm "gpt-oss-120b" --mac 64        # ✗ WON'T FIT → what to change to make it fit
npx fitllm "Qwen 3.6 35B" --gpu "5090 + 3090"   # multi-GPU rig — VRAM pools (56GB), even mixed cards
npx fitllm --top --detect                 # what CAN this machine run? — best quant per model
npx fitllm --detect                       # reads this machine's real hardware

¿Por qué una CLI? La pregunta «¿funcionará?» nace en la terminal — una línea antes de ollama pull. Sin instalación, sin cambiar de pestaña, y lee tu hardware real con --detect en lugar de pedirte que conozcas tu VRAM. El código de salida 0/1 lo convierte en un guardia previo a la descarga:

# in your model-pull script — stop BEFORE the 40 GB download:
npx fitllm "gpt-oss-120b" --detect || { echo "won't fit — aborting pull"; exit 1; }

Este es el núcleo de cálculo abierto de FitLLM. Las matemáticas son abiertas para que puedas auditarlas.

Pregúntale a un LLM «¿Qwen 3.6 cabe en mi GPU?» y hará coincidencia de patrones con una arquitectura de su corte de entrenamiento — y normalmente dirá no. Las calculadoras basadas en catálogos se quedan atrás con los nuevos lanzamientos. FitLLM lee el config.json oficial de cada modelo en vivo, por lo que acierta en los lanzamientos del primer día y en las arquitecturas híbridas / de ventana deslizante / MoE que las fórmulas ingenuas calculan mal.

Cubre memoria unificada de Apple Silicon (M1–M5, Pro/Max/Ultra — hasta el Mac Studio de 512 GB), GPUs NVIDIA (RTX 20/30/40/50, estación de trabajo RTX 6000 Ada / RTX PRO 6000, centro de datos A100/H100/H200/B200), AMD Radeon (RX 7000/9000, PRO W7900) y presets multi-GPU (2×3090, 2×4090, 4×3090) — con la cuantización de pesos por niveles GGUF Q separada de la cuantización de la caché KV. Cada número de hardware está verificado de forma cruzada con ≥2 fuentes independientes (URLs de fuentes incrustadas por valor en engine.js).

Por qué la mayoría de las calculadoras de memoria para LLM se equivocan

Casi todas las calculadoras de «¿puedo ejecutar este LLM?» estiman la caché KV con la fórmula de libro de texto:

KV ≈ 2 × num_layers × num_kv_heads × head_dim × context_length × bytes

Eso asume que cada capa mantiene una caché KV de contexto completo con una forma de cabeza uniforme. Cierto para Llama-1/2 — incorrecto para la mayoría de los modelos de 2025–2026:

Un error de 11× invierte el veredicto: una calculadora ingenua dice que Gemma 4 31B no cabe en 64 GB con contexto largo, cuando cabe cómodamente.

Las cinco cosas que ignoran

1. Atención de ventana deslizante (Gemma 2/3/4, gpt-oss): la mayoría de las capas solo conservan los últimos N tokens, por lo que su KV deja de crecer. Solo las capas globales escalan con el contexto completo.

2. Atención híbrida / lineal (Qwen 3.6 / 3.8, muchos modelos de 2026): las capas de atención lineal usan un estado recurrente de tamaño fijo, no una caché KV creciente. Ese estado también se modela, como componente propio (linearState) — es constante por secuencia, por lo que nunca infla la curva de contexto.

3. MLA — Atención Latente Multi-cabeza (GLM-5.2, GLM-4.7-Flash, familia DeepSeek): la caché es un único latente de bajo rango (kv_lora_rank + dimensiones RoPE) compartido entre todas las cabezas — las fórmulas por cabeza «2 × cabezas × head_dim» sobrecuentan por un orden de magnitud. Verificado contra el artículo de DeepSeek-V2 (arXiv:2405.04434) y el código oficial de inferencia de DeepSeek-V3.

4. Dimensiones de cabeza heterogéneas + MoE: las capas globales pueden usar un head_dim diferente (Gemma 4: 512 vs 256). MoE mantiene todos los expertos en memoria mientras activa solo unos pocos por token.

5. PLE — Embeddings por capa (Gemma 4 e2b/e4b): llama.cpp mantiene el tensor per_layer_token_embd en RAM del sistema por defecto independientemente de -ngl (forzarlo a CUDA falla para GGUFs K-quant; solo los quants no-K pueden optar — ggml-org/llama.cpp#14430), por lo que solo los pesos no-PLE necesitan VRAM. Contar todos los 5.1B parámetros contra una GPU sobrepredice los pesos residentes de e2b en ~1.9× e invierte los veredictos de tarjetas pequeñas. En Apple Silicon la RAM del sistema es memoria de acelerador, por lo que los parámetros totales siguen siendo correctos allí. (Advertencias: vLLM carga PLE completamente en la GPU — el cálculo de GPU de este motor está anclado al comportamiento predeterminado de GGUF/llama.cpp del que provienen sus niveles de cuantización; las mediciones de residencia provienen de la pila PLE de la serie E, y una medición directa en un GGUF de Gemma 4 es bienvenida en el issue #7.)

Este motor modela cada tipo de capa por separado, verificado contra los archivos oficiales config.json de HuggingFace.

Related MCP server: VisualAI MCP Server

Qué calcula

Total = Parameters (quantization-adjusted)
      + KV cache (per layer kind: sliding / global / linear / dense)
      + Runtime overhead (quant metadata + KV block padding + activations + fixed)
      + macOS base (Apple Silicon unified memory)

Además, un parseHfConfig() que convierte cualquier configuración de HuggingFace en la forma de modelo anterior. (Sin predicción de tokens/s — deliberadamente: la velocidad depende del runtime/backend de maneras que un modelo estático no puede afirmar honestamente. El ajuste es una afirmación verificable; la velocidad no lo es.)

Uso

import { simulate, LOCAL_MODELS, parseHfConfig } from './engine.js';

const model = LOCAL_MODELS.find((m) => m.name === 'Gemma 4 31b');
const sim = simulate(model, /*ram*/ 64, /*ctx*/ 131072, /*bits*/ 8);
// → { used, free, verdict: 'yes'|'tight'|'no', param, kv, rt, os, maxContext, ... }

// any HuggingFace model:
const m = parseHfConfig('Qwen/Qwen3-32B', configJson, totalSizeBytes);

Verificación

• Los valores de arquitectura se verifican contra el config.json oficial de HuggingFace.

• La KV de contexto completo de Gemma 4 31B reproduce 20.78 GiB, coincidiendo con el análisis de arquitectura publicado. Reprodúcelo a mano:

global: 10 layers × 2(K,V) × 4 heads × 512 dim × 2 B × 262,144 = 21,474,836,480 B
local:  50 layers × 2(K,V) × 16 heads × 256 dim × 2 B × 1,024  =    838,860,800 B
total = 22,313,697,280 B ÷ 1024³ = 20.78 GiB

• Calibración: Qwen 3.6 35B-A3B @128K, 8-bit ≈ 54 GB (coincide con ejecuciones locales reales).

• Costo por token de MLA: GLM-4.7-Flash = (512 + 64) × 2 B × 47 capas = 54,144 B/token — fijado por vectores de conformidad.

Todas las cifras son estimaciones — el uso real varía con el runtime (MLX/Ollama/llama.cpp), el estado del sistema operativo y el esquema de cuantización.

Vectores de conformidad

vectors/fit-vectors-v1.json fija 16 vectores de prueba neutrales al idioma (bytes KV exactos, costos por token, veredictos de ajuste) derivados a mano de los valores oficiales de config.json — p. ej. «Gemma 4 31B a 262,144 ctx, bf16 = exactamente 22,313,697,280 bytes». Cualquier implementación en cualquier idioma es conforme si todos los vectores pasan — ejecuta la nuestra con node vectors/run.mjs.

Por qué esto importa: las fórmulas son fáciles de copiar; una clave de respuestas verificada no lo es. Si portas este motor a Python, Rust o Go, no te conviertes en un fork no confiable — pasa los vectores y eres una implementación conforme del mismo estándar. Porta el motor, conserva los vectores.

El Censo de Ajuste — cada modelo × cada dispositivo, una tabla de verdad

census/ contiene más de 8,000 veredictos (24 modelos incl. nivel de borrador × 88 GPUs/Macs × niveles de cuantización) calculados por este motor — como CSV/JSON que puedes importar, graficar o citar, además de una matriz inicial («el modelo más grande que cabe cómodamente por dispositivo»). Regéneralo tú mismo: npm run census. Las mediciones del mundo real se colocan junto a las predicciones mediante PRs de fixtures/ — predicho vs. medido, en público.

Incrusta una insignia de ajuste

Muestra si un modelo se ejecuta en un hardware dado — en vivo desde el motor, una línea en cualquier README o tarjeta de modelo:

![fits](https://img.shields.io/endpoint?url=https%3A%2F%2Ffitllm.run%2Fapi%2Fbadge%3Fmodel%3DGLM-4.7-Flash%26gpu%3D4090)

Parámetros: model (nombre, difuso), gpu (nombre, difuso) o ram (GB, memoria unificada de Apple), opcional quant (nivel GGUF / 4|8|16), ctx, kv. Color del veredicto: verde cabe · amarillo justo · rojo no cabe.

¿Por qué incrustarla? La pregunta número uno bajo cada tarjeta de modelo y tutorial de IA local es «¿funcionará en mi máquina?». La insignia la responde en vivo desde el motor — recalculada cuando los datos se actualizan, no una afirmación obsoleta congelada en tu README. Si publicas modelos o escribes guías: una línea reemplaza un párrafo completo de FAQ y reduce los problemas de «se quedó sin memoria en mi tarjeta de 8 GB» antes de que se reporten.

Pregunta a tu asistente de IA (MCP)

El motor se ejecuta como un servidor MCP público en https://fitllm.run/api/mcp — conéctalo una vez y tu asistente responde «¿puedo ejecutar X en mi Y?» con las matemáticas de este motor en lugar de adivinar a partir de datos de entrenamiento obsoletos (los LLM suelen equivocarse en las matemáticas de la caché KV — consulta la tabla de 17.8× anterior).

• Claude (web / escritorio / móvil): Configuración → Conectores → Añadir conector personalizado → pega https://fitllm.run/api/mcp

• Claude Code: claude mcp add --transport http fitllm https://fitllm.run/api/mcp

• Cursor / Windsurf: añade a mcp.json → { "mcpServers": { "fitllm": { "url": "https://fitllm.run/api/mcp" } } }

• ChatGPT: Configuración → Aplicaciones → Avanzado → Modo desarrollador → añadir servidor MCP (Plus/Pro)

Herramientas: check_llm_fit (veredicto + desglose completo de memoria + sugerencia de corrección — admite configuraciones multi-GPU como "RTX 5090 + RTX 3090"), what_fits_on_hardware (lista clasificada para tu máquina), list_supported. Recursos: fitllm://models, fitllm://hardware, fitllm://census, fitllm://engine. Intencionalmente abierto: solo lectura, sin estado, sin autenticación, sin secretos — cada llamada es una función pura de datos públicos.

Listado en: registro oficial de MCP (run.fitllm/fitllm) · Glama · mcp.so · Smithery

Para agentes y scripts — API HTTP simple

¿Sin cliente MCP? Un GET, sin autenticación, sin clave — JSON por defecto, texto plano para curl:

curl 'https://fitllm.run/api/check?model=gemma%204%2031b&gpu=4090'
# multi-GPU rigs: gpu=5090%2B3090 · Mac: ram=64 · usage: curl https://fitllm.run/api/check

Datos abiertos: el Censo de Ajuste completo (más de 8,000 veredictos, CC0) en fitllm.run/data y en Hugging Face Datasets. Prueba el motor en el navegador: demo de HF Space.

Principios

Sin anuncios. Sin inicio de sesión. Sin enlaces de afiliado. La salida nunca está a la venta. El ajuste es una afirmación ganable y verificable; los tok/s brutos no lo son — por lo que este motor rechaza predicciones de velocidad en lugar de disfrazar una suposición como precisión.

Ayuda a calibrar

¿Ejecutaste un modelo y mediste el pico de memoria real? Reporta una medición — mejora las estimaciones para todos.

Creado por

yongha — GitHub. Impulsa fitllm.run.

Licencia

MIT © click6067-ship-it