Nube privada de GPU: arquitectura, aislamiento y modelo operativo

Nube privada de GPU: arquitectura, aislamiento y modelo operativo

Una nube privada de GPU es una infraestructura de IA dedicada con aprovisionamiento, gobernanza y medición al estilo de la nube. Puede ejecutarse en la región de un proveedor, en un clúster privado alojado, en una jaula de colocation o en su propio centro de datos, pero la pregunta de compra es la misma: ¿necesita capacidad de GPU aislada que su equipo opere como una plataforma, o solo necesita acceso fiable a modelos con controles de coste?

Para los equipos de IA empresariales, la respuesta no debería empezar con una lista de logotipos. Empiece por el límite de la carga de trabajo, el límite de los datos, el límite de la red, el límite del programador y el límite de costes. Vale la pena evaluar una nube privada de GPU cuando los pools de GPU públicos compartidos, los endpoints serverless o las APIs de modelos gestionadas no pueden satisfacer esos límites sin un riesgo inaceptable, latencia, fricción de cumplimiento o incertidumbre en la cola.

Esta guía ofrece una arquitectura práctica y un modelo operativo para las decisiones sobre nube privada de GPU. Cubre las capas de aislamiento que debe inspeccionar, el equipo de plataforma que necesita para operarla, las pruebas de aceptación que debe exigir antes de firmar y dónde encaja Flatkey cuando la gobernanza de modelos/APIs es suficiente sin ser dueño del plano de GPU.

Respuesta rápida sobre la nube privada de GPU

Elija una nube privada de GPU cuando necesite capacidad de GPU reservada, una topología de clúster predecible, redes privadas, límites estrictos entre inquilinos, stacks de serving personalizados, control directo del programador o evidencias para una revisión de seguridad. No elija una nube privada de GPU solo porque "privada" suene más segura. El aislamiento solo importa si el contrato, la red, el almacenamiento, el programador, IAM, la observabilidad y el proceso de incidentes preservan realmente ese límite.

Una propuesta sólida de nube privada de GPU debería responder estas preguntas:

• ¿Qué GPU, nodos, racks y fabrics están dedicados a nosotros?
• ¿Las cargas de trabajo están aisladas por host físico, máquina virtual, espacio de nombres de Kubernetes, partición de Slurm, slice de NVIDIA MIG o una combinación?
• ¿Cómo se mantienen dentro del límite aprobado las imágenes, los pesos de los modelos, los prompts, las salidas, los logs y las métricas?
• ¿Quién se encarga de los parches, las actualizaciones de controladores, la compatibilidad con CUDA, la política del programador, la aplicación de cuotas, las copias de seguridad y la respuesta ante incidentes?
• ¿Cómo se mide el coste: asignación horaria de GPU, capacidad reservada, tokens aceptados, trabajos completados, almacenamiento, salida de datos, soporte o tarifas de servicio gestionado?

Si un proveedor no puede mostrar esos detalles, no está evaluando una nube privada de GPU. Está evaluando un SKU de alquiler de GPU con palabras empresariales alrededor.

Qué puede significar "privada"

La frase nube privada de GPU está sobrecargada. Los equipos de compras suelen comparar varias ofertas distintas bajo la misma palabra clave.

Para los lectores de Flatkey, esa última fila importa. Flatkey ofrece a los equipos una sola clave, un solo saldo, una sola factura, controles de registro de uso, endpoints oficiales de modelos y gobernanza sobre APIs de modelos y herramientas. Eso no sustituye a una nube privada de GPU cuando necesita aislamiento de hardware reservado. Es el camino más sencillo cuando el requisito real es acceso multmodelo, visibilidad de costes, conmutación por error y controles empresariales sin operar infraestructura GPU. Para esa vía de comparación, use la guía complementaria sobre nube de GPU vs API de modelos.

Arquitectura de referencia

Una nube privada de GPU de producción tiene más capas que nodos GPU. Trátela como una plataforma de IA con seis planos de control.

1. Plano de capacidad

El plano de capacidad define el límite físico y contractual:

