Hoy en día, muchas empresas están trabajando para reducir sus emisiones de CO₂. En entornos cloud, esto se traduce en la creación de arquitecturas más ligeras y sostenibles. Desde 2021, AWS incluye un pilar de Sostenibilidad en su Well-Architected Framework, centrado en reducir el consumo energético y mejorar la eficiencia. Este objetivo encaja perfectamente con los principios de FinOps. Recientemente, Devoteam publicó un artículo titulado “Frugal AI: How to Rethink Intelligence in a Resource-Hungry Era”, que me inspiró a profundizar en los aspectos prácticos de construcción desde una perspectiva DevOps.
Con la irrupción de ChatGPT y otros grandes modelos de lenguaje, muchas empresas están desarrollando sus propios servicios de chatbot, tanto para clientes como para uso interno. Como consultor DevOps especializado en AWS, me gustaría compartir algunos consejos prácticos para construir un chatbot interno de forma sostenible. Un enfoque de
Elegir el modelo adecuado
Comparar el consumo energético real de distintos chatbots no es sencillo. Aun así, hay algunos puntos clave que conviene tener en cuenta:
- Sabemos que el mayor consumo energético se concentra en las fases de entrenamiento e inferencia del modelo. En general, las IA más potentes se entrenan con conjuntos de datos más grandes y consumen más recursos que otras. Por ejemplo, Llama 3.1-8B consume menos que Llama 3.1-405B.
- Por otro lado, las versiones más recientes de los modelos suelen ser más eficientes. Un buen ejemplo es Llama-3.3-70B, que consume menos energía que Llama-3.1-70B.
- Sin embargo, los efectos rebote y la paradoja de Jevons muestran que el aumento en el uso de los LLM puede acabar anulando las mejoras de eficiencia.
En resumen, por lo general es mejor utilizar las versiones más pequeñas de los modelos más recientes y priorizar los Small Language Models (SLM) frente a los Large Language Models (LLM) siempre que sea posible. La pregunta clave es: ¿cuál es el objetivo de tu chatbot?
Por ejemplo, un bot de preguntas frecuentes o un asistente de recomendación de productos funcionará perfectamente con un SLM. En cambio, si necesitas analizar e interpretar textos filosóficos, será necesario un modelo de mayor tamaño. El catálogo de Hugging Face es un excelente recurso para encontrar el modelo que mejor se adapte a tus necesidades.
Por último, no he encontrado ningún estudio que compare de forma exhaustiva todos los LLM. No obstante, todo apunta a que Llama suele consumir menos recursos que ChatGPT. Google Gemini y Mistral AI también afirman tener un consumo inferior al de ChatGPT. Estas consideraciones son clave a la hora de diseñar un chatbot frugal.
Reduce cost on fine-tuning
Este diagrama de Mistral AI muestra que la mayor parte del consumo de agua y de las emisiones de gases de efecto invernadero de la IA generativa provienen del entrenamiento y el fine-tuning de los modelos. Entonces, ¿cuáles son las distintas fases implicadas y cómo podemos minimizar el consumo energético?
Recopilación y limpieza de datos
El entrenamiento de un LLM comienza con un conjunto de datos de texto grande, diverso y de alta calidad. Este proceso incluye la limpieza (eliminación de duplicados para evitar el sobreajuste), el filtrado (eliminación de contenido de baja calidad o tóxico) y la normalización (corrección de codificación, puntuación y uso de mayúsculas antes de tokenizar el texto).
Dicho esto, es posible evitar por completo esta fase de entrenamiento, tan intensiva en consumo energético, utilizando modelos preentrenados en Amazon Bedrock.
Si necesitas entrenar tu propio modelo, utiliza servicios serverless como Glue y Lambda para la recopilación de datos en S3, y EMR, SageMaker Processing Jobs o AWS Batch para las tareas de limpieza. Cuando sea imprescindible usar instancias EC2, opta por spot instances con tipos m7g, que ofrecen una mejor eficiencia energética.
Ten también en cuenta las diferencias regionales: regiones como Irlanda, Estocolmo y París utilizan más energía renovable que Frankfurt o Londres.
Elegir la arquitectura del modelo: Transformer
Esta fase es clave, ya que determina la complejidad de tu modelo a futuro. Como se ha comentado anteriormente, el primer paso es tener claro el objetivo de tu chatbot.
En primer lugar, debes elegir el tipo de arquitectura transformer adecuada. Por lo general, los modelos solo decodificadores (decoder-only) son los más apropiados para IA conversacional, mientras que los modelos encoder-decoder encajan mejor en tareas como traducción o resumen de textos.
A continuación, tendrás que configurar parámetros clave como el número de capas transformer y la longitud máxima de la secuencia de tokens (que define cuánta parte del historial de la conversación tiene en cuenta el chatbot al responder). Estas decisiones influyen directamente tanto en la complejidad del modelo como en su consumo energético.
Para chatbots a gran escala y multidominio, puede ser interesante utilizar una arquitectura Mixture of Experts (MoE). Este enfoque cuenta con un gran número de parámetros, pero solo activa un subconjunto de ellos para cada token, lo que permite que un modelo grande consuma una cantidad de energía similar a la de uno de tamaño medio. Esto reduce de forma significativa el consumo energético por inferencia y por paso de entrenamiento. Eso sí, conviene tener en cuenta que MoE no reduce los requisitos de memoria GPU.
Una vez más, es preferible utilizar modelos preentrenados disponibles en SageMaker JumpStart o en el marketplace de Hugging Face, en lugar de entrenar un modelo desde cero. No obstante, si necesitas entrenar tu propio modelo, valora el uso de arquitecturas decoder-only más pequeñas, como ALiBi o FlashAttention, que gestionan contextos largos de forma más eficiente. Estos enfoques ligeros son especialmente adecuados para una implementación de chatbot frugal.
Preentrenamiento (auto-supervisado)
Esta es la fase con mayor consumo energético, en la que el transformer utiliza aprendizaje no supervisado para analizar los datos con una intervención humana mínima.
Para optimizar la eficiencia computacional durante el entrenamiento, utiliza instancias EC2 P4d o P5 con GPUs NVIDIA, activa SageMaker Managed Spot Training para cargas de trabajo no críticas y recuerda seleccionar una región de AWS con mayor eficiencia energética.
Fine-tuning
En esta fase se adapta un modelo de propósito general a tu caso de uso concreto, entrenándolo con documentos e información propios de la empresa. Importante: nunca incluyas datos personales o sensibles en este proceso.
Puedes evitar todos los pasos anteriores utilizando modelos preentrenados disponibles en Amazon Bedrock. Para minimizar los costes de fine-tuning, una muy buena opción es emplear Retrieval-Augmented Generation (RAG). RAG resulta especialmente eficaz para mantener los modelos actualizados cuando los datos cambian, ya que permite actualizaciones continuas sin recurrir a costosos ciclos de reentrenamiento, manteniendo el modelo más pequeño y eficiente en costes. Otra alternativa sencilla es mejorar el rendimiento del modelo añadiendo dinámicamente contexto relevante a los prompts.
Si necesitas reentrenar un foundation model (FM) grande ya existente, utiliza SageMaker HyperPod.
También puedes implementar un flujo de aprendizaje continuo: cachear las consultas de los usuarios con API Gateway, vectorizarlas con Lambda, almacenarlas en DynamoDB u OpenSearch y devolverlas a tu LLM en Bedrock. Este enfoque encaja perfectamente con los principios de un chatbot frugal, al maximizar la eficiencia.
Refuerzo y benchmarking
En esta última fase puedes aplicar Reinforcement Learning from Human Feedback (RLHF) para refinar el modelo y realizar pruebas y comparativas.
Para mantener las evaluaciones bajo control, automatiza los pipelines de evaluación utilizando workflows serverless, como Step Functions y Lambda, y utiliza conjuntos de datos representativos para los benchmarks en lugar de ejecutar pruebas exhaustivas.
Desplegar una infraestructura sostenible en AWS
Para una arquitectura de chatbot compacta pero eficiente, esto es lo que recomiendo:
- Amazon CloudFront – Distribución de contenido
- S3 – Hosting web estático
- AWS WAF – Control de tráfico y seguridad
- Application Load Balancer (ALB) – Distribución del tráfico
- ECS – Alojamiento de la lógica conversacional
- DynamoDB – Almacenamiento del historial de conversación
- Bedrock (LLM) – Generación de respuestas
Entonces, ¿cómo podemos maximizar el impacto en sostenibilidad de este diseño?
Estrategia de caché
En primer lugar, como ya hemos visto, Bedrock concentrará gran parte del impacto ambiental. Podemos reducirlo de forma significativa con estrategias de caché.
- Utiliza una caché dentro del servicio —por ejemplo, Valkey (sustituyendo a Redis/ElastiCache) o DynamoDB con TTL— para reutilizar respuestas recientes casi en tiempo real. Combínalo con hashing de respuestas y prompts deterministas para que solicitudes idénticas impacten en la caché. Esto es especialmente eficaz en chatbots tipo FAQ, donde muchas preguntas se repiten.
- Bedrock ya ofrece prompt caching nativo para modelos como Claude y Amazon Nova, lo que permite evitar el reprocesado de tokens de entrada. Esto puede reducir de forma notable los requisitos de cómputo cuando los prompts se repiten.
- También puedes implementar caché a nivel de CloudFront, con TTL más largos para respuestas con plantillas o que se repiten con frecuencia.
Trabajo por lotes cuando sea posible
Para tareas como resúmenes o informes largos, plantéate implementar una cola SQS con un pool de workers con autoescalado. Este enfoque evita desperdiciar tiempo de cómputo por los retrasos de arranque de contenedores y ayuda a garantizar un uso eficiente de los recursos.
Impacto del cómputo
Para optimizar la sostenibilidad:
- Prioriza EC2 Spot frente a On-Demand siempre que sea viable.
- Mejor aún, utiliza Fargate (serverless) en lugar de EC2, salvo que tengas requisitos específicos (por ejemplo, red especializada o acceso a GPU).
- Si usas Fargate, elige Graviton3 (ARM), que ofrece mejor rendimiento por vatio y normalmente también es más rentable.
- Mantén las imágenes de contenedor lo más pequeñas posible para reducir consumo de recursos.
Autoescalado
Configura el autoescalado en función de métricas de negocio como la longitud de la cola de peticiones y las solicitudes LLM pendientes, no solo por CPU y memoria. Mantén la capacidad mínima baja en horas valle para evitar recursos ociosos, garantizando a la vez que el sistema escale rápido ante picos de tráfico.
Red
- Usa VPC endpoints (en lugar de NAT) para S3 y DynamoDB.
- Comprime payloads y prioriza formatos binarios cuando tenga sentido.
WAF
Implementa rate limits, control de bots y reglas gestionadas para bloquear tráfico abusivo y evitar llamadas innecesarias al LLM. Añade cuotas por usuario para un uso equilibrado.
Almacenamiento y retención eficientes
- DynamoDB: usa facturación on-demand y habilita TTL (Time to Live) para limpiar automáticamente historiales antiguos.
- S3: activa Intelligent-Tiering y define lifecycle policies para archivar o eliminar ficheros no utilizados de forma automática.
- Logging: define periodos de retención basados en necesidades reales de observabilidad y cumplimiento; evita conservar logs más tiempo del necesario.
Bedrock
Observabilidad y control de costes: implementa una monitorización completa de número de peticiones, invocaciones al LLM, consumo de tokens y cache hit rate. Considera herramientas externas como LiteLLM proxy para control de gasto, presupuestos y límites por usuario, o Langfuse para monitorizar, depurar y analizar aplicaciones LLM. Etiqueta todos los recursos para habilitar informes detallados con Cost & Usage Reports y seguimiento con AWS Budgets.
Optimización de tokens: minimiza el tamaño de los tokens de entrada filtrando preguntas previamente y “compactando” el contexto cuando sea posible.
Monitorización de huella de carbono: utiliza la AWS Customer Carbon Footprint Tool para medir la intensidad de carbono por región y seleccionar opciones con menor huella cuando la latencia y el cumplimiento lo permitan. AWS mide la eficiencia con PUE (Power Usage Effectiveness). Como se comentó antes, prioriza regiones como Estocolmo o París frente a Frankfurt o Londres, por su menor huella de carbono.
Conclusión
Por último, recuerda el primer principio de las 5R (Refuse, Reduce, Reuse, Recycle, Rot): Refuse (rechazar). Solo construye un chatbot si realmente lo necesitas. Si decides seguir adelante, espero que este artículo te haya aportado pautas útiles para minimizar el impacto medioambiental de tu chatbot. Siguiendo estas buenas prácticas, podrás crear un chatbot verdaderamente frugal, que responda a las necesidades de tu negocio respetando tanto el presupuesto como el entorno.