Su función de IA está funcionando. Las demostraciones van bien, los clientes de pago la utilizan y el panel de control tiene un aspecto saludable.
Entonces, un martes por la tarde, publica una nueva plantilla de prompt, el tráfico se duplica durante una hora y todo se ralentiza hasta casi detenerse. Algunas solicitudes agotan el tiempo de espera. Otras devuelven un error de cuota que nunca antes había visto.
Su factura de AWS, cuando llega, es la segunda sorpresa.
Si está ejecutando una carga de trabajo de IA en AWS a cualquier escala real, está realizando una planificación de la capacidad de IA, tenga un plan o no. La mayoría de los equipos en etapas iniciales no lo tienen, porque el MVP que les valió sus primeros usuarios no lo necesitaba.
Este artículo es para ese momento. Aquí explicamos qué es la planificación de la capacidad de IA, los muros con los que se topará en AWS a medida que crezca y cómo planificar la capacidad antes de que la próxima ronda de financiación, el pico de tráfico o el límite de cuota decidan por usted.
Resumen: Planificación de la capacidad de IA en AWS
|
¿Qué es la planificación de la capacidad de IA?
La planificación de la capacidad de IA es el proceso de dimensionar el cómputo, la selección de modelos, las cuotas de rendimiento y la infraestructura de soporte para manejar la demanda actual y proyectada de una carga de trabajo de IA, sin sobreaprovisionar el costo o subaprovisionar la fiabilidad. En AWS, eso significa modelar el rendimiento de tokens, la concurrencia de solicitudes y las cuotas de servicio junto con la capacidad tradicional de cómputo y base de datos.
La planificación de capacidad tradicional dimensiona la CPU, la memoria y el disco para una curva de carga conocida. La planificación de la capacidad de IA tiene que modelar tres cosas a la vez: cómo se comporta el modelo bajo carga, cuántos tokens consume cada solicitud y cómo las cuotas de servicio de AWS lo limitan mucho antes de que lo haga su hardware.
Esa última parte es lo que la mayoría de los equipos pasan por alto. Puede tener capacidad de sobra en todas las dimensiones que aparecen en un panel de CloudWatch y aun así ser limitado porque alcanzó un límite de tokens por cuenta en un servicio gestionado.
Por qué la planificación de la capacidad de IA rompe la mayoría de las infraestructuras de startups
La infraestructura que lo llevó a sus primeros mil usuarios probablemente fue construida para la creación de prototipos, no para la capacidad. Tres cosas hacen que las cargas de trabajo de IA sean especialmente difíciles de planificar la capacidad a posteriori.
La inferencia es intermitente y sensible a la concurrencia. Una sola solicitud parece rápida en las pruebas. Cincuenta solicitudes concurrentes contra el mismo punto final pueden ejecutarse a una fracción de esa velocidad, porque la memoria de la GPU, el procesamiento por lotes y la cola cambian las matemáticas.
Las cuotas basadas en tokens se alcanzan antes que la CPU. En servicios gestionados como Amazon Bedrock, su cuenta tiene límites de solicitudes por minuto (RPM) y tokens por minuto (TPM) por modelo. Las cuotas predeterminadas están ajustadas para la evaluación, no para el tráfico de producción, y las alcanza mucho antes de que sus servidores sientan cualquier tensión.
Los costos escalan de forma no lineal. El tamaño del prompt, la longitud de la salida y la elección del modelo multiplican la factura. Un pequeño aumento en la longitud promedio del prompt, multiplicado en cada solicitud, puede cambiar su factura mensual en un 30% o más sin ningún cambio en el número de usuarios, razón por la cual la optimización continua de costos de AWS para cargas de trabajo de IA es ahora imprescindible.
Cuando los tres se combinan, la carga de trabajo que funcionaba bien el trimestre pasado comienza a fallar de maneras que su monitoreo no fue diseñado para detectar.
Los cuatro muros de capacidad que se encuentra en AWS
Cada muro tiene un síntoma específico y una solución específica, y la mayoría de los equipos los encuentran en el mismo orden a medida que crecen.
Una breve nota primero: estos muros no son teóricos. Aparecen en el tráfico de producción real, a menudo semanas después de un lanzamiento o una nueva característica, y tienden a agravarse. Chocar contra el muro de cuota oculta el muro de concurrencia, y una vez que soluciona la concurrencia, el panorama de costos se convierte en la nueva restricción. La forma más rápida de planificar la capacidad es saber a qué muro está más cerca en este momento.
El muro de cuota
Síntoma: las solicitudes comienzan a devolver ThrottlingException o errores de capacidad, aunque la CPU y la memoria no estén cerca de la saturación.
Lo que está sucediendo: ha alcanzado su cuota de nivel de servicio para el servicio de AWS que está utilizando. En Bedrock, las cuotas predeterminadas por cuenta son de alrededor de 800 RPM y 600,000 TPM en un modelo como Llama 3.3 70B Instruct. En las propias pruebas de rendimiento de Avahi, alcanzar 6,000 RPM y 36 millones de TPM requirió cuotas elevadas concedidas especialmente que no son automáticas.
Solución: identifique su cuota vinculante por servicio y modelo, luego solicite aumentos a través del Soporte de AWS mucho antes de necesitarlos. Las aprobaciones de cuotas de producción pueden llevar tiempo.
El muro de concurrencia
Síntoma: la latencia por solicitud es buena de forma aislada, pero la latencia de cola aumenta drásticamente a medida que aumentan las solicitudes concurrentes.
En las pruebas de Avahi, los tokens por segundo en Llama 3.3 70B Instruct oscilaron entre aproximadamente 135 con baja concurrencia y aproximadamente 119 con concurrencia 50 con prompts pequeños. Con prompts grandes, la misma carga de trabajo entregó casi la mitad del rendimiento de los prompts pequeños con concurrencia 50.
Solución: realice pruebas de estrés a los niveles de concurrencia que realmente espera, no al promedio. Dimensionar correctamente los modelos para cada tarea y enrutar el trabajo simple a modelos más pequeños para que el modelo grande no sea el cuello de botella.
El muro de costos
Síntoma: la factura de AWS crece más rápido que su número de usuarios activos.
Esto generalmente significa que el tamaño de sus prompts, la lógica de reintentos o la elección del modelo están realizando más trabajo por solicitud del necesario. El costo de la IA escala con los tokens y el tamaño del modelo, no con las solicitudes, por lo que un aumento del 20% en la longitud promedio del contexto es un aumento del 20% en el gasto.
Solución: ajuste los prompts, almacene en caché las solicitudes repetidas, procese por lotes donde pueda y dimensione correctamente los modelos por tarea. El trabajo de costos para las cargas de trabajo de IA generalmente comienza con el enrutamiento del modelo antes que la infraestructura.
El muro de latencia
Síntoma: el tiempo hasta el primer token (TTFT) se mantiene estable durante un tiempo, luego se degrada drásticamente con una mayor concurrencia, especialmente para prompts grandes.
Solución: limite el tamaño del contexto, transmita la salida donde el flujo de cara al usuario lo permita y utilice el autoescalado que agrega capacidad antes de la demanda en lugar de después.
Cómo planificar la capacidad de IA en AWS (un enfoque práctico)
No existe un número de capacidad universal. Existe, en cambio, un proceso medido que puede ejecutar en su propia carga de trabajo.
- Establezca una línea de base para una sola solicitud. Mida el tiempo hasta el primer token, el tiempo hasta el último token, los tokens por segundo y el costo por solicitud en un prompt representativo. Este es su punto de referencia.
- Realice pruebas de estrés bajo concurrencia. Ejecute el mismo prompt con 1, 5, 10, 25 y 50 solicitudes concurrentes. Capture la latencia p50, p95 y p99 en cada nivel. La brecha entre p50 y p99 es donde los usuarios sienten el dolor.
- Asigne las cargas de trabajo a la primitiva de escalado de AWS adecuada. Las solicitudes web sin estado se ajustan a Lambda o Fargate. Los trabajos por lotes de larga duración se ajustan a ECS con autoescalado. La inferencia personalizada se ajusta a los puntos finales de SageMaker con autoescalado gestionado. Los modelos fundacionales se ajustan a Amazon Bedrock con atención a las cuotas.
- Solicite aumentos de cuota antes de necesitarlos. Identifique su cuota vinculante por modelo y servicio, calcule el límite de producción que espera y presente la solicitud de aumento semanas antes del lanzamiento, no el día en que salga en vivo.
- Agregue las primitivas de escalado adecuadas en la capa correcta. Grupos de autoescalado para EC2, seguimiento de objetivos en balanceadores de carga de aplicaciones, escalado predictivo en métricas de CloudWatch, almacenamiento en caché en la capa de aplicación y limitación de velocidad en la puerta de enlace de API.
Hecho en este orden, pasará de adivinar a tener un plan documentado que puede defender en una reunión de la junta directiva o en una revisión de seguridad.
¿Qué servicios de AWS escalan automáticamente (y cuáles no)?
Una razón común por la que los planes de capacidad fallan es tratar cada servicio de AWS como si escalara de la misma manera. No lo hacen.
| Servicio de AWS | ¿Escala automáticamente? | Qué saber |
|---|---|---|
|
AWS Lambda |
Sí |
Escala a miles de ejecuciones concurrentes; observe los límites de concurrencia de la cuenta |
|
AWS Fargate (ECS) |
Sí, con autoescalado de servicio configurado |
Seguimiento de objetivos en CPU, memoria o métricas personalizadas |
|
Aurora Serverless v2 |
Sí |
Las unidades de capacidad escalan hacia arriba y hacia abajo con la carga |
|
Amazon Bedrock |
Gestionado, pero limitado por cuota |
No hay instancias para escalar; las cuotas de RPM y TPM son el límite |
|
Puntos finales de SageMaker |
Con políticas de autoescalado |
Los puntos finales en tiempo real necesitan seguimiento de objetivos o escalado programado configurado |
|
Amazon EC2 |
Solo con grupos de autoescalado |
Defina plantillas de lanzamiento, capacidad mínima/máxima/deseada y políticas de escalado |
|
S3, DynamoDB bajo demanda |
Sí |
Prácticamente ilimitado para cargas de trabajo típicas |
¿Puede usar el autoescalado sin un balanceador de carga? Sí. Los grupos de autoescalado pueden escalar en cualquier métrica de CloudWatch: profundidad de cola de SQS, métricas de aplicaciones personalizadas o acciones programadas. Los balanceadores de carga son comunes porque la mayoría del tráfico web utiliza el seguimiento de objetivos en el recuento de solicitudes o el tiempo de respuesta, pero no son un requisito.
La conclusión: elija la primitiva de escalado que se ajuste a cada capa de su infraestructura de IA, y no asuma que «gestionado» significa «infinitamente escalable».
Cómo usar la IA para la planificación de la capacidad
Hay una meta-versión de este problema que vale la pena señalar, porque aparece en las búsquedas.
Puede usar la IA para pronosticar la demanda de su propia carga de trabajo. Los LLM pueden leer registros de tráfico históricos y proponer políticas de autoescalado. Los modelos de pronóstico pueden predecir patrones de carga diarios y semanales a partir de métricas de CloudWatch, lo que alimenta el escalado predictivo. Las herramientas de prueba de carga impulsadas por IA pueden generar perfiles de tráfico realistas en lugar de scripts estáticos.
El enfoque honesto: la IA le ayuda a modelar el comportamiento de su IA, pero no reemplaza las pruebas de línea de base. Todavía necesita mediciones reales de su propia carga de trabajo antes de que cualquier modelo pueda pronosticarla de manera útil. Use la IA para comprimir el ciclo de análisis, no para omitir el paso de medición.
Resultado real: Vela Health pasa de MVP a escala de pacientes en 5 semanas
Vela Health es una startup de salud digital cuya configuración de AWS había crecido orgánicamente. Sus cargas de trabajo de IA se ejecutaban en OpenAI con ChromaDB y FAISS para la búsqueda vectorial, sin separación de entornos y sin una línea de base de capacidad formal. Funcionó para el desarrollo. No iba a sobrevivir a un lanzamiento de cara al paciente.
Avahi entregó la graduación completa en cinco semanas.
- Establecimiento de una zona de aterrizaje de múltiples cuentas con entornos separados
- Implementación de CI/CD a través de GitHub Actions con OIDC y cero credenciales codificadas
- Uso de ECS Fargate para el backend, RDS MySQL y ElastiCache Redis para datos y colas, y Secrets Manager para secretos
- Migración de cargas de trabajo de OpenAI a Amazon Bedrock y reemplazo de ChromaDB y FAISS con OpenSearch KNN
El resultado: una plataforma AWS segura y escalable lista para pacientes reales, con primitivas de autoescalado donde Vela Health las necesitaba y una infraestructura que ya no dependía del conocimiento tribal de un solo ingeniero.
Esa es la diferencia entre un MVP que le consigue usuarios e infraestructura que le permite mantenerlos.
Lea el estudio de caso completo →
Resultado real: Healthi adjudica reclamaciones en menos de un minuto con IA agéntica 
Healthi es una compañía de tecnología de seguros que procesa reclamaciones a un ritmo que la revisión manual no puede igualar. El desafío de capacidad no era solo el volumen, era la latencia bajo volumen: las decisiones de reclamaciones debían llegar en menos de un minuto, siempre, incluso cuando las tasas de solicitud aumentaban.
Avahi diseñó un flujo de trabajo de IA agéntica en AWS que ofrece adjudicación en tiempo real mientras mantiene los costos de picos de carga bajo control.
El resultado: decisiones de reclamaciones en menos de un minuto, en una arquitectura que absorbe los picos de tráfico sin que cada pico aparezca como una partida en la factura.
Así es como se ve la planificación de la capacidad de IA en la práctica para una carga de trabajo en tiempo real.
Lea el estudio de caso completo →
Dónde fallan silenciosamente los planes de capacidad de IA
Una breve lista de patrones que aparecen en casi todas las auditorías que realiza Avahi.
- Planificar para promedios, no para p99. Su usuario promedio está bien. El percentil 99 es el que se da de baja.
- Ignorar las cuotas de TPM y RPM. El límite de capacidad reside en el nivel del modelo, no en el nivel de cómputo.
- Elegir el modelo primero, la capacidad después. Los modelos de frontera son caros a escala, y el modelo más barato que cumple con el estándar de calidad suele ganar en economía unitaria.
- Sin capa de caché. Las solicitudes idénticas repetidas no deberían pagar por la inferencia dos veces.
- Sin limitación de velocidad. Un cliente que se comporta mal o una ejecución de bot puede agotar su cuota diaria en una hora.
- Autoescalado sin grupos de recursos precalentados para cargas de trabajo sensibles al arranque en frío. Escalar horizontalmente solo es útil si la nueva capacidad está lista para cuando llega el tráfico.
La mayoría de estos son fáciles de solucionar una vez que sabe dónde buscar. Lo difícil es encontrarlos antes de que ellos lo encuentren a usted.
Dónde encaja la financiación de AWS
A través de nuestra asociación con AWS, el trabajo para endurecer el modelo de capacidad de una carga de trabajo de IA a menudo puede ser financiado. Las empresas elegibles pueden recibir una PoC financiada dependiendo del proyecto.
La forma de bajo riesgo de empezar es una PoC acotada que se dirija primero al mayor cuello de botella de capacidad, para que vea el resultado en métricas de carga de trabajo reales antes de comprometerse con una construcción más amplia.
Planifique su capacidad de IA en AWS con Avahi
La planificación de la capacidad de IA es uno de esos problemas que es invisible hasta que se vuelve urgente. La solución es sencilla: mida su carga de trabajo, asígnela a las primitivas de AWS adecuadas y endurezca la capa que falla primero.
En Avahi hacemos esto como un Socio de Servicios de Nivel Premier de AWS con seis Competencias de AWS, incluyendo IA Generativa y Migración. A través de nuestra asociación con AWS, gran parte del trabajo puede ser financiado.
Comience con una PoC acotada para planificar y endurecer la capacidad de su carga de trabajo de IA en AWS. Las empresas elegibles pueden recibir una PoC financiada dependiendo de su proyecto.
Preguntas frecuentes sobre la planificación y escalado de la capacidad de IA en AWS
¿Cómo se autoescala en AWS?
Se define un grupo de autoescalado para EC2 o autoescalado de servicio para ECS, Fargate, Lambda o SageMaker, y luego se adjuntan políticas de escalado. Las políticas comunes incluyen el seguimiento de objetivos (mantener una métrica en un valor objetivo), el escalado por pasos (reaccionar a los umbrales superados) y el escalado programado (carga anticipada). Cada política utiliza métricas de CloudWatch como disparador.
¿Qué servicios de AWS pueden escalar automáticamente sin intervención?
Lambda, Fargate, Aurora Serverless v2, DynamoDB bajo demanda y S3 escalan automáticamente sin pasos de capacidad manuales. EC2, los puntos finales de SageMaker y ECS necesitan autoescalado configurado. Bedrock es gestionado pero está limitado por cuotas de RPM y TPM por cuenta, por lo que escala dentro de sus límites y no más allá de ellos.
¿Cuáles son los desafíos de escalar la IA?
Tres cosas hacen que las cargas de trabajo de IA sean más difíciles de escalar que el cómputo tradicional: la inferencia es intermitente y sensible a la concurrencia, las cuotas basadas en tokens restringen el rendimiento a nivel del modelo, y los costos crecen de forma no lineal con el tamaño del prompt y la elección del modelo. Planificar para promedios en lugar de la latencia p99 es el error más común.
¿Podemos usar el autoescalado sin un balanceador de carga?
Sí. Los grupos de autoescalado pueden escalar en cualquier métrica de CloudWatch, incluyendo la profundidad de la cola de SQS, métricas de aplicaciones personalizadas o un programa. Los balanceadores de carga son comunes para el tráfico web porque el seguimiento de objetivos en el recuento de solicitudes o el tiempo de respuesta es conveniente, pero no son necesarios para que el autoescalado funcione.
¿Cuánto tiempo se tarda en rediseñar una carga de trabajo de IA para escalar en AWS?
Depende del punto de partida y del alcance, pero una construcción enfocada que se dirija al mayor cuello de botella de capacidad suele ser cuestión de semanas en lugar de meses en AWS, porque la mayor parte del trabajo pesado son servicios gestionados en lugar de infraestructura personalizada. Vela Health, por ejemplo, completó una graduación completa a producción en cinco semanas.
¿Puede Avahi financiar el trabajo para escalar mi carga de trabajo de IA en AWS?
Sí, potencialmente. Como Socio de Servicios de Nivel Premier de AWS, Avahi puede financiar una prueba de concepto (PoC) acotada que aborde su cuello de botella de escalado de mayor prioridad. Las empresas elegibles pueden recibir una PoC financiada dependiendo del proyecto.