• Generación de GPU y factor de forma: H100, H200, B200, GB200, L40S, A100 u otros aceleradores.
• Forma del nodo: inferencia de nodo único, nodos de entrenamiento de 8 GPU, pods multinodo, sistemas a escala de rack o formas de VM en la nube.
• Interconexión: NVLink/NVSwitch dentro de los nodos, InfiniBand, RoCE, EFA, GPUDirect RDMA o redes de IA específicas del proveedor.
• Modelo de reserva: bajo demanda, comprometido, reservado, clúster dedicado, bloque de capacidad o nube privada alojada.
• Derechos de reemplazo: qué sucede cuando falla una GPU, NIC, disco, rack o zona.

No normalice las ofertas de nube privada de GPU solo por el precio horario de la GPU. Normalícelas por la topología utilizable. Un pool más barato que no puede colocar ocho GPU con la interconexión de red requerida puede costar más por trabajo completado que un bloque privado de mayor precio. Si la conversación todavía está al nivel de la tarifa, primero normalice las entradas con una hoja de cálculo de precios de alquiler de GPU.

2. Plano de red

El plano de red decide si el clúster es realmente accesible y está aislado de la forma en que su equipo de seguridad espera.

Preguntas mínimas de diseño:

• ¿El clúster está dentro de su VPC, una VPC del proveedor, una VLAN privada, un segmento de conexión directa o una cuenta de servicio administrada?
• ¿Las API de control están expuestas públicamente, de forma privada o a través de un bastión/proxy de identidad?
• ¿El tráfico este-oeste entre nodos GPU está aislado de otros inquilinos?
• ¿Los endpoints de servicio de modelos son privados por defecto?
• ¿Pueden los datos de entrenamiento, checkpoints, imágenes de contenedor, pesos del modelo y registros moverse sin rutas de Internet público?
• ¿Existen controles de salida explícitos, políticas de NAT, políticas de DNS y reglas de firewall?

Para entrenamiento a gran escala e inferencia de alto rendimiento, los detalles de red no son solo detalles de seguridad. Cambian el rendimiento, la tasa de reintentos, el tiempo de checkpoint y el comportamiento de fallo del trabajo.

3. Plano de planificador

El plano de planificador decide quién puede usar las GPU y cuándo.

Opciones comunes:

• Kubernetes con complementos de dispositivo, GPU Operator, pools de nodos, namespaces, cuotas, taints, tolerations y políticas de admisión.
• Slurm con particiones, cuentas, reglas de calidad de servicio, programación de reparto justo, preempción y matrices de trabajos.
• Un plano de control de inferencia administrado para escalado de endpoints, colas, batching, autoscaling y despliegues canary.
• Un modelo híbrido donde Slurm se encarga del entrenamiento mientras Kubernetes se encarga del servicio.

Una nube privada de GPU sin política de planificador se convierte rápidamente en una hoja de cálculo compartida. Defina reglas de cuota, clases de prioridad, límites de cola, reglas de preempción, apagado por inactividad, ventanas de reserva y acceso de emergencia break-glass antes de que migre el primer equipo.

4. Plano de ejecución

El plano de ejecución es donde la mayoría de las afirmaciones de "la GPU está disponible" fallan en la práctica.

Necesita una propiedad clara para:

• Versión del controlador NVIDIA, CUDA, cuDNN, NCCL y del runtime de contenedores.
• GPU Operator o herramientas equivalentes de ciclo de vida.
• vLLM, SGLang, TensorRT-LLM, Triton, Ray Serve o marcos de servicio personalizados.
• Acceso al registro de contenedores y análisis de imágenes.
• Distribución de pesos del modelo y verificación de checksum.
• Ajuste del kernel, huge pages, política NUMA, configuraciones de GPUDirect y pruebas de topología NCCL.
• Planes de reversión para actualizaciones del controlador y del framework de servicio.

Para los equipos de inferencia, una nube privada de GPU útil debe exponer una capa de API compatible con OpenAI o un contrato de servicio interno. De lo contrario, cada equipo de producto tiene que volver a aprender batching, streaming, compatibilidad con llamadas a herramientas, reintentos y contabilidad de solicitudes. Los detalles de implementación se cubren en la guía de implementación de vLLM y en la comparación vLLM vs SGLang.

5. Plano de datos

