En breve. El dimensionamiento de IA clínica on-premise depende de volumen, modalidad, latencia, concurrencia y alta disponibilidad; la VRAM de la GPU es la restricción que manda. Referencialmente, un piloto de lenguaje clínico parte de 8 vCPU, 32 GB de RAM y 1 GPU de 24 GB; imagenología exige desde una GPU de 48 GB. Las cifras se validan caso a caso.
Cuando una clínica u hospital decide ejecutar inteligencia artificial clínica dentro de su propia red —en lugar de enviar datos a un servicio en la nube pública—, la primera pregunta del equipo de TI suele ser muy concreta: ¿qué servidor y qué GPU necesito? Esta guía ordena los criterios para responderla con fundamento y evitar dos errores caros: comprar de más “por si acaso” o quedarse corto y degradar la experiencia clínica.
Un aviso importante antes de las cifras: todos los números de esta guía son referenciales. Sirven para planificar y presupuestar, pero el dimensionamiento definitivo se valida caso a caso, según el volumen real, los modelos seleccionados, la latencia objetivo y los requisitos de alta disponibilidad de cada institución.
Qué determina realmente el tamaño
El hardware no depende de una sola variable, sino de la combinación de cinco factores:
- Volumen. Cuántos estudios, informes o epicrisis se procesan por día. Es el punto de partida del cálculo.
- Modalidad: texto vs. imagen. No es lo mismo generar borradores de lenguaje clínico (un LLM de texto) que apoyar la lectura de imágenes. Los modelos de visión son considerablemente más exigentes en VRAM y almacenamiento que los de texto.
- Latencia objetivo. El tiempo aceptable por borrador. Una latencia baja y estable exige más capacidad de cómputo por solicitud.
- Concurrencia. Cuántos profesionales trabajan en simultáneo. La concurrencia, más que el volumen diario total, es la que suele obligar a sumar una segunda GPU.
- Alta disponibilidad (HA). Si el servicio no puede tener un punto único de falla, se duplican los recursos del plano crítico. Es una decisión de negocio antes que técnica.
Requisitos referenciales por escenario
La siguiente tabla resume el dimensionamiento de referencia por escenario. Es el mismo criterio que usamos para presupuestar un piloto y que puede revisarse en detalle en la guía de despliegue on-premise.
| Escenario | Carga aprox. | CPU | RAM | GPU (VRAM) | Almacenamiento |
|---|---|---|---|---|---|
| Piloto — lenguaje clínico | hasta ~300 epicrisis/día, baja concurrencia | 8 vCPU | 32 GB | 1× GPU 24 GB (LLM ~7–14B cuantizado) | 200 GB SSD |
| Producción — lenguaje clínico | clínica mediana, concurrencia media | 16 vCPU | 64 GB | 1–2× GPU 48 GB | 1 TB SSD |
| Imagenología (piloto) | volumen acotado por modalidad | 16 vCPU | 64 GB | 1× GPU 48 GB (modelos de visión) | 1 TB+ SSD (estudios) |
| Alta disponibilidad | sin punto único de falla | ×2 nodos | ×2 | ×2 GPU | almacenamiento replicado |
Dos lecturas rápidas de la tabla. Primero: pasar de piloto de texto a producción no solo suma una GPU, también duplica CPU y RAM, porque crece la concurrencia y el trabajo de orquestación. Segundo: la imagenología parte donde termina la producción de texto —16 vCPU, 64 GB de RAM y una GPU de 48 GB— y el procesamiento DICOM tiende a requerir todavía más VRAM y almacenamiento, por lo que siempre se dimensiona por modalidad.
Por qué la GPU (y su VRAM) es la restricción que manda
En la práctica, el cuello de botella de la IA clínica on-premise no es la CPU ni el disco: es la memoria de la GPU (VRAM). Un modelo debe caber completo en VRAM para servirse con buena latencia. Por eso el dimensionamiento se expresa en gigabytes de VRAM antes que en un modelo de tarjeta concreto.
Para lenguaje clínico, un LLM de ~7–14B parámetros cuantizado entra cómodo en una GPU de 24 GB para un piloto. Al escalar a producción con concurrencia media, se sube a GPU de 48 GB —una o dos según carga— para sostener más solicitudes simultáneas sin degradar el tiempo de respuesta. La codificación CIE-10, al ser también procesamiento de texto, comparte este perfil liviano; puedes ver el detalle en codificación CIE-10 y lenguaje clínico.
Para imagenología, los modelos de visión necesitan más memoria, de ahí el piso de 48 GB de VRAM ya en piloto y el mayor almacenamiento para las series DICOM. El desglose está en la página de imagenología y radiología.
Conviene recordar el encuadre del producto: en todos los escenarios MedAI genera borradores que un profesional revisa, edita y firma (arquitectura human-in-the-loop). No hay diagnóstico autónomo ni priorización de casos por criterio clínico, y esa decisión de diseño no cambia el hardware, pero sí explica por qué el dimensionamiento se piensa para asistir a personas, no para reemplazarlas.
Software base
Sobre el hardware, la plataforma de referencia es estándar y conocida por cualquier equipo de infraestructura:
- Sistema operativo Linux con drivers NVIDIA y el NVIDIA Container Toolkit, para exponer la GPU a los contenedores.
- Docker / Compose para un piloto de un nodo, o Kubernetes (vía Helm) para producción y alta disponibilidad.
- Certificados TLS provistos por el cliente en el punto de ingreso, e integración con el IdP corporativo mediante SSO (SAML/OIDC).
- Conectividad interna hacia HIS/EMR (HL7/FHIR) y PACS/RIS (DICOM), sin exponer nada a internet.
Modo air-gapped: qué cambia en el dimensionamiento
MedAI puede operar sin conexión saliente a internet. En ese modo cambian dos cosas del lado de infraestructura. Primero, los pesos de los modelos y las imágenes de contenedor se entregan dentro de un bundle de release firmado (cosign/sigstore), que el equipo del cliente verifica antes de importar; no hay descargas automáticas. Segundo, conviene reservar espacio adicional de almacenamiento para conservar versiones, de modo que siempre exista la posibilidad de revertir (rollback) a una versión anterior conocida ante una regresión. Es una holgura de disco pequeña frente al beneficio operativo de poder volver atrás sin depender de la red.
Cómo aterrizar el dimensionamiento en tu institución
Antes de cotizar hardware, vale la pena tener a mano cuatro respuestas: el volumen diario por modalidad, la concurrencia máxima esperada en hora punta, la latencia que el flujo clínico tolera y si el servicio requiere alta disponibilidad. Con esos datos, la tabla de escenarios deja de ser genérica y se convierte en un presupuesto realista.
Para profundizar en la arquitectura completa —componentes, integración, seguridad y empaquetado— están disponibles el whitepaper de arquitectura de referencia, el one-pager de arquitectura y, para el equipo de seguridad, el dossier de seguridad. El detalle de dimensionamiento por escenario forma parte de la guía de despliegue on-premise.
Cierre
El dimensionamiento de IA clínica on-premise no es un misterio: se reduce a cruzar volumen, modalidad, latencia, concurrencia y alta disponibilidad, y a entender que la VRAM de la GPU es la restricción que gobierna el resto. Las cifras de esta guía te permiten planificar con orden, pero el número final siempre se valida contra la realidad de tu operación. Si quieres cerrar ese cálculo, una revisión técnica para dimensionar un piloto y validar la integración con tu HIS/EMR y PACS/RIS es el siguiente paso natural.
Este artículo es informativo y no constituye asesoría legal ni médica.