GPU Nvidia H200: arquitectura, rendimiento y guía de despliegue en la nube
La GPU Nvidia H200 es un acelerador de generación Hopper diseñado para cargas de trabajo de IA y HPC en las que la capacidad de memoria, el ancho de banda de memoria y la topología multi-GPU afectan significativamente al resultado. NVIDIA documenta 141 GB de memoria HBM3e y 4,8 TB/s de ancho de banda de memoria por H200. Estos son puntos de partida importantes, pero por sí solos no indican si un despliegue de H200 cumplirá un objetivo de latencia, alojará un modelo más la caché KV o escalará eficientemente en un nodo de nube. Las especificaciones de H200 de NVIDIA son la referencia de hardware; esta guía las convierte en un proceso de despliegue.
Para los desarrolladores de IA y los equipos de infraestructura de ML, la decisión práctica suele ser esta: ¿pueden un modelo, su contexto activo máximo y la sobrecarga de tiempo de ejecución caber con suficiente margen en una GPU? Si no es así, ¿puede la carga de trabajo permanecer dentro de un nodo H200 de alto ancho de banda antes de tener que cruzar la red? La respuesta debe determinar el factor de forma, el plan de paralelismo y las pruebas de aceptación, no un titular sobre TFLOPS máximos.
Esta es una guía de arquitectura y despliegue, no una lista de precios. Si está comparando presupuestos o tarifas horarias en la nube, comience con nuestra guía de precios de la GPU H200. Si la decisión es específicamente H200 frente a H100, consulte la comparación entre H200 y H100.
La respuesta rápida: cuándo una GPU Nvidia H200 es una buena opción
Elija una GPU Nvidia H200 cuando se cumplan todas o la mayoría de las siguientes condiciones:
- Su carga de trabajo está limitada por la memoria del modelo, el crecimiento de la caché KV o el ancho de banda de memoria, y no solo por el rendimiento aritmético.
- Necesita más espacio para inferencia de contexto largo o solicitudes simultáneas sin dividir inmediatamente el modelo entre nodos.
- Puede validar la topología real de la nube —factor de forma SXM o PCIe/NVL, número de GPU por nodo e interconexión disponible— en lugar de tratar «H200» como una especificación de despliegue completa.
- Está preparado para medir el tiempo hasta el primer token, el rendimiento de tokens de salida, la latencia de cola, la memoria de GPU y las colas con la misma forma de solicitud que espera en producción.
- Necesita suficiente control sobre el software de serving, los pesos del modelo, el batching o la localidad de los datos como para justificar operar directamente la capacidad de GPU.
Una H200 no es automáticamente la mejor opción para todas las aplicaciones de IA generativa. Si un acelerador más pequeño aloja cómodamente el modelo y su contexto activo, o si su producto necesita alternar entre muchos modelos alojados sin mantener operaciones de GPU, una API de modelos gestionada puede ser la base operativa más sencilla. La comparación importante es el coste y la fiabilidad de la carga de trabajo completada con su propio perfil de tráfico, no una cifra bruta de hardware.
Arquitectura de la GPU Nvidia H200: las especificaciones que cambian las decisiones de despliegue
La H200 utiliza la arquitectura Hopper de NVIDIA. Hopper incluye el Transformer Engine y NVLink de cuarta generación; NVIDIA posiciona estas características para el trabajo con transformadores de precisión mixta y la comunicación multi-GPU. Su descripción general de la arquitectura Hopper también explica por qué la topología del servidor importa cuando las cargas de trabajo se extienden más allá de un acelerador.
| Atributo relevante para el despliegue | Especificación de referencia de H200 | Qué validar en un despliegue en la nube |
|---|---|---|
| Arquitectura | NVIDIA Hopper | Su matriz de compatibilidad de CUDA, framework, controlador y contenedor |
| Memoria de GPU | 141 GB de HBM3e por GPU | Pesos del modelo, caché KV activa máxima, espacios de trabajo de tiempo de ejecución, margen de fragmentación y cualquier servicio colocado conjuntamente |
| Ancho de banda de memoria | 4,8 TB/s por GPU | Comportamiento de prefill/decode con su combinación de longitud de entrada, longitud de salida y concurrencia |
| Factores de forma | H200 SXM y H200 NVL | El factor de forma exacto del acelerador ofrecido por el proveedor, no solo el nombre de la familia de instancias |
| Conectividad dentro del nodo | NVIDIA documenta 900 GB/s de NVLink para H200 SXM; H200 NVL tiene opciones de puente NVLink de 2 o 4 vías | nvidia-smi topo -m, conectividad entre pares y ancho de banda GPU a GPU medido |
| Opción de múltiples instancias | Hasta siete instancias MIG, con tamaños de partición que varían según el factor de forma | Si el aislamiento beneficia a su combinación de servicios más que un plan de serving con GPU completa |
| Envolvente térmica | Hasta 700 W configurables para SXM; hasta 600 W configurables para NVL | La política de potencia y refrigeración del proveedor, porque afecta a los factores de forma disponibles |
Fuente: especificaciones de NVIDIA H200. NVIDIA señala que algunas cifras de rendimiento publicadas usan dispersión; utilice esas cifras como referencia de capacidad, no como una promesa de rendimiento en producción.
La capacidad de memoria es una variable de despliegue, no un número de marketing
Para servir LLM, planifique la HBM en torno al conjunto de trabajo completo:
memoria de GPU requerida ≈ pesos del modelo
+ caché KV activa máxima
+ espacios de trabajo de tiempo de ejecución
+ margen de fragmentación y seguridad
El punto de control del modelo es solo el primer término. Una configuración que se carga correctamente puede seguir teniendo demasiado poco margen para la ventana de contexto activa y las secuencias simultáneas que pretende atender. Por eso los 141 GB de HBM3e de la H200 pueden ser útiles incluso cuando un modelo cabe técnicamente en una configuración de la clase H100: ofrece al despliegue más margen para equilibrar el tamaño de lote, la longitud de contexto y la concurrencia frente a la latencia.
Antes de reservar capacidad, anote estas entradas de carga de trabajo:
- Modelo, formato de pesos y cualquier modo de cuantización o precisión.
- Máximo de tokens de entrada y máximo de tokens generados para una solicitud real.
- Secuencias activas simultáneas esperadas, no solo solicitudes por segundo.
- SLO de latencia, incluido el tiempo hasta el primer token y la latencia de cola.
- Si la aplicación necesita una GPU completa única, una partición aislada o una réplica de modelo multi-GPU.
Realice el primer ejercicio de dimensionamiento con prompts deliberadamente difíciles. Una prueba con un prompt corto que parece saludable puede ocultar la presión sobre la caché KV que aparece con longitudes de contexto de producción.
El ancho de banda y la topología son comprobaciones independientes
El ancho de banda de memoria puede importar al menos tanto como el cómputo para la decodificación autorregresiva y las cargas de trabajo con uso intensivo de memoria. El ancho de banda entre GPU importa una vez que el modelo se fragmenta. No suponga que ocho GPU H200 tienen un único grupo de memoria compartida de 1.128 GB: el software de servicio distribuido debe ubicar los tensores e intercambiar activaciones a través de los enlaces reales disponibles.
NVIDIA describe NVLink de cuarta generación como capaz de proporcionar 900 GB/s de ancho de banda bidireccional por GPU en sistemas DGX y HGX, mientras que NVSwitch admite el dominio de ocho GPU. Por eso una topología de un nodo merece una evaluación independiente de un clúster multinodo. La referencia de arquitectura Hopper de NVIDIA es la fuente de referencia para la capacidad de interconexión; la documentación de instancias del proveedor de nube es la fuente para la topología que realmente recibe.
H200 SXM frente a H200 NVL: seleccione la forma de despliegue antes de seleccionar la instancia
«H200» no identifica un único diseño de servidor. Dos formas de despliegue comunes tienen distintas implicaciones operativas.
| Opción | Para qué está optimizada | Qué preguntar al proveedor | Implicación típica de despliegue |
|---|---|---|---|
| H200 SXM en un nodo de estilo HGX | Sistemas densos de 4 u 8 GPU con conectividad NVLink/NVSwitch de alto ancho de banda | Número de GPU, topología NVLink/NVSwitch, CPU/RAM del host, red, almacenamiento local y aislamiento de inquilinos | Opción predeterminada sólida para un modelo que necesita varias GPU, pero puede permanecer dentro de un nodo |
| H200 NVL en un sistema MGX o certificado | Despliegues PCIe, de doble ranura y refrigerados por aire con opciones documentadas de puente NVLink de 2 o 4 vías | Topología de puentes, número de GPU con acceso entre pares, disposición PCIe y si la VM en la nube expone la topología esperada | Útil cuando el diseño del nodo y el modelo de tenencia coinciden con su carga de trabajo; no infiera un comportamiento similar al de SXM a partir del nombre H200 |
Ambos factores de forma incluyen 141 GB de HBM3e y 4,8 TB/s de ancho de banda de memoria en la tabla de especificaciones de NVIDIA. Para una carga de trabajo multi-GPU, el factor diferenciador suele ser la topología del servidor y los enlaces que rodean esa memoria. Considere el diagrama de topología del proveedor y una comprobación de topología dentro de la instancia como elementos obligatorios para la adquisición.
Una matriz de decisión de carga de trabajo a topología
Utilice esta matriz para decidir el primer experimento de despliegue. Es una hipótesis inicial, no un sustituto de un benchmark.
| Señal de carga de trabajo | Primera configuración H200 que probar | Por qué | Evidencia de aceptación |
|---|---|---|---|
| Un modelo y la caché máxima caben con margen en una GPU | Una GPU H200, una réplica | Simplifica el servicio, aísla los fallos y evita la comunicación por fragmentación | La memoria permanece por debajo del límite de protección configurado durante una prueba de carga de contexto largo; se cumple el SLO de latencia |
| Un modelo necesita varias GPU, pero cabe dentro de un servidor de 8 GPU | Un nodo H200 con paralelismo de tensor | Mantiene dentro del nodo la comunicación frecuente del modelo | La topología muestra las rutas entre pares esperadas; el ancho de banda colectivo y el rendimiento de extremo a extremo escalan de forma aceptable |
| El modelo o la concurrencia objetivo supera un nodo | Clúster multinodo con una red documentada | Añade capacidad agregada, pero convierte la red y el comportamiento colectivo en parte del diseño de servicio | Los colectivos entre nodos, el comportamiento de recuperación y la latencia de cola cumplen el plan de pruebas de producción |
| Muchas cargas de trabajo más pequeñas y aisladas | Evalúe MIG solo después de validar la memoria de la partición y la compatibilidad de software | Puede mejorar el aislamiento o la utilización, pero no hace que un modelo grande quepa | Se comprenden la memoria por partición, la planificación, la atribución de telemetría y el radio de impacto |
| Tráfico en ráfagas con poca necesidad de control del hardware | Compare una línea de base de API de modelo gestionada | Evita comprometerse con capacidad de bajo nivel antes de que la ventaja de control sea clara | El coste, la latencia, la fiabilidad y la flexibilidad del modelo se comparan con la misma forma de carga de trabajo |
Para la inferencia distribuida, la documentación de vLLM plantea la misma progresión básica: use una GPU cuando el modelo quepa, use paralelismo de tensor cuando quepa en un nodo y añada paralelismo de canalización cuando deba abarcar varios nodos. Las marcas exactas y las estrategias compatibles dependen de la versión de vLLM y de la arquitectura del modelo, así que valide con respecto a la versión instalada. Consulte la documentación de inferencia distribuida de vLLM.
Guía de despliegue en la nube para cargas de trabajo con GPU Nvidia H200
El despliegue más seguro se realiza por etapas. Cada etapa responde a una pregunta antes de añadir otra fuente de variabilidad.
1. Redacte un contrato de carga de trabajo
Defina el tráfico de prueba antes del aprovisionamiento. Incluya la versión del modelo, la precisión, las distribuciones de tokens de entrada y salida, la concurrencia, los objetivos de nivel de servicio, la ubicación geográfica, los requisitos de datos y una referencia de costes. Mantenga un conjunto de regresión pequeño y fijo, además de un conjunto de reproducción realista.
Esto evita un error común: comparar hardware en una prueba sintética de rendimiento y descubrir después que la configuración elegida falla con los prompts largos o las condiciones de latencia de cola que importan para la aplicación.
2. Verifique el nodo antes de desplegar el servidor de modelos
Después de que se inicie la instancia, identifique la disposición física en lugar de confiar en su nombre de producto:
nvidia-smi topo -m
nvidia-smi topo -p2p n
NVIDIA recomienda estas comprobaciones al diagnosticar la topología y el comportamiento de NVLink. Su guía de rendimiento y ajuste de NCCL también indica nvbandwidth o nvloom para comprobar si el ancho de banda medido de GPU a GPU coincide con la ruta de hardware esperada.
Registre la salida de la topología en el manual operativo de despliegue. Esto permite auditar una regresión de rendimiento posterior: puede distinguir un cambio en la aplicación de una ubicación diferente de PCIe, NVLink o red.
3. Instale una pila de software de GPU compatible
Para Kubernetes, el clúster necesita el controlador de NVIDIA, una ruta de tiempo de ejecución de contenedores y un complemento de dispositivo del proveedor antes de que las cargas de trabajo puedan solicitar una GPU. Kubernetes expone las GPU como recursos personalizados programables después de instalar el complemento de dispositivo. La guía de programación de GPU de Kubernetes explica el modelo de recursos y el uso de etiquetas o afinidad para flotas mixtas de aceleradores.
GPU Operator de NVIDIA puede gestionar el controlador, NVIDIA Container Toolkit, el complemento de dispositivo, DCGM Exporter y MIG Manager como una pila coordinada en nodos de trabajo con GPU. Use la documentación de instalación de GPU Operator actual y confirme que sus pods de validación y del operador estén en buen estado antes de introducir un servidor de modelos.
Una solicitud mínima de recursos es conceptualmente sencilla:
resources:
limits:
nvidia.com/gpu: 4
En Kubernetes, las GPU normalmente se especifican en limits; si también especifica una solicitud de GPU, debe ser igual al límite. Añada etiquetas de nodo, afinidad, taints y etiquetas de clase de carga de trabajo para que un servicio H200 sensible a la latencia no se programe en un grupo de aceleradores no previsto.
4. Comience con una prueba de servicio de una variable
Inicie una réplica de modelo con la topología más pequeña que pueda alojar la carga de trabajo. Para un despliegue de vLLM de varias GPU en un único nodo, el tamaño de paralelismo de tensor debe coincidir con el número de GPU asignadas a la réplica. Por ejemplo:
vllm serve <model-identifier> \
--tensor-parallel-size 4
Esto es intencionadamente un ejemplo de topología, no un comando de producción para copiar y ejecutar. Fije la imagen de contenedor, la compatibilidad del controlador/CUDA, la revisión del modelo, el tokenizador y la versión del motor de servicio en su propio manifiesto de despliegue. Después, cambie una variable a la vez: el tamaño del paralelismo de tensor, las secuencias activas máximas, la política de asignación de caché o el número de réplicas.
5. Pruebe prefill y decode por separado
El rendimiento de tokens puede ocultar la ruta de latencia que experimenta el usuario. Mida al menos:
- Tiempo hasta el primer token para prompts de entrada cortos y largos.
- Rendimiento de tokens de salida después del primer token.
- Latencia de extremo a extremo P50, P95 y P99.
- Memoria de GPU utilizada, presión de caché y eventos de falta de memoria.
- Tiempo en cola, cancelaciones de solicitudes, reintentos y tasa de errores.
La GPU Nvidia H200 puede mejorar un despliegue limitado porque su memoria más grande y rápida crea más margen de programación, pero solo la mezcla de solicitudes medida puede mostrar si ese margen se convierte en capacidad útil de cara al usuario.
6. Añada réplicas antes que nodos cuando sea posible
Si un nodo H200 aloja el modelo y cumple los objetivos de latencia, añadir réplicas puede ser operativamente más sencillo que introducir un segundo nodo. Una vez que abarque varios nodos, pruebe primero la red y la ruta colectiva. Para la inferencia multinodo, mantenga coherentes el entorno y los artefactos del modelo entre nodos; una discrepancia en el contenedor, el controlador, la revisión del modelo o el tokenizador puede parecer un problema de hardware.
No fuerce la configuración del algoritmo NCCL antes de recopilar una referencia de topología. La documentación de NCCL de NVIDIA indica que la selección predeterminada tiene en cuenta la topología; la configuración manual responde a un comportamiento medido, no sustituye la medición.
7. Monitorice la capacidad antes de que el tráfico esté en riesgo
DCGM Exporter puede exponer la telemetría de las GPU a una pila de monitorización de Kubernetes. NVIDIA lo documenta como parte de la pila gestionada por GPU Operator y proporciona instrucciones de instalación para entornos de Prometheus en su documentación de DCGM Exporter.
Construya paneles que conecten la salud de la infraestructura con los resultados del servicio:
| Señal | Por qué es importante | Pregunta de alerta |
|---|---|---|
| Memoria y utilización de la GPU | Revela si el margen de capacidad se está convirtiendo en trabajo útil o en presión de caché | ¿Las cargas de trabajo con contexto largo se están acercando al límite de seguridad de memoria? |
| Temperatura de la GPU y comportamiento de potencia | Ayuda a aislar la inestabilidad a nivel de host o proveedor | ¿La limitación de rendimiento coincide con regresiones de latencia o rendimiento? |
| Tiempo hasta el primer token y latencia de cola | Captura mejor la experiencia de la aplicación que una puntuación de rendimiento máximo | ¿Las colas, la presión de caché o un cambio de topología perjudicaron el SLO? |
| Profundidad de cola y secuencias activas | Muestra si la capacidad es un problema de réplicas o de configuración por réplica | ¿Necesitamos otra réplica, un control de admisión más restrictivo o una política de lotes diferente? |
| Coste de la carga de trabajo completada | Mantiene la elección del hardware vinculada al resultado de negocio | ¿El compromiso de capacidad se justifica por las solicitudes completadas con el SLO requerido? |
8. Planifique el comportamiento ante fallos y mantenimiento
Un despliegue de H200 está listo para producción solo cuando cuenta con una estrategia de recuperación. Pruebe el reinicio de una réplica, el drenaje de nodos, la recarga del modelo, el arranque en frío de la caché y la interrupción de la red ascendente. Defina qué sucede cuando la capacidad no está disponible temporalmente: poner en cola, descartar, enrutar a un modelo más pequeño o usar una alternativa de API gestionada. La mejor opción depende de los requisitos de corrección y latencia del producto.
Rendimiento: evalúe la carga de trabajo, no el folleto
NVIDIA publica material sobre capacidades y pruebas de rendimiento para la H200, incluida una afirmación de mayor rendimiento de inferencia de LLM en comparaciones seleccionadas. Estos resultados son útiles para comprender lo que el acelerador puede permitir, pero no constituyen una promesa para un modelo, longitud de contexto, cuantización, pila de serving o topología de nube concretos. La hoja de datos de H200 debe leerse junto con sus condiciones de prueba y notas al pie.
Para una comparación práctica de H200, mantenga constantes estas variables:
- Revisión del modelo, tokenizador, precisión y cuantización.
- Distribución de tokens de entrada y salida.
- Concurrencia y política de control de admisión.
- Diseño de paralelismo de tensor/canalización y topología real del hardware.
- Versiones del motor de serving y de CUDA/NCCL.
- Método de medición del SLA, incluidos el calentamiento y el estado de la caché.
- Unidad de precios de la nube y costes no relacionados con la GPU, como almacenamiento, salida de datos, CPU y operaciones.
Ese plan de pruebas es más valioso que una comparación genérica de «tokens por segundo» porque indica si la Nvidia H200 GPU modifica un SLO orientado al cliente o el coste por solicitud completada.
Lista de verificación de despliegue de H200
Use esta lista de verificación como criterio de publicación para una nueva carga de trabajo H200.
- [ ] Registre el modelo, la precisión, la longitud máxima de contexto, la longitud de salida y la concurrencia objetivo.
- [ ] Calcule un presupuesto de memoria para pesos, caché KV, espacio de trabajo de tiempo de ejecución y un margen de seguridad.
- [ ] Confirme si la H200 asignada es SXM o NVL y capture
nvidia-smi topo -m. - [ ] Verifique la compatibilidad del controlador, CUDA, contenedor, framework y motor de serving.
- [ ] Solicite el número previsto de GPU con restricciones de colocación en el orquestador.
- [ ] Ejecute una prueba de salud de CUDA/operadores antes de cargar el modelo.
- [ ] Ejecute la validación de topología y ancho de banda colectivo antes de aceptar un resultado multi-GPU.
- [ ] Mida por separado el tráfico de contexto corto y de contexto largo.
- [ ] Realice seguimiento de TTFT, rendimiento de tokens de salida, latencia P95/P99, tiempo en cola, errores y memoria de GPU.
- [ ] Pruebe un escenario de reinicio, drenaje de nodos y reducción de capacidad.
- [ ] Compare el resultado con una referencia de API de modelo gestionada para la misma carga de trabajo y SLO.
- [ ] Guarde la topología, la configuración de las pruebas de rendimiento y los supuestos de coste junto con la decisión de despliegue.
Cuándo una API de modelo es la mejor opción de despliegue en la nube
Operar directamente la Nvidia H200 GPU le proporciona control sobre los pesos del modelo, la configuración de serving, la ubicación de los datos y la capacidad. También añade trabajo de planificación de capacidad, validación de topología, observabilidad y recuperación. Si esos controles no crean una ventaja significativa para el producto, mantenga una comparación honesta: evalúe una API de modelo gestionada con las mismas métricas de calidad, latencia, disponibilidad y carga de trabajo completada.
Flatkey puede ser una de esas referencias para equipos que necesitan probar o enrutar entre API oficiales de modelos sin mantener integraciones independientes con proveedores. Su descripción general del producto indica que ofrece una clave de API y un saldo para modelos y herramientas; la elección correcta es la que cumple los requisitos de su carga de trabajo con la menor superficie operativa innecesaria. Explore el catálogo de modelos de Flatkey u obtenga una clave de API cuando una API enrutada se adapte mejor a la carga de trabajo que una capacidad de GPU dedicada.
Preguntas frecuentes
¿Cuál es la capacidad de memoria de una GPU Nvidia H200?
NVIDIA indica 141 GB de memoria HBM3e por GPU H200, con 4,8 TB/s de ancho de banda de memoria. Esto es por acelerador, por lo que aún necesita un plan de servicio distribuido si el modelo y la caché activa superan el margen utilizable de una sola GPU.
¿La H200 es principalmente una GPU de inferencia o de entrenamiento?
La H200 está posicionada tanto para cargas de trabajo de IA como de HPC. Para la planificación del despliegue, distinga la carga de trabajo en lugar de la etiqueta: el servicio de LLM con contexto largo, el ajuste fino, el entrenamiento distribuido y la computación científica someten a estrés la memoria, la comunicación y la planificación de formas distintas. Evalúe comparativamente el framework y la topología que realmente operará.
¿Cuál es la diferencia entre H200 SXM y H200 NVL?
Son diferentes factores de forma de H200 y rutas de integración en servidores. NVIDIA enumera sistemas SXM con conectividad NVLink en configuraciones estilo HGX de 4 u 8 GPU, mientras que H200 NVL es un factor de forma PCIe de doble ranura con opciones de puente documentadas. Confirme la topología real del proveedor de nube antes de asumir un comportamiento multi-GPU equivalente.
¿Puedo ejecutar una carga de trabajo H200 en Kubernetes?
Sí, siempre que el clúster tenga un controlador NVIDIA compatible, una ruta de runtime de contenedores y un plugin de dispositivos. Kubernetes programa las GPU como recursos extendidos, y NVIDIA GPU Operator puede gestionar la pila de software de GPU y los componentes de telemetría. Valide las etiquetas de los nodos, la solicitud de recursos de GPU, el estado del operador y los SLO a nivel de aplicación antes de enviar tráfico de producción.
¿Debería elegir H200 en lugar de H100?
Elija según el cuello de botella. La mayor capacidad HBM3e de la H200 y su mayor ancho de banda de memoria documentado pueden ser valiosos para el servicio limitado por memoria, pero una H100 aún puede satisfacer una carga de trabajo más pequeña con mejor ajuste operativo o comercial. Compare factores de forma idénticos y ejecute la misma carga de trabajo en ambas configuraciones. Nuestra guía H200 vs. H100 ofrece el marco de decisión.
Mantenga reproducible la decisión de despliegue
La arquitectura de la H200 resulta atractiva cuando la memoria y la topología son las restricciones reales. Haga reproducible la decisión sobre la GPU Nvidia H200 guardando juntos el contrato de carga de trabajo, el plan de memoria, la topología de hardware, las versiones de software y los resultados de las pruebas de carga. Ese registro permite al siguiente ingeniero explicar por qué funciona el despliegue e identificar qué cambió si deja de funcionar.
Para los próximos pasos de planificación, lea la guía de arquitectura de clústeres de GPU para el diseño de cómputo, red, almacenamiento y plano de control; después, use la guía de inferencia multi-GPU de vLLM para la configuración del paralelismo de tensores y de canalización.