El plano de datos incluye todo lo que los usuarios olvidan durante la adquisición de GPU:

• Conjuntos de datos de entrenamiento y stores de características.
• Almacenamiento de objetos, sistemas de archivos compartidos y NVMe local.
• Almacenamiento de checkpoints y retención de snapshots.
• Registro de modelos y promoción de artefactos.
• Retención de prompts, salidas, telemetría y trazas.
• Copia de seguridad, restauración y retención legal.
• Replicación entre regiones o entre zonas.

Las GPU privadas no hacen que los datos sean privados automáticamente. Sus controles deben cubrir dónde se escriben las entradas del modelo, las salidas del modelo, los embeddings, los registros, las métricas, las trazas, los checkpoints y las solicitudes fallidas.

6. Plano de gobernanza y FinOps

Una nube privada de GPU todavía necesita controles al estilo cloud:

• Roles IAM y acceso con privilegio mínimo.
• Cuotas y presupuestos por equipo.
• Etiquetas o labels de asignación de costes.
• Horas de GPU, memoria asignada, tokens aceptados, trabajos completados, espera en cola y capacidad ociosa.
• Chargeback o showback.
• Registros de auditoría de seguridad.
• Reglas de aprobación para la exposición de endpoints públicos.
• Evidencia de SLA, incidentes y escalamiento de soporte.

Si no puede atribuir el gasto de GPU a equipos, entornos, proyectos y resultados aceptados, la nube privada de GPU parecerá más barata en la cotización y más cara al cierre del trimestre.

Modelo de aislamiento: pida evidencia, no adjetivos

El aislamiento de una nube privada de GPU debe describirse en cuatro niveles.

Aislamiento físico

El aislamiento físico significa que los hosts, racks, pods o clústeres son dedicados. Es el más sólido para cargas de trabajo reguladas y para un rendimiento predecible, pero debe reflejarse en el contrato y en el proceso operativo. Pregunte si los hosts fallidos se reemplazan con hosts igualmente dedicados, si los ingenieros de soporte pueden acceder al entorno y cómo se auditan las manos remotas.

Aislamiento de virtualización

Las máquinas virtuales pueden proporcionar sólidos límites operativos, pero debe confirmar la ubicación en el host, el modo de passthrough de GPU o vGPU, la conexión de almacenamiento, la tenencia de red y los eventos de mantenimiento. Para los proveedores que ofrecen reservas de capacidad o hosts dedicados, pregunte cómo se asignan sus GPU a los hosts y cómo se demuestra la ubicación durante las auditorías.

Aislamiento de partición de GPU

NVIDIA Multi-Instance GPU (MIG) puede particionar las GPU compatibles en instancias de GPU separadas. MIG puede ser útil para la densidad de inferencia y los controles de tenencia, pero no es un sustituto universal de la dedicación de host completo o GPU completa. Verifique qué modelos de GPU admiten MIG, qué perfiles están permitidos, cómo se asignan los slices y cómo la supervisión distingue a los inquilinos.

Aislamiento de orquestación

Los namespaces de Kubernetes, las políticas de red, las cuentas de servicio, los controles de admisión y las cuotas ayudan a separar equipos. Las cuentas y particiones de Slurm ayudan a separar usuarios de lotes. Estos son necesarios para las operaciones de la plataforma, pero por sí solos no garantizan el aislamiento físico. La arquitectura debe indicar exactamente dónde termina el aislamiento de orquestación y dónde comienza el aislamiento a nivel de host.

Modelo operativo: ¿quién ejecuta qué?

Una nube privada de GPU no es solo una compra. Es un modelo operativo. Antes de firmar, defina la responsabilidad en una tabla RACI.

Si su equipo no puede dotarse de personal para ingeniería de plataforma, operaciones de seguridad, FinOps y soporte de aplicaciones, una nube privada de GPU puede convertirse en un activo ocioso. En ese caso, compárela con APIs de modelos gestionadas, inferencia sin servidor y opciones de nube de GPU antes de comprometerse. Para capacidad multi-nodo específicamente, utilice la lista de verificación de alquiler de clúster de GPU antes de negociar un bloque privado.

Categorías de proveedores para comparar

Las principales plataformas de nube privada de GPU para IA empresarial suelen encajar en cinco categorías:

