Siete casos, todos corregidos.

Estos son los proyectos que resulta poco habitual poder aceptar: el modelo se ejecuta en el hardware del propio cliente y nada llega a un tercero. Antes eso costaba consistencia. Con el modelo actual ya no: la columna local iguala pregunta por pregunta al mejor de los dos modelos alojados, y responde más rápido que ambos.

La mayoría de las organizaciones está aquí, y muchas no lo saben. Estos datos no tienen restricción de residencia, así que un modelo alojado aprobado es lo adecuado: nada que operar, ningún hardware que comprar y más rápido de poner en marcha. Lo diremos, en lugar de venderte infraestructura que no necesitas.

La mayoría de las organizaciones no necesita un modelo privado, y lo diremos. Si tu política ya admite un proveedor de IA aprobado, un modelo alojado de frontera es lo que menos trabajo da: sin GPUs que comprar, nada que operar y la precisión que se ve arriba. Sigue siendo nuestra opción por defecto para la mayoría. Lo que no es, en estas preguntas, es lo más rápido.

Lo que no vamos a hacer es fingir que esa elección no tiene consecuencias. En esa configuración, tus prompts y los resultados de consulta que lee el agente se envían al proveedor del modelo según el acuerdo que tengas con él. Para muchísimas cargas de trabajo eso es perfectamente aceptable y ya está cubierto por una revisión de proveedores existente. Para algunas no lo es, y ese es el caso que resulta poco habitual poder atender.

Alojado: nuestra opción por defecto

Nada que operar y ningún hardware que comprar, precio por token. La configuración individual más precisa de las medidas aquí, aunque por poco. Los datos llegan al proveedor del modelo. Adecuado para la mayoría de los clientes la mayor parte del tiempo.

En tu hardware

Para datos que realmente no pueden salir. Nada llega a un tercero y no hay coste por token una vez que existe el hardware. La precisión depende mucho de qué modelo abierto ejecutes: la columna local es una mezcla de expertos de 36B en una sola máquina, y pasar a ella desde un modelo de código de 30B cerró por completo la diferencia con los modelos alojados. Así que la lección no es «un modelo más grande ayudaría»: importó mucho más cuál es el modelo, y cómo está ajustado, que su tamaño.

Mixto

Suele ser la respuesta correcta cuando el despliegue madura: los datos restringidos en local y todo lo demás por una API aprobada, decidido por caso de uso y no por proveedor.

Cambiar después

Una línea de configuración. No eliges una vez para siempre, ni quedas atado a nosotros en ninguno de los dos casos.

Hay un resultado que merece detenerse, porque invierte la suposición obvia. Mediciones anteriores daban a los dos modelos alojados más precisión que al local y menos velocidad, y atribuimos esa latencia a los viajes de ida y vuelta más que a los modelos: esto es un bucle de agente que descubre el esquema, describe tablas y ejecuta una consulta a lo largo de varias llamadas, y cuando el modelo está alojado cada una cruza internet. Cambiar el modelo local puso a prueba esa lectura. El actual iguala pregunta por pregunta al mejor de los alojados y responde en unos 230s frente a sus 391 y 403. El coste eran los viajes. «Lo alojado es rápido, lo local es privado» siempre fue demasiado simple: en estas preguntas, lo local es ahora lo más rápido.

OpenAI 20–21/21 × 3 · 374–411s DeepSeek 21/21 × 3 · 329–591s Local 20–21/21 × 4 · 215–242s

Los resultados varían según el modelo, el hardware y la ejecución. Cada modelo aquí se evaluó varias veces, y las cifras son rangos y medianas de esas ejecuciones, no una única medición; eso sí, todas se tomaron el mismo día y no constituyen una garantía. Hemos visto al mismo modelo local acertar una pregunta en una ejecución y fallarla en la siguiente, que es precisamente por lo que la tabla cuenta ejecuciones en lugar de dar un solo veredicto. Si te importa un modelo concreto, la respuesta honesta es ejecutar estas mismas preguntas corregidas contra él en lugar de confiar en una tabla de una web, y lo haremos contigo, sobre tu esquema.