CommunityProgramación y desarrollogithub.com

Ayaansiddiq07/ingeniería-de-inferencia

Toma decisiones de arquitectura, rendimiento y producción para servir modelos de IA generativa. Úsalo al seleccionar modelos o hardware, diagnosticar latencia o rendimiento, optimizar inferencia de LLM o multimodal, realizar benchmarks, escalar servicios GPU o estimar costos de servicio.

¿Qué es ingeniería-de-inferencia?

Esta habilidad transforma los requisitos de calidad, latencia, confiabilidad y costo de un producto de IA en un sistema de inferencia medido. Está basada en el libro *Inference Engineering* de Philip Kiely (Baseten Books, 2026) y no está afiliada al autor o editor. Proporciona un flujo de trabajo operativo completo: desde caracterizar la carga de trabajo y seleccionar modelos candidatos, hasta establecer presupuestos de rendimiento, ajustar modelos al hardware, localizar cuellos de botella y validar el comportamiento en producción. Cubre métricas clave como TTFT, ITL, latencia de extremo a extremo, rendimiento y goodput, junto con una tabla de diagnóstico de síntomas. Además, incluye guías de optimización para batching, cuantización, decodificación especulativa, caching de KV, paralelismo y optimización de kernels, así como secciones sobre benchmarking, profiling y preparación para producción. Es compatible con cualquier plataforma de servicio de modelos generativos (LLMs, modelos multimodales, de embeddings, etc.) y ofrece referencias detalladas para decisiones sobre modelos, hardware, software y operaciones.

Compatible con~Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add https://github.com/Ayaansiddiq07/Inference-skill/tree/HEAD

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Ingeniería de Inferencia

Usa esta habilidad para convertir los requisitos de calidad, latencia, confiabilidad y costo de un producto de IA en un sistema de inferencia medido. Es una síntesis operativa independiente informada por el libro Inference Engineering de Philip Kiely (Baseten Books, 2026), y no está afiliada ni respaldada por el autor o la editorial. Las características de los proveedores, los lanzamientos de modelos, la disponibilidad de hardware y el comportamiento del software cambian rápidamente; verifica los detalles actuales contra la documentación oficial antes de tomar decisiones de implementación.

Comienza con la carga de trabajo

Antes de elegir un motor u optimización, establece:

  • Contrato del producto: calidad de salida requerida, modalidades, tamaños de contexto/entrada, forma de la respuesta, necesidades de streaming y comportamiento ante fallos.
  • Forma del tráfico: tasa de solicitudes, concurrencia, ráfagas, patrón de llegada, distribuciones de longitud de entrada/salida y frecuencia de prefijos almacenables en caché.
  • Objetivos del servicio: latencia P50/P95/P99 de extremo a extremo, tiempo hasta el primer token (TTFT), latencia entre tokens (ITL), rendimiento, disponibilidad y objetivos de recuperación.
  • Restricciones: presupuesto, regiones, residencia de datos, privacidad, licencia, acceso a hardware y capacidad operativa.
  • Línea base: evaluación de calidad representativa más rendimiento y costo de extremo a extremo bajo carga realista.

No optimices una métrica proxy de forma aislada. Define la unidad de trabajo e incluye el tiempo de cliente, cola, red, preprocesamiento, modelo y postprocesamiento cuando sea aplicable. Para flujos agénticos, mide toda la tarea incluyendo llamadas a herramientas y reintentos.