1. Bloques de GPU de hyperscaler: AWS, Google Cloud, Azure y capacidad de VM o clúster de GPU estilo Oracle con redes privadas, IAM, opciones de capacidad reservada y adquisición empresarial.
2. Nubes de GPU especializadas: CoreWeave, Lambda, Crusoe, Nebius, Voltage Park y proveedores similares centrados en capacidad de IA, fabrics de alta velocidad y operaciones de clúster.
3. Nubes de GPU para desarrolladores y marketplaces: RunPod, Vast.ai, TensorDock y opciones similares para capacidad flexible, prototipos y descubrimiento de precios.
4. Stacks de IA privadas alojadas: HPE Private Cloud AI con NVIDIA y otras ofertas de nube privada tipo appliance para empresas que quieren hardware, software y soporte integrados.
5. Capa de gobernanza de modelos/API: Flatkey y routers relacionados cuando la necesidad es acceso oficial a modelos, controles de coste, auditabilidad y failover en lugar de propiedad del hardware.

Si está comparando específicamente los servicios de nube privada de GPU de Vultr, separe el requisito en disponibilidad de VM de GPU, necesidades de bare metal o host dedicado, aislamiento de VPC/red, capacidad comprometida, términos de soporte y evidencias de cumplimiento. La página de Cloud GPU de un proveedor puede ser un buen punto de partida, pero la respuesta final suele estar en la cotización, el diagrama de arquitectura y el contrato de soporte.

Campos de TCO que los compradores pasan por alto

Construya el modelo de TCO de la nube privada de GPU en torno al trabajo completado, no al precio de lista.

Use esta hoja de cálculo:

Luego compáralo con tres alternativas:

• Alquiler de GPU en la nube pública para trabajos con picos.
• Inferencia serverless o gestionada para una demanda de producción irregular.
• Enrutamiento de modelos/API para equipos que quieren gobernanza, endpoints oficiales, registros de uso y una sola factura sin operar GPUs.

Aquí es donde Flatkey resulta útil en la evaluación. Si el modelo de TCO muestra que la nube privada de GPU se justifica principalmente por el acceso a múltiples modelos, la consolidación de facturas, la auditabilidad o el control del costo por token, evalúa Flatkey antes de comprometerte con hardware. Si el modelo muestra que el requisito es hardware dedicado, kernels personalizados, residencia de datos o entrenamiento específico de la topología, mantén viva la opción de nube privada de GPU. Para la revisión financiera, combina esto con el modelo de TCO de clústeres GPU y el marco más amplio de comparación de precios de API de IA.

Pruebas de aceptación antes de firmar

No aceptes una presentación como prueba. Ejecuta pruebas de aceptación en la topología exacta o en un entorno contractualmente equivalente.

Pruebas de seguridad y aislamiento

• Confirma el acceso al endpoint privado desde tu red.
• Verifica que no se requiera un plano de control público ni un endpoint de servicio de modelos público.
• Comprueba la separación de IAM entre administradores de plataforma, equipos de modelos, lectores de seguridad y lectores de finanzas.
• Confirma que el registro de contenedores, el almacenamiento de objetos, el almacenamiento de checkpoints y los registros permanezcan dentro del perímetro aprobado.
• Revisa los eventos de auditoría para inicio de sesión, extracción de imágenes, envío de trabajos, despliegue de endpoints, lectura de secretos, salida de datos y escalada de privilegios de administrador.

Pruebas de rendimiento

• Ejecuta pruebas NCCL all-reduce y pruebas de topología para entrenamiento multinodo.
• Reproduce tráfico representativo de inferencia a través de la pila de servicio elegida.
• Mide la latencia p50, p95 y p99 bajo carga estable y en picos.
• Mide tokens por segundo por GPU, tokens aceptados por dólar y consumo por solicitudes fallidas.
• Prueba el tiempo de carga del modelo, el tiempo de escritura del checkpoint, el tiempo de reversión y el comportamiento de drenaje del nodo.

Pruebas operativas

