- Guía comunitaria que recopila benchmarks reales de dispositivos para inferencia local de LLM, centrada en agentes de IA y modelos a partir de 9B parámetros.
- Utiliza la familia Qwen 3.5 como referencia estándar y mide principalmente velocidad de decodificación y prefill en tokens/s, contrastando los resultados con límites teóricos por ancho de banda.
- Expone tácticas habituales de inflación de cifras en el márketing de hardware (TOPS dispersos, precisiones extremas, stacking heterogéneo) para evitar compras engañosas.
- Ofrece vistas interactivas (ranking, gráficos 2D/3D y tabla completa) y acepta aportaciones manuales de la comunidad con evidencias de pruebas para mantener datos transparentes y útiles.
Si te estás planteando montar un agente de IA en tu propio equipo y no depender de la nube, seguramente te habrás topado con el término “I Agent Local LLM Inference Device Deployment Guide” o con la web llmdev.guide. Detrás de ese nombre tan largo hay algo muy concreto: una guía práctica, basada en datos reales, para ayudarte a elegir el hardware adecuado para ejecutar modelos grandes de lenguaje de forma local sin tirar el dinero.
La idea que hay detrás de este proyecto es sencilla pero potente: reunir benchmarks reales, medidos por la comunidad, de los dispositivos más usados para inferencia local de LLMs (sobre todo para agentes de IA) y presentarlos en un formato claro, visual y fácil de comparar. Con esto se pretende contrarrestar el mar de cifras infladas, tácticas de márketing dudosas y especificaciones confusas que inundan el mercado de aceleradores de IA y GPUs.
Qué es I Agent Local LLM Inference Device Deployment Guide
La llamada “AI Agent Local LLM Inference Device Deployment Guide” es una guía de despliegue enfocada a usuarios individuales que quieren ejecutar modelos grandes de lenguaje en local, con especial atención a cargas de trabajo de agentes (tipo Claude Code, Cursor, OpenClaw, PicoClaw, etc.). Estas cargas suelen consumir una barbaridad de tokens frente a un simple chat, así que el rendimiento del hardware se vuelve crítico para no desesperarse esperando respuestas.
El proyecto se aloja en llmdev.guide y se articula como una base de datos abierta y colaborativa, en la que la comunidad aporta resultados de rendimiento de distintos dispositivos ejecutando modelos concretos. La condición mínima para que un dispositivo aparezca en la guía es que pueda mover al menos un modelo de alrededor de (9B), es decir, algo razonable para montar un agente de IA decente.
Además de servir de catálogo, la guía está pensada como una especie de antídoto contra el márketing engañoso de algunos fabricantes, que prometen capacidades enormes en TOPS o TFLOPS que luego, en la práctica, no se traducen en más tokens por segundo. En la propia guía se explican las tácticas más típicas de inflación de cifras para que no te la cuelen cuando compares dispositivos.
Otro punto importante es que la guía se centra en equipos con un coste habitualmente por debajo de los 10.000 $, lo que abarca desde PCs con GPUs de consumo, hasta mini PCs, SBCs vitaminadas, aceleradores dedicados y algunas estaciones de trabajo más serias. La idea no es competir con centros de datos, sino mostrar qué tiene más sentido para alguien que quiera montar su propio “rig” de IA en casa u oficina y ejecutar LLM en local.
Tácticas de márketing infladas en hardware de IA
Uno de los valores añadidos de la guía es que desmonta varias tretas comerciales muy habituales para inflar la “potencia de cálculo” de un dispositivo. Entenderlas ayuda bastante a interpretar con cabeza las especificaciones.
Una primera táctica es usar la “computación dispersa (sparse)” como cifra principal de TOPS. Muchos chips anuncian, por ejemplo, 200 TOPS, pero esa cifra solo se alcanza con sparsity (parte de los pesos a cero) y bajo condiciones muy concretas. El resultado real en modelos densos puede ser fácilmente la mitad, así que, como regla general, se considera que ahí hay como mínimo un factor 2x de inflación.
Otra forma de maquillar números es basarse en precisiones muy bajas como FP4 o INT4 al presentar la potencia bruta. Estas cifras disparan los TOPS teóricos frente a INT8 o FP16, pero no siempre son aprovechables ni ofrecen suficiente calidad para todos los modelos. El “inflado” real suele moverse entre 2 y 4 veces respecto a lo que veríamos en condiciones realistas.
También es bastante común el “stacking” heterogéneo de cómputo, es decir, sumar a lo bruto la potencia de CPU, GPU, NPU, DSP y lo que se tercie, como si todo se pudiera usar a la vez con eficiencia perfecta. En la práctica, co-utilizar bien todos esos bloques es muy difícil, y lo que tienes es una cifra global bonita en el papel pero poco representativa de lo que verás con un LLM concreto.
Por último, hay dispositivos que apilan mucha capacidad de cómputo con muy poco ancho de banda de memoria. Sobre el papel, parecen bestias de TOPS, pero en cuanto se ponen a atender un modelo grande de lenguaje acaban totalmente estrangulados por la memoria. En la guía se insiste en que el verdadero límite de rendimiento suele venir más por el ancho de banda que por los TOPS teóricos.
Cómo estructura la información llmdev.guide
La web llmdev.guide ofrece varias maneras de visualizar y comparar los dispositivos para inferencia local de LLM, pensadas para usuarios con distintos niveles de experiencia técnica. No es solo una tabla plana: hay varias vistas interactivas que facilitan mucho las comparaciones.
Por un lado, tenemos un “Leaderboard” clásico que permite ordenar los dispositivos por un único criterio, como por ejemplo velocidad de decodificación (tokens por segundo), relación rendimiento/precio o eficiencia energética. Esta vista es ideal si solo te interesa, por ejemplo, ver qué opción da más tokens/s por euro gastado dentro de tu presupuesto.
Si quieres hilar más fino, la guía incluye gráficas de dispersión 2D en las que puedes elegir qué variable colocar en cada eje (precio, consumo, ancho de banda, tokens/s, etc.) y usar el tamaño de la burbuja para representar otra métrica adicional. Esto permite ver de un vistazo, por ejemplo, qué dispositivos ofrecen un equilibrio razonable entre coste, rendimiento y consumo.
Para quien disfrute de los datos a tope, también hay gráficas 3D interactivas donde se cruzan tres parámetros a la vez, con burbujas en un espacio tridimensional. Aunque es una vista más “friki”, viene muy bien para entender, por ejemplo, cómo se agrupan ciertos tipos de hardware en términos de tokens/s, precio y eficiencia por vatio.
La cuarta vista es una tabla de datos completa con todas las especificaciones y resultados de benchmarks. Aquí puedes filtrar, ordenar y entrar al detalle de cada modelo de GPU, NPU o sistema. Cada dispositivo tiene su ficha, con especificaciones técnicas, resultados de pruebas y notas adicionales, además de enlaces a las evidencias de test que hayan aportado los usuarios.
Modelo unificado de referencia: familia Qwen 3.5
Para evitar el caos de comparar peras con manzanas, la guía usa la familia de modelos Qwen 3.5 como referencia estándar. La idea es sencilla: si todos los benchmarks se hacen con las mismas arquitecturas de modelo, la comparación entre dispositivos es mucho más limpia.
Hay dos modelos de la familia Qwen3.5 que se consideran obligatorios para que un dispositivo entre en el listado. Por un lado, Qwen3.5-9B, que hace de referencia para dispositivos pequeños o de entrada. Si tu hardware no puede con este modelo, difícilmente será recomendable para agentes de IA exigentes.
El segundo modelo obligatorio es Qwen3.5-27B, pensado como referencia para dispositivos de gama media. Si un equipo mueve razonablemente este modelo, ya se considera algo sólido para usos más serios, como aplicaciones profesionales de generación de código, análisis de documentos o asistentes internos.
Además, la guía contempla varios modelos Mixture of Experts (MoE) como opciones opcionales: Qwen3.5-35B-A3B, Qwen3.5-122B-A10B y Qwen3.5-397B-A17B. Cada uno sirve como referencia para dispositivos con más memoria o ambiciones más altas: desde equipos con bastante RAM hasta auténticos “flagships” pensados para tareas muy pesadas.
En todos los casos se fija una cuantización mínima de 4 bits (INT4/Q4), de forma que los resultados sean comparables y realistas. Si un dispositivo no tiene aún datos directos para Qwen 3.5, se puede recurrir de forma excepcional a estimaciones basadas en modelos similares, y en esos casos se marcan con un asterisco para dejar claro que no son medidas directas.
Qué métricas de rendimiento se miden realmente
En lugar de perderse en mil números, la guía se centra en dos métricas fundamentales para el uso interactivo de agentes de IA: la velocidad de decodificación y la velocidad de prefill, ambas expresadas en tokens por segundo.
La velocidad de decodificación (decode speed) es la más importante para la experiencia de usuario, porque marca cuántos tokens por segundo puede ir generando el modelo una vez arranca la respuesta. Es lo que define, básicamente, si ves cómo el texto va saliendo con fluidez o a tirones.
La velocidad de prefill (prefill speed) afecta al tiempo hasta el primer token, es decir, cuánto tarda el sistema en digerir el prompt inicial (que puede ser largo en agentes con contexto, herramientas, historial, etc.) antes de empezar a generar la salida. Es crítica en aplicaciones donde se cargan contextos enormes o muchos documentos de golpe.
Además de estas dos métricas principales, la guía presta mucha atención a la relación entre el ancho de banda de memoria y la velocidad real que se consigue. De hecho, los valores de tokens/s reportados se contrastan con un techo teórico calculado a partir del ancho de banda disponible, y si las cifras superan lo razonable se marcan con un símbolo de advertencia para indicar que algo huele raro.
Todo esto se complementa con información sobre consumo energético, precio aproximado, capacidad de memoria, ancho de banda y TOPS declarados, que luego se usan para derivar ratios como rendimiento por euro o rendimiento por vatio. Esos ratios son los que permiten ver rápidamente qué dispositivos son “chollos” y cuáles están claramente sobrevalorados.
Comparaciones reales de hardware: ejemplos significativos
Uno de los casos más ilustrativos que se comentan usando la guía es el de comparar GPUs caras y estaciones de trabajo premium con opciones bastante más modestas. Al poner todos los datos en la misma gráfica, se ve que el precio no siempre se traduce en más tokens/s.
Por ejemplo, tomando como referencia Qwen3.5 9B, la guía muestra que equipos de más de 4.000 $ como un sistema NVIDIA DGX Spark o un Apple Mac Studio con chip M3 pueden acabar ofreciendo un rendimiento muy similar en tokens por segundo a una máquina montada con una GPU mucho más terrenal, como una Intel Arc B580 de 12 GB que ronda los 260 $.
En el otro extremo, si el dinero no es un problema y se persigue la máxima velocidad posible con modelos de tamaño contenido, lo lógico es mirar a GPUs tope de gama, como podría ser una hipotética NVIDIA GTX 5090 de 32 GB, que ofrece una relación rendimiento absoluto / coste bastante razonable si solo te importa ir al límite y asumir la inversión.
Cuando se sube a modelos realmente grandes, como Qwen 122B-A10B, la cosa cambia bastante porque la memoria empieza a ser el cuello de botella. En este contexto, dispositivos tipo NVIDIA DGX Spark pueden ofrecer una relación precio/rendimiento sorprendentemente buena frente a máquinas como un Apple Mac Studio M3 Ultra con 256 GB, principalmente por cómo gestionan la memoria y el ancho de banda.
Hay que tener en cuenta, eso sí, que no todas las entradas de la guía reflejan el mismo nivel de detalle sobre el coste: en algunos casos se indica el precio del sistema completo, y en otros solo el de la GPU. Aun así, como herramienta de comparación general, la guía permite detectar fácilmente cuando un equipo está muy sobredimensionado para el rendimiento que realmente aporta en LLMs.
Opciones de visualización y análisis en la guía
La interfaz de llmdev.guide permite jugar con múltiples parámetros para los ejes X e Y de las gráficas y para el tamaño de las burbujas. Puedes elegir, por ejemplo, que el eje X sea el precio, el eje Y los tokens/s de decodificación, y que el tamaño de la burbuja represente el consumo energético.
También puedes cruzar características de hardware (ancho de banda de memoria, capacidad, TOPS declarados) con resultados de inferencia (velocidad de prefill, velocidad de salida) o con ratios derivados (rendimiento por vatio, rendimiento por dólar). Esto ayuda a detectar patrones, como dispositivos que rinden muy por encima o por debajo de lo que su ficha técnica haría pensar.
En cuanto a la parte de precios, la herramienta no dispone inicialmente de un filtro directo por rango de coste, pero sí ofrece la posibilidad de usar una escala logarítmica en el eje de precios para que las opciones de entrada y gama media no queden aplastadas frente a las estaciones más caras. Además, se puede hacer zoom dibujando un recuadro con el ratón para centrarse en un subconjunto concreto de dispositivos.
Si prefieres algo más tradicional, la vista en forma de lista con tabla ordenable te permite reordenar las filas por cualquier columna, incluido el precio. De esta forma puedes ver de un vistazo cuál es el dispositivo más barato que cumple ciertos requisitos mínimos o cuáles son los que dan más rendimiento dentro de un presupuesto concreto.
Al hacer clic en un elemento de la lista o en una burbuja de la gráfica se accede a una ficha con más detalles de cada dispositivo, incluyendo especificaciones técnicas completas, resultados de pruebas y notas sobre cómo se hizo el benchmark. Es ahí donde se indica si los datos son medidos o extrapolados, así como cualquier aspecto peculiar del setup.
Datos comunitarios, estimaciones y proceso de contribución
Uno de los pilares del proyecto es que todos los datos de rendimiento se nutren de aportaciones de la comunidad. No se trata de una batería de tests cerrada realizada por un único laboratorio, sino de una base de datos viva, a la que cualquiera puede sumar sus resultados si siguen el procedimiento establecido.
Cuando un dispositivo no ha sido probado directamente con Qwen 3.5, algunos resultados pueden aparecer como estimados a partir de otros modelos, como Llama 7B en el caso del Raspberry Pi 5 de 16 GB. Esto se hace para ofrecer una referencia aproximada, pero se marca explícitamente para que nadie lo confunda con mediciones reales.
El proceso de contribución pasa por hacer un fork del repositorio del proyecto, copiar una plantilla de dispositivo (devices/_template.md) y rellenarla con la información del hardware y los resultados obtenidos. Además, se pide adjuntar evidencias de las pruebas, como capturas de pantalla o salidas de terminal, para que otros puedan verificar que los números tienen sentido.
Es obligatorio, al menos, ejecutar Qwen 3.5 9B con un prompt suficientemente largo para obtener datos de rendimiento significativos, sobre todo en escenarios de uso típico de agentes de IA. También se recomienda tomar fotos de la placa o del equipo utilizado, y documentar la configuración (cuantización, contexto, backend, etc.).
De momento, el sistema no automatiza la recolección de datos; hay que rellenar todo a mano siguiendo la plantilla. Algunos usuarios han señalado que sería ideal contar con scripts tipo “sbc-bench.sh” que ejecuten los tests y envíen los resultados, pero por ahora el enfoque manual permite un mayor control de calidad y evita que se llenen las tablas de resultados dudosos.
Contexto: qué son los LLM locales y por qué importan
Más allá de la propia guía, conviene entender el contexto en el que surge: los modelos de lenguaje grandes que se ejecutan en local, sin depender de la nube, están viviendo un boom. Cada vez más usuarios y empresas quieren tener su propio asistente, agente o sistema conversacional corriendo en sus máquinas, sin enviar datos sensibles a terceros.
Los LLM locales suponen un cambio respecto a los servicios en la nube tradicionales porque permiten conservar la soberanía sobre los datos y trabajar completamente offline. En lugar de pagar llamadas a una API externa, descargas el modelo, lo ejecutas en tu hardware y controlas tanto la configuración como las posibles personalizaciones o afinados.
En el ecosistema actual conviven modelos como Llama 3.x, Qwen 2.5/3.5, DeepSeek R1 o Phi-4, que han ido mejorando en eficiencia hasta el punto de que versiones de 7B-9B parámetros ofrecen resultados muy sólidos corriendo en una sola GPU de consumo o incluso solo con CPU potente y buena RAM.
Para organizaciones con cargas intensivas (análisis masivo de documentos, generación de código continua, chatbots internos…), el paso a LLMs locales puede significar un ahorro enorme frente a los costes recurrentes de las APIs comerciales, especialmente cuando se manejan millones de tokens al mes. A esto se suma el control fino sobre el modelo y su comportamiento.
Los agentes de IA llevan todo esto un paso más allá, porque no se limitan a responder a preguntas, sino que encadenan herramientas, contextos y acciones en flujos bastante más largos. Eso dispara el número de tokens y hace que el rendimiento de inferencia del dispositivo sea un factor aún más determinante, justamente el tipo de escenario para el que la guía I Agent Local LLM Inference Device Deployment resulta más útil; para diseñar estos sistemas conviene conocer las arquitecturas de agentes.
Requisitos de hardware para LLM locales: GPU, CPU y memoria
Uno de los grandes quebraderos de cabeza cuando alguien se plantea montar un LLM en local es entender qué hardware necesita realmente y qué parte del presupuesto tiene más impacto. La GPU y la memoria (VRAM y RAM) suelen ser los factores decisivos, pero no los únicos.
En el terreno de las GPUs, la clave está en la cantidad de VRAM y el ancho de banda. Para modelos de entrada de 7-8B parámetros (tipo Llama 3.1 8B o Qwen 2.5 7B) una GPU con 8-12 GB de VRAM suele ser suficiente, sobre todo si se usan cuantizaciones de 4 bits. Esto cubre casos de uso generales y proyectos personales sin demasiadas complicaciones.
Si el objetivo es subir a modelos de 14-32B parámetros (como Qwen 2.5 14B o DeepSeek R1 32B), lo razonable es apuntar a GPUs con 16-24 GB de VRAM, o a configuraciones multi-GPU en ciertos casos. A partir de 70B parámetros, la cosa se dispara y ya hablamos de 48 GB o más, a menudo en sistemas con varias GPUs de gama alta o aceleradores dedicados para empresas.
Existe una regla aproximada para calcular cuánta memoria requiere un modelo: M = (P × Q/8) × 1,2, donde M es la memoria en GB, P el número de parámetros en miles de millones y Q la precisión en bits. Así, un modelo de 70B a 16 bits puede rondar los 168 GB de VRAM, mientras que con cuantización a 4 bits se quedaría cerca de los 42 GB. A partir de ahí se puede ajustar según el backend y los buffers adicionales.
El papel de la CPU no debe infravalorarse: procesadores modernos con buenas extensiones vectoriales y buen ancho de banda de memoria pueden mover modelos más pequeños con un rendimiento sorprendente. Ejemplos recientes muestran CPUs como ciertos Ryzen AI capaces de superar los 50 tokens/s con modelos ligeros, lo que abre la puerta a setups sin GPU para algunos usos.
Herramientas populares para desplegar LLM locales
Una vez claro el hardware, el siguiente paso es elegir la plataforma de software para gestionar los modelos y la inferencia. Aquí se combinan herramientas pensadas para usuarios principiantes con otras orientadas a exprimir hasta el último ciclo de CPU o GPU.
Ollama se ha consolidado como una de las opciones más amigables para empezar. Funciona con un enfoque tipo “Docker para modelos”, permitiendo descargar y lanzar modelos con comandos muy sencillos. Gestiona automáticamente cuantización, uso de GPU y memoria, y expone una API compatible con OpenAI, lo que simplifica mucho integrar un agente o un chatbot en tus propias aplicaciones.
Para quienes prefieren una interfaz gráfica cuidada, LM Studio ofrece un entorno visual muy pulido para descubrir, descargar y probar modelos. Se integra directamente con Hugging Face, dispone de interfaz de chat y facilita cambiar de modelo, cuantización o backend sin tocar la línea de comandos, a costa de perder algo de flexibilidad extrema.
En el extremo más técnico, llama.cpp sigue siendo el referente cuando se busca el máximo rendimiento y control fino. Es una implementación en C++ muy optimizada, con soporte para múltiples backends (CUDA, Metal, Vulkan…) y técnicas de cuantización avanzadas. Además, ha ido mejorando notablemente en arquitecturas ARM, lo que beneficia tanto a portátiles con Apple Silicon como a equipos con Snapdragon X y similares.
Junto a estas, hay proyectos como GPT4All o LocalAI que apuestan por una experiencia de escritorio unificada o por exponer APIs locales muy fáciles de integrar. Además, aparecen alternativas como Jan AI entre las opciones para quienes buscan una experiencia local similar a ChatGPT. La elección depende del equilibrio que cada persona busque entre simplicidad, rendimiento y capacidad de personalización.
Estrategias de despliegue y optimización para agentes de IA
Cuando el objetivo es ejecutar agentes de IA más complejos (con llamadas a herramientas, navegación, cadenas de razonamiento largas, etc.), entran en juego estrategias de optimización adicionales para sacar partido al hardware que ya tienes o al que vayas a comprar siguiendo la guía.
La cuantización es el primer gran aliado: trabajar en 4 bits suele dar una relación muy buena entre calidad y tamaño, permitiendo que modelos de 7-9B quepan cómodamente en GPUs de 8-12 GB y que diseños de 30B o más puedan moverse en GPUs de 24 GB o configuraciones multi-GPU. Para casos donde se necesite máxima calidad, 8 bits ofrece un equilibrio intermedio aún bastante compacto.
También es clave ajustar parámetros como la longitud de contexto, el tamaño de lote (batch) y el número de capas que se offloadean a GPU en configuraciones híbridas CPU/GPU. Aumentar el contexto mejora la capacidad de manejar historiales largos, pero dispara el consumo de memoria; afinar estos valores según el uso concreto del agente es fundamental.
En entornos empresariales o de laboratorio, tiene sentido plantearse configuraciones multi-GPU y despliegues distribuidos, usando técnicas como el paralelismo de tensores para dividir grandes modelos de 70B o más entre varias tarjetas. Frameworks como vLLM o ciertas interfaces web avanzadas ofrecen soporte directo para estos modos, aunque exigen más conocimientos de sistemas.
Por último, desde el punto de vista de costes, el despliegue local suele volverse muy competitivo frente a la nube cuando el volumen de tokens procesados es alto y el hardware se amortiza a medio plazo. La guía de dispositivos ayuda precisamente a encontrar el punto dulce entre inversión en equipo, coste energético y rendimiento, para que la ecuación salga a favor del despliegue local de agentes.
Teniendo en mente todas estas piezas -datos de benchmarks reales, métodos para filtrar márketing inflado, métricas relevantes y herramientas de despliegue- la I Agent Local LLM Inference Device Deployment Guide se convierte en una referencia muy útil para cualquiera que quiera montar agentes de IA en local con cabeza: ayuda a priorizar ancho de banda y memoria sobre cifras de TOPS vistosas, orienta sobre qué modelos de la familia Qwen 3.5 usar como prueba de fuego y ofrece comparaciones claras de precio, rendimiento y eficiencia para elegir hardware sin pagar de más.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.