Correr modelos locales ya vale la pena

Hace dos o tres años, correr un modelo local era una mezcla de curiosidad técnica y paciencia. Lo hacías por privacidad, por control o por pura ganas de experimentar, pero casi nunca porque el negocio cerrara. Hoy la ecuación cambió. Ya no estás hablando solo de “si se puede”, sino de cuándo conviene, para qué casos y con qué hardware.

La diferencia no es menor. Si tu flujo depende de enviar datos sensibles a una API externa, pagar por token y convivir con límites de uso, un modelo local puede darte algo mucho más concreto: costos más predecibles, menor latencia y más control sobre tus datos. Y si trabajas en una empresa en LatAm, donde el presupuesto de infraestructura se siente más que en otros mercados, eso pesa todavía más.

Qué cambió para que ahora sí valga la pena

El primer cambio es simple: los modelos abrieron el rango de uso útil. Ya no necesitas un monstruo de 70B parámetros para obtener respuestas decentes en tareas concretas. Para muchos casos reales, un modelo de 7B o 8B bien afinado alcanza. Eso baja la barrera de entrada porque te permite correr inferencia en una sola GPU de consumo, o incluso en CPU con paciencia, según el caso.

El segundo cambio es el ecosistema. Hoy tienes tooling más maduro para cuantización, serving y evaluación. Frameworks como llama.cpp, Ollama o vLLM reducen el tiempo que antes perdías armando una pila artesanal. Si quieres ver documentación oficial, vale la pena revisar llama.cpp y Ollama. No necesitas inventarte una infraestructura desde cero para validar una idea.

El tercer cambio es económico. En muchos equipos, el costo de usar una API externa deja de ser bajo cuando crecen los volúmenes o cuando el caso de uso exige prompts largos, múltiples llamadas o contexto persistente. Ahí un modelo local no solo compite por privacidad, también compite por presupuesto.

La señal más clara: ya no es solo para hackers

Antes, correr modelos locales era casi sinónimo de estar dispuesto a compilar, ajustar flags y aceptar errores raros. Eso sigue existiendo, pero ya no es la norma. Hoy puedes levantar un modelo en minutos, probarlo en una laptop potente o en una workstation y decidir con datos si te sirve.

También cambió la conversación interna. Antes, la pregunta era si el equipo de ML podía hacerlo. Ahora la pregunta es si el caso de uso justifica hacerlo local. Esa diferencia importa porque mueve el tema de la curiosidad al análisis de negocio.

Y ojo, no significa que todo deba correr localmente. Significa que ya no estás obligado a ir a la nube por defecto. Esa es la parte interesante.

Cuándo un modelo local sí te conviene

No todos los casos justifican montar infraestructura propia. Pero hay escenarios muy claros donde sí empieza a cerrar mejor. El primero es privacidad. Si trabajas con contratos, datos médicos, información financiera o soporte interno, mandar contenido a un proveedor externo puede complicarte por compliance, auditoría o simple riesgo operativo.

El segundo es latencia. Si tu aplicación necesita respuestas rápidas y repetibles, quitar el viaje a una API pública ayuda. En local, el tiempo de respuesta depende más de tu hardware y de tu optimización que de la red. Eso se nota mucho en productos internos, asistentes de equipo o flujos de edición asistida.

El tercero es costo por volumen. Si tu app procesa miles de consultas al día, el costo por token puede crecer rápido. En cambio, una GPU amortizada en un servidor propio puede salir más barata si mantienes una utilización razonable. No es magia: es capex versus opex, y hay que hacer la cuenta.

Casos concretos donde sí suma

Algunos ejemplos reales donde un modelo local suele tener sentido:

• Un equipo legal que resume contratos con datos sensibles.
• Un soporte interno que responde sobre documentación privada.
• Una app de productividad que indexa notas personales sin salir del dispositivo.
• Un flujo de análisis de texto en una empresa con restricciones de residencia de datos.
• Un asistente para desarrolladores que trabaja sobre repositorios internos.

En todos esos casos, el valor no está en “tener IA”. Está en reducir fricción operativa sin abrir una fuga de datos ni depender de una cuota mensual que sube con el uso.

Cuándo no vale la pena

También hay casos donde te conviene seguir con API externa. Si tu volumen es bajo, si el equipo no tiene tiempo para operar infraestructura o si tu caso necesita capacidades de razonamiento muy altas que todavía no igualas localmente, probablemente no compense.

Lo mismo pasa si tu producto necesita escalado impredecible. Una API te da elasticidad inmediata. En local, tú asumes la capacidad y el mantenimiento. Si tu tráfico sube y baja fuerte, esa rigidez puede salir cara.

La clave es no romantizar la autonomía. Correr localmente no es mejor por definición. Es mejor cuando te da una ventaja medible.

Qué hardware necesitas de verdad

Aquí conviene aterrizar expectativas. No todo se resuelve con una laptop y buena voluntad. Para modelos pequeños y cuantizados, una máquina de consumo puede bastar. Para más contexto, más velocidad o más usuarios concurrentes, ya necesitas pensar en GPU, memoria y almacenamiento con más cuidado.

La memoria es el primer cuello de botella. Un modelo de 7B cuantizado puede correr en menos de 8 GB de VRAM en ciertos escenarios, pero eso no significa que vayas a tener una experiencia fluida para producción. Si agregas contexto largo, batching o varias sesiones, el consumo sube.

