Cómo elegir, dimensionar y desplegar modelos de pesos abiertos en producción: qué modelo para qué tarea, de qué tamaño, y sobre qué hardware — cubriendo CUDA y MLX.
Actualizado a mayo de 2026 — refleja la ola de lanzamientos de abril 2026 (DeepSeek V4, Qwen 3.6, Kimi K2.6).
Por qué solo modelos open-weights
Las APIs cerradas son fáciles. Pagas la cuenta, recibes la respuesta. La ingeniería interesante — y donde está la mayor parte de los malentendidos — está del lado de los pesos abiertos, donde realmente tienes que pensar en cantidad de parámetros, arquitectura MoE, cuantización, VRAM, y si tu Mac Studio realmente puede correr ese modelo de 1.6T que alguien tuiteó.
Esta guía cubre solo modelos de pesos abiertos. Todos los modelos descritos abajo se pueden descargar, correr en tu propio hardware, y enviar dentro de un producto sin pagar por token. El intercambio es que tienes que entender el hardware. De eso trata la mayor parte de esta guía.
Una nota sobre actualidad: la frontera de open-weights se mueve rápido — tres de los modelos más importantes en esta guía (DeepSeek V4, Qwen 3.6, Kimi K2.6) salieron dentro de una sola ventana de 30 días en abril 2026. Los números de versión específicos van a seguir cambiando. Los patrones arquitectónicos y el dimensionamiento de hardware no.
Parte 1 — Los modelos open-weights que importan en 2026
Hay aproximadamente 7 familias de modelos que vale la pena conocer para trabajo de producción real. Cualquier cosa que no esté en esta lista es un artefacto de investigación o una variante más pequeña de una de estas.
DeepSeek — Familia V4 (lanzada el 24 de abril de 2026)
DeepSeek V4 es la frontera actual de open-weights. Dos variantes lanzadas simultáneamente, ambas bajo licencia MIT, ambas con contexto de 1M de tokens. El cambio arquitectónico principal es la atención híbrida CSA + HCA (Compressed Sparse Attention + Heavily Compressed Attention), que reduce los FLOPs de inferencia a ~27% de V3.2 y la ocupación de KV cache a ~10% en contextos de 1M.
Tamaños que realmente usas:
- DeepSeek V4-Pro (MoE, 49B activos / 1.6T totales) — clase frontera, compite con Claude Opus y GPT-5 en programación y razonamiento.
- DeepSeek V4-Flash (MoE, 13B activos / 284B totales) — rápido, eficiente, ejecutable en una configuración multi-GPU que la mayoría de equipos pueden costear.
- DeepSeek R1 (aún mantenido, MoE 37B/671B) — predecesor afinado para razonamiento; sigue siendo relevante si ya estás desplegado con él o quieres una opción de razonamiento frontera más pequeña.
Licencia: MIT. Tan limpia como puede ser.
Casos de uso reales:
- «GPT-5 privado» auto-hospedado para una empresa regulada — un banco mexicano (Banorte, Banamex), una EPS colombiana, un hospital chileno, una fintech brasileña sujeta a LGPD, o una entidad gubernamental sujeta a soberanía de datos. V4-Pro sobre 8× H200 en un datacenter privado es la respuesta estándar en 2026 cuando no puedes mandar datos a APIs cerradas pero necesitas calidad frontera.
- Pipeline de revisión de código a alto volumen. V4-Flash procesa pull requests, code review, sugerencias de refactorización, herramientas de migración automatizada. Con 13B parámetros activos, el throughput por GPU es excelente y el costo por token es despreciable después del hardware.
- Análisis de documentos largos a escalas que hace seis meses solo eran posibles vía API. El contexto de 1M de V4 con el nuevo mecanismo de atención realmente funciona en rangos largos (el KV cache no explota). Útil para due diligence legal, revisión de literatura científica, análisis de bases de código completas.
- Inferencia barata vía la API de DeepSeek si no quieres auto-hospedar. V4-Flash a $0.14/M de tokens de entrada es ~18× más barato que el flagship de GPT-5 y suficientemente bueno para la mayoría del trabajo de producción.
- Base frontera para fine-tunes propietarios. La licencia MIT hace el fine-tuning comercial legalmente limpio — importante para SaaS verticales que quieren construir un modelo defendible sobre una base abierta.
Realidad de hardware: V4-Pro a precisión completa necesita un cluster de 8× H100/H200. V4-Flash entra cómodo en 2–4× H100 a FP8, o un Mac Studio de gama alta con cuantización fuerte para inferencia de un solo usuario. La mayoría de equipos van a usar V4-Pro vía API y auto-hospedar V4-Flash si necesitan control.
Moonshot — Kimi K2.6 (lanzado abril 2026)
Kimi K2.6 es el modelo open-weights más fuerte para programación a mediados de 2026 — top de cada benchmark relevante para tareas de programación autónoma de largo horizonte. INT4 QAT nativo (entrenamiento consciente de cuantización), lo que significa que está específicamente construido para correr cuantizado sin pérdida de calidad. Incluye capacidad de «agent swarm» — puede orquestar hasta 300 sub-agentes en paralelo.
Tamaños que realmente usas:
- Kimi K2.6 (MoE, 32B activos / 1T totales) — INT4 nativo, capacidad visual, contexto de 256K.
- Kimi K2.5 (predecesor) — aún ampliamente desplegado, más barato de hospedar.
Licencia: MIT Modificada (libre para casi todo uso comercial; atribución requerida arriba de 100M MAU o $20M de ingresos mensuales).
Casos de uso reales:
- Productos de programación agéntica en producción (alternativas open-source a Cursor / Devin). K2.6 es el modelo detrás de varios de estos en 2026. Economía competitiva contra APIs cerradas para startups de IA con respaldo VC.
- Code review y análisis de PR auto-hospedado sobre bases de código empresariales. La cuantización INT4 nativa es crítica aquí — obtienes calidad de programación frontera con materialmente menos hardware del que requiere V4-Pro.
- Tareas autónomas de largo horizonte — Moonshot demostró K2.6 ejecutando 4,000+ llamadas a herramientas a lo largo de 12+ horas para completar un proyecto real de ingeniería. Útil para trabajo agéntico nocturno por lotes (migraciones de bases de código, refactors a gran escala, generación de documentación).
- Bases de código políglotas (Rust + Go + Python + frontend + DevOps). K2.6 generaliza entre lenguajes mejor que la mayoría de modelos especializados en código, que tienden a ser muy enfocados en Python.
- Apps donde desplegar capacidad frontera de programación en tu propio hardware es ventaja competitiva — software de defensa, sistemas de trading financiero, firmware de dispositivos médicos. El código mismo es la propiedad intelectual y no puede salir del edificio.
Realidad de hardware: El INT4 nativo significa que K2.6 es genuinamente desplegable en 4× H100 o 2× H200, lo cual es mucho más accesible que V4-Pro. Cuantización fuerte corre en un Mac Studio de 256GB para inferencia de un solo usuario.
Alibaba — Familia Qwen 3.5 / 3.6
La familia abierta más completa. Cubre cada clase de tamaño desde sub-1B hasta flagships MoE de 1T. Qwen 3.5 (febrero 2026) fue el lanzamiento generacional principal; Qwen 3.6 (marzo-abril 2026) es el refresh enfocado en programación agéntica encima. Ambas líneas están activamente mantenidas.
Tamaños que realmente usas (mezcla Qwen 3.5 / 3.6):
- Qwen 3.5 4B / 9B / 27B (denso) — todoterreno fuertes. El 9B específicamente saca 81.7 en GPQA Diamond, sin precedente para modelos sub-30B.
- Qwen 3.6 27B (denso) — refresh del 27B con mejor programación agéntica.
- Qwen 3.6 35B-A3B (MoE, 3B activos / 35B totales) — el punto dulce de throughput de todo el ecosistema open en 2026. Calidad de 35B a velocidad de clase 3B.
- Qwen 3.5 122B-A10B (MoE, 10B activos / 122B totales) — corre en una Mac de 64GB.
- Qwen 3.5-397B-A17B flagship (MoE, 17B activos / 397B totales) — clase frontera.
- Qwen 3.6-Max-Preview — actualmente solo API, no open-weight; se menciona solo porque las derivadas open-weight de 3.6 fluyen de él.
Licencia: Apache 2.0 para tamaños hasta ~30B; personalizada (utilizable comercialmente) para los flagships más grandes.
Casos de uso reales:
- Soporte multilingüe para productos globales. Qwen maneja mandarín, japonés, coreano, indonesio, vietnamita, hindi, árabe, portugués (importante para operaciones que cubren Brasil) y español a calidad que Llama no puede igualar. La opción por defecto para cualquier producto LATAM con expansión a Asia.
- Backend de chat de alto throughput con presupuesto de latencia ajustado. Qwen 3.6 35B-A3B sirve 3–5× más usuarios concurrentes por GPU que alternativas densas de 30B porque solo 3B parámetros están activos por token. La mejor relación precio/desempeño para servir en producción en 2026.
- Programación agéntica local sobre Apple Silicon. Qwen 3.6 35B-A3B corre cómodo en una MacBook Pro M-series de 64GB vía MLX. Esta combinación (MLX + 35B-A3B MoE) se está volviendo el setup estándar para desarrolladores individuales.
- Despliegue on-prem para empresas con requerimientos de soberanía de datos — se puede correr completamente desconectado del internet, cumpliendo con regulaciones locales de protección de datos (LGPD en Brasil, Ley 1581 en Colombia, Ley 25.326 en Argentina, LFPDPPP en México).
- Base de fine-tuning para SaaS verticales. Los tamaños Qwen 3.5 4B–14B son las bases de fine-tuning más costo-efectivas del ecosistema — suficientemente pequeñas para fine-tunear en una sola GPU, suficientemente capaces para enviar a producción.
- Despliegue en edge. Los tamaños Qwen 3.5 0.8B y 2B corren en celulares y dispositivos IoT — útil para funciones de IA offline en apps móviles.
Meta — Familia Llama 4
La línea open más soportada del mundo. Cada framework de inferencia, librería de fine-tuning e integración de herramientas soporta Llama primero. Llama 4 introdujo MoE (Scout + Maverick) y multimodalidad nativa. Llama 3.3 70B sigue siendo el caballo de batalla denso; Llama 4 Behemoth (288B activos / ~2T totales) fue anunciado como modelo maestro pero no ha sido liberado como open-weights.
Tamaños que realmente usas:
- Llama 3.3 70B (denso) — sigue siendo el 70B abierto más desplegado en producción.
- Llama 4 Scout (MoE, 17B activos / 109B totales, 16 expertos) — entra en una sola H100 con cuantización INT4, contexto de 10M tokens.
- Llama 4 Maverick (MoE, 17B activos / 400B totales, 128 expertos) — entra en un solo host H100 DGX (8× H100), contexto 1M, multimodal nativo.
Licencia: Llama 4 Community License. Permisiva para la mayoría de usuarios; requiere licencia especial arriba de 700M MAU. No disponible para empresas domiciliadas en la UE a inicios de 2026 — esto es un detalle importante a verificar en la licencia actual antes de usar Llama 4 en cualquier despliegue cross-border desde LATAM.
Casos de uso reales:
- Asistente interno de empresa entrenado sobre tu wiki/documentación. Un fine-tune con LoRA de Llama 3.3 70B sobre documentación interna, servido vía vLLM en una sola H100, le da a cada empleado un equivalente privado de ChatGPT. El patrón de despliegue Llama más común en empresas medianas y grandes en LATAM.
- RAG multimodal sobre bibliotecas de documentos (PDFs con diagramas, formularios escaneados, gráficas). La comprensión de imágenes nativa de Llama 4 Scout + contexto de 10M maneja esto en un solo modelo. Caso típico: archivo histórico de actas notariales, expedientes médicos digitalizados, repositorios de diseño de ingeniería.
- Workflows de documentos largos — análisis de bases de código completas, procesamiento de documentos del tamaño de un libro, memoria conversacional de múltiples sesiones. El contexto de 10M de Scout es genuinamente útil aquí.
- SaaS multi-tenant donde necesitas auto-hospedar. Llama es la opción abierta más segura porque cada dependencia que necesitas (vLLM, TGI, Ollama, llama.cpp, MLX) lo soporta desde el día cero.
- Equipos de fine-tuning que necesitan máximo soporte de librerías. Llama es la base de fine-tuning más documentada y soportada del ecosistema.
Mistral
El laboratorio insignia europeo. Pragmático, bien licenciado, enfocado en código. Menos hype que DeepSeek o Kimi, más confiabilidad.
Tamaños que realmente usas:
- Mistral Small 3 (~24B denso) — eficiente, buena obediencia a instrucciones.
- Mistral Medium / Large 3 — flagships densos y MoE clase frontera.
- Codestral / Devstral — especializados en código; Devstral está afinado para programación agéntica multi-archivo.
- Magistral (~24B razonamiento) — modelo abierto de razonamiento.
Licencia: Apache 2.0 para la mayoría de releases.
Casos de uso reales:
- Chatbot on-prem cumpliendo con regulaciones de protección de datos — particularmente útil cuando el cliente requiere modelo de origen no-chino (algunos sectores en defensa, banca y gobierno tienen estos requisitos).
- Herramienta de programación agéntica que edita múltiples archivos. Devstral está hecho específicamente para esto — es el modelo detrás de varias alternativas open-source a Cursor.
- Backend de function-calling para features de producto. Los modelos Mistral son confiables para salida estructurada en JSON sin necesidad de prompting exótico. Común en features tipo «lenguaje natural → consulta estructurada».
- Procesamiento de documentos en español, portugués, francés donde Mistral tiene una ventaja medible sobre Qwen en variantes europeas del español.
- Asistente de programación local barato en una sola GPU. Devstral 24B en una GPU de 24GB corre cómodo y maneja tareas reales de refactorización.
Google — Familia Gemma
La respuesta abierta de Google a Llama y Qwen. Apache 2.0, tamaños desde ~1B hasta ~30B, con visión y tool calling en la última generación.
Tamaños que realmente usas:
- Gemma 4 9B — modelo pequeño fuerte con visión + tool calling.
- Gemma 4 27B — denso de tamaño medio; buena obediencia a instrucciones.
Licencia: Apache 2.0.
Casos de uso reales:
- Agente local con tool calling sobre hardware modesto. Gemma 4 9B en una GPU de 16GB maneja function calling de forma confiable — bueno para asistentes de escritorio, extensiones de navegador, automatización ligera.
- Pipeline de extracción de visión + texto sin pagar precios de API — leer screenshots, extraer datos de gráficas, procesar formularios escaneados (usos típicos: digitalización de archivos, automatización de back-office en aseguradoras).
- Despliegue en edge o on-device para apps móviles, kioscos, dispositivos industriales. Gemma es la familia abierta más optimizada para esto.
- Apps donde Apache 2.0 es legalmente requerida. Algunos procesos de procurement gubernamental y distribuciones OSS requieren específicamente una licencia aprobada por OSI. Gemma y Mistral son las opciones más limpias.
- Workloads sobre Google Cloud / Vertex AI donde Gemma tiene soporte de infraestructura de primera clase.
NVIDIA — Familia Nemotron
Los releases abiertos de NVIDIA, principalmente para mostrar lo que su stack de entrenamiento e inferencia puede hacer. Vale considerarlo si ya estás profundamente invertido en CUDA/TensorRT/NeMo.
Tamaños que realmente usas:
- Nemotron Nano (~4B–9B) — razonamiento eficiente.
- Nemotron Cascade / Ultra — variantes MoE más grandes afinadas para razonamiento.
Licencia: Varía por release; mayormente open-weight permisiva.
Casos de uso reales:
- Inferencia en producción exprimiendo cada token/seg de H100/H200/B200. Nemotron está co-diseñado con TensorRT-LLM y da throughput medible mejor que Llama/Qwen equivalente en el mismo hardware NVIDIA.
- Workloads de razonamiento sobre NVIDIA NIM microservices — si tu equipo de plataforma estandarizó en NIM, Nemotron es el camino de menor resistencia.
- Equipos de fine-tuning que ya usan NVIDIA NeMo. Quedarse dentro de un solo toolchain vale mucho operacionalmente.
Parte 2 — 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.
