Proyecto 07 / Caso de estudio
Infraestructura propia · IA
Un servidor propio sirve un modelo grande a través de una API compatible con OpenAI. No está ahí de decoración: el CRM, los rascadores de clientes, la demo de RAG y un juego con modo IA le hablan por una variable de entorno. Esta ficha va de por qué eso sale más barato que una factura por tokens, y de qué se paga a cambio.
Cada proyecto mío que usa IA se paga por tokens. Un rascador que clasifica treinta mil fichas no es una consulta, es una factura, y el margen del producto se va en eso. Además está el otro coste, el que no se ve en la cuenta: para enriquecer una base de datos de clientes tengo que enviar esa base de datos a un servidor de terceros. Quería razonar con modelos grandes sin contador y sin entregar un dato de un cliente a nadie.
Un servicio de inferencia en contenedor que expone una API compatible con OpenAI. El modelo llega cuantizado y repartido entre la memoria disponible. Cada proyecto apunta a él cambiando una variable de entorno, exactamente igual que apuntaría a un proveedor comercial: el código no sabe dónde está el modelo que le responde.
Que la compra no se juzga en la ficha técnica sino en el coste por tarea terminada. Y que la parte difícil no es el arranque: es decidir qué modelo entra, a qué precisión, cuántas capas se descargan a la memoria principal y qué pasa cuando el modelo no responde. Eso último ya lo tenía resuelto en otro proyecto, y aquí volvió a ser lo importante.
Arquitectura
El servidor de cómputo corre los servicios pesados en contenedor. La otra máquina actúa de puerta de entrada: cada servicio deja de ser una IP con un puerto raro y pasa a tener un dominio, con su TLS, desde un punto único.
La base es una máquina propia dedicada al cómputo, que pasa el día con modelos enteros mapeados en memoria. Elegí el equipo por la memoria disponible y no por la velocidad, y eso condiciona todo lo que viene después en esta ficha.
Ahí está la razón de ser del proyecto: un modelo de 125 mil millones de parámetros, incluso cuantizado a tres bits, no entra en una sola tarjeta de consumo. Con una sola habría que servir un modelo cuatro veces más pequeño, y un modelo cuatro veces más pequeño es otro producto. El formato GGUF permite además que el excedente se descargue a la memoria principal, así que hay margen para subir la cantidad de contexto sin tocar el modelo.
Sobre eso corren varios servicios en contenedor, cada uno con su volumen de datos independiente. El principal es el servidor de inferencia en GPU con API compatible con OpenAI: un único endpoint al que se puede llamar con cualquier cliente que ya exista. El resto son servicios de desarrollo y de automatización que consumen ese mismo endpoint. Viven aquí y no se publican.
La segunda máquina resuelve un problema distinto. Un servicio en 192.168.x.x:8000 no se le puedes explicar a nadie, y en cuanto cambias un contenedor de puerto se rompe todo lo que depende de él. Con un proxy inverso que da un dominio a cada servicio, los proyectos apuntan a un nombre estable y el mapeo interno cambia sin que nadie se entere. La separación entre las dos máquinas es deliberada: reiniciar el servidor de cómputo para probar algo no debería tumbar la puerta de entrada, y viceversa.
Decisiones
Todas tienen una alternativa descartada y un coste que se paga todos los meses.
Las tarjetas son de una generación ya retirada para cargas nuevas. Con esa compra se elige mucha memoria gráfica por una fracción de lo que cuesta equipararse en la generación actual, y se renuncia a lo demás: a las funciones de aceleración que las tarjetas actuales traen de serie y a un soporte de fabricante que va de salida. Es un intercambio, no una ganga. Para servir un modelo grande a un usuario o a dos, la memoria manda y la generación es secundaria; para servir a mucha gente a la vez, esta máquina no es la respuesta y no lo será.
Todos mis proyectos hablan con modelos por el formato de siempre, que es el que popularizó el proveedor comercial. Servir por ese mismo formato hace que cambiar de proveedor, o volver a la nube para una prueba, sea cambiar una URL y una clave. El CRM lo demuestra: su integración entera está detrás de un flag y una dirección base, y puede funcionar sin IA sin tocar una línea. El coste es depender del formato de un tercero, que lo cambia cuando le da la gana, y perder los parámetros propios de cada motor que por ese tubo no viajan.
El modelo se sirve cuantizado, en un formato que además viene partido en varios ficheros. Bajar la precisión de los pesos es lo que hace entrar un modelo de 125 mil millones de parámetros en la memoria disponible con margen para el contexto. La factura es de calidad en tareas muy finas: en clasificación de fichas de empresa o en extraer un correo de una página web no se nota; en un texto largo y ambiguo, sí. La comparación honesta no es contra el modelo en precisión completa, es contra el modelo pequeño que sí cabría sin cuantizar, y ahí la versión cuantizada gana por lejos.
Hay un servicio que trabaja con sesiones iniciadas, y es el más delicado de la máquina: quien llegue a él maneja todo lo que tengas abierto. Está desplegado pero parado, y solo se levanta cuando hay una ejecución. Superficie de ataque cero los días que no se usa. El coste es que cada ejecución empieza con un arranque en frío, unos segundos que en un lote de horas no se notan.
Lo que da y lo que cuesta
Lo bueno es real y lo malo también. Pongo las dos columnas.
Lo que da. Cero coste marginal por token: un lote que clasifica treinta mil fichas cuesta lo mismo en cómputo que una sola pregunta, y eso cambia qué cosas merece la pena automatizar. Cero límites de tasa, con lo que un rascador puede ir a su ritmo sin que un proveedor le corte a mitad. Los datos no salen de casa, que para una base de clientes no es un detalle técnico sino la condición para poder trabajar con ella. Y se sirve el modelo que yo elijo, sin condiciones de uso sobre lo que se puede hacer con la salida y sin filtros de contenido que aparecen cuando un proveedor cambia una política. Sin cuota de suscripción, sin tarjeta, sin depender de que un tercero no decida retirar una versión.
Lo que cuesta. El equipo se paga por adelantado y se degrada en silencio: si mañana quiero servir un modelo de 200 mil millones con contexto largo, la respuesta es otra compra, no una tarjeta de crédito. El consumo eléctrico es permanente. Y la operación es mía: nadie me llama cuando algo se cae, así que si un reinicio deja un servicio sin levantar me entero cuando un proyecto falla. Aquí no hay monitorización montada todavía, y eso es una deuda real, no una virtud.
Lo que no me creo y por eso lo digo. No he medido tokens por segundo, ni concurrencia sostenida, ni temperatura con la sala cerrada. Las cifras de esta ficha son de código y de uso, y no hay ni una medida de rendimiento porque aún no la tengo. Quien lea esta ficha y quiera un número de rendimiento, no se lo puedo dar todavía.
Lo primero, medir antes de ampliar. Monté el servicio y lo puse a trabajar sin registrar nunca tokens por segundo, utilización de las tarjetas ni coste eléctrico real por lote. Sin esa línea base, la próxima ampliación es una corazonada. Lo segundo, monitorización y aviso: un servicio que se cae de noche no se entera nadie hasta que un proyecto falla, y eso ya ha pasado. Lo tercero, revisar cómo se comunican las tarjetas entre sí: sin un enlace directo declarado, todo pasa por el bus de la placa, y en cuanto haya peticiones simultáneas eso será el cuello de botella. Y lo que viene ahora, exponer herramientas al agente para que la máquina no solo responda texto sino que actúe sobre los servicios que ya corren en ella: es la razón por la que monté el cómputo en casa en lugar de contratarlo.
No publico direcciones, dominios, credenciales ni el contenido de los repositorios privados que viven en esta máquina, y tampoco las especificaciones del equipo ni lo que corre dentro. Lo que se cuenta aquí es la decisión y su coste, que es lo que se puede razonar. Lo que no he medido, está marcado como no medido.