IA local frente a ChatGPT: ¿Qué tan cerca estamos?

La IA local ofrece una opción práctica para trabajos delimitados con comprobaciones claras. Sustituir el trabajo que entregas a ChatGPT o Claude exige alinear tres elementos: capacidad del modelo, memoria disponible y un agente capaz de inspeccionar y verificar su resultado.

Un modelo que cabe en tu estación de trabajo aún necesita herramientas adecuadas y velocidad suficiente para repetir intentos. Este artículo separa resultados de benchmarks, estimaciones de memoria y pruebas de tareas completadas para que evalúes cada aspecto por separado.

Puntos clave #

• Capacidad: las puntuaciones de referencia describen configuraciones de evaluación concretas, no tu compilación local cuantizada.
• Memoria: reserva espacio para pesos, caché de contexto y sobrecarga del tiempo de ejecución.
• Velocidad: reproducir una conversación de agente mide el servicio, no la corrección.
• Verificación: un agente necesita comprobaciones ajustadas al resultado solicitado.
• Selección: compara tareas repetidas, tiempo de reparación y coste total antes de comprar hardware.

Lee las puntuaciones en contexto #

El Artificial Analysis Intelligence Index reúne varias evaluaciones en una puntuación de referencia. El clasificador de modelos y los resultados de hardware local muestran las siguientes entradas, comprobadas el 6 de octubre de 2026.

Los puntos del índice no son porcentajes de inteligencia ni de éxito de tareas. Una diferencia de 13 puntos entre GLM y Claude no demuestra una diferencia del 13 % en tus resultados de código. La configuración de razonamiento también importa al comparar entradas del mismo modelo.

La metodología de evaluación publicada describe la configuración de las pruebas. Algunas evaluaciones incluyen herramientas e infraestructura de agentes. Trata la puntuación como un resultado dentro de esas condiciones. No la transfieras directamente a una copia comprimida que se ejecuta localmente mediante otra aplicación.

ChatGPT y Claude son productos, mientras que esta tabla compara modelos subyacentes seleccionados. Tu suscripción, el modelo seleccionado, las herramientas disponibles y el contexto de la tarea crean diferencias adicionales. Empieza con una tarea repetida y prueba la configuración completa.

Calcula toda la solicitud #

El ajuste de memoria empieza con tres asignaciones. Los pesos del modelo almacenan parámetros aprendidos. La caché de valores y claves, o caché KV, conserva datos de atención usados durante la inferencia. Los búferes del tiempo de ejecución y otro software consumen el espacio restante.

Memoria necesaria = pesos residentes + caché de contexto + margen del tiempo de ejecución
Memoria disponible = capacidad física - reserva del sistema operativo y las aplicaciones

La cuantización reduce la precisión de almacenamiento de los pesos. Una precisión menor reduce los requisitos de memoria, con una calidad dependiente del modelo y de la compilación cuantizada. La precisión de la caché es una configuración separada. Un archivo de pesos Q4 no establece una caché de cuatro bits.

Como ejemplo aproximado basado solo en pesos, 27.000 millones de parámetros a 16 bits requieren unos 50,3 GiB. Ocho bits requieren unos 25,1 GiB y cuatro bits unos 12,6 GiB. Los tamaños publicados de los archivos también reflejan metadatos, empaquetado y precisión mixta. Usa los archivos exactos para planificar el despliegue.

La ficha de Qwen3.8-27B y la ficha de GLM-5.3 describen arquitecturas distintas. Un modelo de mezcla de expertos activa solo parte de sus parámetros para cada token, pero los pesos restantes aún requieren almacenamiento. El offload cambia la ubicación y la latencia. No elimina esos pesos.

Empieza por los archivos publicados #

El tamaño de descarga ofrece un inicio más concreto que el número de parámetros. Las compilaciones publicadas de Qwen y GLM de Unsloth muestran cuánto cambia el requisito de almacenamiento con la cuantización elegida.

Fuentes de los archivos: Qwen Q4_0 , Qwen Q8_0 , fragmentos GLM UD-Q4_K_XL y fragmentos GLM UD-IQ2_M . Son listados redondeados comprobados el 6 de octubre de 2026. Las conversiones a GiB dividen los bytes decimales entre 2³⁰.

Estos son tamaños de archivos de pesos, no mediciones de memoria residente total. El comportamiento de carga, las cachés, los búferes temporales y otros componentes del modelo afectan al proceso en ejecución. No compares una descarga de 29 GB directamente con una asignación de 30 GiB sin convertir las unidades.

El contexto cambia el ajuste #

La caché de atención de Qwen ofrece un ejemplo calculado. Su configuración publicada especifica 64 capas, atención completa en una de cada cuatro capas, cuatro cabezas de valores y claves, y una dimensión de cabeza de 256.

