--- title: "AirLLM con 4 GB de VRAM: inferencia por capas" canonical: https://wavect.io/es/blog/airllm-layer-wise-inference-low-vram/ language: es description: "¿AirLLM ejecuta modelos 70B a 2,8T con 4 GB de VRAM? Entiende la inferencia por capas, el coste de disco y velocidad, y cuándo hacer un piloto." image: "https://wavect.io/img/blog/headers/header_airllm-layer-wise-inference-low-vram.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min de lectura · 20 de agosto de 2026 Última revisión 20 de agosto de 2026 [**Siguiente**](/es/blog/moneyprinterturbo-review-2026/) # AirLLM con 4 GB de VRAM: cómo funciona la inferencia por capas Resumen AirLLM reduce el pico de memoria de GPU cargando solo la capa actual o, en modelos sparse compatibles, los expertos elegidos por el router. Su repositorio reporta unos 4 GB de VRAM para 70B, 8 GB para Llama 3.1 405B, 12 GB para DeepSeek-V3 y 3,72 GB para Kimi K3. Son afirmaciones de ejecución y memoria máxima, no garantías de throughput productivo. El checkpoint completo sigue en disco, cada token puede provocar nuevas transferencias de pesos y el contexto y los buffers también consumen memoria. El proyecto no publica tokens por segundo reproducibles para esos titulares. Kimi K3 además distribuye pesos MXFP4 nativos, por lo que "sin cuantización" no describe bien ese caso. AirLLM encaja en investigación, evaluación offline y pruebas de acceso a modelos. Para un servicio a clientes, mide tiempo al primer token, velocidad de decode, espacio, concurrencia, calidad y coste total frente a un modelo cuantizado menor o una API. **Sí, AirLLM puede ejecutar un modelo mucho mayor que la VRAM de la GPU.** Eso no significa que el modelo quepa en la tarjeta. El checkpoint sigue en disco. AirLLM carga la capa o los expertos necesarios, calcula, libera memoria y repite. Cambia residencia en memoria por movimiento de datos. Un pico de 4 GB no revela el espacio en disco, el tiempo de preparación, la latencia, el contexto útil ni la concurrencia. Verificamos esta guía el **20 de agosto de 2026** y le damos un intent acotado: explicar AirLLM con poca VRAM y decidir cuándo merece un piloto comercial. Para elegir un modelo local convencional que sí encaje en tu equipo, usa nuestra [guía de hardware para LLM locales](/es/blog/llmfit-local-llm-hardware-guide/). | Afirmación | Qué apoya la evidencia | Qué no demuestra | | --- | --- | --- | | 70B con 4 GB de VRAM | Solo reside una capa cada vez | Velocidad interactiva | | Llama 3.1 405B con 8 GB | Hay un código y notebook públicos | Benchmark full precision reproducible | | DeepSeek-V3 con unos 12 GB | Soporte y cifra de memoria máxima | Latencia, concurrencia o fiabilidad | | Kimi K3 2,8T con 3,72 GB | Medición del mantenedor en una RTX 6000 Ada | El checkpoint de 1,6 TB sigue en almacenamiento | | Sin cuantización | AirLLM no obliga a comprimir ciertos pesos | Kimi K3 ya usa MXFP4 nativo | ## ¿Qué es AirLLM? AirLLM es una librería Python con licencia Apache 2.0. Divide checkpoints transformer compatibles en shards menores y los carga bajo demanda. El [repositorio oficial de AirLLM](https://github.com/lyogavin/airllm) anuncia soporte para Llama, Qwen, DeepSeek, Mistral, Phi, Gemma, Kimi K3 y otras familias mediante `AutoModel`. También ofrece compresión opcional de pesos en 4 u 8 bits, ejecución CPU, Apple Silicon y prefetch limitado. Su beneficio es el acceso. Permite examinar un checkpoint que fallaría al cargar por falta de VRAM. El precio son transferencias repetidas. Un servidor GPU normal conserva pesos residentes y los reutiliza para cada token. AirLLM los recupera desde un nivel más lento porque prioriza capacidad sobre throughput. ## ¿Cómo reduce VRAM la inferencia por capas? 1. **Divide el checkpoint.** AirLLM crea archivos por capa. El original y la copia transformada pueden coexistir durante el setup. 2. **Conserva el estado de ejecución.** Activaciones, atención, KV cache y buffers aún necesitan RAM o VRAM. 3. **Carga la capa actual.** Transfiere el bloque, calcula y reutiliza la memoria para el siguiente. 4. **Repite por token.** El decode autorregresivo vuelve a recorrer el modelo. Sin caché, vuelve el tráfico de disco. El pico de VRAM depende de la capa mayor, las activaciones y el workspace, no de la suma de parámetros. El disco sigue dependiendo del checkpoint completo. Los contextos largos, batches grandes y varias solicitudes aumentan la memoria de ejecución. ## ¿Por qué Kimi K3 puede reportar menos VRAM que un 70B denso? Kimi K3 no es un modelo denso. El [repositorio oficial de Kimi K3](https://github.com/MoonshotAI/Kimi-K3) documenta 93 capas, 896 expertos enrutados, 16 expertos seleccionados por token y 104.000 millones de parámetros activos. AirLLM carga solo los expertos elegidos. Ese working set puede ser menor que una capa densa de 70B aunque la biblioteca completa sea muchísimo mayor. La cifra de memoria máxima no reduce el download. El checkpoint publicado ronda 1,6 TB. Moonshot recomienda vLLM, SGLang y TokenSpeed para producción. AirLLM es una ruta experimental de acceso, no la receta de serving estándar del fabricante. ## La frase «sin cuantización» necesita una corrección AirLLM no exige cuantizar todos los checkpoints. Pero Kimi K3 se entrenó con quantization-aware training y se publicó con pesos MXFP4 y activaciones MXFP8. La afirmación viral confunde compresión añadida por el runtime con el formato descargado. Los tamaños también necesitan contexto. El [repositorio oficial de DeepSeek-V3](https://github.com/deepseek-ai/DeepSeek-V3) enumera 671.000 millones de parámetros principales, 37.000 millones activos por token y 14.000 millones adicionales en el módulo de predicción multitoken. «671B con 12 GB» describe VRAM máxima, no 671B pesos residentes. ## ¿Qué ocultan los 4 GB de VRAM? - **Disco:** original y shards pueden coexistir. En Kimi K3, solo el checkpoint fuente ronda 1,6 TB. - **I/O:** capas y expertos fríos cruzan almacenamiento, RAM y a veces PCIe. Prefetch no convierte NVMe en memoria GPU. - **Velocidad:** el README no publica una tabla reproducible de tokens/s para los grandes titulares. - **Contexto:** KV cache, activaciones y batching siguen consumiendo memoria. Una [auditoría pública de evidencia en el repositorio](https://github.com/lyogavin/airllm/issues/295) señala que el notebook 405B carece de resultados ejecutados de tiempo y memoria y utiliza un modelo pre-cuantizado de 4 bits. La velocidad es desconocida hasta fijar checkpoint, revisión, prompt, contexto, hardware y salida. ## AirLLM frente a un modelo que sí cabe | Necesidad | Mejor opción inicial | Motivo | | --- | --- | --- | | Inspeccionar un checkpoint gigante | Piloto AirLLM | Importa más el acceso que la respuesta | | Chat local privado | Modelo cuantizado menor | Los pesos residentes suelen dar mejor latencia | | API multiusuario | vLLM, SGLang o API gestionada | Batching y scheduling son esenciales | | Batch offline | Medir ambos | Una carga puede servir varias secuencias | | Producción | El menor modelo que apruebe la evaluación | La tarea aceptada importa más que los parámetros | El offload a disco crea capacidad, pero luego la arquitectura debe recuperar velocidad. El [paper de PRIMA.CPP](https://arxiv.org/abs/2504.08791) usa memory mapping, pipeline, prefetch y colocación de capas por dispositivo para modelos de 30B a 70B. No es un benchmark de AirLLM. Demuestra que la diferencia entre «ejecuta» y «ejecuta de forma útil» es un problema de sistemas. ## ¿Cuándo tiene sentido comercial un piloto? Prueba AirLLM para acceso offline ocasional, investigación de modelos, batches grandes o formación con hardware limitado. Descártalo si el cliente exige respuesta interactiva, hay varios usuarios simultáneos, se procesan datos regulados sin revisión de seguridad o un modelo cuantizado de 7B a 70B ya supera la misma evaluación. ## Plan de benchmark para decidir 1. Fija ID, revisión, formato de pesos, commit de AirLLM y versiones del runtime. 2. Mide pico de VRAM, RAM, swap, checkpoint, shards y espacio temporal. 3. Separa descarga, split, arranque frío, prefill, primer token y decode. 4. Prueba contexto, herramientas, idiomas, batch y concurrencia reales. 5. Compara calidad y coste por tarea aceptada con un baseline alojado. Después aplica nuestro [modelo de break-even entre LLM local y API](/es/blog/local-models-vs-apis-break-even-eu-2026/). Para términos, datos y compra, consulta la [review de Kimi K3 para empresas de la UE](/es/blog/kimi-k3-eu-api-production-review/). Para otra arquitectura NVMe con velocidad publicada, revisa el [análisis de Colibri](/es/blog/colibri-glm-5-2-consumer-hardware/). ## Fuentes y límites AirLLM aporta funciones y cifras de pico. Moonshot documenta arquitectura K3 y MXFP4. DeepSeek aporta sus parámetros. La auditoría pública documenta el hueco del notebook 405B. PRIMA.CPP da contexto independiente, pero no valida AirLLM. Wavect no descargó los checkpoints de terabytes ni reprodujo los picos. ## Preguntas frecuentes ### ¿Puede AirLLM ejecutar 70B con 4 GB de VRAM? Sí, un checkpoint compatible puede lograr un pico bajo cargando una capa cada vez. El modelo completo permanece en disco y la cifra no garantiza velocidad interactiva. ### ¿Cómo funciona AirLLM? Divide el checkpoint en shards, carga la capa actual, procesa activaciones y libera pesos. En modelos sparse compatibles puede transmitir expertos enrutados. ### ¿AirLLM usa cuantización? Ofrece compresión opcional de 4 y 8 bits. Kimi K3 ya usa pesos MXFP4 nativos, así que su ejemplo no es un checkpoint sin cuantizar. ### ¿Qué velocidad tiene AirLLM? No existe una tabla upstream reproducible para los grandes titulares. Mide arranque frío, primer token y decode con el modelo exacto. ### ¿AirLLM está listo para producción? Trátalo como herramienta de investigación y acceso hasta que tus pruebas demuestren latencia, throughput, calidad, fiabilidad y operación. ## Reflexiones finales AirLLM ejecuta un checkpoint aunque no quepa en la memoria GPU. Sus cifras de 4 GB, 8 GB, 12 GB y 3,72 GB describen picos reportados. No reducen el checkpoint ni aceleran el almacenamiento. Verifica el formato, reserva espacio para original y shards, mide cada fase y compara coste por tarea aceptada con un modelo residente menor o una API. El modelo más grande que arranca rara vez es el mejor producto. ## También te puede gustar.. [**¿Qué LLM local cabe en tu hardware?** Descarta candidatos antes de probar streaming extremo por capas.](/es/blog/llmfit-local-llm-hardware-guide/) [**Modelos locales frente a API** Calcula el self-hosting después de medir latencia, uso e ingeniería.](/es/blog/local-models-vs-apis-break-even-eu-2026/) Modelos e infraestructura ## Continúa por este clúster Selección de modelos, economía de inferencia, despliegue local, compresión y serving. [Empieza por el artículo fundamental**Alojar LLMs en la UE: Cuándo Salen a Cuenta los Open Weights**](/es/blog/self-hosting-llms-eu-cost/) - [Qwen3.8-27B: agentes de computer use autoalojados sin exportar capturas](/es/blog/qwen3-8-27b-self-hosted-computer-use-agents/) - [El stack vLLM y Triton de Netflix: 7 lecciones de producción](/es/blog/netflix-vllm-triton-inference-stack/) - [Transformers.js en el navegador: cuándo llevar la IA local a tu producto](/es/blog/transformers-js-browser-ai-guide/) - [Cómo autoalojar LiteLLM en producción: guía 2026](/es/blog/self-host-litellm-production-2026/) - [Wiki empresarial preparada para IA: arquitectura e implementación](/es/blog/ai-ready-company-wiki/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min de lectura · 20 de agosto de 2026 Última revisión 20 de agosto de 2026 [**Siguiente**](/es/blog/moneyprinterturbo-review-2026/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/airllm-layer-wise-inference-low-vram/#webpage", "@type": "WebPage", "dateModified": "2026-08-20", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-20", "url": "https://wavect.io/es/blog/airllm-layer-wise-inference-low-vram/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "AirLLM reduce el pico de memoria de GPU cargando solo la capa actual o, en modelos sparse compatibles, los expertos elegidos por el router. Su repositorio reporta unos 4 GB de VRAM para 70B, 8 GB para Llama 3.1 405B, 12 GB para DeepSeek-V3 y 3,72 GB para Kimi K3. Son afirmaciones de ejecución y memoria máxima, no garantías de throughput productivo. El checkpoint completo sigue en disco, cada token puede provocar nuevas transferencias de pesos y el contexto y los buffers también consumen memoria. El proyecto no publica tokens por segundo reproducibles para esos titulares. Kimi K3 además distribuye pesos MXFP4 nativos, por lo que \"sin cuantización\" no describe bien ese caso. AirLLM encaja en investigación, evaluación offline y pruebas de acceso a modelos. Para un servicio a clientes, mide tiempo al primer token, velocidad de decode, espacio, concurrencia, calidad y coste total frente a un modelo cuantizado menor o una API.", "articleBody": " Resumen del blog/IA y agentes/Modelos e infraestructura AirLLM con 4 GB de VRAM: cómo funciona la inferencia por capas Resumen AirLLM reduce el pico de memoria de GPU cargando solo la capa actual o, en modelos sparse compatibles, los expertos elegidos por el router. Su repositorio reporta unos 4 GB de VRAM para 70B, 8 GB para Llama 3.1 405B, 12 GB para DeepSeek-V3 y 3,72 GB para Kimi K3. Son afirmaciones de ejecución y memoria máxima, no garantías de throughput productivo. El checkpoint completo sigue en disco, cada token puede provocar nuevas transferencias de pesos y el contexto y los buffers también consumen memoria. El proyecto no publica tokens por segundo reproducibles para esos titulares. Kimi K3 además distribuye pesos MXFP4 nativos, por lo que \"sin cuantización\" no describe bien ese caso. AirLLM encaja en investigación, evaluación offline y pruebas de acceso a modelos. Para un servicio a clientes, mide tiempo al primer token, velocidad de decode, espacio, concurrencia, calidad y coste total frente a un modelo cuantizado menor o una API. Sí, AirLLM puede ejecutar un modelo mucho mayor que la VRAM de la GPU. Eso no significa que el modelo quepa en la tarjeta. El checkpoint sigue en disco. AirLLM carga la capa o los expertos necesarios, calcula, libera memoria y repite. Cambia residencia en memoria por movimiento de datos. Un pico de 4 GB no revela el espacio en disco, el tiempo de preparación, la latencia, el contexto útil ni la concurrencia. Verificamos esta guía el 20 de agosto de 2026 y le damos un intent acotado: explicar AirLLM con poca VRAM y decidir cuándo merece un piloto comercial. Para elegir un modelo local convencional que sí encaje en tu equipo, usa nuestra guía de hardware para LLM locales. Afirmaciones de AirLLM y lectura útil para una decisión AfirmaciónQué apoya la evidenciaQué no demuestra 70B con 4 GB de VRAMSolo reside una capa cada vezVelocidad interactiva Llama 3.1 405B con 8 GBHay un código y notebook públicosBenchmark full precision reproducible DeepSeek-V3 con unos 12 GBSoporte y cifra de memoria máximaLatencia, concurrencia o fiabilidad Kimi K3 2,8T con 3,72 GBMedición del mantenedor en una RTX 6000 AdaEl checkpoint de 1,6 TB sigue en almacenamiento Sin cuantizaciónAirLLM no obliga a comprimir ciertos pesosKimi K3 ya usa MXFP4 nativo ¿Qué es AirLLM? AirLLM es una librería Python con licencia Apache 2.0. Divide checkpoints transformer compatibles en shards menores y los carga bajo demanda. El repositorio oficial de AirLLM anuncia soporte para Llama, Qwen, DeepSeek, Mistral, Phi, Gemma, Kimi K3 y otras familias mediante AutoModel. También ofrece compresión opcional de pesos en 4 u 8 bits, ejecución CPU, Apple Silicon y prefetch limitado. Su beneficio es el acceso. Permite examinar un checkpoint que fallaría al cargar por falta de VRAM. El precio son transferencias repetidas. Un servidor GPU normal conserva pesos residentes y los reutiliza para cada token. AirLLM los recupera desde un nivel más lento porque prioriza capacidad sobre throughput. ¿Cómo reduce VRAM la inferencia por capas? Divide el checkpoint. AirLLM crea archivos por capa. El original y la copia transformada pueden coexistir durante el setup. Conserva el estado de ejecución. Activaciones, atención, KV cache y buffers aún necesitan RAM o VRAM. Carga la capa actual. Transfiere el bloque, calcula y reutiliza la memoria para el siguiente. Repite por token. El decode autorregresivo vuelve a recorrer el modelo. Sin caché, vuelve el tráfico de disco. El pico de VRAM depende de la capa mayor, las activaciones y el workspace, no de la suma de parámetros. El disco sigue dependiendo del checkpoint completo. Los contextos largos, batches grandes y varias solicitudes aumentan la memoria de ejecución. ¿Por qué Kimi K3 puede reportar menos VRAM que un 70B denso? Kimi K3 no es un modelo denso. El repositorio oficial de Kimi K3 documenta 93 capas, 896 expertos enrutados, 16 expertos seleccionados por token y 104.000 millones de parámetros activos. AirLLM carga solo los expertos elegidos. Ese working set puede ser menor que una capa densa de 70B aunque la biblioteca completa sea muchísimo mayor. La cifra de memoria máxima no reduce el download. El checkpoint publicado ronda 1,6 TB. Moonshot recomienda vLLM, SGLang y TokenSpeed para producción. AirLLM es una ruta experimental de acceso, no la receta de serving estándar del fabricante. La frase «sin cuantización» necesita una corrección AirLLM no exige cuantizar todos los checkpoints. Pero Kimi K3 se entrenó con quantization-aware training y se publicó con pesos MXFP4 y activaciones MXFP8. La afirmación viral confunde compresión añadida por el runtime con el formato descargado. Los tamaños también necesitan contexto. El repositorio oficial de DeepSeek-V3 enumera 671.000 millones de parámetros principales, 37.000 millones activos por token y 14.000 millones adicionales en el módulo de predicción multitoken. «671B con 12 GB» describe VRAM máxima, no 671B pesos residentes. ¿Qué", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "repositorio oficial de AirLLM", "url": "https://github.com/lyogavin/airllm" }, { "@type": "WebPage", "name": "repositorio oficial de Kimi K3", "url": "https://github.com/MoonshotAI/Kimi-K3" }, { "@type": "WebPage", "name": "repositorio oficial de DeepSeek-V3", "url": "https://github.com/deepseek-ai/DeepSeek-V3" }, { "@type": "WebPage", "name": "auditoría pública de evidencia en el repositorio", "url": "https://github.com/lyogavin/airllm/issues/295" }, { "@type": "WebPage", "name": "paper de PRIMA.CPP", "url": "https://arxiv.org/abs/2504.08791" } ], "dateModified": "2026-08-20", "datePublished": "2026-08-20", "description": "AirLLM reduce el pico de memoria de GPU cargando solo la capa actual o, en modelos sparse compatibles, los expertos elegidos por el router. Su repositorio reporta unos 4 GB de VRAM para 70B, 8 GB para Llama 3.1 405B, 12 GB para DeepSeek-V3 y 3,72 GB para Kimi K3. Son afirmaciones de ejecución y memoria máxima, no garantías de throughput productivo. El checkpoint completo sigue en disco, cada token puede provocar nuevas transferencias de pesos y el contexto y los buffers también consumen memoria. El proyecto no publica tokens por segundo reproducibles para esos titulares. Kimi K3 además distribuye pesos MXFP4 nativos, por lo que \"sin cuantización\" no describe bien ese caso. AirLLM encaja en investigación, evaluación offline y pruebas de acceso a modelos. Para un servicio a clientes, mide tiempo al primer token, velocidad de decode, espacio, concurrencia, calidad y coste total frente a un modelo cuantizado menor o una API.", "headline": "AirLLM con 4 GB de VRAM: cómo funciona la inferencia por capas", "image": "https://wavect.io/img/blog/headers/header_airllm-layer-wise-inference-low-vram.svg", "inLanguage": "es", "keywords": "AirLLM, LLM local, Inferencia GPU", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/airllm-layer-wise-inference-low-vram/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/airllm-layer-wise-inference-low-vram/", "wordCount": 1703 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/models-infrastructure/", "name": "Modelos e infraestructura", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/airllm-layer-wise-inference-low-vram/", "name": "AirLLM con 4 GB de VRAM: inferencia por capas | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Sí, un checkpoint compatible puede lograr un pico bajo cargando una capa cada vez. El modelo completo permanece en disco y la cifra no garantiza velocidad interactiva." }, "name": "¿Puede AirLLM ejecutar 70B con 4 GB de VRAM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Divide el checkpoint en shards, carga la capa actual, procesa activaciones y libera pesos. En modelos sparse compatibles puede transmitir expertos enrutados." }, "name": "¿Cómo funciona AirLLM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ofrece compresión opcional de 4 y 8 bits. Kimi K3 ya usa pesos MXFP4 nativos, así que su ejemplo no es un checkpoint sin cuantizar." }, "name": "¿AirLLM usa cuantización?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No existe una tabla upstream reproducible para los grandes titulares. Mide arranque frío, primer token y decode con el modelo exacto." }, "name": "¿Qué velocidad tiene AirLLM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Trátalo como herramienta de investigación y acceso hasta que tus pruebas demuestren latencia, throughput, calidad, fiabilidad y operación." }, "name": "¿AirLLM está listo para producción?" } ] } ```