Flujo de trabajo operativo

  1. Caracteriza la carga de trabajo. Separa el tráfico interactivo en línea del trabajo offline/por lotes; identifica las rutas sensibles a latencia y las orientadas a rendimiento. Registra las distribuciones reales de entrada/salida y la concurrencia.
  2. Elige modelos candidatos. Preselecciona según calidad específica de la tarea, modalidad, contexto, restricciones de servicio, licencia y ajuste operativo. Usa benchmarks públicos solo para reducir candidatos; evalúa con datos de producto representativos y casos de fallo.
  3. Establece presupuestos. Traduce los objetivos de extremo a extremo en presupuestos para encolamiento, red, preprocesamiento, prefill, decodificación y postprocesamiento. Incluye margen para ráfagas y condiciones degradadas.
  4. Ajusta el modelo al hardware. Estima la memoria de pesos, la sobrecarga de tiempo de ejecución/activaciones, la demanda de caché KV y el margen utilizable. Verifica el ancho de banda de memoria medido, la computación, la interconexión y la topología; una especificación nominal del acelerador no es un benchmark de carga de trabajo.
  5. Establece una línea base reproducible. Fija la revisión del modelo, motor/versión, hardware, precisión, configuración, mezcla de prompts, límites de salida y forma de carga. Calienta, ejecuta suficientes muestras e informa percentiles y rendimiento al mismo tiempo.
  6. Localiza el cuello de botella. Usa primero mediciones de extremo a extremo, luego perfilado del sistema y del kernel. Distingue encolamiento, prefill, decodificación, capacidad/ancho de banda de memoria, computación, comunicación y sobrecarga del host.
  7. Cambia una variable a la vez. Aplica la optimización menos compleja que aborde el cuello de botella medido. Vuelve a verificar calidad, latencia de cola, rendimiento, memoria y costo juntos.
  8. Valida el comportamiento en producción. Prueba sobrecarga, arranques en frío, eventos de escalado, fallos, despliegues, cancelación, streaming y recuperación. Instrumenta las mismas métricas utilizadas en los objetivos del servicio.

Métricas y diagnóstico

  • TTFT: tiempo desde un evento de inicio claramente definido (por ejemplo, envío del cliente o aceptación del servidor) hasta el primer token generado. Mantén ese límite consistente al comparar ejecuciones; es sensible al encolamiento, la longitud del prompt, el prefill y los efectos de arranque.
  • ITL: tiempo entre tokens generados; refleja la capacidad de respuesta de la decodificación. Reporta distribuciones por solicitud, no solo la tasa agregada de tokens.
  • Latencia de extremo a extremo: tiempo de finalización observado por el cliente; incluye trabajo de red y de aplicación.
  • Rendimiento: solicitudes o tokens completados por unidad de tiempo con una carga de trabajo y un envolvente de latencia/calidad indicados. Especifica si los tokens/segundo son por usuario o a nivel de sistema.
  • Percentiles: reporta P50 más objetivos de cola como P95/P99; los promedios pueden ocultar solicitudes lentas.
  • Goodput: trabajo completado cumpliendo los objetivos relevantes de latencia y calidad. Úsalo para comparar configuraciones que intercambian velocidad por calidad o comportamiento de cola.

Interpreta los síntomas como hipótesis, luego verifica con trazas/perfiles:

SíntomaÁreas probables a medir
TTFT alto, ITL normalEspera en cola, prompts largos, cómputo de prefill, arranque en frío, preprocesamiento
TTFT normal, ITL pobreAncho de banda de decodificación, contención de lotes, presión de caché KV, eficiencia del kernel
Ambos empeoran al aumentar la concurrenciaEncolamiento, capacidad de memoria, política de lotes, control de admisión, saturación
Baja utilización de GPU, latencia altaCPU/tokenización, transferencia de datos, sincronización, red, planificación
El rendimiento aumenta pero la latencia de cola viola el SLOPolítica de batching/concurrencia, límites de cola, aislamiento de carga de trabajo

Estas son pistas diagnósticas, no conclusiones. Confirma el cuello de botella activo antes de cambiar la configuración.

Decisiones de modelo y hardware

  • Prefiere el modelo más pequeño/menos costoso que pase la evaluación de calidad del producto con margen aceptable. Considera prompting, recuperación, ajuste fino o destilación solo cuando la evaluación identifique una brecha específica y el costo del ciclo de vida esté justificado.
  • Separa despliegues en línea y offline cuando sus objetivos de latencia, batching o disponibilidad entren en conflicto y el tráfico medido justifique la sobrecarga operativa.
  • Ajusta el modelo y el estado de ejecución en la memoria del acelerador con margen explícito para caché KV, activaciones, fragmentación y concurrencia. El ajuste de pesos por sí solo es insuficiente.
  • Para LLM autorregresivos, el prefill y la decodificación estresan el hardware de manera diferente: el prefill suele ser intensivo en cómputo; la decodificación a menudo se vuelve limitada por ancho de banda de memoria. Mide ambos para la mezcla real de secuencias y batching.
  • Las opciones multi-GPU intercambian memoria/latencia/rendimiento por comunicación y complejidad. El paralelismo tensorial puede reducir la latencia por solicitud para un modelo dividido; el paralelismo de expertos puede servir expertos dispersos a escala. Valida los costos de interconexión y sincronización. La ejecución multinodo requiere una medición de comunicación especialmente cuidadosa.
  • Para cargas de trabajo de imagen, video, audio, embeddings y visión-lenguaje, usa pipelines y métricas específicas de la modalidad. Incluye costos de preprocesamiento, fragmentación, codificador/decodificador y postprocesamiento; no apliques métricas de tokens de LLM ciegamente.
  • Verifica las licencias del modelo y del conjunto de datos, así como los requisitos relevantes de seguridad, privacidad y regulación antes del despliegue.

