{"id":801707,"date":"2025-10-20T14:44:00","date_gmt":"2025-10-20T12:44:00","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/frugal-chatbot-on-aws\/"},"modified":"2025-12-23T11:09:19","modified_gmt":"2025-12-23T10:09:19","slug":"chatbot-frugal-en-aws","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/es\/expert-view\/chatbot-frugal-en-aws\/","title":{"rendered":"C\u00f3mo entrenar y alojar un chatbot de forma eficiente en costes en AWS"},"content":{"rendered":"\n

Hoy en d\u00eda, muchas empresas est\u00e1n trabajando para reducir sus emisiones de CO\u2082. En entornos cloud, esto se traduce en la creaci\u00f3n de arquitecturas m\u00e1s ligeras y sostenibles. Desde 2021, AWS incluye un pilar de Sostenibilidad<\/strong> en su Well-Architected Framework<\/strong>, centrado en reducir el consumo energ\u00e9tico y mejorar la eficiencia. Este objetivo encaja perfectamente con los principios de FinOps<\/strong>. Recientemente, Devoteam public\u00f3 un art\u00edculo titulado \u201cFrugal AI: How to Rethink Intelligence in a Resource-Hungry Era\u201d<\/em>, que me inspir\u00f3 a profundizar en los aspectos pr\u00e1cticos de construcci\u00f3n desde una perspectiva DevOps.<\/p>\n\n\n\n

Con la irrupci\u00f3n de ChatGPT y otros grandes modelos de lenguaje, muchas empresas est\u00e1n desarrollando sus propios servicios de chatbot, tanto para clientes como para uso interno. Como consultor DevOps especializado en AWS, me gustar\u00eda compartir algunos consejos pr\u00e1cticos para construir un chatbot interno de forma sostenible. Un enfoque de<\/p>\n\n\n\n

Elegir el modelo adecuado<\/h2>\n\n\n\n

Comparar el consumo energ\u00e9tico real de distintos chatbots no es sencillo. Aun as\u00ed, hay algunos puntos clave que conviene tener en cuenta:<\/p>\n\n\n\n

    \n
  1. Sabemos que el mayor consumo energ\u00e9tico se concentra en las fases de entrenamiento<\/strong> e inferencia<\/strong> del modelo. En general, las IA m\u00e1s potentes se entrenan con conjuntos de datos m\u00e1s grandes y consumen m\u00e1s recursos que otras. Por ejemplo, Llama 3.1-8B<\/strong> consume menos que Llama 3.1-405B<\/strong>.<\/li>\n\n\n\n
  2. Por otro lado, las versiones m\u00e1s recientes de los modelos suelen ser m\u00e1s eficientes. Un buen ejemplo es Llama-3.3-70B<\/strong>, que consume menos energ\u00eda que Llama-3.1-70B<\/strong>.<\/li>\n\n\n\n
  3. Sin embargo, los efectos rebote<\/strong> y la paradoja de Jevons<\/strong> muestran que el aumento en el uso de los LLM puede acabar anulando las mejoras de eficiencia.<\/li>\n<\/ol>\n\n\n\n

    En resumen, por lo general es mejor utilizar las versiones m\u00e1s peque\u00f1as de los modelos m\u00e1s recientes y priorizar los Small Language Models (SLM)<\/strong> frente a los Large Language Models (LLM)<\/strong> siempre que sea posible. La pregunta clave es: \u00bfcu\u00e1l es el objetivo de tu chatbot?<\/strong>
    Por ejemplo, un bot de preguntas frecuentes o un asistente de recomendaci\u00f3n de productos funcionar\u00e1 perfectamente con un SLM. En cambio, si necesitas analizar e interpretar textos filos\u00f3ficos, ser\u00e1 necesario un modelo de mayor tama\u00f1o. El cat\u00e1logo de Hugging Face<\/strong> es un excelente recurso para encontrar el modelo que mejor se adapte a tus necesidades.<\/p>\n\n\n\n

    Por \u00faltimo, no he encontrado ning\u00fan estudio que compare de forma exhaustiva todos los LLM. No obstante, todo apunta a que Llama<\/strong> suele consumir menos recursos que ChatGPT<\/strong>. Google Gemini<\/strong> y Mistral AI<\/strong> tambi\u00e9n afirman tener un consumo inferior al de ChatGPT. Estas consideraciones son clave a la hora de dise\u00f1ar un chatbot frugal<\/strong>.<\/p>\n\n\n\n

    Reduce cost on fine-tuning<\/h2>\n\n\n\n

    Este diagrama de Mistral AI<\/strong> muestra que la mayor parte del consumo de agua y de las emisiones de gases de efecto invernadero de la IA generativa<\/strong> provienen del entrenamiento<\/strong> y el fine-tuning<\/strong> de los modelos. Entonces, \u00bfcu\u00e1les son las distintas fases implicadas y c\u00f3mo podemos minimizar el consumo energ\u00e9tico?<\/p>\n\n\n\n

    Recopilaci\u00f3n y limpieza de datos<\/h3>\n\n\n\n

    El entrenamiento de un LLM comienza con un conjunto de datos de texto grande, diverso y de alta calidad. Este proceso incluye la limpieza<\/strong> (eliminaci\u00f3n de duplicados para evitar el sobreajuste), el filtrado<\/strong> (eliminaci\u00f3n de contenido de baja calidad o t\u00f3xico) y la normalizaci\u00f3n<\/strong> (correcci\u00f3n de codificaci\u00f3n, puntuaci\u00f3n y uso de may\u00fasculas antes de tokenizar el texto).<\/p>\n\n\n\n

    Dicho esto, es posible evitar por completo esta fase de entrenamiento, tan intensiva en consumo energ\u00e9tico<\/strong>, utilizando modelos preentrenados en Amazon Bedrock<\/strong>.
    Si necesitas entrenar tu propio modelo, utiliza servicios serverless<\/strong> como Glue<\/strong> y Lambda<\/strong> para la recopilaci\u00f3n de datos en S3<\/strong>, y EMR<\/strong>, SageMaker Processing Jobs<\/strong> o AWS Batch<\/strong> para las tareas de limpieza. Cuando sea imprescindible usar instancias EC2<\/strong>, opta por spot instances<\/strong> con tipos m7g<\/strong>, que ofrecen una mejor eficiencia energ\u00e9tica.<\/p>\n\n\n\n

    Ten tambi\u00e9n en cuenta las diferencias regionales<\/strong>: regiones como Irlanda<\/strong>, Estocolmo<\/strong> y Par\u00eds<\/strong> utilizan m\u00e1s energ\u00eda renovable que Frankfurt<\/strong> o Londres<\/strong>.<\/p>\n\n\n\n

    Elegir la arquitectura del modelo: Transformer<\/h3>\n\n\n\n

    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<\/strong>.<\/p>\n\n\n\n

    En primer lugar, debes elegir el tipo de arquitectura transformer<\/strong> adecuada. Por lo general, los modelos solo decodificadores (decoder-only)<\/strong> son los m\u00e1s apropiados para IA conversacional, mientras que los modelos encoder-decoder<\/strong> encajan mejor en tareas como traducci\u00f3n o resumen de textos.<\/p>\n\n\n\n

    A continuaci\u00f3n, tendr\u00e1s que configurar par\u00e1metros clave como el n\u00famero de capas transformer<\/strong> y la longitud m\u00e1xima de la secuencia de tokens<\/strong> (que define cu\u00e1nta parte del historial de la conversaci\u00f3n tiene en cuenta el chatbot al responder). Estas decisiones influyen directamente tanto en la complejidad del modelo como en su consumo energ\u00e9tico.<\/p>\n\n\n\n

    Para chatbots a gran escala y multidominio, puede ser interesante utilizar una arquitectura Mixture of Experts (MoE)<\/strong>. Este enfoque cuenta con un gran n\u00famero de par\u00e1metros, pero solo activa un subconjunto de ellos para cada token, lo que permite que un modelo grande consuma una cantidad de energ\u00eda similar a la de uno de tama\u00f1o medio. Esto reduce de forma significativa el consumo energ\u00e9tico por inferencia y por paso de entrenamiento. Eso s\u00ed, conviene tener en cuenta que MoE no reduce los requisitos de memoria GPU<\/strong>.<\/p>\n\n\n\n

    Una vez m\u00e1s, es preferible utilizar modelos preentrenados<\/strong> disponibles en SageMaker JumpStart<\/strong> o en el marketplace de Hugging Face<\/strong>, en lugar de entrenar un modelo desde cero. No obstante, si necesitas entrenar tu propio modelo, valora el uso de arquitecturas decoder-only m\u00e1s peque\u00f1as<\/strong>, como ALiBi<\/strong> o FlashAttention<\/strong>, que gestionan contextos largos de forma m\u00e1s eficiente. Estos enfoques ligeros son especialmente adecuados para una implementaci\u00f3n de chatbot frugal<\/strong>.<\/p>\n\n\n\n

    Preentrenamiento (auto-supervisado)<\/h3>\n\n\n\n

    Esta es la fase con mayor consumo energ\u00e9tico<\/strong>, en la que el transformer utiliza aprendizaje no supervisado para analizar los datos con una intervenci\u00f3n humana m\u00ednima.<\/p>\n\n\n\n

    Para optimizar la eficiencia computacional durante el entrenamiento, utiliza instancias EC2 P4d o P5<\/strong> con GPUs NVIDIA<\/strong>, activa SageMaker Managed Spot Training<\/strong> para cargas de trabajo no cr\u00edticas y recuerda seleccionar una regi\u00f3n de AWS con mayor eficiencia energ\u00e9tica<\/strong>.<\/p>\n\n\n\n

    Fine-tuning<\/h3>\n\n\n\n

    En esta fase se adapta un modelo de prop\u00f3sito general a tu caso de uso concreto, entren\u00e1ndolo con documentos e informaci\u00f3n propios de la empresa. Importante:<\/strong> nunca incluyas datos personales o sensibles en este proceso.<\/p>\n\n\n\n

    Puedes evitar todos los pasos anteriores<\/strong> utilizando modelos preentrenados disponibles en Amazon Bedrock<\/strong>. Para minimizar los costes de fine-tuning, una muy buena opci\u00f3n es emplear Retrieval-Augmented Generation (RAG)<\/strong>. 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\u00e1s peque\u00f1o y eficiente en costes. Otra alternativa sencilla es mejorar el rendimiento del modelo a\u00f1adiendo din\u00e1micamente contexto relevante a los prompts<\/em>.<\/p>\n\n\n\n

    Si necesitas reentrenar un foundation model (FM)<\/strong> grande ya existente, utiliza SageMaker HyperPod<\/strong>.<\/p>\n\n\n\n

    Tambi\u00e9n puedes implementar un flujo de aprendizaje continuo<\/strong>: cachear las consultas de los usuarios con API Gateway<\/strong>, vectorizarlas con Lambda<\/strong>, almacenarlas en DynamoDB<\/strong> u OpenSearch<\/strong> y devolverlas a tu LLM en Bedrock<\/strong>. Este enfoque encaja perfectamente con los principios de un chatbot frugal<\/strong>, al maximizar la eficiencia.<\/p>\n\n\n\n

    Refuerzo y benchmarking<\/h3>\n\n\n\n

    En esta \u00faltima fase puedes aplicar Reinforcement Learning from Human Feedback (RLHF)<\/strong> para refinar el modelo y realizar pruebas y comparativas.<\/p>\n\n\n\n

    Para mantener las evaluaciones bajo control, automatiza los pipelines de evaluaci\u00f3n utilizando workflows serverless<\/strong>, como Step Functions<\/strong> y Lambda<\/strong>, y utiliza conjuntos de datos representativos<\/strong> para los benchmarks en lugar de ejecutar pruebas exhaustivas.<\/p>\n\n\n\n

    Desplegar una infraestructura sostenible en AWS<\/h2>\n\n\n\n

    Para una arquitectura de chatbot compacta pero eficiente, esto es lo que recomiendo:<\/p>\n\n\n\n