La IA local suena fácil hasta que dejas de mirar demos bonitas y empiezas a medir lo que pasa en una máquina real: cuánto tarda en cargar, cuánto procesa de contexto, cuánto piensa, cuánto escribe y cuántas veces entrega algo que realmente se puede usar.
Por qué hablar de IA local ahora
Durante mucho tiempo, hablar de inteligencia artificial práctica significaba hablar de servicios externos, APIs cerradas y modelos que uno no podía tocar. Eso sigue siendo útil, pero ya no es la única historia. Hoy una workstation bien configurada puede ejecutar modelos locales capaces de programar, razonar sobre archivos grandes, generar interfaces, construir demos visuales y apoyar flujos editoriales completos.
El problema es que la conversación pública se llenó de atajos: capturas bonitas, rankings sin contexto y comparaciones de “tokens por segundo” que no explican qué está midiendo cada número. En FreakingJSON queríamos responder una pregunta más aterrizada: ¿qué pasa cuando intentas usar modelos locales de verdad, con tareas reales y hardware real?
La respuesta no cabe en un benchmark de una línea. Por eso abrimos esta serie. No para vender la fantasía de que todo se resuelve localmente, sino para mostrar dónde la IA local ya funciona, dónde todavía duele y qué metodología usamos para separar entusiasmo de evidencia.
Qué probamos en MiniV
MiniV es nuestra máquina local dedicada a pruebas de IA en una Corsair AI Workstation 300 con Ryzen AI MAX 385, Radeon 8050S Graphics y 64GB de memoria UMA. En la galería pública de benchmarks publicamos una actualización Bench v2.2 con 21 modelos evaluados, 84 runs y cuatro tareas diseñadas para medir utilidad real.
| Dato público | Resultado | Por qué importa |
|---|---|---|
| Modelos evaluados | 21 | Permite comparar familias, cuantizaciones y roles sin depender de una sola demo. |
| Runs totales | 84 | Reduce el ruido de una prueba aislada. |
| Tareas | tool_call, coding_fix, context_heavy, deep_context_retrieval | Miden uso real: orquestación, código, contexto y recuperación profunda. |
| Modelos con score perfecto | 11 | No basta ser rápido; también hay que entregar correctamente. |
| Modelos con MTP | 8 | La aceptación 89–94% cambia la experiencia de generación. |
La regla que cambia todo: separar métricas
El primer aprendizaje fuerte fue metodológico: no puedes confiar en un número global de velocidad si mezcla fases distintas de la inferencia. Un modelo puede procesar contexto muy rápido, pensar mucho, escribir lento o responder con buen ritmo pero fallar en tareas largas. Si todo termina comprimido en una sola cifra, el benchmark se vuelve una ilusión cómoda.
En Bench v2.2 separamos las métricas desde el objeto timings del servidor: prompt_per_second para prefill, predicted_per_second para decode, reasoning_content para tokens de pensamiento y draft_n_accepted / draft_n para aceptación MTP. Ese detalle parece técnico, pero cambia completamente la lectura.
Una buena prueba de IA local no busca el número más bonito. Busca el número que explica mejor la experiencia real.
Hallazgos que sí sirven para decidir
El modelo architect-35b-q6 quedó como el mejor balance público de esta ronda: 71.2 decode tok/s, 320.3 prefill tok/s, score 1.00 y contexto de 131K. Pero el punto no es coronar un campeón eterno. El punto es mostrar cómo una prueba puede convertirse en una decisión de uso.
Por ejemplo: si necesitas una lane para arquitectura, tool-calls y trabajo general, priorizas balance. Si necesitas coding dedicado, miras estabilidad en bugs reales y contexto pesado. Si necesitas máxima precisión, tal vez aceptas menos velocidad. Si estás explorando creatividad visual, otra suite puede ser más importante que el ranking de decode.
También vimos una mejora concreta en recuperación profunda de contexto: el caso pasó de 310 segundos a 92 segundos después de ajustar ubatch y timeouts adaptativos. Eso es una lección importante: a veces el cuello de botella no es “el modelo es malo”, sino “el entorno está mal afinado para esa tarea”.
Nuestra metodología sin humo
Hay tres reglas que vamos a mantener en esta serie.
- Primero evidencia, después opinión. Si no hay salida verificable, no hay victoria.
- No mezclar grupos incomparables. Host, runtime, flags, tareas y gates importan.
- No usar LLM-as-judge como cierre. Para estas pruebas preferimos checkers determinísticos y validación de artefactos.
Esto no significa que un judge nunca sirva. Sirve para exploración, revisión cualitativa o feedback editorial. Pero cuando hablamos de promover una lane de trabajo, queremos algo más firme que “a otro modelo le pareció bien”.
| Anti-patrón | Problema | Cómo lo evitamos |
|---|---|---|
| Ranking único | Reduce todo a velocidad | Separar score, prefill, decode, MTP y contexto |
| Demo bonita | No prueba utilidad | Tareas verificables y artefactos ejecutables |
| Comparar runs históricos | Mezcla entornos distintos | Comparabilidad por grupo de evidencia |
| “El modelo dijo que está bien” | Puede perdonar errores reales | Checkers determinísticos y QA de runtime |
Qué significa para creadores y equipos tech
Para un creador tech, IA local significa control. Puedes probar, romper, ajustar y repetir sin esperar a que una plataforma te diga si tu experimento cabe en sus reglas. Para un equipo de desarrollo, significa tener lanes especializadas: una para razonar, otra para programar, otra para generar borradores, otra para explorar visuales.
Pero la palabra clave es criterio. Ejecutar modelos localmente no elimina la necesidad de evaluar. Al contrario: cuando tienes más control, tienes más responsabilidad sobre la calidad de lo que produces.
Por eso esta serie va a mezclar benchmarks, producción visual, hardware, gaming y laboratorio editorial. No queremos hablar de IA local como una religión. Queremos mostrarla como una herramienta: poderosa, imperfecta y mucho más interesante cuando se prueba sin humo.
La galería pública con los datos base está disponible aquí: Corsair AI Workstation 300 64GB Benchmark Gallery. El repositorio público vive en GitHub.
Preguntas frecuentes
¿Esto reemplaza la nube?
No siempre. La IA local da control, privacidad y velocidad de iteración, pero la nube sigue siendo útil para modelos enormes, picos de carga o servicios especializados.
¿El modelo más rápido es siempre el mejor?
No. La velocidad importa, pero debe leerse junto con score, estabilidad, contexto, calidad de salida y tipo de tarea.
¿Por qué Bench v2.2 separa prefill y decode?
Porque prefill mide procesamiento de entrada/contexto y decode mide generación de salida. Son fases distintas y mezclarlas puede producir conclusiones falsas.
¿Por qué no usar solo LLM-as-judge?
Porque un modelo evaluador puede sonar convincente y aun así pasar errores que un usuario, un navegador o un test determinístico no perdonarían.
Qué puedes revisar por tu cuenta
Los números no sustituyen una decisión: sirven para abrir la caja negra. Si quieres ver cómo conectamos modelos, imagen, vídeo y voz en una máquina local, visita nuestro workflow real de IA local. Y para separar capacidades útiles de promesas infladas, completa esta lectura con los mitos que más distorsionan la conversación sobre IA.
El conocimiento verdadero trasciende a lo público 🌀
¿Quieres seguir la línea de investigación? Continúa con artículos relacionados y guarda esta lectura para volver después.
Ver relacionados