Para el razonamiento detrás de estas elecciones, usa fundamentos de modelo y hardware. Para compatibilidad de framework, formato y motor de servicio, usa selección de pila de software. Estas referencias proporcionan métodos de decisión, no rankings atemporales: verifica el soporte para el modelo exacto, acelerador, versión de ejecución y conjunto de características.

Guías de optimización

Aplica solo después de establecer una línea base e identificar un cuello de botella compatible:

Batching y planificación

El batching puede mejorar la utilización del acelerador y amortizar la sobrecarga, mientras aumenta el encolamiento y la latencia por solicitud. Ajusta la concurrencia, los límites de lotes, las ventanas de espera y el control de admisión contra llegadas realistas. Protege el tráfico interactivo del trabajo por lotes cuando sus objetivos entren en conflicto.

Cuantización

Trata la cuantización como un espectro de calidad/rendimiento, no como una configuración binaria. Elige qué componentes y precisión cambiar según las restricciones medidas de memoria, ancho de banda, cómputo y calidad. Evalúa la calidad de la tarea representativa, los casos extremos y los conjuntos de regresión después de cada cambio; observa por separado los efectos en pesos, activaciones, atención y caché KV donde el motor lo permita. Revierte si se incumple el piso de calidad del producto o el objetivo de confiabilidad.

Decodificación especulativa

Usa un mecanismo de borrador/propuesta solo cuando su costo de propuesta y comportamiento de aceptación produzcan una ganancia neta para la carga de trabajo objetivo. Mide la tasa de aceptación, la sobrecarga de memoria, el impacto en el tamaño del lote, el ITL por usuario, el rendimiento agregado y el costo. El beneficio puede reducirse o revertirse con alta concurrencia o aceptación débil.

Caching de KV y prefijos

Reutiliza el estado almacenado en caché cuando los prefijos se repitan y los requisitos de corrección/aislamiento lo permitan. Mide la tasa de aciertos, el trabajo de prefill ahorrado, el costo de almacenamiento/memoria, el comportamiento de desalojo y la localidad de enrutamiento. Define claves de caché y límites de inquilino/seguridad para que una solicitud no pueda reutilizar el contexto privado de otro inquilino. Los contextos largos y la alta concurrencia aumentan la presión sobre KV; considera los costos de colocación y transferencia.

Paralelismo y desagregación

Introduce paralelismo cuando las mediciones de ajuste del modelo, latencia o rendimiento justifiquen la sobrecarga de comunicación. Desagrega prefill y decodificación solo cuando la carga de trabajo sea lo suficientemente grande y estable para beneficiarse de la asignación independiente de recursos y el sistema pueda gestionar la transferencia/enrutamiento de KV. Incluye ancho de banda de red, latencia de transferencia, modos de fallo y complejidad operativa en la comparación.

Optimización de kernels y tiempo de ejecución

Perfila antes de escribir o seleccionar kernels especializados. La fusión de kernels puede reducir el tráfico de memoria y la sobrecarga de lanzamiento, pero la compatibilidad y el comportamiento numérico importan. Compara candidatos de framework/ejecutable/motor usando la misma revisión de modelo, hardware, mezcla de prompts, longitudes de salida, carga y controles de calidad.

Para comparaciones detalladas de métodos de cuantización, familias de decodificación especulativa, colocación de caché, servicio de contextos largos y ejecución distribuida, lee la guía de optimización.