Bytes de KV por token con atención completa:
16 capas × 4 cabezas KV × 256 dimensiones × 2 (K y V) × 2 bytes
= 65.536 bytes

8.192 tokens  = 0,5 GiB
32.768 tokens = 2,0 GiB

Este componente de caché calculado supone claves y valores de 16 bits para una secuencia. Excluye el estado de atención lineal, los búferes del tiempo de ejecución, la sobrecarga del asignador y los componentes opcionales de visión o decodificación especulativa. Esas asignaciones también necesitan una reserva.

Para un presupuesto de planificación ilustrativo, añade 3–5 GiB para las asignaciones restantes a los tamaños de pesos redondeados. Sustituye esta suposición por mediciones de tu tiempo de ejecución.

Una asignación utilizable de 30 GiB deja espacio considerable para el ejemplo Q4, mientras que los escenarios Q8 la superan bajo estas suposiciones. Una reserva medida menor cambia el límite. Por eso un prompt corto que funciona no demuestra capacidad suficiente para una sesión de código larga.

Las solicitudes simultáneas añaden otra dimensión. Ollama documenta el crecimiento de memoria de contexto con solicitudes paralelas y controles separados para la precisión de caché. Su caché Q8 usa aproximadamente la mitad de memoria que la caché F16. Q4 usa aproximadamente una cuarta parte, con compromisos de calidad dependientes del modelo. Consulta las preguntas frecuentes del tiempo de ejecución de Ollama .

Ajusta el hardware a la asignación #

Una RTX 5090 ofrece 32 GB de memoria gráfica dedicada. Un DGX Spark con 128 GB usa memoria compartida. Artificial Analysis documenta ambas configuraciones en sus resultados de hardware. Una capacidad mayor permite asignaciones mayores, pero la capacidad por sí sola no demuestra la velocidad de servicio.

GLM UD-Q4_K_XL supera las tres capacidades antes de añadir una caché. El conjunto de pesos IQ2 de aproximadamente 222,6 GiB también supera un sistema de 128 GB. En un Mac de 256 GB, su viabilidad depende de la asignación accesible para la GPU y de la sobrecarga restante. Las especificaciones de Apple establecen opciones de hardware, no una asignación de inferencia garantizada.

Un presupuesto hipotético utilizable de 240 GiB deja unos 17,4 GiB después de esos pesos IQ2. Un presupuesto de 192 GiB falla con los pesos solos. Ninguno establece el valor predeterminado del sistema operativo, el soporte de caché comprimida, un rendimiento útil ni una calidad IQ2 aceptable. Exige una configuración de tiempo de ejecución demostrada antes de comprar hardware para esta carga.

La velocidad es un resultado separado #

El benchmark de inferencia local de Artificial Analysis reproduce una carga registrada de 168 turnos de modelo. Sus resultados para portátiles y estaciones de trabajo muestran estos tiempos para las configuraciones Qwen3.8 27B probadas.

El resultado de RTX tarda aproximadamente una quinta parte del tiempo de Spark. Las configuraciones de servicio importan, por lo que esta no es una proporción universal de hardware. Las compilaciones probadas también difieren de los ejemplos de planificación GGUF anteriores.

El tiempo de reproducción excluye la ejecución de herramientas y fuerza longitudes de respuesta registradas. No califica si las respuestas generadas resuelven la tarea original. Una medición de MacBook tampoco establece el rendimiento de Mac Studio.

Da retroalimentación al agente #

Un sistema de ejecución de agentes proporciona herramientas, contexto, un bucle de acción y verificación. Un modelo escribe o elige acciones dentro del sistema. Para exportar un CSV, las capacidades útiles incluyen leer archivos del proyecto, cambiar código, ejecutar pruebas y recibir los errores resultantes.

Considera una tarea de exportación ilustrativa, no un experimento medido. El agente crea una función de descarga, pero usa el formato de fecha incorrecto. Una revisión visual no detecta el problema. Una prueba abre el archivo exportado y compara sus fechas con el formato requerido. El agente recibe el fallo, cambia el formateador y repite la comprobación.

LangChain informa de un cambio de 52,8 % a 66,5 % en Terminal Bench 2.0 manteniendo fijo GPT-5.2-Codex. Su informe de ingeniería de agentes describe orientación de verificación, contexto del entorno, detección de ediciones repetidas y cambios del presupuesto de razonamiento.

Esta es evidencia informada por un proveedor, no una prueba de que un modelo local pequeño iguale a un modelo de frontera. Apoya una conclusión más limitada: la selección del modelo por sí sola no explica los resultados del agente. LangChain también informa de peores resultados con el razonamiento máximo en todo momento por los tiempos de espera.

