Coste de IA local frente a IA en la nube: dejad de alquilar inferencia que podríais tener en propiedad
La cuantización agresiva ha llevado modelos abiertos capaces desde la escala de un centro de datos hasta la de un portátil. Eso convierte «con qué proveedor firmamos» en la pregunta equivocada para una parte creciente del trabajo empresarial.
La mayoría de las compras de IA empiezan por decidir con qué proveedor firmar. Es la pregunta equivocada para empezar, y la comparativa de coste entre IA local e IA en la nube explica por qué. La factura por token es el coste más visible de ejecutar un modelo y el menos interesante, porque una parte creciente del trabajo que hay detrás de esa factura ya no necesita el centro de datos de otro.
Seguid el mecanismo, porque no tiene ningún misterio. Los parámetros de un modelo son números, y cuántos bits gastáis en almacenar cada número es una decisión de ingeniería, no una ley física. Dieciséis bits por parámetro ha sido el estándar de trabajo. La investigación sobre cuantización agresiva, incluido el trabajo publicado sobre modelos de peso ternario que restringen cada parámetro a tres estados, ha ido arrastrando esa cifra hacia un par de bits.
Haced la cuenta vosotros mismos, porque la cuenta es todo el argumento. Coged un modelo de 27.000 millones de parámetros. A dieciséis bits por parámetro son unos 54 GB de peso, lo que exige hardware de servidor. A 1,58 bits ronda los 6 GB. A un bit, se acerca a los 3,5 GB. Son cifras ilustrativas derivadas del recuento de parámetros y del ancho de bits, no resultados de benchmark de ninguna versión concreta, y una implementación real arrastra un sobrecoste que esta suma ignora. Lo que sobrevive a todas las salvedades es el orden de magnitud.
Un archivo de 6 GB cabe sin problema en un portátil de gama media. Uno de 3,5 GB cabe en un móvil actual. Cualquier modelo que corra en un teléfono corre en todos los portátiles que ya lleva vuestro equipo y en todos los servidores que tenéis parados en el rack.
¿Cómo comparar de verdad el coste de la IA local frente a la IA en la nube?
No dividiendo la factura mensual entre el número de tokens. Esa comparación favorece a la API porque solo pone precio a lo que la API cobra, y todo lo demás queda fuera del contador. Los documentos que salen de vuestro perímetro cargan con exposición de residencia de datos y coste de salida. Los prompts largos queman reintentos y desbordamientos de contexto que pagáis dos veces. Un modelo sobre el que habéis construido todo un flujo de trabajo puede quedar obsoleto, o ver sus condiciones reescritas, según el calendario del proveedor, no el vuestro.
El hardware propio invierte la ecuación. El coste de capital es fijo y conocido, el coste marginal de cada petición es casi cero, y nada sale de vuestro perímetro, algo especialmente relevante bajo la vigilancia de la AEPD sobre dónde acaban los datos personales. Lo que sustituye al coste como restricción principal es la variabilidad de la capacidad: un modelo comprimido es fiable dentro de una franja de tareas y poco fiable fuera de ella, y esa franja es más estrecha de lo que sugiere el marketing. Delimitarla con precisión para vuestro propio flujo de trabajo es el verdadero oficio dentro de la estrategia técnica y de compra de IA, y es un trabajo poco vistoso que nada más sustituye.
Hay una trampa en las cifras de retención publicadas que merece la pena nombrar. Cuando un proveedor anuncia que su versión comprimida conserva un noventa y pico por ciento de la media de benchmark de su versión sin comprimir, suena a un impuesto modesto. Las medias esconden la distribución. Una caída de cinco puntos en un conjunto de pruebas mixto puede ser un desplome de veinte puntos en la única capacidad de la que depende vuestro proceso, compensado por ninguna pérdida en tareas que nunca ejecutáis. Ninguna media publicada os dice cuál de las dos habéis comprado, así que tendréis que montar vuestro propio conjunto de evaluación con vuestros propios datos y comprobarlo.
¿Qué tareas siguen justificando una API de pago por uso?
Replantead la pregunta y la respuesta deja de ser el nombre de un proveedor para convertirse en una lista. Clasificación, extracción, redacción de textos internos, enrutado, resúmenes de documentos internos y primeros borradores son candidatos claros para un modelo que tengáis en propiedad. La ingeniería agéntica de largo recorrido, donde un sistema planifica a lo largo de decenas de pasos y se recupera de sus propios errores, no lo es, al menos todavía.
Quien espere que una clasificación general resuelva esto debería fijarse en lo poco que coinciden las clasificaciones entre sí. Plataformas públicas de evaluación como LMArena dividen sus tablas por categoría, y los mismos modelos ocupan posiciones muy distintas en texto, programación, visión y desarrollo web. Esa divergencia dice más que cualquier posición destacada en el titular. La capacidad depende de la tarea, lo que convierte «el mejor modelo» en un error de categoría antes incluso de convertirse en un error de compra, y un contrato plurianual anclado a una sola cifra compuesta está anclado a algo que nunca midió vuestro trabajo real. Es la misma razón por la que la preparación va antes que la construcción, no después de firmar el contrato.
El prestigio del proveedor tampoco sirve como referencia. Las rondas de financiación y el currículum de los fundadores reflejan expectativas sobre el futuro de un laboratorio, no mediciones del modelo que lanzaron el mes pasado, y ambas cosas se han separado suficientes veces como para que leer una valoración como prueba de ventaja técnica sea también un error de categoría. Una ventaja real aparecerá en vuestro propio conjunto de evaluación. Si solo aparece en el comunicado de la ronda de financiación, os han vendido un relato, no una capacidad.
El argumento de seguridad apunta en la misma dirección, hasta cierto punto
Aquí es donde matizaría mi propio argumento. Traer la inferencia a casa reduce vuestra exposición de datos, algo que vale la pena tener, pero no arregla el prompt injection. En el momento en que un modelo lee correos, páginas web o adjuntos no verificados y además puede actuar, la frontera entre dato e instrucción se convierte en vuestra superficie de ataque, y sigue siéndolo tanto si los pesos están en vuestro rack como en el de otro. El despliegue local limita el alcance del daño sobre los datos sin tocar la inyección en sí, un beneficio real y más estrecho de lo que sugiere el discurso de la soberanía del dato. Por eso los sistemas agénticos necesitan un contenimiento diseñado, no un simple cambio de alojamiento.
Esperad que esta asimetría se ensanche antes de estrecharse. Las herramientas de ataque automatizado escalan con la capacidad de cómputo disponible, mientras que las correcciones defensivas correspondientes tienden a desarrollarse y quedarse dentro de las organizaciones que construyen los modelos. Tomadlo como una razón para diseñar vosotros mismos el contenimiento, no para esperar a que un proveedor lo resuelva por vosotros.
La señal de fondo es que los lanzamientos comercialmente relevantes se están alejando de las interfaces de chat para acercarse a la infraestructura. El proyecto QiMeng del Instituto de Tecnología Informática de la Academia China de Ciencias afirma que su sistema completó automáticamente el diseño de una CPU RISC-V de escala industrial en cinco horas, y que el chip ya fabricado ejecuta Linux. Es una afirmación del propio equipo investigador, no una réplica independiente, y esa salvedad importa, pero la ambición que describe apunta al sustrato, no a la interfaz.
Las empresas que firman compromisos plurianuales de IA este año están fijando una estructura de coste y un grado de dependencia frente a una referencia técnica que se mueve bajo sus pies. La inferencia más barata que ejecutaréis nunca es la que ya tenéis en propiedad, y la única manera honesta de saber qué parte de vuestro trabajo cumple esa condición es probarlo con vuestros propios datos antes de firmar nada.
Preguntas frecuentes
¿Sale más barato ejecutar modelos de IA en local que pagar por token?
Para tareas estables, de volumen alto y bien definidas, normalmente sí, porque el hardware propio tiene un coste de capital fijo y un coste marginal por petición cercano a cero. Para trabajo puntual, de bajo volumen o razonamiento genuinamente complejo, una API de pago por uso suele salir más a cuenta, porque de lo contrario estaríais comprando capacidad para tenerla parada. El punto de equilibrio depende de vuestro volumen de peticiones y de vuestra utilización real, no de ninguna comparativa de precios publicada.
¿Qué hardware hace falta para ejecutar un modelo cuantizado en las propias instalaciones?
Depende por completo del tamaño comprimido. Una versión de entre 4 y 8 GB cabe sin problema en un portátil de desarrollo moderno o en una GPU de gama media. La restricción práctica rara vez es el archivo del modelo, es la concurrencia: dar servicio a veinte usuarios simultáneos exige bastante más memoria y capacidad que una sola persona probando en su puesto de trabajo, y es la cifra que la mayoría de pilotos olvida dimensionar.
¿Ejecutar un modelo en local protege frente al prompt injection?
No. El prompt injection explota el hecho de que un modelo no puede distinguir de forma fiable entre contenido no verificado e instrucciones, y esa limitación viaja con el modelo allá donde se ejecute. El despliegue local limita qué datos pueden salir de vuestra red si un ataque tiene éxito, lo que reduce las consecuencias sin eliminar la vulnerabilidad. Seguís necesitando límites de permisos por herramienta, validación de salidas y confirmación humana antes de acciones con consecuencias.
Relacionado
- La pérdida de habilidades por la IA es el riesgo que tu empresa no está calculando
- El oligopolio de la memoria que está inflando el coste real de la IA
- Mínimo privilegio para agentes de IA: la norma de 1975 que los pilotos actuales están ignorando
- AI & Automation
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.