Benchmarking y perfilado

  • Usa trazas de producción o una carga de trabajo que preserve las privacidades, así como los tamaños de solicitud, patrones de llegada y características de caché. Las pruebas sintéticas son útiles para experimentos controlados, pero indica sus limitaciones.
  • Registra el comportamiento en frío y en caliente por separado. Incluye calentamiento, duración/número de muestras adecuados, ejecuciones repetidas, varianza y versiones de hardware/software.
  • Barre la carga para encontrar tanto la saturación como el goodput máximo bajo SLO. Evita comparar una ejecución con carga ligera con una sobrecargada.
  • Cambia un factor a la vez para la atribución; después del ajuste, ejecuta una prueba combinada de extremo a extremo porque las optimizaciones pueden interactuar.
  • Empareja los benchmarks del sistema con la evaluación de calidad de la tarea. Las mejoras de rendimiento que degradan las salidas más allá del umbral del producto no son ganancias.
  • El benchmarking muestra qué es lento; el perfilado ayuda a explicar por qué. Usa el perfilador menos intrusivo que pueda aislar el cuello de botella activo y valida la corrección propuesta con un benchmark fresco.

Preparación para producción

  • Capacidad y autoescalado: escala según indicadores adelantados (profundidad de cola, utilización, presión de memoria/KV, tasa de llegada) así como trabajo completado. Considera el tiempo de aprovisionamiento y carga del modelo; mantén suficiente capacidad o degrada gracefulmente cuando los arranques en frío violen los objetivos.
  • Encolamiento y sobrecarga: limita las colas y los tamaños de solicitud, establece tiempos de espera/cancelación, usa control de admisión y define respuestas explícitas a la sobrecarga. El encolamiento ilimitado convierte la saturación en fallo de latencia de cola.
  • Confiabilidad: prueba verificaciones de salud, reintentos con límites, idempotencia donde sea necesario, pérdida de instancias, fallo de región/proveedor, despliegue, reversión y agotamiento de capacidad. Los reintentos pueden amplificar la sobrecarga.
  • Despliegue: fija los artefactos y dependencias del modelo, valida el inicio/preparación, realiza cambios canary, compara métricas de calidad y servicio, y conserva un camino de reversión probado. Evita exponer secretos en imágenes, registros o artefactos de benchmark.
  • Observabilidad: correlaciona las trazas de las solicitudes con las versiones del modelo, motor, hardware y configuración. Rastrea TTFT, ITL, percentiles de extremo a extremo, tiempo de cola, rendimiento/goodput, errores, tasa de aciertos de caché, utilización, memoria, arranques en frío y costos.
  • Costo: compara el costo por solicitud exitosa o salida útil con la calidad y SLO requeridos, incluyendo capacidad inactiva, replicación, redes, almacenamiento y carga de ingeniería/operaciones. Escalar a cero puede reducir el gasto inactivo, pero agrega latencia de arranque en frío.
  • Seguridad y cumplimiento: controla el acceso al modelo y los datos, aísla inquilinos, protege prompts y salidas en registros, define retención, valida dependencias y artefactos, y cumple con los requisitos aplicables de residencia de datos y regulación.

Para reproducibilidad de contenedores, capacidad y enrutamiento, operaciones multirregión, protocolos de cliente y prácticas de despliegue, lee operaciones de producción. Para medición por modalidad, lee consideraciones de inferencia específicas por modalidad.

Enrutamiento de referencias

TareaLeer
Construir una tarjeta de carga de trabajo, establecer una línea base o localizar un cuello de botellaEste archivo, luego guía de optimización
Entender la ejecución del modelo, el ajuste del acelerador o las compensaciones de hardwareFundamentos de modelo y hardware
Seleccionar un framework, formato de modelo, ruta de kernel o motor de servicioSelección de pila de software
Ajustar cuantización, especulación, cachés, paralelismo o desagregaciónGuía de optimización
Servir cargas de trabajo de visión, embeddings, audio, imagen o videoConsideraciones específicas por modalidad
Planificar autoescalado, despliegue, confiabilidad, comportamiento de API/cliente y costosOperaciones de producción

Formato de respuesta para tareas de inferencia

Al asesorar o implementar, proporciona:

  1. Suposiciones de la carga de trabajo y mediciones faltantes.
  2. El objetivo y las métricas de línea base.
  3. La hipótesis principal del cuello de botella y cómo probarla.
  4. Un plan de experimentos clasificado con compensaciones esperadas.
  5. Criterios de aceptación de calidad, latencia de cola, confiabilidad, seguridad y costos.
  6. Hechos actuales del proveedor/modelo/ejecutable con enlaces a fuentes oficiales cuando afecten la recomendación.

…

[truncado para traducción]

Skills relacionados