Ajusta las comprobaciones al trabajo #

Una comprobación aprobada establece solo lo que cubre. Una prueba CSV que valida nombres de columnas deja sin probar el formato de fecha, las comillas, Unicode y el control de acceso. Define el resultado solicitado antes de decidir cómo verificarlo.

El estudio τ-bench evalúa agentes que interactúan con herramientas, usuarios y reglas de dominio. Su artículo de investigación comprueba el estado final de la base de datos frente a los resultados esperados. Esto muestra por qué un texto de confirmación fluido no basta para comprobar una transacción.

Local no significa sin conexión #

La inferencia local controla dónde se ejecuta el modelo. La aplicación circundante aún determina dónde viajan documentos, consultas de búsqueda, trazas y resultados de herramientas. Un modelo de código local conectado a búsquedas remotas o herramientas en la nube sigue siendo un sistema conectado a la red.

Ollama declara que no recibe prompts ni respuestas durante la ejecución local y documenta cómo desactivar sus funciones en la nube. Esta es una afirmación específica del tiempo de ejecución, no una garantía de privacidad para cada agente conectado. Verifica el endpoint del modelo y cada integración según la documentación del tiempo de ejecución .

Un flujo híbrido necesita una regla explícita de transferencia. Por ejemplo, conserva localmente la extracción de documentos privados y envía solo resultados agregados aprobados para el análisis alojado. Revisa el material saliente exacto. Un resumen aún contiene información sensible si conserva nombres, datos de clientes o hallazgos confidenciales.

Prueba antes de comprar #

Elige una tarea repetida con una condición de finalización clara. Compara la configuración local con el producto alojado que usas, incluidas sus herramientas. Entrega a ambos las mismas entradas y criterios de aceptación. Repite la tarea con varios ejemplos representativos.

1. Registra la configuración: archivo exacto del modelo, cuantización, versión del backend, límite de contexto y configuración de razonamiento.
2. Define el éxito: artefacto esperado, comportamiento requerido y efectos secundarios prohibidos.
3. Mide la finalización: tiempo transcurrido, comprobaciones aprobadas, intentos fallidos y reparaciones manuales.
4. Incluye el coste de propiedad: hardware, electricidad, tarifas de API, mantenimiento y tu tiempo.
5. Clasifica los fallos: errores de razonamiento, límites de memoria, latencia, contexto ausente o verificación ausente.

La inferencia local sirve para trabajos cuya calidad y latencia evaluadas cumplen tus requisitos. Un modelo alojado sigue siendo útil cuando su capacidad adicional reduce fallos o esfuerzo de revisión. Un flujo híbrido asigna tareas diferentes a cada opción después de definir qué datos pueden salir de la máquina.

Cuenta el coste por resultado aceptado #

El tiempo de reparación humana cambia a menudo la economía. Una respuesta local rápida que necesita diez minutos de corrección consume más tiempo de trabajo que una respuesta lenta que supera la revisión. Cuenta los resultados aceptados junto con el gasto de inferencia.

Coste por tarea aceptada =
(asignación de hardware + electricidad + tarifas del servicio + mantenimiento + tiempo de revisión)
÷ tareas aceptadas

Coste de revisión ilustrativo: con una tarifa supuesta de 30 dólares por hora, ocho minutos de corrección cuestan 4 dólares por tarea. Cien tareas así consumen 400 dólares de tiempo de revisión. Son ejemplos aritméticos, no tasas medidas de fallos de modelos locales.

Compara resultados equivalentes. Incluye los intentos rechazados en el tiempo y el coste transcurridos. Para hardware propio, reparte el coste de compra durante un periodo de servicio y un volumen de tareas realistas. Para un servicio alojado, incluye la suscripción o el gasto de API aplicable y el trabajo de revisión que aún requiere.

Para conocer el hardware, continúa con la guía de modelos locales, GPU y contexto . Para capacidad y precios, lee la comparación de memoria del DGX Spark . Usa tus resultados de tareas para elegir la configuración más pequeña que cumpla tus requisitos de calidad, velocidad y datos.

Vídeo de referencia #

Referencias #

• AI Mechanics: IA local frente a ChatGPT: ¿Qué tan cerca estamos? .
• Artificial Analysis: resultados de modelos , metodología de evaluación y resultados de inferencia local .
• Publicadores de modelos: Qwen3.8-27B y GLM-5.3 .
• Unsloth: compilaciones Qwen GGUF y compilaciones GLM GGUF .
• Ollama: documentación de tiempo de ejecución, memoria y privacidad .
• LangChain: resultados de ingeniería de agentes .
• τ-bench: investigación de evaluación de agentes, herramientas y usuarios .