Proyecto 07 / Caso de estudio
Infraestructura propia · IA · dos máquinas
Una máquina de servidor con dos tarjetas gráficas y 256 GB de memoria con corrección de errores 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.
Plataforma de servidor con dos GPU y un servidor de inferencia en contenedor que expone una API compatible con OpenAI. El modelo llega cuantizado y repartido entre las dos tarjetas. 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 RAM 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. Otra máquina actúa de puerta de entrada con Nginx: 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 plataforma de servidor con 24 núcleos a 2,00 GHz y 256 GiB de DDR4 con corrección de errores multi-bit. La RAM con ECC no es un capricho en esta máquina: pasa el día con modelos enteros mapeados en memoria, y un bit que cambia en un tensor no da un error, da una respuesta plausible y equivocada. Es la clase de fallo que no se detecta porque no hay una excepción que lo pare.
El cómputo pesado de GPU son dos tarjetas de 32 GB, 64 GB en total. 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 32 GB. Con una sola tarjeta 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 RAM, que aquí es de 256 GiB, así que hay margen para subir la cantidad de contexto sin tocar el modelo.
Sobre eso corren cuatro servicios en contenedor, cada uno con su volumen de datos independiente. El primero 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. Los otros tres son una forja git privada con API HTTP para automatizar el despliegue de mis propios servicios, un agente autónomo que consume ese mismo endpoint de inferencia, y un navegador gestionado con puerto de depuración remoto para las automatizaciones de formulario y sesión, que se levanta solo cuando se usa.
La segunda caja 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 pasamuros inverso que da un dominio a cada servicio, los proyectos apuntan a un nombre estables y el mapeo interno cambia sin que nadie se entere. La separación entre las dos cajas es deliberada: reiniciar el servidor de cómputo para probar una tarjeta 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 dos tarjetas son de una arquitectura de hace ocho años. Con esa compra se eligen 64 GB de memoria gráfica por una fracción de lo que cuesta equipararse en una generación actual, y se renuncia a lo demás: sin núcleos tensor, sin el tipo numérico de ocho bits con rango ampliado, y con un soporte de fabricante que va de salida para esa arquitectura. 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 casarse con el formato de un tercero, que cambia sus cosas 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 tres ficheros. Bajar la precisión de los pesos es lo que hace entrar un modelo de 125 mil millones de parámetros en dos tarjetas de 32 GB 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.
El servicio que expone un navegador con puerto de depuración remoto es el más peligroso de la máquina: quien llegue a ese puerto maneja las sesiones que estén abiertas. 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 aparezcan 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 hardware 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 hardware y de código, verificables, 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 comprar la siguiente pieza. Monté el servicio y lo puse a trabajar sin registrar nunca tokens por segundo, utilización de las dos 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 la interconexión entre las dos tarjetas: sin un enlace directo declarado entre ellas, la comunicación va 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. El hardware y los servicios están descritos tal cual; lo que no he medido, está marcado como no medido.