Contact salesFree trial
Blog

KI-Einsatzstrategien: Abwägung zwischen Effizienz und Umweltauswirkungen

AINachhaltigkeitgrünBereitstellungLeistung
Teilen Sie

Video-Abschrift

Der eigentliche Titel des Vortrags lautet "LLM Deployment Strategies: Gleichgewicht zwischen Effizienz und Umweltauswirkungen". Ich weiß - niemand will wirklich die "Umweltrede" hören. Aber keine Sorge, dies wird ein Vortrag zum Wohlfühlen sein. Hier ist ein Kätzchen! Es kostet nur etwa 30 Gramm CO₂-Emissionen, um es zu erzeugen. Und wenn ich das richtig sehe, belaufen sich die CO₂-Emissionen aller LLM-Anwendungen auf der Erde derzeit auf weniger als 0,0274 % der globalen Emissionen. Das ist wirklich nicht viel.

Eigentlich sollten wir uns selbst auf die Schulter klopfen. Die CO₂-Emissionen von LLMs betragen wahrscheinlich weniger als 0,03 Megatonnen pro Tag - knapp 11 Megatonnen pro Jahr. Als Industrie haben wir tatsächlich angefangen, uns zu kümmern. Wir haben uns verbessert. Ich kann Sie nicht alle sehen, aber Handzeichen - wie viele von Ihnen wissen, ob Ihr Unternehmen eine Klimazusage hat oder klimaneutral ist? Ein paar von Ihnen vielleicht?

Die Sache ist die, dass wir zwar besser geworden sind, aber noch einen weiten Weg vor uns haben. Wir haben wieder angefangen, Kohle zu verbrennen, als gäbe es kein Morgen, was ironischerweise dazu führt, dass es kein Morgen gibt. Jede Tonne CO₂, die ausgestoßen wird, verbleibt in der Atmosphäre - das ist reine Thermodynamik; mit der Wissenschaft kann man nicht streiten.

Hier geht es nicht darum, ein technischer Optimist oder ein Progressiver zu sein. So funktioniert die Wissenschaft nicht. CO₂ verschwindet nicht einfach. Im Moment sind die Emissionen von LLM etwa zehnmal so hoch wie die von Bomben. Und Bomben sind, nun ja, nicht so toll - manche Leute sind da anderer Meinung, aber lassen wir das mal so stehen. Und es spielt auch keine Rolle, ob Sie neben einem Wasserkraftwerk sitzen oder nicht. Die meisten Emissionen sind in den von uns genutzten Prozessen enthalten.

Werfen wir also einen Blick auf die Größenordnung. In diesem Jahr wurden etwa zwei Millionen H100-Rechner und einige Grace-Hopper-Supercomputer verkauft, wobei jeder Rechner etwa 700 Watt verbraucht. Bei etwa 56.000 Watt pro Rechner und einem PUE-Faktor (Power Usage Effectiveness) kommen wir allein in diesem Jahr auf etwa 12 Megatonnen zusätzliche Emissionen. Und das ist zusätzlich zu den 11 Megatonnen, die ich gerade erwähnt habe.

Wir verdoppeln unsere Emissionen jährlich, was bedeutet, dass wir, wenn wir so weitermachen, in den nächsten fünf Jahren etwa eine halbe Gigatonne an Emissionen haben werden. Zum Vergleich: Die Welt emittiert derzeit etwa 40 Gigatonnen pro Jahr. Dieser Trend ist nicht nachhaltig, und das zeigen die Grafiken deutlich.

Werbepause! Dieser Vortrag wird von Reality and Wily gesponsert. Ich habe also einen Cartoon für diese Präsentation lizenziert - er hat mich 40 Dollar gekostet. Und ja, ich bezahle auch für einige LLM-Abonnements, wie ChatGPT und Claude von Anthropic, die etwa 40 Dollar pro Monat kosten. Da es sich um ein All-you-can-eat-Abonnement handelt, könnte ich sie technisch gesehen bitten, einen ähnlichen Cartoon kostenlos zu erstellen, aber es wäre nicht ganz dasselbe.