• Simula una GPU fallida, un nodo fallido, un montaje de almacenamiento fallido, un componente del plano de control fallido y un despliegue de servicio de modelos fallido.
• Prueba la actualización y reversión de drivers en un pool de nodos no productivo.
• Confirma quién responde a las 3 a. m. y a qué información puede acceder.
• Valida los campos de exportación de uso para finanzas y auditoría.
• Confirma qué ocurre cuando la demanda supera la capacidad reservada.

Pruebas contractuales

• Mapea cada promesa arquitectónica a una cláusula contractual o documento de soporte.
• Define fechas de entrega de capacidad, SLA de reemplazo, aviso de mantenimiento, eliminación de datos, notificación de incidentes y cooperación en auditorías.
• Confirma si "privado" cubre solo cómputo, o también almacenamiento, registros, métricas, acceso de soporte y copias de seguridad.

Patrón de arquitectura interna

Una nube privada de GPU práctica para IA empresarial suele usar este patrón:

1. Perímetro de red privada con conexión directa o VPN.
2. Pools dedicados de nodos GPU divididos por tipo de carga: entrenamiento, inferencia por lotes, inferencia en línea, evaluación y experimentos.
3. Kubernetes para servicios y Slurm para grandes lotes/entrenamiento cuando sea necesario.
4. Registro de modelos y ruta de promoción de artefactos desde experimento a staging y producción.
5. vLLM, SGLang, TensorRT-LLM, Triton o Ray Serve detrás de una pasarela interna.
6. Cuotas por equipo, políticas de admisión y etiquetas de costo.
7. Observabilidad para utilización de GPU, memoria, espera en cola, latencia, trabajos fallidos, salidas aceptadas y gasto.
8. Fallback externo de modelo/API a través de un router gobernado para desbordamiento, modelos no compatibles o comparación de costos.

El punto final no es un atajo. Es un patrón de resiliencia. Incluso los equipos con una nube privada de GPU suelen mantener un router de modelo/API para desbordamiento, comparación de modelos, fallback de proveedor y casos de uso en los que comprar la GPU no es racional.

Matriz de decisión

Lista de verificación de adquisición de nube privada de GPU

Use esta lista de verificación antes de seleccionar proveedores:

• Defina las cargas de trabajo: entrenamiento, ajuste fino, inferencia por lotes, inferencia en línea, evaluación, embeddings, generación de medios o notebooks.
• Defina el aislamiento: físico, virtual, partición de GPU, planificador, red, almacenamiento y acceso de soporte.
• Defina la topología: modelo de GPU, GPUs por nodo, nodos por clúster, fabric, almacenamiento y región.
• Defina el runtime: CUDA, controladores, NCCL, Kubernetes, Slurm, vLLM, SGLang, TensorRT-LLM, Triton, Ray y observabilidad.
• Defina los controles de datos: pesos de modelos, prompts, resultados, registros, trazas, checkpoints, copias de seguridad, eliminación y retención legal.
• Defina la unidad de coste: hora de GPU, trabajo completado, salida aceptada, token aceptado, hora de endpoint, almacenamiento, egress, soporte y mano de obra de plataforma.
• Defina las pruebas de aceptación: seguridad, red, planificador, rendimiento, conmutación por error, exportación de uso y respuesta a incidentes.
• Defina el plan alternativo: desbordamiento a nube pública de GPU, APIs de modelos o rutas gobernadas por Flatkey.

Fuentes oficiales que consultar

Use fuentes oficiales para las partes volátiles de una evaluación de nube privada de GPU:

• La Guía de usuario de NVIDIA MIG para particionamiento de GPU y compatibilidad de perfiles: documentación de NVIDIA MIG.
• La documentación de NVIDIA GPU Operator y del complemento de dispositivo de Kubernetes para el ciclo de vida y la programación de GPU en Kubernetes: GPU Operator y NVIDIA k8s-device-plugin.
• La documentación del complemento de dispositivo de Kubernetes para el modelo de integración del planificador: complementos de dispositivo de Kubernetes.
• La documentación de instancias GPU de AWS EC2 y de capacidad: instancias Amazon EC2 P5 y EC2 Capacity Blocks for ML.
• La documentación de Google Cloud sobre máquinas optimizadas para aceleradores y AI Hypercomputer: máquinas optimizadas para aceleradores de Google Cloud y AI Hypercomputer.
• La documentación de las VM GPU de la serie ND de Microsoft Azure: Azure ND H100 v5-series.
• Las páginas de proveedores para capacidad especializada de nube GPU, como Lambda Private Cloud, CoreWeave y Vultr Cloud GPU.
• HPE Private Cloud AI para evaluación de una pila integrada de IA privada: HPE Private Cloud AI.
• FOCUS de FinOps para vocabulario de asignación de costes y estructura de informes: FOCUS by the FinOps Foundation.
• Páginas de producto de Flatkey para la alternativa de gobernanza de modelos/API: Flatkey, Flatkey Compute y precios de Flatkey.

