Lo que cambia de verdad al autoalojar un modelo

Autoalojar un modelo de lenguaje se ha vuelto técnicamente sencillo: descargas los pesos, levantas un servidor de inferencia y en una tarde tienes algo respondiendo. Esa parte es la fácil, y por eso es la única que sale en los tutoriales.

Lo que decide si el proyecto sale bien no es esa tarde, sino los dos años siguientes. Cuento lo que he aprendido operándolo de verdad.

Lo que ganas: tres cosas, por este orden

Los datos dejan de ser un problema jurídico

Es la razón principal y la única que a veces no tiene alternativa. Cuando trabajas con historia clínica, documentación interna de un despacho o expedientes de personal, enviar eso a un tercero abre una conversación incómoda: encargado del tratamiento, transferencias internacionales, subencargados, retención, y la duda de si tu proveedor entrena con lo que le mandas.

Autoalojando, esa conversación desaparece. No la gestionas mejor: no existe. Para nosotros fue lo que hizo viable el proyecto.

Siguen haciendo falta base legal, control de accesos, minimización, política de conservación y cuidado con lo que acaba escrito en los registros. Ese último punto se olvida siempre: he visto sistemas impecables volcando conversaciones completas con datos personales a un fichero de texto que nadie vigilaba. Nosotros lo detectamos en una auditoría interna, con 45 volcados ya escritos.

El coste deja de crecer con el éxito

Con una API pagas por uso, así que cada usuario nuevo encarece la factura. Con infraestructura propia el coste es fijo: a partir de cierto volumen, crecer es gratis. El punto de equilibrio depende de tu caso, y calcularlo antes de comprar nada es la parte honesta del trabajo.

Aviso de consultor: si tu volumen es bajo, la API es más barata y más simple, y montar esto es tirar dinero. Lo digo a clientes que venían decididos a autoalojar.

Nadie te cambia el suelo bajo los pies

La versión que validaste sigue ahí mañana. No hay deprecaciones, ni cambios silenciosos de comportamiento, ni límites de uso en el peor momento, ni subidas de precio. Cuando has invertido semanas en calibrar prompts contra un modelo concreto, esto vale más de lo que parece.

Lo que cuesta: la parte aburrida

Aquí es donde los proyectos se tuercen, y no tiene nada que ver con la IA.

• La luz se va. Y cuando vuelve, ¿arranca todo solo y en el orden correcto? Nosotros aprendimos esto por las malas. Un SAI y los servicios configurados para levantarse solos no son opcionales.
• El disco se llena. Los modelos pesan, los registros crecen y las descargas se acumulan. Sin vigilancia del disco, un día el servicio deja de escribir y falla de forma rarísima.
• Actualizar da miedo, con razón. Cambiar de versión de modelo mueve el comportamiento. Sin una batería de casos que ejecutes antes y después, estás actualizando a ciegas.
• Alguien tiene que estar. Si el servicio cae un domingo, ¿quién se entera? Una monitorización sencilla que avise es lo mínimo, y decidir de antemano qué pasa si no hay nadie.
• Salida a internet. Un detalle tonto nos costó horas: el servidor salía por IPv6 y el relé de correo solo autorizaba la IPv4. Estas cosas no salen en ningún tutorial.

Nada de esto es difícil. Todo es trabajo, y hay que asignarlo a alguien antes de empezar, no después del primer susto.

Elegir modelo y GPU sin copiar tablas

La pregunta que más me hacen es qué GPU hace falta, y la respuesta honesta es que depende del modelo y de cuánta gente lo use a la vez, no del tamaño de tu empresa. Para un asistente interno con un modelo mediano cuantizado, una sola GPU profesional de 24 a 48 GB da servicio a decenas de usuarios simultáneos.

Dos recomendaciones que ahorran dinero:

• Empieza alquilando. Una GPU en un proveedor europeo te da el mismo aislamiento de datos sin inversión inicial. Si el volumen crece, entonces valoras comprar.
• Lee la licencia. No todo lo que se llama abierto permite uso comercial sin condiciones. Es de las pocas cosas que pueden obligarte a rehacer el proyecto entero.

Y sobre qué modelo: probamos alternativas más grandes esperando una mejora clara y nos quedamos con el que ya teníamos, porque la diferencia real en nuestro dominio no compensaba el coste. Medir tu caso concreto vale más que cualquier tabla comparativa.

Entonces, ¿merece la pena?

Si tus datos son sensibles, casi siempre sí, y a veces es la única forma de que el proyecto exista. Si tu volumen es alto y estable, los números salen solos. Si no se cumple ninguna de las dos, probablemente no, y quien te diga lo contrario sin mirar tus cifras te está vendiendo algo.

Lo que sí es seguro es que no es un proyecto de una tarde. Es un servicio en producción, con todo lo que eso implica.