Aber hey, ich habe nachgerechnet, und der CO₂-Ausgleich, den wir für diesen 12-Megatonnen-Fußabdruck benötigen würden, würde etwa 0,7 Milliarden Dollar kosten - eine Zahl, die für einige in dieser Branche wie "Kleingeld" klingt. Die größte Anlage zur direkten Luftabscheidung auf der Erde in Orca, Island, bewältigt nur 4.000 Tonnen CO₂ pro Jahr. Vergleichen Sie das mit 12 Megatonnen, und Sie verstehen, worum es geht.

Okay, kann ich mal kurz aufhören, über CO₂ zu schreien und zum technischen Teil übergehen? Fast, ich verspreche es! Da ich ein wissenschaftlich-technischer Mensch bin, habe ich ein paar LLMs gefragt, wie viel CO₂ sie erzeugen, um die Frage zu beantworten, wie viel CO₂ sie erzeugen. Und natürlich haben sie mir keine Antwort gegeben. Verstärkungslernen durch Marketing-Feedback - kurz RLFM - nenne ich das. Es geht nicht um Ausrichtung, sondern eher um Ausweichmanöver. Sie sind im Grunde darauf trainiert, nicht über ihren ökologischen Fußabdruck zu sprechen.

Probieren Sie es einfach aus - fragen Sie Gemini oder einen anderen LLM, wie viel CO₂ sie ausstoßen. Sie werden Sie auf einen netten Blogbeitrag verweisen, in dem sie Ihnen versichern, dass sie kein CO₂ ausstoßen, zumindest ihrer Meinung nach. Aber lassen Sie uns technisch werden. Bei dieser Art von Gesprächen braucht man ein Diagramm, oder? Also habe ich ein einfaches Diagramm erstellt, bei dem das Verhältnis von Vorhersagbarkeit zu Risiko auf einer Achse und das Verhältnis von Altlasten zu Innovation auf der anderen liegt. Dieses Diagramm kann LLM-Einsatzstrategien recht effektiv darstellen.

Bei der Bereitstellung von Modellen für maschinelles Lernen geht es um alles, von einfachen SQL-Abfragen bis zum Training unserer eigenen grundlegenden Modelle. Und in den meisten Fällen geht es bei diesen Anwendungen um das Abrufen von Informationen: Sie haben einige Daten, möchten Fragen stellen und brauchen Antworten. Das Schöne an dieser Art von Diagramm ist, dass man die Achsenbeschriftungen austauschen kann und die Punkte immer noch einen Sinn ergeben.

Wir können die x-Achse mit "Gemessen in Millisekunden" oder "Gemessen in Monaten" oder "Arbeitende Software" oder "Hardware, die wirklich hart arbeitet" beschriften. Oder, um es noch unverblümter auszudrücken: "Ich interessiere mich für die globale Erwärmung" im Gegensatz zu "Ich interessiere mich nicht dafür". Eine der interessantesten Dimensionen, die wir angeben könnten, ist Geld. Die Ausführung von SQL ist billig; wir machen das schon seit Jahren. Eigene GPUs zu betreiben, kostet jedoch ein Vermögen.

Reden wir also über die Kompromisse, die hier eingegangen werden müssen. Als Software-Ingenieure wissen Sie, dass alles auf Kompromisse hinausläuft - eine Systemqualität zu optimieren bedeutet oft, eine andere zu opfern. Nehmen Sie zum Beispiel die Ausbildung von LLMs. Dies ist ein komplexer Prozess, der spektakulär scheitern kann, so dass wir ein überangepasstes Modell erhalten, das schlecht verallgemeinert. Die schlechte Nachricht ist, dass wir in diesem Fall keine Komprimierung oder echtes Lernen erhalten - was wir am Ende haben, ist im Wesentlichen eine Datenbank.

Und natürlich könnte man ein überangepasstes LLM als eine Art Datenbank verwenden. Nehmen wir an, Sie haben es so eingestellt, dass Sie den Vornamen Ihres Kunden kennen. Ist es dafür effizient? Vielleicht - für den Entwickler, der keinen neuen Datenspeicher von DevOps oder eine neue Spalte in der Datenbank anfordern muss. Aber es erhöht die Latenzzeit. Jede Abfrage kann Monate an zusätzlicher Verarbeitungszeit in Anspruch nehmen, da sie nicht durch einen L1- oder L2-Cache läuft. Es könnten sogar falsche Daten abgerufen werden.