Preguntas frecuentes

¿Qué es una nube privada de GPU?

Una nube privada de GPU es una infraestructura de GPU dedicada o fuertemente aislada que se entrega con aprovisionamiento, red, seguridad, medición y soporte al estilo cloud. Puede estar alojada por un proveedor, desplegada en colocation o ejecutarse on-premises. El punto importante no es la ubicación. El punto importante es el aislamiento y el modelo operativo.

¿Es lo mismo una nube privada de GPU que el alquiler de GPU bare metal?

No. El alquiler de GPU bare metal puede ser uno de los componentes de un diseño de nube privada de GPU, pero una nube privada de GPU también debe definir el aislamiento de red, los límites de almacenamiento, la política del planificador, los controles de acceso, la observabilidad, la asignación de costes, el soporte y la respuesta a incidentes.

¿Cuándo es mejor una nube privada de GPU como servicio que las APIs de modelos?

La nube privada de GPU como servicio es mejor cuando necesita hardware dedicado, control personalizado del entorno de ejecución, rutas de red privadas, entrenamiento específico de topología, gestión de datos regulados o capacidad reservada predecible. Las API de modelos suelen ser mejores cuando necesita muchos modelos de frontera, integración rápida, respaldo, controles de libro mayor y una menor carga de infraestructura.

¿Cómo deberían comparar los equipos de IA empresarial las principales plataformas privadas de nube GPU?

Compare según la adecuación a la carga de trabajo, la evidencia de aislamiento, la topología, la propiedad del programador, el límite de datos, la observabilidad, el modelo de soporte, la exportación de costes y los resultados de las pruebas de aceptación. No clasifique las principales plataformas privadas de nube GPU para IA empresarial solo por el precio por hora de la GPU.

¿Qué debería preguntar sobre los servicios de nube privada de GPU de Vultr?

Pregunte si su requisito se ajusta a VMs Cloud GPU, bare metal, VPC/redes privadas, capacidad comprometida, tiempo de respuesta del soporte, evidencia de cumplimiento, límite de almacenamiento y operaciones de servicio de modelos. También pida acceso a benchmarks antes de tratar la oferta como una nube privada de GPU.

¿Dónde encaja Flatkey si ya tenemos una nube privada de GPU?

Flatkey puede situarse junto a una nube privada de GPU como la ruta gobernada de modelos/API para modelos externos, desbordamiento, respaldo, comparación de costes y equipos que no necesitan control a nivel de hardware. Proporciona una sola clave, un solo saldo, una sola factura y controles de libro mayor de uso en todas las APIs oficiales de modelos y herramientas.

Conclusión

Una nube privada de GPU es un compromiso de plataforma, no un atajo de adquisiciones. Es la respuesta correcta cuando los equipos de IA empresarial necesitan capacidad dedicada, control de topología, rutas privadas de datos y evidencia operativa. Es la respuesta incorrecta cuando la necesidad real es simplemente un acceso más fácil a muchos modelos, una factura más limpia y una mejor gobernanza de costes de API.

Primero use la lista de verificación de arquitectura de nube privada de GPU. Luego evalúe la topología exacta. Después compare el TCO frente al alquiler de GPU, la inferencia gestionada y las rutas de modelos/API gobernadas por Flatkey. La mejor decisión es la que proporciona a sus equipos de IA el límite que realmente necesitan sin obligarlos a operar infraestructura que no necesitan. Si la elección del hardware todavía no está resuelta, empiece con mejor GPU para inferencia de LLM antes de pedir a los proveedores un presupuesto privado.