La CPU también importa, sobre todo si corres inferencia sin GPU o si usas una GPU modesta y parte de la carga cae al procesador. En ese caso, la latencia puede ser aceptable para tareas asíncronas, pero no para una interfaz conversacional exigente.

Tabla rápida de referencia

No tomes esta tabla como una receta universal. Sirve para ubicarte. La decisión real depende del tamaño del modelo, la cuantización, el contexto y la concurrencia que esperas.

Si quieres una guía técnica más formal sobre formatos y optimización, la documentación de vLLM explica bien cómo se maneja el serving eficiente de modelos grandes. No es el único camino, pero sí uno de los más usados cuando quieres algo más serio que una demo.

Costos, privacidad y latencia: la cuenta que sí importa

La discusión real no es “cloud vs local” en abstracto. Es cuánto te cuesta cada respuesta, qué riesgo aceptas y qué experiencia recibe tu usuario. Si miras solo el precio de la GPU, te equivocas. Si miras solo el precio por token, también.

Hay tres variables que deberías medir antes de decidir:

1. Costo total mensual de la infraestructura.
2. Volumen de requests o tokens que vas a procesar.
3. Valor del control adicional sobre datos y latencia.

Si tu equipo hace pocas consultas, una API puede seguir siendo más barata. Si tu uso crece y se vuelve constante, el costo fijo de un servidor puede empezar a ganar. El punto de equilibrio depende de tu caso, no de una fórmula universal.

Un ejemplo sencillo de comparación

Supón que tienes un asistente interno con 10 personas del equipo usando 50 consultas al día cada una. Eso da 500 consultas diarias. Si cada consulta consume bastante contexto y respuesta, una API puede volverse cara rápido. En local, el costo principal pasa a ser la máquina, el mantenimiento y la electricidad.

Ahora cambia el escenario: 30 usuarios, 200 consultas diarias y prompts largos. Ahí el gasto por token puede crecer lo suficiente como para justificar una workstation dedicada o un servidor pequeño. No necesitas un clúster para hacer la cuenta; necesitas medir tu uso real durante una o dos semanas.

Dónde sí gana la privacidad

La privacidad no es un argumento abstracto. Si tu equipo manda reportes internos, tickets de soporte o datos de clientes a un tercero, ya tienes una discusión de riesgo. Incluso cuando el proveedor promete no entrenar con tus datos, sigues teniendo que revisar contratos, retención, acceso y residencia.

En local, tú controlas más capas. Eso no significa seguridad automática, porque igual debes cuidar logs, acceso a la máquina y backups. Pero sí reduces el número de terceros involucrados. Para muchas empresas en Ecuador y en el resto de LatAm, eso simplifica auditorías y conversaciones con legal.

Cómo empezar sin sobredimensionar

La mejor forma de empezar no es comprar hardware antes de validar el caso. Es probar con un modelo pequeño, medir calidad y latencia, y solo después decidir si vale la pena escalar. Si haces lo contrario, puedes terminar con una GPU cara que nadie usa.

Un camino razonable se ve así:

1. Define una tarea concreta, por ejemplo resumen de tickets o clasificación de texto.
2. Elige un modelo pequeño y cuantizado.
3. Ejecuta pruebas con datos reales, no con prompts de juguete.
4. Mide latencia, calidad y tasa de errores.
5. Compara contra tu opción actual en nube.
6. Solo entonces decide si compras hardware o sigues con API.

Un flujo mínimo de prueba

Si quieres validar localmente sin complicarte demasiado, puedes arrancar con una herramienta como Ollama y un modelo pequeño. El objetivo no es tener la mejor arquitectura del mundo, sino responder una pregunta concreta: ¿sirve para tu caso?

ollama pull llama3.1:8b
ollama run llama3.1:8b

Ese tipo de prueba te deja ver rápido si el modelo entiende tu dominio, si responde con suficiente calidad y si la latencia es aceptable. Si no pasa esa prueba, no tiene sentido seguir invirtiendo.

Qué medir desde el día uno

No te quedes solo con “se siente rápido”. Mide:

• Tiempo hasta la primera respuesta.
• Tokens por segundo.
• Uso de VRAM o RAM.
• Tasa de respuestas útiles sobre un set de pruebas.
• Costo mensual estimado si escalas a producción.

Con esos datos puedes hablar con producto, finanzas y seguridad sin vender humo. Y eso suele ser más útil que cualquier benchmark genérico.

El punto de equilibrio ya cambió

Lo interesante de correr modelos locales hoy no es que sea posible. Eso ya lo sabíamos. Lo interesante es que ahora puede ser una decisión racional. Si tienes datos sensibles, volumen suficiente o necesidad de control, el local ya no es un hobby: es una opción de arquitectura.

Tampoco conviene caer en extremos. No todo debe ir local, y no todo debe ir a una API. Muchas veces la mejor solución es híbrida: local para tareas sensibles o repetitivas, nube para picos de carga o tareas más complejas. Esa mezcla te da flexibilidad sin obligarte a elegir una sola postura.

Si trabajas en una empresa en LatAm, este cambio importa todavía más. El presupuesto suele ser más ajustado, la latencia de red puede afectar más y la conversación sobre datos no es opcional. Correr modelos locales ya no es una rareza técnica. Es una herramienta más en tu caja.

Tabla resumen