7 Min. Tiempo de lectura<\/p>\n
La sostenibilidad en la nube se vende principalmente como una estrategia de marketing: logotipo verde, compensaci\u00f3n de CO2, informe de RSC. La discusi\u00f3n interesante se desarrolla en otro lugar. La planificaci\u00f3n consciente del carbono (Carbon-aware Scheduling) desplaza las cargas de trabajo hacia donde la mezcla de energ\u00eda es limpia en ese momento o hacia donde lo ser\u00e1 en el futuro. Esto no es ideolog\u00eda, sino una decisi\u00f3n arquitect\u00f3nica con n\u00fameros concretos, verdaderos compromisos y un grado de madurez que var\u00eda mucho seg\u00fan el patr\u00f3n.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado<\/span>La IA impulsa la nube – y el consumo de energ\u00eda<\/a> \/<\/span> Costos de inferencia de IA en 2026: FinOps para cargas de trabajo de GPU<\/a><\/p>\n Los impulsores son la Fundaci\u00f3n Green Software (fundada en 2021 bajo el paraguas de la Fundaci\u00f3n Linux, con miembros como Accenture, Microsoft, GitHub, Intel) y una serie de proveedores de datos que proporcionan la intensidad de CO2 de la red de manera regional y en tiempo real. La fundaci\u00f3n ha identificado tres palancas en sus patrones: Demand Shifting (Location-Shifting y Time-Shifting) y Demand Shaping. Cada palanca tiene un efecto diferente en las emisiones, la latencia y los costos. Quien conoce las diferencias toma mejores decisiones arquitect\u00f3nicas. Quien las mezcla, obtiene un proyecto de lavado verde con esfuerzo de CI.<\/p>\n Este art\u00edculo clasifica t\u00e9cnicamente los tres patrones. Muestra d\u00f3nde la palanca de CO2 es real, d\u00f3nde sigue siendo peque\u00f1a y qu\u00e9 significa esto pr\u00e1cticamente para los arquitectos de nube hoy en d\u00eda.<\/p>\n La planificaci\u00f3n consciente del carbono es la decisi\u00f3n de cu\u00e1ndo<\/em> y d\u00f3nde<\/em> se ejecuta una carga de trabajo, tomada en funci\u00f3n de una se\u00f1al externa: la intensidad de CO2 de la red el\u00e9ctrica en una regi\u00f3n determinada en un momento espec\u00edfico. La intensidad se expresa en gramos de CO2 equivalente por kilovatio hora. Cuanto mayor es la proporci\u00f3n de energ\u00eda e\u00f3lica y solar, menor es el valor. Cuanto mayor es la proporci\u00f3n de carb\u00f3n o gas, mayor es el valor.<\/p>\n Los servicios como Electricity Maps o WattTime proporcionan la se\u00f1al a trav\u00e9s de API. La granularidad t\u00edpica es de intervalos de 5 minutos o 1 hora. La planificaci\u00f3n en s\u00ed se realiza en el cl\u00faster (a trav\u00e9s de plugins del programador de Kubernetes), en el sistema CI\/CD (GitHub Actions tiene un modo de compilaci\u00f3n consciente del carbono a trav\u00e9s de la integraci\u00f3n con Azure) o en la l\u00f3gica de la aplicaci\u00f3n (marcos de procesamiento por lotes que retrasan el inicio de un trabajo hasta que la intensidad est\u00e9 por debajo de un umbral).<\/p>\n La Green Software Foundation distingue tres patrones pr\u00e1cticos. No son t\u00e9rminos de marketing, sino decisiones arquitect\u00f3nicas claras con diferentes efectos y riesgos.<\/p>\n Fuente: Cat\u00e1logo de patrones de la Green Software Foundation 2024\/2025.<\/p>\n<\/div>\n Location-Shifting traslada un trabajo a una regi\u00f3n con una intensidad de CO2 actualmente m\u00e1s baja. T\u00e9cnicamente, esta es la variante m\u00e1s obvia: los proveedores de cloud tienen muchas regiones y la definici\u00f3n de la carga de trabajo suele ser independiente de la regi\u00f3n. Los grandes hyperscalers ofrecen datos de emisiones regionales como parte de sus exportaciones de facturaci\u00f3n.<\/p>\n El impacto es real porque las redes el\u00e9ctricas en Europa est\u00e1n compuestas de manera muy diferente. Un lote que se ejecuta en una regi\u00f3n con una alta proporci\u00f3n de energ\u00edas renovables causa significativamente menos emisiones que el mismo lote en una regi\u00f3n con una carga base f\u00f3sil. Esto no es un truco contable: la electricidad est\u00e1 ligada a la ubicaci\u00f3n. La mezcla de la red local determina la carga real.<\/p>\n Los l\u00edmites son tangibles. La residencia de datos (DSGVO, regulaci\u00f3n sectorial, contratos con clientes) puede prohibir un traslado a trav\u00e9s de Europa. La latencia aumenta si los datos o los usuarios no est\u00e1n en la regi\u00f3n de destino. Y el tr\u00e1fico de salida entre regiones cuesta dinero – con grandes cantidades de datos, el lado de los costos puede consumir el beneficio de CO2 si no se controla el traslado.<\/p>\n Location-Shifting es m\u00e1s s\u00f3lido donde los datos ya est\u00e1n disponibles de forma multirregional: conjuntos de datos de entrenamiento en almacenamiento de objetos que de todos modos se replican. O cargas de trabajo sin persistencia: c\u00e1lculos por lotes sin estado que solo leen entradas y escriben resultados.<\/p>\n Time-Shifting mantiene la carga de trabajo en su regi\u00f3n, pero retrasa el inicio a una ventana con menor intensidad. El caso t\u00edpico: una compilaci\u00f3n nocturna o un entrenamiento de ML que comienza hoy a las 2 de la ma\u00f1ana porque entonces la proporci\u00f3n de energ\u00eda e\u00f3lica en la red es alta. O que comienza justo a las 4 de la ma\u00f1ana porque la previsi\u00f3n de intensidad actual lo recomienda.<\/p>\n T\u00e9cnicamente, esto suele ser m\u00e1s sencillo que Location-Shifting: no hay efectos de red, no hay preguntas sobre la residencia. Un plugin de programaci\u00f3n o un wrapper de cron basado en sondeo consulta la API de intensidad y activa el trabajo cuando se alcanza el umbral. Proyectos de Kubernetes como el escalador KEDA con conciencia de carbono o el lote de Google Cloud con la bandera de sensibilidad de carbono van exactamente en esta direcci\u00f3n.<\/p>\n El l\u00edmite es la tolerancia a la demora. Una compilaci\u00f3n de CI que espera cuatro horas no bloquea un lanzamiento – pero un trabajo de ingesti\u00f3n de registros que espera seis horas viola los requisitos de cumplimiento (plazos de GDPR, pistas de auditor\u00eda). Quien practique Time-Shifting de manera seria debe definir por carga de trabajo cu\u00e1nto retraso es aceptable. De lo contrario, surge una segunda clase de trabajos \u00abque se ejecutan en alg\u00fan momento\u00bb que nadie depura.<\/p>\n \n”<\/span><\/p>\n La sostenibilidad en la nube se vende la mayor\u00eda de las veces como una presentaci\u00f3n de marketing: logotipo verde, compensaci\u00f3n de CO2, informe de RSC.<\/p>\n<\/blockquote>\n<\/figure>\n Demand-Shaping es el patr\u00f3n m\u00e1s exigente. En lugar de posponer la carga de trabajo, la aplicaci\u00f3n adapta sus necesidades de recursos a la se\u00f1aligen. Ejemplos: un codificador de video elige un preset m\u00e1s d\u00e9bil cuando la intensidad de CO2 es alta, una canalizaci\u00f3n de recomendaciones reduce la profundidad de su modelo, un trabajo de an\u00e1lisis calcula agregados m\u00e1s gruesos.<\/p>\n El encanto: Demand-Shaping tambi\u00e9n funciona para aplicaciones cr\u00edticas de latencia que no pueden esperar ni migrar. El precio: la aplicaci\u00f3n debe modelar expl\u00edcitamente la compensaci\u00f3n. Ya no es un tema de infraestructura, sino de producto. Un equipo que cambia su codificaci\u00f3n de video de \u00abAlta\u00bb a \u00abEst\u00e1ndar\u00bb cuando la mezcla de electricidad es mala debe responder por el resultado ante el cliente. Quien no lo comunica arriesga tickets de soporte.<\/p>\n La programaci\u00f3n consciente del carbono no es un almuerzo gratis. Los patrones chocan con otros objetivos de arquitectura. Estas colisiones no son te\u00f3ricas. Quien no lo entiende temprano se acumula deuda t\u00e9cnica, que bajo la etiqueta de \u00absostenibilidad\u00bb es m\u00e1s dif\u00edcil de discutir que la complejidad habitual.<\/p>\n La tentaci\u00f3n es grande de establecer Carbon-aware Scheduling como una iniciativa de plataforma. Rara vez es sensato. El mejor camino es un piloto estrecho que produzca un resultado real antes de que se escriban las directrices.<\/p>\n La mayor debilidad abierta es la atribuci\u00f3n. Los proveedores de cloud informan de emisiones por regi\u00f3n, pero rara vez por trabajo o servicio. Quien quiera saber cu\u00e1nto CO2 causa un microservicio concreto durante un sprint, debe calcularlo \u00e9l mismo – con intensidad energ\u00e9tica, tiempo de ejecuci\u00f3n, utilizaci\u00f3n y suposiciones sobre la efectividad del uso de energ\u00eda del centro de datos. Esto es factible, pero es trabajo de ingenier\u00eda y no un clic en el panel. En la pr\u00e1ctica, esto significa: un modelo de telemetr\u00eda interno que calcula las m\u00e9tricas de tiempo de ejecuci\u00f3n del programador con curvas de intensidad regionales y agrega resultados por equipo o servicio. Los equipos sin un modelo de este tipo se quedan con estimaciones que dif\u00edcilmente se pueden justificar frente a los clientes o procesos de auditor\u00eda.<\/p>\n Otro punto a menudo subestimado: la responsabilidad operativa del propio programador. Si se interrumpe la alimentaci\u00f3n de la se\u00f1al de carbono, debe estar claro qu\u00e9 sucede – \u00bfse detiene el trabajo, se ejecuta inmediatamente, espera a un tiempo de espera? Sin un plan de contingencia definido, se producen fallos silenciosos. Carbon-aware Scheduling necesita la misma rigidez en la gesti\u00f3n de incidentes que cualquier otro programador de producci\u00f3n; de lo contrario, se convierte en un sistema en la sombra junto al funcionamiento real de Cron o Kubernetes.<\/p>\n La segunda debilidad abierta es la calidad de la se\u00f1al. Las previsiones para las pr\u00f3ximas horas han mejorado, pero no son exactas. Quien construye un programador que reacciona a cada peque\u00f1o pico en la mezcla de la red, obtendr\u00e1 inicios de trabajo inestables. M\u00e1s pragm\u00e1tico es una regla simple: retrasar hasta la pr\u00f3xima ventana por debajo de un umbral; de lo contrario, iniciar despu\u00e9s del tiempo de espera m\u00e1ximo de todos modos. Sin optimizaci\u00f3n de segundo orden, sin pron\u00f3stico de ML sobre el pron\u00f3stico.<\/p>\n Y finalmente, el l\u00edmite m\u00e1s honesto: Carbon-aware Scheduling reduce las emisiones de las cargas de trabajo desplazadas. No reduce la demanda absoluta de energ\u00eda. Quien quiera hablar en serio sobre la sostenibilidad en la TI, no puede evitar temas de eficiencia: mover menos datos, modelos m\u00e1s ligeros, pol\u00edticas de retenci\u00f3n limpias, manejo consciente de la infraestructura inactiva. La programaci\u00f3n es una palanca, no la respuesta.<\/p>\n Para los equipos que operan muchas cargas de trabajo por lotes, vale la pena el desplazamiento en el tiempo como primer paso: baja complejidad, ahorro s\u00f3lido, sin trampas de residencia. El desplazamiento de ubicaci\u00f3n es interesante si Multi-Region ya est\u00e1 establecido y los datos lo permiten – de lo contrario, se vuelve r\u00e1pidamente caro. La formaci\u00f3n de la demanda vale la pena para algunos productos bien elegidos con componentes cr\u00edticos de latencia y computaci\u00f3n intensiva, pero no como iniciativa transversal.<\/p>\n Quien trata Carbon-aware Scheduling como un tema de arquitectura, lo introduce en las discusiones a las que pertenece: selecci\u00f3n de regi\u00f3n, dise\u00f1o del programador, dise\u00f1o de datos. Quien lo trata como un tema de comunicaci\u00f3n, construye una etiqueta que mueve poco. Los patrones de la Green Software Foundation no son un manifiesto – son un vocabulario con el que se pueden tomar estas decisiones de manera limpia.<\/p>\n No. Para un piloto, basta con un contenedor Cron que consulte una API de intensidad y retrase el inicio del trabajo. Las caracter\u00edsticas de la plataforma como KEDA-Carbon-Scaler o los modos de procesamiento por lotes propios del proveedor son \u00fatiles cuando se deben coordinar varias cargas de trabajo.<\/p>\n<\/details>\n Buenas para la mezcla actual de la red en la mayor\u00eda de las regiones europeas. Las previsiones de varias horas son \u00fatiles, pero no exactas. Quien optimiza para previsiones de minutos, arriesga una programaci\u00f3n inestable. M\u00e1s robusto: combinar umbrales y tiempos m\u00e1ximos de espera.<\/p>\n<\/details>\n El cambio de ubicaci\u00f3n solo dentro de un cl\u00faster de regiones legalmente liberadas. Las especificaciones de residencia suelen ser m\u00e1s fuertes que cualquier regla de carbono, por lo que es necesario coordinar con la privacidad de datos y el cumplimiento antes de que un programador pueda seleccionar regiones.<\/p>\n<\/details>\n A menudo neutral o ligeramente positivo: los momentos de baja intensidad de CO2 coinciden con frecuencia con tarifas el\u00e9ctricas fuera de pico y disponibilidad de instancias Spot. Al cambiar de ubicaci\u00f3n, el tr\u00e1fico de salida puede anular el efecto, por lo que siempre hay que tener en cuenta los costos de red.<\/p>\n<\/details>\n API s\u00edncronas orientadas al usuario. Sistemas transaccionales con presupuestos de latencia estrictos. Cargas de trabajo con tiempos de respuesta vinculados a SLA. Aqu\u00ed, la formaci\u00f3n de la demanda sigue siendo el \u00fanico camino, y es un tema de producto, no una decisi\u00f3n de infraestructura.<\/p>\n<\/details>\n Recomendaciones de lectura de la redacci\u00f3n<\/p>\n M\u00e1s del MBF Media Netzwerk<\/p>\n\n
Qu\u00e9 es t\u00e9cnicamente la planificaci\u00f3n consciente del carbono<\/h2>\n
\n\n
\n \nPatr\u00f3n<\/th>\n Principio<\/th>\n Adecuado para<\/th>\n Grado de madurez<\/th>\n<\/tr>\n<\/thead>\n \n Desplazamiento de ubicaci\u00f3n<\/strong><\/td>\n Desplazar la carga de trabajo a una regi\u00f3n con una red el\u00e9ctrica limpia<\/td>\n Procesamiento por lotes, entrenamiento de ML, agregaci\u00f3n de datos sin restricciones de latencia<\/td>\n Productivo en GCP\/AWS, requiere configuraci\u00f3n multirregional<\/td>\n<\/tr>\n \n Desplazamiento temporal<\/strong><\/td>\n Desplazar la carga de trabajo a la hora limpia dentro de la misma regi\u00f3n<\/td>\n Informes posteriores, copias de seguridad, reentrenamiento de modelos<\/td>\n Utilizable con integraci\u00f3n del programador (Airflow, Argo)<\/td>\n<\/tr>\n \n Conformaci\u00f3n de la demanda<\/strong><\/td>\n Reducir el esfuerzo computacional cuando la intensidad de CO2 de la red es alta<\/td>\n Transcodificaci\u00f3n de video, caracter\u00edsticas de UX no cr\u00edticas, precomputaci\u00f3n<\/td>\n Temprano, a menudo implementado en la aplicaci\u00f3n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Location-Shifting: llevar la carga de trabajo a la corriente limpia<\/h2>\n
Time-Shifting: llevar la carga de trabajo a la hora limpia<\/h2>\n
Demand-Shaping: menos c\u00e1lculo cuando la electricidad es sucia<\/h2>\n
Compensaciones: lo que habla en contra de la programaci\u00f3n consciente del carbono<\/h2>\n
A favor<\/h3>\n
\n
En contra<\/h3>\n
\n
Piloto: c\u00f3mo se ve una entrada realista<\/h2>\n
\n
Qu\u00e9 sigue siendo dif\u00edcil<\/h2>\n
Recomendaci\u00f3n<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfNecesito una herramienta especial para la programaci\u00f3n consciente del carbono?<\/strong><\/summary>\n
\u00bfQu\u00e9 tan confiables son las se\u00f1ales de emisi\u00f3n?<\/strong><\/summary>\n
Conflicto con la residencia de datos: \u00bfc\u00f3mo manejarlo?<\/strong><\/summary>\n
\u00bfVale la pena la programaci\u00f3n consciente del carbono desde el punto de vista financiero?<\/strong><\/summary>\n
\u00bfQu\u00e9 definitivamente no es adecuado para la programaci\u00f3n consciente del carbono?<\/strong><\/summary>\n
\n