Siempre llega el mismo momento, en cuanto alguien tiene un modelo local corriendo: ¿por qué seguir pagando el de la nube? La respuesta real no es de dinero, y no es de velocidad. Es de lo que el modelo entiende mal, y esa parte es invisible hasta que la tarea es lo bastante grande para dejarla ver.
Yo uso los dos, a propósito, y la pregunta que respondo cada vez no es «qué modelo es mejor». Es «qué le voy a pedir exactamente, y esta tarea cae en la zona donde la diferencia deja de importar».
Esta no es la pregunta de nube vs local de herramientas
Nube vs local en herramientas de IA es sobre dónde vive el estado de tu producto: tus specs, tus decisiones, tu grafo de producto, en tu disco o en el servidor de otro. Ese trade es real, y no tiene nada que ver con qué modelo escribe tu código. Una herramienta puede ser local-first y aun así llamar a un modelo frontier para inferencia, porque el sistema coordinador y el motor detrás de una llamada concreta son cosas distintas.
Esta es la otra pregunta, la que queda incluso después de haber resuelto dónde vive tu dato: si el motor en sí es un modelo pequeño corriendo en tu máquina en vez de un modelo frontier en la nube, qué pierdes de verdad en el código que produce.
Lo que la brecha no es
No es latencia. El módulo de benchmarks de inferencia de PAELLADOC mide tiempo al primer token, velocidad de generación y fallos para las rutas que de verdad usas, y lo dice sin rodeos: una medición de latencia no sabe si el código es correcto, si un plan es bueno, o si el modelo manejó una herramienta con seguridad. Un modelo local puede contestar rápido y contestar mal. Un modelo frontier lento puede ser el que debiste haber usado.
Tampoco es precio, no directamente. Controlar los costes de IA trata de no mandar un copy edit al motor más caro que tienes. Esa heurística asume que la ruta barata basta para la tarea fácil, y normalmente es verdad. No dice nada de qué pasa cuando la tarea deja de ser fácil.
Dónde vive la brecha de verdad
Tres sitios, por lo que he visto, y ninguno se nota en una demo corta.
Razonamiento en varios pasos bajo ambigüedad. Una tarea bien especificada con un test ya escrito está más cerca de la transcripción que del juicio, y un modelo pequeño transcribe bien. La brecha se abre cuando la spec está incompleta y el modelo tiene que decidir qué probablemente querías decir. Un modelo frontier tiende a preguntar, o a hacer una suposición defendible y señalarla. Un modelo local más pequeño tiende a comprometerse con confianza con la primera interpretación, que es exactamente la forma de un falso éxito: un resultado plausible que está mal en silencio.
Uso de herramientas en modo agente. Leer un mensaje de error, decidir si reintentar, cambiar de enfoque o pararse a preguntar, durante diez o quince pasos sin perder el hilo, es una habilidad distinta de escribir una función. Aquí es donde los agentes derivan más rápido de un plan con un motor más débil debajo, porque recuperarse de un paso malo exige el mismo juicio que causó el paso.
Contexto entre ficheros a escala. Un cambio que toca una sola función es trabajo local. Un cambio donde la respuesta correcta depende de un invariante a tres archivos de distancia es otra tarea, y es exactamente el tipo que SWE-bench se construyó para medir con honestidad, con issues y pull requests reales de repositorios reales en vez de un problema de juguete escrito para el benchmark. Ese es el instinto que conviene adoptar aunque nunca corras el benchmark público tú mismo: juzgar si la tarea se hizo contra un código real, no por lo seguro que suena el resultado.
Dónde la brecha apenas importa
Dale la vuelta, porque la brecha no es un impuesto sobre toda tarea, solo sobre algunas.
Un cambio acotado con un test que ya fija el comportamiento esperado. Formateo, boilerplate, un endpoint CRUD que sigue un patrón ya establecido diez veces en el repo. Cualquier cosa donde ya existan los criterios de aceptación y el trabajo del modelo sea cumplirlos, no inventarlos. En ese tipo de tarea, un modelo local que termina en unos segundos, gratis, no es una renuncia. Es la herramienta correcta, y pagarle a un modelo frontier por hacer transcripción es el despilfarro, no al revés.
Y hay un caso donde la brecha es irrelevante por una razón completamente distinta: cuando el trabajo no puede salir de tu máquina, por un cliente, un contrato o una jurisdicción. Correr en local por privacidad es un requisito, no un trade-off, y en ese eje la brecha de calidad es un precio que pagas a propósito, con los ojos abiertos, por una garantía que ningún modelo en la nube puede darte.
Cómo lo averiguas de verdad, para tu propio repo
El benchmark de nadie te responde esto, porque la brecha depende de la forma de tu código, de la calidad de tus specs, y de las tareas concretas que le lanzas. La versión honesta no tiene truco: corre la tarea que de verdad importa por las dos rutas, en tu propio repo, y juzga el resultado contra una puerta real, no contra lo fluida que suena la explicación.
Esa es la forma de la decisión cada vez, no un veredicto único sobre qué modelo gana. El routing de modelos es el mecanismo para actuar sobre eso sin volver a decidir a mano en cada tarea: manda el trabajo acotado y bien especificado al motor barato y local, y reserva la llamada frontier para la tarea donde la ambigüedad o un bucle de agente largo convierten la brecha en dinero real. Es una versión pequeña y constante de ser el runtime: no escribir el código, sino decidir, tarea a tarea, qué motor se ha ganado de verdad esta.
Qué cuesta cerrar la brecha
Puedes acortar la brecha con más andamiaje: prompts más ajustados, más ejemplos, un mensaje de sistema más largo, un bucle de reintento que atrape los errores del propio modelo. Todo eso es tiempo de ingeniería real, y recupera solo parte de la diferencia, porque buena parte de la brecha es profundidad de razonamiento, no seguir instrucciones, y ningún ajuste de prompt convierte un modelo pequeño en uno grande.
La pregunta que vale la pena hacerse no es «puedo cerrar la brecha» sino «esta tarea concreta es lo bastante barata, y el riesgo lo bastante bajo, como para preferir cinco minutos de ingeniería de un rodeo antes que mandarla al modelo que la habría resuelto sin más». Pasado cierto nivel de ambigüedad o cierto radio de impacto, la respuesta es no, y está bien. El sentido del routing es no tener que volver a discutirlo cada vez.
Dónde encaja PaellaDoc
PaellaDoc trata esto como una decisión de routing, no como un compromiso único con un modelo. La flota incluye motores locales vía Ollama y modelos frontier de cualquier proveedor, y el router elige el motor para la tarea que tiene delante en vez de apostar todo el proyecto a una única respuesta a «qué modelo es mejor». El módulo de benchmarks de inferencia te dice qué hacen de verdad tus propias rutas configuradas antes de apoyarte en cualquiera de los dos lados del trade.
¿Dónde pones tú la línea entre local y frontier? Cuéntamelo en el foro.
Preguntas frecuentes
¿Un modelo de IA local es tan bueno como uno en la nube para programar?
Depende de la tarea, no de un veredicto general sobre los modelos. En trabajo acotado y bien especificado, con un test o unos criterios de aceptación que ya fijan el resultado esperado, un modelo local suele resolverlo sin problema. La brecha se abre con specs ambiguas, bucles largos de uso de herramientas en modo agente, y cambios cuya corrección depende de algo a varios archivos de distancia. Son las tareas donde un modelo más débil tiende a comprometerse con confianza con una respuesta equivocada en vez de señalar la ambigüedad.
¿Qué pierdo exactamente si uso un modelo local en vez de uno frontier?
No velocidad, y no dinero directamente. Pierdes profundidad de razonamiento bajo ambigüedad, fiabilidad en un bucle de agente de varios pasos donde el modelo tiene que interpretar sus propios errores y decidir si reintenta o se detiene, y robustez en cambios que dependen de contexto a varios archivos del que se está editando. En tareas acotadas y fijadas por un test, no pierdes nada que importe.
¿Cómo sé si la brecha importa para mi proyecto concreto?
Corre la tarea que de verdad te importa por las dos rutas y juzga el resultado contra una puerta real (tests que pasan, criterios de aceptación cumplidos), no contra lo seguro o fluido que suena la explicación. Un benchmark local de tus propias rutas configuradas, midiendo resultados reales sobre tu propio repo, te dice más que cualquier tabla pública, porque la brecha depende de la forma de tu código y de la calidad de tus specs, no de la reputación general de un modelo.
¿Puedo cerrar la brecha con mejor prompting?
En parte. Prompts más ajustados, más ejemplos y un bucle de reintento que atrape errores obvios recuperan algo de la diferencia en seguir instrucciones. No recuperan profundidad de razonamiento, porque esa parte de la brecha no depende de cómo esté redactada la tarea. Pasado cierto nivel de ambigüedad o de riesgo, mandar la tarea a un modelo más fuerte cuesta menos que hacer ingeniería alrededor de los límites de uno más pequeño.