Das haben wir alle schon einmal erlebt. Früher haben wir Oracle für alles verwendet. Heute legen wir die Daten vielleicht in einer Docker-Schichtdatei ab und hoffen das Beste. Wenn Ihr einziges Tool ein neuronales Netzwerk ist, dann kann es sein, dass Ihre PyTorch-Datei als Datenbank endet. Das kommt vor, sogar in der Produktion.

Wenn Probleme auftreten, stützen wir uns auf promptes Engineering. Wir versuchen, Dinge herauszufiltern, die das Modell nicht zeigen sollte, und hoffen, dass es auch dann noch funktioniert, wenn wir das Modell aktualisieren oder den Anbieter wechseln. Dies ist nur eine neue Art von technischer Schuld - die neueste Erfindung unserer Branche. Und seien wir ehrlich, es liegt eine tragische Ironie in diesem Ansatz: Wenn Sie ein LLM ohne Validierung den Benutzereingaben aussetzen, bereiten Sie sich im Grunde auf eine Katastrophe vor.

Und es sind nicht nur unsere Eingaben. Die Daten der ganzen Welt werden zu Benutzereingaben für LLMs, was bedeutet, dass wir nur begrenzte Kontrolle haben. Die Retrieval-Augmented Generation (RAG) ändert an dieser Realität nicht viel. Es ist nur eine weitere Schicht, eine weitere "freundliche" Abstraktion. Wenn Sie also Einbettungen aus einem großen Modell verwenden, denken Sie daran: Es handelt sich nicht um eine einfache Darstellung der latenten Schichten. Diese Einbettungen enthalten eine Fülle semantischer Informationen, die in Ihrem Vektorspeicher oft effektiv genutzt werden können.

Die effektive Nutzung eines Vektorspeichers kann Ihnen eine erhebliche Menge an Ressourcen ersparen. Viele Aufgaben können mit einfachen Abstandsabfragen auf Daten, die Sie bereits in Ihrer Vektordatenbank haben, erledigt werden. Dieser Ansatz ist viel billiger, aber das Problem ist, dass das Geld irgendwann aufgebraucht sein wird. Was wir derzeit tun - massive Modelle auf Spitzenhardware wie Grace Hoppers - wird in den nächsten fünf Jahren finanziell nicht mehr tragbar sein. Die Wissenschaft unterstützt nicht, dass wir diese Prozesse plötzlich erschwinglich machen können.

Was sind also die grünen Teile dieser Gleichung? Sie stehen für Dinge, von denen wir wissen, wie man sie ohne GPUs erledigen kann, also für Aufgaben, die von CPUs ausgeführt werden können. Die CPU-Auslastung ist gut bekannt, vorhersehbar und stabil. Aber die GPU-Auslastung? Das ist für die meisten von uns immer noch ein Rätsel.

Ihre Aufgabe ist es, diese Kompromisse herauszufinden. Ja, es ist mehr Code zu schreiben, und ja, es ist vielleicht nicht so glamourös wie die Verwendung der neuesten, modernsten Funktionen. Aber im Gegenzug erhalten Sie ein stabileres, wirtschaftlicheres System. Jedes Mal, wenn Sie eine nicht zwischengespeicherte Abfrage ausführen, anstatt einen LLM zu verwenden, sparen Sie Ressourcen. Stellen Sie sich das so vor: Jedes Mal, wenn Sie für eine Abfrage auf einen LLM zurückgreifen, "stirbt" metaphorisch gesehen ein Kätzchen. Verwenden Sie die Tools, die Sie bereits haben - wie PostgreSQL und PG Vector - um die Kätzchen zu retten. Hier geht es nicht darum, irgendwelche mysteriösen "die" zu beschuldigen; hier geht es um uns und unsere Entscheidungen.

Ich danke Ihnen allen, ich bin Ori. Passt auf euch auf!

Nützliche Links

Ihr größtes Werk
steht vor der Tür

Kostenloser Test
Discord
© 2025 Platform.sh. All rights reserved.