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 del modelo, las cuotas de rendimiento y la infraestructura de soporte para gestionar la demanda actual y proyectada de una carga de trabajo de IA, sin sobredimensionar los costes ni infradimensionar 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 le limitan mucho antes que su hardware.
Esa última parte es la que la mayoría de los equipos pasan por alto. Puede tener capacidad de sobra en cada dimensión que aparece en un panel de CloudWatch y, aun así, sufrir una limitación de tráfico porque ha alcanzado 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 las startups
La infraestructura que le llevó a sus primeros mil usuarios probablemente fue construida para el prototipado, no para la capacidad. Tres factores hacen que las cargas de trabajo de IA sean especialmente difíciles de planificar a posteriori.
La inferencia es irregular y sensible a la concurrencia. Una sola solicitud parece rápida en las pruebas. Cincuenta solicitudes concurrentes contra el mismo punto de enlace pueden ejecutarse a una fracción de esa velocidad, porque la memoria de la GPU, el procesamiento por lotes y el encolado cambian el cálculo.
Las cuotas basadas en tokens se alcanzan antes que las de 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 se alcanzan mucho antes de que sus servidores sientan cualquier tensión.
Los costes 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 media del prompt, multiplicado por 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 de costes de AWS continua para las cargas de trabajo de IA es ahora fundamental.
Cuando los tres factores se combinan, la carga de trabajo que funcionaba bien el trimestre pasado empieza a fallar de formas que su monitorización no estaba preparada para detectar.
Los cuatro muros de capacidad con los que chocará en AWS
Cada muro tiene un síntoma específico y una solución específica, y la mayoría de los equipos chocan con ellos aproximadamente en el mismo orden a medida que crecen.
Una breve nota previa: estos muros no son teóricos. Aparecen en el tráfico de producción real, a menudo a las pocas semanas de un lanzamiento o de una nueva función, y tienden a acumularse. Chocar con el muro de la cuota oculta el muro de la concurrencia, y una vez que soluciona la concurrencia, el panorama de los costes 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 la cuota
Síntoma: las solicitudes comienzan a devolver ThrottlingException o errores de capacidad, a pesar de que la CPU y la memoria están lejos de estar saturadas.
Qué está ocurriendo: se ha topado con su cuota de nivel de servicio para el servicio de AWS que está utilizando. En Bedrock, las cuotas predeterminadas por cuenta son de unas 800 RPM y 600.000 TPM en un modelo como Llama 3.3 70B Instruct. En las propias pruebas de rendimiento de Avahi, llegar a 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, y luego solicite aumentos a través de AWS Support mucho antes de necesitarlos. Las aprobaciones de cuotas de producción pueden llevar tiempo.
El muro de la concurrencia
Síntoma: la latencia por solicitud es correcta de forma aislada, pero la latencia de cola (tail latency) aumenta drásticamente a medida que suben las solicitudes concurrentes.
En las pruebas de Avahi, los tokens por segundo en Llama 3.3 70B Instruct oscilaron entre unos 135 con baja concurrencia y aproximadamente 119 con una concurrencia de 50 con prompts pequeños. Con prompts grandes, la misma carga de trabajo ofreció casi la mitad del rendimiento que con prompts pequeños con una concurrencia de 50.
Solución: realice pruebas de estrés a los niveles de concurrencia que realmente espera, no a la media. Dimensione adecuadamente los modelos para cada tarea y derive el trabajo sencillo a modelos más pequeños para que el modelo grande no sea el punto de estrangulamiento.
El muro del coste
Síntoma: la factura de AWS crece más rápido que su número de usuarios activos.
Esto suele significar 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 coste 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 media del contexto supone un aumento del 20 % en el gasto.
Solución: ajuste los prompts, almacene en caché las solicitudes repetidas, procese por lotes donde sea posible y dimensione adecuadamente los modelos por tarea. El trabajo de costes para las cargas de trabajo de IA suele comenzar con el enrutamiento de modelos antes que con la infraestructura.
El muro de la latencia
Síntoma: el tiempo hasta el primer token (TTFT) se mantiene estable durante un tiempo, pero luego se degrada bruscamente con una mayor concurrencia, especialmente para prompts grandes.
Solución: limite el tamaño del contexto, utilice streaming para la salida donde el flujo de cara al usuario lo permita y emplee un autoescalado que añada 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 base para una sola solicitud. Mida el tiempo hasta el primer token, el tiempo hasta el último token, los tokens por segundo y el coste 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 problema.
- Asigne las cargas de trabajo a la primitiva de escalado de AWS adecuada. Las solicitudes web sin estado encajan en Lambda o Fargate. Los trabajos por lotes de larga duración encajan en ECS con autoescalado. La inferencia personalizada encaja en los puntos de enlace de SageMaker con autoescalado gestionado. Los modelos fundacionales encajan en Amazon Bedrock prestando atención a las cuotas.
- Solicite aumentos de cuota antes de necesitarlos. Identifique su cuota vinculante por modelo y servicio, calcule el techo de producción que espera y presente la solicitud de aumento semanas antes del lanzamiento, no el día de la puesta en marcha.
- Añada las primitivas de escalado adecuadas en la capa correcta. Grupos de Auto Scaling para EC2, seguimiento de objetivos en equilibradores de carga de aplicaciones, escalado predictivo en métricas de CloudWatch, almacenamiento en caché en la capa de aplicación y limitación de tasa en el API gateway.
Hecho en este orden, pasará de las suposiciones a un plan documentado que podrá 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 es así.
| Servicio de AWS | ¿Escala automáticamente? | Qué debe saber |
|---|---|---|
|
AWS Lambda |
Sí |
Escala a miles de ejecuciones concurrentes; vigile los límites de concurrencia de la cuenta |
|
AWS Fargate (ECS) |
Sí, con el autoescalado del 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 cuotas |
No hay instancias que escalar; las cuotas de RPM y TPM son el techo |
|
Puntos de enlace de SageMaker |
Con políticas de autoescalado |
Los puntos de enlace en tiempo real necesitan un seguimiento de objetivos o un escalado programado configurado |
|
Amazon EC2 |
Solo con grupos de Auto Scaling |
Defina plantillas de lanzamiento, capacidad mínima/máxima/deseada y políticas de escalado |
|
S3, DynamoDB on-demand |
Sí |
Efectivamente ilimitado para cargas de trabajo típicas |
¿Se puede usar Auto Scaling sin un equilibrador de carga? Sí. Los grupos de Auto Scaling pueden escalar basándose en cualquier métrica de CloudWatch: profundidad de la cola SQS, métricas de aplicación personalizadas o acciones programadas. Los equilibradores 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 utilizar la IA para la planificación de la capacidad
Hay una versión meta de este problema que vale la pena señalar, porque aparece en las búsquedas.
Puede utilizar 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 las métricas de CloudWatch, lo que alimenta el escalado predictivo. Las herramientas de pruebas de carga impulsadas por IA pueden generar perfiles de tráfico realistas en lugar de scripts estáticos.
El planteamiento honesto: la IA le ayuda a modelar el comportamiento de su IA, pero no sustituye a las pruebas de línea base. Sigue necesitando mediciones reales de su propia carga de trabajo antes de que cualquier modelo pueda pronosticarla de forma útil. Utilice la IA para comprimir el ciclo de análisis, no para saltarse el paso de la 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 de forma orgánica. Sus cargas de trabajo de IA se ejecutaban en OpenAI con ChromaDB y FAISS para la búsqueda vectorial, sin separación de entornos ni una línea base de capacidad formal. Funcionaba para el desarrollo. No iba a sobrevivir a un lanzamiento orientado a pacientes.
Avahi completó 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 las cargas de trabajo de OpenAI a Amazon Bedrock y sustitución de ChromaDB y FAISS por OpenSearch KNN
El resultado: una plataforma de 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 y una infraestructura que le permite mantenerlos.
Lea el caso de estudio completo →
Resultado real: Healthi adjudica reclamaciones en menos de un minuto con IA agéntica 
Healthi es una empresa 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, sino la latencia bajo volumen: las decisiones sobre las reclamaciones debían llegar en menos de un minuto, siempre, incluso cuando las tasas de solicitudes se disparaban.
Avahi diseñó un flujo de trabajo de IA agéntica en AWS que ofrece adjudicación en tiempo real mientras mantiene bajo control los costes de carga máxima.
El resultado: decisiones sobre reclamaciones en menos de un minuto, sobre una arquitectura que absorbe los picos de tráfico sin que cada pico aparezca como una partida individual en la factura.
Así es como se ve en la práctica la planificación de la capacidad de IA para una carga de trabajo en tiempo real.
Lea el caso de estudio 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 va.
- Ignorar las cuotas de TPM y RPM. El techo de capacidad reside en el nivel del modelo, no en el nivel de cómputo.
- Elegir primero el modelo y después la capacidad. Los modelos de vanguardia son caros a escala, y el modelo más barato que cumpla con el estándar de calidad suele ganar en economía unitaria.
- Sin capa de almacenamiento en caché. Las solicitudes idénticas repetidas no deberían pagar por la inferencia dos veces.
- Sin limitación de tasa. Un cliente con mal comportamiento o la ejecución de un bot pueden agotar su cuota diaria en una hora.
- Autoescalado sin grupos de instancias preparadas (warm pools) 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 problemas son rápidos de solucionar una vez que se sabe dónde mirar. Lo difícil es encontrarlos antes de que ellos le encuentren a usted.
Dónde encaja la financiación de AWS
A través de nuestra asociación con AWS, el trabajo para reforzar 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 empezar con bajo riesgo 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 refuerce la capa que se rompa primero.
En Avahi hacemos esto como AWS Premier Tier Services Partner 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 reforzar 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 de la capacidad de IA y el escalado en AWS
¿Cómo se realiza el autoescalado en AWS?
Se define un grupo de Auto Scaling para EC2 o un 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 ante el incumplimiento de umbrales) y el escalado programado (carga anticipada). Cada política utiliza métricas de CloudWatch como activador.
¿Qué servicios de AWS pueden escalar automáticamente sin intervención?
Lambda, Fargate, Aurora Serverless v2, DynamoDB on-demand y S3 escalan automáticamente sin pasos de capacidad manuales. EC2, los puntos de enlace de SageMaker y ECS necesitan una configuración de autoescalado. Bedrock es gestionado pero está limitado por las cuotas de RPM y TPM por cuenta, por lo que escala dentro de sus límites y no más allá.
¿Cuáles son los desafíos de escalar la IA?
Tres factores hacen que las cargas de trabajo de IA sean más difíciles de escalar que el cómputo tradicional: la inferencia es irregular y sensible a la concurrencia, las cuotas basadas en tokens limitan el rendimiento a nivel de modelo y los costes crecen de forma no lineal con el tamaño del prompt y la elección del modelo. Planificar para promedios en lugar de para la latencia p99 es el error más común.
¿Podemos usar Auto Scaling sin un equilibrador de carga?
Sí. Los grupos de Auto Scaling pueden escalar basándose en cualquier métrica de CloudWatch, incluyendo la profundidad de la cola SQS, métricas de aplicación personalizadas o una programación. Los equilibradores 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 Auto Scaling funcione.
¿Cuánto tiempo se tarda en rediseñar una carga de trabajo de IA para que escale 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 lo realizan los servicios gestionados en lugar de la infraestructura personalizada. Vela Health, por ejemplo, completó una transición completa a un estado listo para producción en cinco semanas.
¿Puede Avahi financiar el trabajo para escalar mi carga de trabajo de IA en AWS?
Sí, potencialmente. Como AWS Premier Tier Services Partner, Avahi puede financiar una prueba de concepto acotada que aborde primero su cuello de botella de escalado de mayor prioridad. Las empresas elegibles pueden recibir una PoC financiada dependiendo del proyecto.
