Última revisión: junio de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen NCP-GENL. Lee de arriba a abajo o salta a una sección.
Se necesita menor latencia en H100/Blackwell sin el impacto en la precisión de una cuantización INT agresiva.
Use cuantización FP8 (E4M3) a través de TensorRT-LLM; Hopper y Blackwell tienen Tensor Cores FP8 nativos.
Por qué: FP8 preserva mejor el rango dinámico que INT8 y se ejecuta a la máxima velocidad de hardware en Hopper+, ofreciendo una calidad cercana a FP16 con un rendimiento de clase INT8.
El modelo apenas cabe en la memoria de la GPU y el rendimiento está limitado por el ancho de banda de la memoria.
Aplique cuantización INT4 solo de pesos (AWQ o GPTQ); mantenga las activaciones en FP16/FP8.
Por qué: INT4 solo de pesos reduce aproximadamente a la mitad la memoria frente a INT8 y alivia la presión del ancho de banda; la precisión de activación se mantiene alta, por lo que la pérdida de precisión es pequeña.
Decidir entre cuantización post-entrenamiento y entrenamiento consciente de la cuantización.
Comience con PTQ (calibre con una muestra representativa); recurra a QAT solo si la pérdida de precisión de PTQ excede el presupuesto.
Por qué: PTQ es rápido y no necesita reentrenamiento; QAT recupera la precisión pero implica un ciclo de entrenamiento, así que resérvelo para modelos críticos en cuanto a precisión.
Servicio de contexto largo donde la caché KV domina la memoria y limita el tamaño del lote.
Habilite la cuantización de caché KV FP8 o INT8 en TensorRT-LLM.
Por qué: La caché KV crece con la longitud de la secuencia × lote; cuantizarla libera memoria para lotes más grandes y contextos más largos con un impacto mínimo en la calidad.
Longitudes de solicitud mixtas causan tiempo de inactividad de la GPU con el procesamiento por lotes estático.
Utilice el procesamiento por lotes en curso (continuo) en TensorRT-LLM para que las secuencias terminadas sean desalojadas y las nuevas se unan a mitad de proceso.
Por qué: El procesamiento por lotes continuo mantiene la GPU saturada y aumenta el rendimiento muy por encima del procesamiento por lotes estático para flujos de solicitudes heterogéneos.
Un modelo grande "maestro" cumple con la calidad pero no alcanza el objetivo de latencia y costo.
Destile en un modelo "estudiante" más pequeño, luego cuantifique el estudiante para la inferencia.
Por qué: La destilación transfiere la capacidad a una arquitectura más barata; combinada con la cuantificación, multiplica los ahorros de costo/latencia.
La latencia de una sola secuencia es demasiado alta para un caso de uso interactivo.
Aplique la decodificación especulativa con un modelo de borrador pequeño verificado por el modelo objetivo.
Por qué: El borrador propone múltiples tokens que el modelo grande verifica en una sola pasada, reduciendo la latencia de tiempo real sin cambiar la distribución de salida.
Cuantizar todo a INT4 reduce drásticamente la precisión en algunas capas sensibles.
Use precisión mixta: mantenga las capas sensibles (por ejemplo, proyección final, atención) con mayor precisión y cuantifique el resto.
Por qué: La sensibilidad por capa varía; la precisión selectiva protege la precisión donde importa mientras reduce la mayor parte de los pesos.
La precisión de PTQ es deficiente a pesar de un esquema de cuantización razonable.
Recalibre con una muestra en distribución (cientos de prompts representativos) que coincida con el tráfico de producción.
Por qué: La calibración establece rangos de activación; una muestra no representativa produce escalas incorrectas y una pérdida de precisión evitable.
Los pesos del modelo exceden una sola GPU pero caben dentro de un nodo conectado por NVLink.
Utilice paralelismo de tensor en las GPUs del nodo.
Por qué: El paralelismo de tensor fragmenta cada capa e intercambia activaciones en cada paso, por lo que necesita el alto ancho de banda intra-nodo de NVLink/NVSwitch.
El modelo es demasiado grande para un solo nodo y debe extenderse a través de nodos usando InfiniBand.
Agregue paralelismo de pipeline entre nodos, manteniendo el paralelismo de tensor dentro de cada nodo.
Por qué: El paralelismo de pipeline se comunica solo en los límites de las etapas, tolerando enlaces inter-nodo más lentos; reserve el paralelismo de tensor, que consume mucho ancho de banda, para NVLink.
La escalabilidad a más GPUs produce ganancias de rendimiento decrecientes.
Perfile con Nsight Systems para clasificar el cuello de botella; si los colectivos dominan, reduzca el grado de paralelismo o mejore la topología.
Por qué: Más allá de cierto punto, la sobrecarga de all-reduce/all-gather supera el cómputo adicional; diagnosticar si está limitado por la comunicación o por el cómputo guía la solución.
La sobrecarga de lanzamiento de kernel por paso aumenta la latencia de decodificación en tamaños de lote pequeños.
Habilite CUDA Graphs para capturar y reproducir el bucle de decodificación.
Por qué: CUDA Graphs colapsa muchos lanzamientos pequeños en una sola reproducción, eliminando la sobrecarga de lanzamiento del lado de la CPU que domina en tamaños de lote bajos.
Rangos de paralelismo de tensor colocados a través de un enlace lento causan bloqueos.
Fije los rangos de paralelismo de tensor a las GPUs que comparten NVLink/NVSwitch; coloque las etapas de pipeline a través de los nodos.
Por qué: La colocación no coincidente dirige los colectivos de alta frecuencia a través de PCIe o InfiniBand, estrangulando todo el pipeline.
La atención está limitada por la memoria y limita la longitud de contexto alcanzable.
Utilice FlashAttention (kernels de atención fusionados y conscientes de E/S) proporcionados por la pila de TensorRT-LLM/NeMo.
Por qué: FlashAttention evita materializar la matriz de atención completa, reduciendo el tráfico de memoria y permitiendo secuencias más largas a mayor velocidad.
Varios modelos pequeños subutilizan las GPUs H100 completas.
Particione las GPUs con MIG (Multi-Instance GPU) para aislar cada modelo en una porción.
Por qué: MIG proporciona particiones aisladas por hardware, aumentando la utilización y ofreciendo QoS predecible para cargas de trabajo pequeñas co-localizadas.
El servicio descendente requiere JSON estrictamente válido en todo momento.
Utilice decodificación guiada/restringida (gramática o esquema JSON) en el tiempo de ejecución del servicio en lugar de depender únicamente de la redacción del prompt.
Por qué: La decodificación restringida enmascara tokens inválidos en el momento de la generación, garantizando una salida válida según el esquema, mientras que el prompting solo reduce la tasa de fallos.
La tarea requiere un formato consistente que el modelo base maneja de manera inconsistente.
Pruebe primero con ejemplos few-shot; pase al ajuste fino solo si la dirección basada en prompts se estanca o el costo por token es excesivo.
Por qué: Few-shot no requiere entrenamiento y es editable al instante; el ajuste fino solo es ventajoso cuando los patrones son estables y la sobrecarga del prompt es perjudicial.
Una tarea de razonamiento de múltiples pasos da respuestas finales incorrectas.
Procure un "chain-of-thought" ('piensa paso a paso') o use una plantilla de razonamiento estructurado antes de la respuesta final.
Por qué: Exponer los pasos intermedios mejora la precisión de múltiples saltos y hace que los errores sean auditables, a costa de tokens adicionales.
Un pequeño ajuste en el prompt regresó silenciosamente la calidad de producción.
Versionar los prompts del sistema como código, controlar los cambios mediante evaluación y desplegar a través del mismo CI que los artefactos del modelo.
Por qué: Los prompts son parte del contrato del modelo; las ediciones sin versionar causan regresiones no rastreadas y un comportamiento no reproducible.
El modelo alucina hechos fuera de sus datos de entrenamiento.
Recupere contexto relevante e inyéctelo en el prompt con una instrucción para responder solo a partir del contexto proporcionado.
Por qué: Basarse en pasajes recuperados restringe el modelo al material fuente y reduce la alucinación en consultas intensivas en conocimiento.
La latencia y el costo son altos porque los prompts son excesivos.
Recorte y comprima el prompt: elimine instrucciones duplicadas, resuma el contexto recuperado y limite los ejemplos al mínimo que mantenga la calidad.
Por qué: El pre-llenado escala con los tokens de entrada; los prompts concisos reducen tanto la latencia como el costo por solicitud sin una pérdida de calidad medible.
El texto proporcionado por el usuario puede anular la instrucción del sistema.
Separe las instrucciones confiables de la entrada no confiable con delimitadores claros y trate el contenido recuperado/del usuario como datos, no como comandos.
Por qué: Concatenar texto no confiable en el canal de instrucciones invita a la inyección de prompt; los límites explícitos reducen la superficie de ataque.
Adaptar un modelo base grande a un dominio con un presupuesto de GPU limitado.
Utilice LoRA: entrene adaptadores de bajo rango y congele los pesos base.
Por qué: LoRA entrena una pequeña fracción de parámetros, reduciendo drásticamente la memoria y el cómputo, mientras iguala el ajuste fino completo en la mayoría de las tareas específicas.
Incluso el entrenamiento LoRA de un modelo de 70B no cabrá en la memoria disponible.
Utilice QLoRA: cuantifique la base congelada a 4 bits (NF4) y entrene adaptadores LoRA sobre ella.
Por qué: Mantener la base en 4 bits mientras se actualizan solo los adaptadores permite que los modelos grandes se ajusten en una sola GPU con una pérdida mínima de precisión.
Elegir el rango LoRA para una nueva tarea de ajuste fino.
Comience con un rango modesto (por ejemplo, 8-16); auméntelo solo si la tarea es compleja y la pérdida de validación sigue mejorando.
Por qué: Un rango más alto añade capacidad y costo; un rango excesivo corre el riesgo de sobreajuste en conjuntos de datos pequeños, mientras que un rango insuficiente limita la calidad alcanzable.
El modelo sigue las instrucciones pero sus resultados no coinciden con la preferencia humana.
Primero realice el ajuste fino supervisado, luego la alineación de preferencias con RLHF o DPO.
Por qué: SFT enseña el formato y la tarea; la optimización de preferencias da forma a qué respuestas válidas prefieren realmente los humanos.
RLHF con PPO es inestable y operacionalmente pesado.
Utilice DPO (Optimización Directa de Preferencias) en un conjunto de datos de preferencias en lugar de un modelo de recompensa + bucle PPO.
Por qué: DPO optimiza las preferencias directamente sin un modelo de recompensa separado o un despliegue de RL, simplificando el pipeline y mejorando la estabilidad.
El adaptador LoRA añade una sobrecarga por solicitud en el momento de la inferencia.
Combine los pesos del adaptador en la base para el despliegue cuando solo se sirve un adaptador.
Por qué: Un modelo combinado no tiene una rama de adaptador en la inferencia; mantenga los adaptadores separados solo cuando intercambie múltiples tareas en caliente sobre una base.
El ajuste fino en una tarea específica degrada las capacidades generales.
Mezcle una parte de datos generales/de instrucción, reduzca la tasa de aprendizaje y prefiera PEFT sobre el ajuste fino completo.
Por qué: Reproducir datos generales y limitar el movimiento de pesos preserva las habilidades amplias mientras se sigue aprendiendo la nueva tarea.
Los datos de pre-entrenamiento/ajuste fino contienen muchas duplicaciones casi exactas.
Ejecute la deduplicación difusa (por ejemplo, MinHash/LSH) antes del entrenamiento.
Por qué: Las duplicaciones desperdician cómputo, sesgan el modelo hacia contenido repetido y pueden causar memorización; la deduplicación mejora la generalización por token.
Puntuaciones de benchmark sospechosamente altas después del entrenamiento.
Descontamine el conjunto de entrenamiento de los datos de benchmark/evaluación mediante el filtrado de solapamiento de n-gramas.
Por qué: La fuga de elementos de prueba infla las métricas y oculta la calidad real; la descontaminación mantiene la evaluación honesta.
El corpus puede contener datos personales sujetos a reglas de gobernanza.
Agregue una etapa de detección y redacción de PII al pipeline de datos antes del entrenamiento.
Por qué: Entrenar con PII sin procesar conlleva riesgos de regurgitación y violaciones de cumplimiento; la limpieza previa es mucho más barata que corregir un modelo con fugas.
Los datos brutos extraídos de la web son ruidosos y disminuyen la calidad del modelo.
Aplique filtros de calidad (heurísticas más un clasificador) para descartar documentos de baja calidad, repetitivos y spam.
Por qué: La calidad de los datos supera la cantidad bruta a partir de un umbral; el filtrado produce mejores modelos con el mismo presupuesto de entrenamiento.
Los datos de ajuste fino deben introducirse limpiamente en el pipeline de entrenamiento de NeMo.
Convierta al formato NeMo esperado (por ejemplo, JSONL con campos de prompt/respuesta) y tokenice con el tokenizador del modelo.
Por qué: Las inconsistencias de formato y tokenizador causan truncamientos silenciosos o errores de etiqueta; conformarse al esquema de NeMo mantiene el entrenamiento reproducible.
Establecer rápidamente un endpoint de LLM en producción con una API compatible con OpenAI.
Despliegue con un microservicio NVIDIA NIM; construya un conjunto Triton personalizado solo para necesidades no estándar de pre/post-procesamiento.
Por qué: NIM ofrece motores optimizados y una API estándar de fábrica; un Triton personalizado vale la pena solo cuando necesita un control de pipeline a medida.
Las solicitudes independientes llegan más rápido de lo que un servicio de una sola solicitud puede manejar.
Habilite el procesamiento por lotes dinámico de Triton para combinar solicitudes concurrentes en lotes de GPU.
Por qué: El procesamiento por lotes amortiza la sobrecarga del kernel entre solicitudes, aumentando el rendimiento con un costo de latencia pequeño y limitado.
Una única instancia de modelo deja el cómputo de la GPU subutilizado.
Configure múltiples instancias de modelo por GPU en Triton para superponer la ejecución.
Por qué: Las instancias concurrentes llenan las brechas de cómputo dejadas por los bloqueos de memoria, mejorando la utilización cuando la memoria lo permite.
El tráfico es variable y las réplicas fijas o desperdician GPUs o incumplen los SLOs.
Escale automáticamente las réplicas según la profundidad de la cola / utilización de la GPU con un pool "caliente" para absorber los arranques en frío.
Por qué: Los arranques en frío de LLM (carga del motor) son lentos; escalar con una señal anticipada y capacidad "caliente" protege la latencia durante los picos.
Los clientes existentes esperan la API de chat-completions de OpenAI.
Exponga el modelo a través del endpoint compatible con OpenAI de NIM para que los clientes se integren sin reescrituras.
Por qué: Una API compatible de reemplazo minimiza el trabajo de migración del cliente y le permite intercambiar backends de forma transparente.
Un cambio en el modelo o en el prompt no debe regresar silenciosamente la calidad.
Ejecute un conjunto de evaluación "golden" curado en CI y bloquee los despliegues que caigan por debajo de un umbral de calidad.
Por qué: Las puertas de regresión automatizadas detectan caídas de calidad antes de que lleguen a los usuarios, de la misma manera que las pruebas unitarias controlan el código.
Las salidas abiertas no tienen una única respuesta de referencia para puntuar.
Utilice un LLM como juez con una rúbrica, calibrado con calificaciones humanas en una muestra.
Por qué: Un juez basado en rúbricas escala la evaluación subjetiva; la calibración humana protege contra el propio sesgo del juez.
Puntuación MMLU alta pero los usuarios se quejan de la tarea de producción.
Evalúe con métricas específicas de la tarea vinculadas a los resultados comerciales, no solo con benchmarks genéricos.
Por qué: Los benchmarks genéricos se correlacionan débilmente con las tareas específicas desplegadas; la métrica correcta refleja lo que los usuarios realmente necesitan.
Las evaluaciones offline parecen buenas pero el impacto en el mundo real es incierto.
Ejecute una prueba A/B online dirigiendo una fracción del tráfico a la nueva versión y compare las métricas de resultado.
Por qué: La prueba A/B en vivo captura el cambio de distribución y el comportamiento del usuario que los conjuntos offline pasan por alto, confirmando una mejora real.
Necesidad de visibilidad sobre la salud y utilización de la GPU en una flota de servicio.
Exporte métricas de DCGM (utilización, memoria, ECC, temperatura) a Prometheus y configure alertas.
Por qué: DCGM es la fuente estándar de telemetría de NVIDIA; sin ella, la saturación y las fallas a nivel de GPU pasan desapercibidas.
Los usuarios ven respuestas lentas intermitentemente pero la latencia promedio parece bien.
Rastree el tiempo hasta el primer token y la latencia entre tokens p95/p99, y alerte sobre incumplimientos de SLO por percentiles.
Por qué: Los promedios ocultan la latencia de cola; la experiencia de usuario de LLM se rige por p95/p99, por lo que los SLIs de percentiles son la señal de alerta adecuada.
Desplegando una nueva versión del modelo a un endpoint de alto tráfico.
Despliegue a través de canary (una pequeña porción de tráfico) con reversión automatizada en caso de SLO o regresión de calidad.
Por qué: El despliegue canary limita el radio de impacto y permite que las métricas confirmen la seguridad antes del despliegue completo, a diferencia de un despliegue "big-bang".
El rendimiento colapsa bajo carga sin un pico obvio de cómputo de GPU.
Monitorice la utilización de la caché KV y los slots de lote; escale o acorte el contexto máximo cuando la caché se sature.
Por qué: El agotamiento de la caché KV limita la concurrencia antes que el cómputo; observarlo explica las caídas de rendimiento que la utilización de GPU por sí sola no detecta.
La caché KV es demasiado grande para el lote y el contexto objetivo.
Prefiera una arquitectura que utilice Grouped-Query Attention (GQA) o Multi-Query Attention (MQA).
Por qué: GQA/MQA comparten las cabezas de clave/valor, reduciendo la memoria de la caché KV y aumentando el tamaño de lote alcanzable con poca pérdida de calidad.
Necesidad de extender el contexto utilizable de un modelo más allá de su longitud entrenada.
Utilice escalado RoPE (por ejemplo, NTK-aware / YaRN) más un ajuste fino ligero de contexto largo.
Por qué: La interpolación RoPE estira las codificaciones posicionales; un ajuste fino corto adapta el modelo a un rango más largo sin reentrenamiento completo.
Se desea más capacidad sin un costo de inferencia proporcional.
Considere un modelo de Mixture-of-Experts que activa solo los k expertos principales por token.
Por qué: MoE escala los parámetros manteniendo bajos los FLOPs por token, pero añade complejidad de enrutamiento y carga desigual de expertos a gestionar.
Un modelo desplegado necesita límites de tema, seguridad y formato.
Envuelva el modelo con NeMo Guardrails para hacer cumplir las "rails" de entrada y salida (tópicas, moderación, jailbreak).
Por qué: Las "rails" programables añaden una capa de seguridad controlable alrededor del modelo sin reentrenarlo.
El modelo produce ocasionalmente contenido tóxico o inseguro.
Agregue un clasificador de moderación de salida y bloquee/regenere las respuestas que superen un umbral de riesgo.
Por qué: Una pasada de moderación separada detecta generaciones inseguras que las instrucciones a nivel de prompt por sí solas no previenen de forma fiable.
Los interesados requieren pruebas de que el modelo cumple con los estándares de IA responsable.
Ejecute benchmarks de sesgo y toxicidad, documente los resultados y rastréelos a través de las versiones en una ficha de modelo.
Por qué: La evaluación de seguridad documentada y reproducible apoya el cumplimiento y detecta regresiones antes de que lleguen a producción.