La Parte 2 desglosa la economía del dimensionamiento de los LLM modernos, así como los costos reales de memoria y cómputo que implica ejecutar los modelos actuales.
Dimensionamiento: denso vs MoE, y qué cuesta cada uno
Esta es la sección donde la mayoría se equivoca.
Los dos números de parámetros que importan
Cada LLM moderno tiene dos tamaños relevantes:
- Parámetros totales — qué tan grande es el modelo en disco y en memoria. Determina la capacidad de hardware requerida.
- Parámetros activos por token — cuántos parámetros realmente computan para cada token generado. Determina el throughput (tokens/seg) y el costo de energía.
Para modelos densos, estos números son iguales. Llama 3.3 70B usa los 70B para cada token.
Para MoE (Mixture of Experts), son muy diferentes. DeepSeek V4-Pro tiene 1.6T totales pero solo 49B activos por token. El modelo es enorme en memoria pero computa como un 49B para cada token generado. Ese es el punto entero de MoE — capacidad sin compute proporcional.
Implicaciones prácticas
| Denso | MoE | |
|---|---|---|
| Memoria requerida | = parámetros totales × bytes/parámetro | = parámetros totales × bytes/parámetro (igual — todos los expertos deben estar cargados) |
| Throughput por GPU | proporcional a parámetros totales | proporcional a parámetros activos |
| Mejor para | comportamiento predecible, fine-tuning fácil, despliegue en una sola GPU | servir alto volumen, capacidad frontera sin compute frontera |
| Peor para | escalar capacidad más allá de lo que entra en una GPU | despliegue de un solo usuario a pequeña escala (pagas el costo total de memoria sin servir suficientes usuarios para amortizarlo) |
Regla práctica: si tienes un usuario o pocos, los modelos densos te dan mejor calidad por GB de VRAM. Si estás sirviendo muchos usuarios concurrentes, MoE gana decisivamente porque pagas el costo de memoria una vez y sirves muchos requests a la velocidad de los parámetros activos.
La matemática de memoria
Memoria aproximada necesaria para cargar un modelo:
memoria ≈ parámetros × bytes_por_parámetro + KV cache + overhead
Bytes por parámetro:
| Precisión | Bytes/parám | Calidad | Cuándo usar |
|---|---|---|---|
| FP16 / BF16 | 2 | Referencia | Servir en producción sobre GPUs de datacenter |
| FP8 | 1 | Cerca de referencia | Servir en producción moderno H100/H200 |
| INT8 | 1 | Pérdida mínima | Servir en producción cuando FP8 no está disponible |
| INT4 (Q4_K_M, AWQ, GPTQ) | 0.5 | Pequeña pero aceptable | El default para inferencia local |
| INT3 / INT2 | 0.25–0.4 | Degradación notable | Último recurso para meter un modelo frontera en hardware de consumo |
Suma 10–30% de overhead para KV cache (escala con la longitud de contexto) y runtime.
Caso especial — modelos con cuantización nativa como Kimi K2.6 son entrenados con cuantización (QAT), lo que significa que la inferencia INT4 es el despliegue intencionado, no un fallback degradado. La pérdida de calidad vs precisión completa es esencialmente cero.
Ejemplos calculados (modelos actuales)
| Modelo | Params totales | Params activos | Memoria FP16 | Memoria INT8 | Memoria INT4 |
|---|---|---|---|---|---|
| Gemma 4 9B | 9B (denso) | 9B | ~18 GB | ~9 GB | ~5 GB |
| Mistral Small 3 24B | 24B (denso) | 24B | ~48 GB | ~24 GB | ~12 GB |
| Qwen 3.5 27B | 27B (denso) | 27B | ~54 GB | ~27 GB | ~14 GB |
| Qwen 3.6 35B-A3B (MoE) | 35B | 3B | ~70 GB | ~35 GB | ~18 GB |
| Llama 3.3 70B | 70B (denso) | 70B | ~140 GB | ~70 GB | ~35 GB |
| Llama 4 Scout (MoE) | 109B | 17B | ~218 GB | ~109 GB | ~55 GB |
| Qwen 3.5 122B-A10B (MoE) | 122B | 10B | ~244 GB | ~122 GB | ~61 GB |
| DeepSeek V4-Flash (MoE) | 284B | 13B | ~568 GB | ~284 GB | ~142 GB |
| Llama 4 Maverick (MoE) | 400B | 17B | ~800 GB | ~400 GB | ~200 GB |
| Qwen 3.5-397B-A17B (MoE) | 397B | 17B | ~794 GB | ~397 GB | ~199 GB |
| Kimi K2.6 (MoE, INT4 nativo) | 1T | 32B | — | — | ~500 GB (nativo) |
| DeepSeek V4-Pro (MoE) | 1.6T | 49B | ~3.2 TB | ~1.6 TB | ~800 GB |
Estos son solo pesos. Suma 10–30% encima para KV cache y overhead.
Parte 3 — Hardware: CUDA y MLX, números reales
Dos caminos viables en 2026: NVIDIA CUDA (el estándar de producción) y Apple MLX/Metal (la jugada de valor para inferencia de modelos grandes de un solo usuario). AMD está mejorando pero todavía no es una opción mainstream para servir LLMs en producción.
Nota sobre disponibilidad en LATAM: Las GPUs de datacenter (A100, H100, H200, B200) son difíciles y caras de conseguir directamente en la región. La realidad práctica para la mayoría de equipos LATAM es: alquilarlas en AWS São Paulo, GCP, Azure México, o proveedores especializados como Lambda Labs, RunPod, o Vast.ai. Costos de importación, aranceles, y tiempos de entrega para hardware on-prem hacen que la nube sea casi siempre más barata para empezar.
Tier 1 — GPU única de consumo (NVIDIA)
| Hardware | VRAM | Qué corre (INT4) | Qué corre (FP16) | Uso realista |
|---|---|---|---|---|
| RTX 3060 12GB | 12 GB | Hasta ~13B denso, Gemma 4 9B INT4 | Hasta ~7B denso | Hobbyista, aprendizaje, máquina de desarrollo para modelos pequeños |
| RTX 4070 Ti / 5070 16GB | 16 GB | Hasta ~22B denso, Gemma 4 9B FP16 | Hasta ~8B denso | Asistente de código pequeño, agentes Gemma |
| RTX 4090 24GB | 24 GB | Hasta ~34B denso, Qwen 3.6 35B-A3B | Hasta ~13B denso | El verdadero punto dulce para desarrolladores individuales |
| RTX 5090 32GB | 32 GB | Hasta ~50B denso, Mistral Small FP8 | Hasta ~16B denso | Más holgura, futuro-prueba la longitud de contexto |
Ejemplos de throughput (RTX 4090):
- Llama 3.3 70B Q4 — ~20–35 t/s
- Qwen 3.6 35B-A3B Q4 — ~50–80 t/s (ventaja de MoE — solo 3B activos)
- Mistral Small 24B Q4 — ~40–60 t/s
Escenarios reales de producción en este tier:
- Desarrollador individual corriendo un asistente de código privado (Devstral 24B o Qwen 3.6 35B-A3B).
- RAG interno de equipo pequeño sobre documentos de empresa (Llama 3.3 70B Q4).
- Prototipo de startup antes de moverse a hardware de producción.
- Workflows agénticos locales para power users (Gemma 4 9B con tool calling).
Tier 2 — Workstation multi-GPU de consumo
| Hardware | VRAM | Qué corre | Uso realista |
|---|---|---|---|
| 2× RTX 4090 (paralelismo de tensores en vLLM) | 48 GB | Llama 3.3 70B FP8, Qwen 3.6 35B-A3B FP16 | Servir en producción para equipo pequeño, experimentos de fine-tuning |
| 2× RTX 5090 | 64 GB | 70B en FP16, Llama 4 Scout en INT4 | Servir local serio, despliegue MoE de tier medio |
| 4× RTX 4090 / 5090 | 96–128 GB | Llama 4 Scout en FP8/FP16, Qwen 3.5 122B-A10B en INT4 | Producción mono-tenant para herramienta interna |
Advertencia: Las GPUs de consumo no están diseñadas para carga sostenida 24/7. El enfriamiento y la energía se vuelven problemas reales de ingeniería. Para cualquier cosa más allá de una sola workstation, considera GPUs de datacenter.
Escenarios reales de producción:
- Tooling de IA interno para SaaS mediano de ~50–200 empleados.
- Fine-tuning de un modelo 70B con LoRA / QLoRA.
- Servidor de inferencia interno para un equipo de ingeniería de 5–20 personas.
Tier 3 — Apple Silicon (MLX / Metal)
Donde Apple es genuinamente competitivo — y donde la mayoría malentiende el intercambio.
La ventaja: memoria unificada. Una Mac Studio con 256GB de memoria unificada puede sostener modelos que de otra forma requerirían 4–8× H100s — a una fracción del precio (~10K USD para la Mac vs $80K+ para el equivalente en GPU). Importante para LATAM donde importar Macs es más barato y rápido que importar GPUs de datacenter de NVIDIA.
La trampa: menor throughput por request. Los cores de GPU de Apple tienen menor FLOPS bruto que NVIDIA de datacenter, y el stack de software de inferencia (MLX, llama.cpp Metal backend) todavía no iguala las optimizaciones de CUDA (variantes de FlashAttention, aceleración FP8, batching avanzado).
| Hardware | Memoria unificada | Qué corre cómodo (INT4) | Uso realista |
|---|---|---|---|
| MacBook Pro M4 Max 36GB | 36 GB | Hasta ~50B denso, Qwen 3.6 35B-A3B | Asistente de código de desarrollador individual |
| MacBook Pro M4 Max 64GB | 64 GB | Llama 3.3 70B Q4, Qwen 3.5 122B-A10B Q4 | Power user, demos, evaluación de modelos |
| Mac Studio M3 Ultra 96GB | 96 GB | Llama 3.3 70B FP8, Llama 4 Scout INT4 | Single-user pesado, asistente compartido en oficina pequeña |
| Mac Studio M3 Ultra 192GB | 192 GB | Llama 4 Scout FP8, Llama 4 Maverick INT4, DeepSeek V4-Flash INT4 | Inferencia de MoE frontera para un solo usuario |
| Mac Studio M4 Ultra 256–512GB | 256+ GB | DeepSeek V4-Flash FP8, Kimi K2.6 INT4 nativo, V4-Pro con cuantización fuerte | Inferencia frontera local seria; la máquina del titular «corriendo modelos de 1T localmente» |
Ejemplos de throughput (Mac Studio M3 Ultra, benchmarks reales):
- Llama 3.3 70B Q4 — ~10–15 t/s (vs 20–35 en 4090, pero la Mac monta modelos mucho más grandes)
- Qwen 3.6 35B-A3B Q4 — ~25–40 t/s; MLX corre aproximadamente 2× más rápido que Ollama en el mismo modelo — vale la pena saberlo
- Kimi K2.6 INT4 nativo — t/s de un dígito pero corre, que es el punto
- DeepSeek V4-Flash INT4 — ~5–10 t/s en máquinas de 192GB+
MLX vs llama.cpp en Apple Silicon: MLX (el framework nativo de Apple) da el mejor desempeño para muchos modelos — hasta 2× sobre llama.cpp Metal en Qwen 3.6 35B-A3B en benchmarks publicados. llama.cpp tiene soporte más amplio de modelos. La mayoría de la gente termina usando ambos según el modelo.
Escenarios reales de producción:
- Desarrollador individual o equipo pequeño corriendo Llama 3.3 70B o Qwen 3.6 35B-A3B localmente para trabajo diario de código — la mejor relación precio/desempeño para este caso de uso en 2026.
- Investigador evaluando modelos abiertos frontera sin acceso a datacenter.
- Consultoría pequeña dando demos in situ de modelos grandes a clientes que requieren ver el modelo correr fuera de la nube.
- Power user enfocado en privacidad corriendo un modelo frontera completamente offline.
- La Mac Studio de 256GB+ específicamente para «demostrar Kimi K2.6 o DeepSeek V4-Flash en una sola máquina.»
Para qué NO sirve MLX: servir alta concurrencia. Si necesitas servir más de ~5 usuarios concurrentes, NVIDIA gana decisivamente.
Tier 4 — GPU única de datacenter
| Hardware | VRAM | Qué corre (FP16) | Características de throughput |
|---|---|---|---|
| A100 80GB | 80 GB | Llama 3.3 70B FP16, Mistral Large denso, Qwen 3.6 35B-A3B con contexto enorme | Caballo de batalla confiable; ~2× más lento que H100 pero más barato |
| H100 80GB | 80 GB | Igual que A100 + soporte FP8 nativo; Llama 4 Scout INT4 | Estándar de producción para modelos clase 70B |
| H200 141GB | 141 GB | Llama 4 Scout FP16, Qwen 3.5 122B-A10B FP16, contextos muy largos | Mejor GPU única para MoE clase 100B |
| B200 (Blackwell) | 192 GB | DeepSeek V4-Flash INT4, modelos MoE más grandes | Tier top actual; salto mayor de throughput sobre H100 |
Escenarios reales de producción:
- Servir en producción para SaaS con cientos a miles de usuarios (vLLM + Llama 70B en H100).
- Pipeline de procesamiento por lotes (extraer datos estructurados de millones de documentos).
- Plataforma de IA interna empresarial sirviendo a miles de empleados.
- Fine-tuning de modelos 7B–13B en precisión completa; LoRA en 70B.
Costo realista en LATAM: En la nube — $2–5 USD/hora dependiendo del proveedor. AWS São Paulo tiende a ser más caro que us-east. On-prem H100 — ~$25–40K USD por GPU más el servidor, sin contar aranceles e impuestos de importación que pueden agregar 20–40% en países como Argentina o Brasil.
Tier 5 — Cluster multi-GPU de datacenter
| Configuración | VRAM total | Qué corre | Caso de uso |
|---|---|---|---|
| 4× H100 / 2× H200 | 320–280 GB | Kimi K2.6 INT4 nativo, DeepSeek V4-Flash FP8, Llama 4 Maverick INT4 | La nueva línea base de «modelo abierto frontera» en 2026 |
| 8× H100 (un nodo DGX) | 640 GB | Llama 4 Maverick FP8, DeepSeek V4-Flash FP16, Kimi K2.6 FP8 | Configuración estándar para «modelo abierto frontera en producción» |
| 8× H200 | 1.1 TB | DeepSeek V4-Pro INT8, Kimi K2.6 FP16 | Servir MoE frontera con calidad máxima |
| 16× H100+ (multi-nodo, InfiniBand) | 1.3 TB+ | DeepSeek V4-Pro FP16, servir frontera con contexto muy largo | Servir hiperescala, proveedores de modelos |
Escenarios reales de producción:
- Auto-hospedar DeepSeek V4 para una empresa regulada (banco, hospital, gobierno).
- Startup sirviendo un modelo abierto frontera como su propio producto API.
- Plataforma de IA multi-tenant con miles de usuarios concurrentes.
- Laboratorio de investigación corriendo inferencia frontera + experimentos de fine-tuning.
Parte 4 — Matriz rápida de decisión
| Si tu situación es… | Elige este modelo | En este hardware |
|---|---|---|
| Dev individual, quiere asistente de código | Qwen 3.6 35B-A3B o Devstral 24B | RTX 4090 / Mac M4 Max 36GB+ |
| Equipo pequeño, RAG interno sobre documentos | Llama 3.3 70B (Q4) | RTX 4090 / Mac Studio 96GB / H100 en nube |
| SaaS mediano, necesita auto-hospedar features de IA | Llama 3.3 70B o Qwen 3.6 35B-A3B | 1× H100 con vLLM |
| Empresa con requisitos de soberanía de datos LATAM | Mistral Small / Medium o Qwen 3.6 35B-A3B | 1× H100 o 2× RTX 5090, datacenter local |
| Producto multilingüe (LATAM + Asia) | Familia Qwen 3.5 / 3.6 | Dimensionado a tu tráfico |
| Calidad open frontera, industria regulada (banca/salud/gobierno) | DeepSeek V4-Pro | Cluster 8× H200 |
| Agente de programación frontera auto-hospedado | Kimi K2.6 (INT4 nativo) | 4× H100 o 2× H200 |
| Producto open de programación agéntica (startup) | Kimi K2.6 o DeepSeek V4-Flash | Single H100 DGX o proveedor hosted |
| Investigación de razonamiento/matemáticas | DeepSeek R1 o V4-Pro | 8× H100 / H200 |
| Agente local con tool calling con presupuesto ajustado | Gemma 4 9B | RTX 4070 Ti / Mac M3 Pro |
| Visión + texto en hardware de consumo | Gemma 4 9B (visión) o Llama 4 Scout | RTX 4090 / Mac M4 Max |
| Modelo frontera en una sola máquina para uso personal | Kimi K2.6 (INT4 nativo) o DeepSeek V4-Flash | Mac Studio M4 Ultra 256GB+ |
| Exprimir máximo throughput de hardware NVIDIA | Variantes Nemotron | H100/H200/B200 con TensorRT-LLM |
| Contexto largo (>1M tokens) | Llama 4 Scout (10M) o DeepSeek V4 (1M) | Dimensionado al modelo |
Parte 5 — Tres patrones que vale internalizar
1. MoE es para servir, denso es para que entre. ¿Corriendo un usuario en una máquina? Los modelos densos te dan más calidad por GB de memoria. ¿Sirviendo muchos usuarios? MoE gana porque la cantidad de parámetros activos define tu costo por token mientras que la cantidad de parámetros totales define tu cuenta única de memoria.
2. La Mac Studio es real, pero solo para inferencia de modelos grandes con un solo usuario. Una Mac Studio de 256GB corre modelos que costarían $80K+ USD en hardware NVIDIA, a velocidades de un solo usuario. Genuinamente útil para desarrolladores individuales, investigadores, consultorías pequeñas. Especialmente relevante en LATAM donde el costo y dificultad de importar GPUs de datacenter NVIDIA hace que la Mac sea una alternativa práctica seria. No es plataforma para servir en producción — para eso, NVIDIA gana en throughput, batching, y madurez de software. Usa MLX sobre llama.cpp cuando ambos soporten el modelo — speedups medibles de 2× en 2026.
3. La cuantización nativa cambia la matemática del despliegue. Kimi K2.6 sale en INT4 nativo. DeepSeek V4 sale en mezcla FP8 + FP4. Esto es un cambio importante respecto al mundo viejo donde la cuantización siempre era un intercambio de calidad-vs-encajar. Para modelos con cuantización nativa, INT4 es el despliegue intencionado — no estás cediendo nada. Espera más modelos siguiendo este patrón a lo largo de 2026.
Reflexión final
Los pesos abiertos en 2026 cubren todo el espectro de calidad. Ya no hay capacidad frontera que esté disponible solo detrás de una API cerrada — DeepSeek V4-Pro, Kimi K2.6, y Qwen 3.6 Max están todos a distancia de golpe de GPT-5 y Claude Opus en los benchmarks que importan para trabajo de producción. La pregunta real de ingeniería ya no es «abierto vs cerrado» — es «qué modelo abierto, a qué cuantización, en qué hardware, para qué workload.» Los números de esta guía te deberían dar suficiente para tomar esa decisión sin adivinar.
Para LATAM específicamente, el caso de auto-hospedar modelos open-weights es aún más fuerte que en otras regiones: regulaciones de soberanía de datos en cada país (LGPD, Ley 1581, LFPDPPP, Ley 25.326), volatilidad cambiaria que hace impredecibles los costos en USD de las APIs, y latencia desde datacenters norteamericanos que importa para experiencias de usuario. La estrategia ganadora típica es: empezar en API para validar producto, mover el volumen sostenido a auto-hospedaje en cuanto el gasto mensual justifique la inversión.
El ritmo va a continuar. Espera otra ola mayor de releases para finales del Q3 2026 — probablemente DeepSeek V4.x, Qwen 4, y un refresh de Llama 4.x. Los patrones arquitectónicos — economía de MoE, intercambios de cuantización, MLX vs CUDA, matriz de dimensionamiento-a-hardware — no van a cambiar. Construye tu sistema alrededor de los patrones, no de los nombres de modelos.
