GPU, host y software
Motor 1.0-rfc2 · Revisión: 26 de septiembre de 2026. Memoria en GB decimales; cifras de planificación, no mediciones de rendimiento.
Memoria de GPU
- Pesos. Los parámetros totales se reparten entre cuantizables y no cuantizables; no se suman embeddings por segunda vez. Se conserva el dato de pesos compartidos de la configuración del modelo. Para Llama, Mistral y Qwen2 densos compatibles se identifican
(2 × capas + 1) × dimensión ocultaparámetros RMSNorm. Otras arquitecturas mantienen el inventario agregado del catálogo, sin extrapolar ese número de normas. - Metadatos de pesos. El perfil por grupos añade escalas y ceros con el tamaño especificado. La aproximación
ceil(parámetros / grupo)no reproduce el padding por matriz ni los auxiliares de todos los kernels. AWQ y GPTQ admiten layouts distintos; selecciona los bytes de escala y bits de cero del archivo real. El perfil manual conserva el porcentaje alternativo, sin sumarlo otra vez. - KV paginada. El contexto se redondea al bloque superior; solo se comparten prefijos de bloques completos. Datos, escalas y tabla de bloques se muestran por separado. vLLM usa índices de 32 bits en sus tablas; el valor inicial de 8 bytes por entrada es un presupuesto genérico conservador, editable. La política de escala por tensor, cabeza o grupo debe corresponder al motor.
- CUDA y comunicación. Ampere 1,2 GB, Hopper 2,2 GB y Blackwell 3 GB son presupuestos del proyecto, no consumos certificados por NVIDIA. Se pueden sustituir por un valor manual. NCCL añade por GPU
canales × buffers por canal × tamaño del buffer; no se multiplica otra vez por TP. Los buffers de tensores se contabilizan aparte. El buffer inicial es 4 MiB, convertido a 0,004194304 GB. - Paralelismo. TP debe dividir las cabezas de consulta; TP × PP debe dividir las GPU del equipo. PP usa la etapa de más capas y reserva el bloque no cuantizado en cada etapa como cota conservadora. La validez matemática no acredita todos los kernels o interconexiones.
Fuentes: configuración Transformers, RMSNorm en Llama, AWQ en vLLM, AWQ de MIT, tablas KV, escalas KV, NCCL.
Host por equipo
| Recurso | Presupuesto | Cómo interpretarlo |
|---|---|---|
| RAM | SO + copia de pesos + KV de cola opcional + transferencia + sesiones + software | Inicialmente: 32 GB de SO, 2 GB/GPU para transferencia y 25 MB/usuario. La copia de pesos y offload comparten reserva; en memoria unificada no se repite la carga GPU. |
| CPU física | 4 + 2 × réplicas + GPU + ceil(usuarios / 16) + software | Política de dotación, no equivalencia de núcleos a tokens/s. Se compara también la demanda de tokenización con el perfil o medición. |
| Red API | Entrada: usuarios × (prompt × bytes/token + payload) / ventana de llegada. Salida: usuarios × objetivo tokens/s × bytes/token. | En full dúplex se compara el mayor sentido, no su suma. Un puerto por camino; no se agregan enlaces automáticamente. Requisitos de almacenamiento o fabric se evalúan aparte. |
| Arranque | Pesos / min(lectura, transferencia a GPU) + inicialización | Es el extremo ideal solapado. El extremo serial suma los dos tiempos de transferencia. Ambos excluyen deserialización y compilación no presupuestada. |
La RAM de KV en cola requiere activar expresamente la reserva de host: estar en cola no implica que el motor guarde esa caché. RAM inferior a 1,5 × VRAM solo produce una observación de equilibrio; no constituye un requisito universal. El reparto aritmético entre sockets invita a revisar afinidad, pero no identifica por sí solo nodos NUMA.
Fuentes: opciones del motor vLLM, transferencia y memoria CUDA, ajuste de rendimiento ThinkSystem.
Software y lista de componentes
El selector diferencia licencias, reservas locales y servicios externos. NVIDIA AI Enterprise no consume VRAM por el hecho de licenciarse. La reserva opcional NIM/Triton se configura aparte y se suma una sola vez al contexto del motor. Las VM de gestión se muestran con sus propios recursos; no se restan de las CPU/GPU de inferencia.
OpenShift AI, ODF y sus dependencias tienen requisitos de nodos, almacenamiento y CPU lógica. El ajuste de SMT convierte únicamente esos requisitos de software a un presupuesto de núcleos físicos. No sustituye los perfiles SNO, compactos o distribuidos que no se han modelado.
Los códigos de compra verificados aparecen como P/N. Las bases CTO y los códigos de función se etiquetan de forma distinta. Las capacidades de disco representan una referencia documentada del formato/capacidad, no todas las combinaciones posibles de backplane. Si no se ha verificado un P/N o el alcance de licencia, el informe lo declara expresamente. El listado requiere validación comercial y de montaje antes de convertirse en una oferta.
Fuentes de cada licencia: enlaces en la lista de componentes del PDF y en la exportación JSON. Los requisitos y presupuestos de cada servicio también se incluyen en el JSON.
Estados del resultado
- Factible según la estimación: caben los presupuestos de memoria y host y el rango conservador de velocidad alcanza el objetivo.
- Viabilidad condicionada: faltan métricas, hay offload, el contexto excede la ficha o el software tiene condiciones sin resolver.
- Configuración insuficiente: una capacidad calculable o un requisito del perfil seleccionado no se cumple.
El resultado es una estimación. No certifica compatibilidad completa, disponibilidad comercial, rendimiento observado ni latencia bajo carga. Los escenarios 30/60/90 % expresan ocupación de VRAM; no porcentajes de rendimiento global.