Im Rahmen der Einführung des MacBook Neo hat Apple auch an seinen Produktionsverfahren gearbeitet. So wird das Gehäuse in einem neuartigen „materialeffizienten Umformverfahren“ hergestellt, wie Apple angibt. Dabei wird laut dem Konzern nur noch die Hälfte an Alu als Ausgangsmaterial „gegenüber herkömmlichen Zerspanungsmethoden“ benötigt. Gänzlich recycelt ist der Stoff allerdings nicht: Hier erreicht Apple aktuell aber einen Faktor von 90 Prozent. Was bislang noch nicht bekannt war: Das Neo soll auch beim Wasserverbrauch in der Herstellung deutlich umweltfreundlicher sein.

Viermal Wasser des Westsees

Angaben dazu macht Apple auf seiner chinesischsprachigen Presse-Website. Man habe einen neuen „Closed Loop“-Prozess für den Eloxierprozess entwickelt, schreibt der Konzern dort. Er wird bei den verwendeten Fertigern – Apple erwähnt Foxconn – in China verwendet. „Closed Loop“ heißt, dass weniger Wasser verloren gehen soll. Allerdings ist auch das nicht perfekt: Die Wasserrecyclingrate liegt derzeit bei 70 Prozent im Produktionsprozess für das Neo.

Insgesamt soll Apple bei seinen Fertigern mit dieser und anderen Maßnahmen 55 Milliarden Liter Trinkwasser eingespart haben. Das entspricht rund dem vierfachen Wasservolumen des bekannten Westsees in Zhejiang. Laut Aussagen von Operations-Chef (COO) Sabih Khan arbeitet mit allen chinesischen Lieferanten zusammen, um „die wertvollste Ressource der Welt“ zu schützen. Der neue Alu-Prozess sei hier ein nächster Schritt, der ein 100 Jahre altes, traditionell wasserintensives Industrieverfahren verändere.

Sauberes Trinkwasser fehlt

Apple hatte vor 13 Jahren das sogenannte Clean Water Project für China gestartet. Dabei soll möglichst wenig Trinkwasser in die Prozesse des Konzerns gelangen, stattdessen Wasser recycelt werden. Zudem werden Lieferanten in den Bereichen Wassermanagement und Ökodesign trainiert. Bei Foxconn entstand so auf dem Campus in Longshua ein Gartenprojekt, bei dem Regenwasser gereinigt und wiederverwendet wird.

Das Thema Trinkwasser ist in China besonders wichtig. So wird auch in Großstädten wie Peking immer noch davon abgeraten, Leitungswasser direkt zu trinken, da dieses belastet sein kann.

(bsc)

Echten Nutzen bringt generative KI nicht bei individuellen Experimenten und Prototyping, sondern dann, wenn bestehende Softwareprodukte, Plattformen und Geschäftsprozesse gezielt durch GenAI erweitert werden.

Oft bilden hier C# und .NET das Fundament zahlreicher ERP-naher Systeme, Individualanwendungen und Standardprodukte. Rund um diese Plattform existieren umfangreiches Know-how, stabile Build- und Deployment-Pipelines sowie erprobte Betriebs- und Sicherheitskonzepte. Diese Investitionen sind langfristig angelegt und lassen sich nicht ohne Weiteres ersetzen.

Statt also komplette Systeme für GenAI neu zu entwickeln, sollen bestehende Anwendungen durch Assistenzfunktionen, kontextbezogene Unterstützung, teilautomatisierte Workflows oder Copilot-ähnliche Erweiterungen intelligenter werden. Dafür müssen Large Language Models (LLMs) nahtlos in bestehende Architekturen integrierbar sein.

Der Kontext zählt: GenAI als Experiment oder im Produktiveinsatz

Hier zeigt sich der Unterschied zwischen Experiment und Produktivsystem. Ein Proof of Concept lässt sich schnell in Python umsetzen. Für produktive Systeme zählen jedoch andere Kriterien: Integration in bestehende Authentifizierungsmechanismen, Zugriff auf interne Services und Datenbanken, Wiederverwendung bestehender Bibliotheken, sauberes Logging, reproduzierbare Builds und klar geregelter Betrieb. Jede zusätzliche Sprache und jede neue Toolchain erhöhen die Komplexität und damit Aufwand und Risiko.

Aus dieser Perspektive ist .NET für GenAI-Anwendungen hochrelevant. Nicht, weil .NET grundsätzlich besser für KI geeignet wäre, sondern weil es den Übergang vom Experiment zur produktiven Anwendung deutlich vereinfacht. Bestehende Teams können mit bekannten Werkzeugen arbeiten, vorhandene Infrastruktur bleibt nutzbar, Governance- und Sicherheitsanforderungen lassen sich leichter einhalten.

Gleichzeitig gilt: .NET ist selten die erste Wahl für KI-nahe Forschung, Modelltraining oder frühe Exploration. In diesen Bereichen dominieren Python und zunehmend auch TypeScript. Neue Frameworks und APIs erscheinen dafür meist zuerst.

Für produktive GenAI-Systeme in Unternehmen hingegen ist .NET häufig die naheliegende Plattform, vorausgesetzt, geeignete SDKs stehen zur Verfügung. Niemand möchte auf Protokollebene mit HTTP-Requests, JSON-Parsing und asynchronen Event-Streams arbeiten, nur um ein LLM anzubinden.

Gut gepflegte .NET-SDKs sind deshalb kein Luxus, sondern ein Enablement-Faktor. Sie bestimmen, ob bestehende Entwicklungsteams GenAI schnell, sicher und wartbar integrieren können oder ob unnötige Reibungsverluste entstehen. Wie gut die aktuelle SDK-Landschaft diesen Anspruch heute erfüllt, zeigt der Blick auf die verfügbaren Anbieter und Abstraktionen.

Die SDK-Landschaft für Large Language Models aus .NET-Sicht

Wer ein LLM mit .NET nutzen möchte, trifft heute auf eine deutlich vielfältigere SDK-Landschaft als noch vor einem Jahr. Doch nicht alle verfügbaren SDKs sind gleichwertig und nicht jedes eignet sich für produktive Anwendungen.

Die folgende Abbildung stellt den Zusammenhang zwischen Basis-SDKs, LLM-Proxies, Agenten-Schicht, Präsentationsschicht und MCP dar. Auf diese Punkte gehen die folgenden Kapitel genauer ein. Dabei beschäftigt sich der Artikel insbesondere damit, wie gut die SDK-Landschaft aus .NET-Sicht aufgestellt ist.

Lange Zeit waren offizielle SDKs für Large Language Models fast ausschließlich für Python und TypeScript verfügbar. Das beginnt sich zu ändern. Inzwischen stellen mehrere große Modellanbieter .NET-SDKs bereit, die sich für produktive Anwendungen eignen.

Die ersten ernstzunehmenden C#-SDKs für die OpenAI-API entstanden nicht direkt bei OpenAI selbst, sondern bei Microsoft als Teil der engen strategischen Partnerschaft zwischen beiden Unternehmen. Sie wiesen jedoch noch Schwächen auf. Nach einer Übergangsphase übernahm OpenAI selbst die Verantwortung. Heute wird das offizielle C#-SDK direkt von OpenAI gepflegt und als reguläres NuGet-Paket veröffentlicht. Microsoft stellt ergänzend ein begleitendes Paket bereit. Es erleichtert unter anderem Authentifizierung, Konfiguration und Integration mit OpenAI in Azure Foundry, ist jedoch optional. Die Kernfunktionalität für den Zugriff auf OpenAI-Modelle liegt heute eindeutig im offiziellen OpenAI-SDK selbst.

Anthropic stellt ein offizielles C#-SDK bereit, das aktuell noch als Beta gekennzeichnet ist, jedoch bereits gut nutzbar ist. Google bietet mit seinem GenAI-SDK eine offizielle .NET-Anbindung für Gemini-Modelle, sowohl für Google AI als auch für Vertex AI. Auch für andere LLM-Anbieter existieren heute offizielle, vom Hersteller gepflegte .NET-SDKs.

Die größte Reife und Verbreitung besitzt aber das OpenAI-SDK. Das zugehörige GitHub-Repository verzeichnet mehrere Tausend Sterne und das NuGet-Paket kommt auf fast 35 Millionen Downloads.

Neben den offiziellen SDKs existiert eine Vielzahl an Community- und Open-Source-SDKs. Eine besondere Rolle spielt hier das Projekt tryAGI, das auf Basis von OpenAI-Spezifikationen systematisch C#-SDKs für eine Vielzahl von LLM-Anbietern generiert.

Auf diese Weise stehen für viele Modelle SDKs zur Verfügung, für die es keine offiziellen .NET-Bibliotheken gibt, darunter auch Anbieter wie Mistral und Plattformen wie Ollama. Der Ansatz ist pragmatisch: Die SDKs sind konsistent aufgebaut, schnell verfügbar und decken in der Regel die grundlegenden API-Funktionen zuverlässig ab. Allerdings haben sie Grenzen: Generierte SDKs folgen relativ streng der jeweiligen API-Spezifikation mit keinen oder begrenzten manuellen Anpassungen, weshalb fortgeschrittene API-Funktionen manchmal nur holprig oder gar nicht verfügbar sind. Auch die langfristige Wartung hängt nicht vom Modellanbieter selbst ab, sondern vom Engagement der Community.

Für einfache Anwendungsfälle sind solche SDKs oft vollkommen ausreichend. Für komplexere, interaktive oder langfristig betriebene Systeme sollte man jedoch genau prüfen, ob ein Community-SDK den eigenen Anforderungen genügt.

Proxies und Kompatibilitätsschichten: Abstraktion statt Anbieterbindung

Eine weitere Kategorie bilden Proxies und Kompatibilitätsschichten, die versuchen, unterschiedliche Modellanbieter hinter einer einheitlichen API zu bündeln. Ein prominentes Beispiel dafür ist LiteLLM, das eine OpenAI-kompatible API bereitstellt und Anfragen an eine Vielzahl von Modellen weiterleitet.

Für .NET-Entwicklerinnen und -Entwickler kann dieser Ansatz attraktiv sein, da sie OpenAI-SDKs verwenden können. Oft genügt es, die Base-URL zu ändern und andere Modellnamen zu konfigurieren. Ähnlich verhält es sich bei lokal betriebenen Modellen über Ollama, das ebenfalls OpenAI-kompatible Endpoints bereitstellt.

Diese Abstraktion erleichtert den Wechsel zwischen Modellen und Anbietern, hat jedoch ihren Preis. Kompatibilitätsschichten orientieren sich in der Regel am kleinsten gemeinsamen Nenner der unterstützten APIs. Neuere oder anbieterspezifische Features werden häufig nur eingeschränkt unterstützt oder fehlen ganz. Besonders bei neueren API-Varianten oder fortgeschrittenen Funktionen kann es hier zu spürbaren Einschränkungen kommen.

Der Volkswagen-Konzern ruft weltweit mehr als 90.000 E-Autos der Marken VW und Cupra in die Werkstatt. Das geht aus einer Meldung in der Rückrufdatenbank des Kraftfahrt-Bundesamtes (KBA) in Flensburg hervor. Module in der Traktionsbatterie könnten zu Problemen führen, die vom Aufleuchten einer gelben Kontrollleuchte über eine Abnahme der Reichweite bis hin zu Brandgefahr reichen könnten.

Den Angaben zufolge geht es um Batteriemodule, die nicht der Spezifikation entsprechen. Vorfälle mit Sach- oder Personenschäden sind dem KBA nach eigenen Angaben bisher nicht bekannt. Ein VW-Sprecher bestätigte den Rückruf auf Anfrage. Zuvor hatten das Magazin kfz-betrieb und die Braunschweiger Zeitung darüber berichtet.

Weltweit rund 94.000 Autos betroffen

Betroffen sind laut KBA bei VW die Modelle ID.3, ID.4, ID.5, ID.Buzz und ID.Buzz Cargo, die zwischen 24. Juni 2023 und 23. August 2024 produziert wurden. Bei Cupra geht es um das Modell Born aus dem Produktionszeitraum 7. Februar 2022 bis 21. April 2024. Insgesamt umfasst der Rückruf weltweit gut 94.000 Fahrzeuge, davon knapp 75.000 VW und gut 19.000 Cupra. In Deutschland sind es rund 28.000 Fahrzeuge, davon 22.000 VW und 6000 Cupra.

Um das Problem zu beheben, müsse in der Werkstatt ein Software-Update durchgeführt und die Traktionsbatterie geprüft werden, heißt es beim KBA. Sofern erforderlich, würden einzelne Module der Batterie ersetzt. Der Rückruf wird bei Volkswagen unter dem Code 93MI geführt, beim KBA unter der Referenznummer 16271R.

VW: „Sehr seltene Einzelfälle“

Nur „in sehr seltenen Einzelfällen“ bestehe die Möglichkeit einer thermischen Überlastung innerhalb eines Batteriemoduls, betonte ein VW-Sprecher. „Eine solche Überlastung könnte im Extremfall zu einem Brandereignis führen“, so der Sprecher weiter. „Um mögliche Risiken auszuschließen, überprüfen wir vorsorglich alle betroffenen Fahrzeuge.“ Die betroffenen Kunden würden nun angeschrieben, hieß es. Der Fehler sei von VW selbst „im Rahmen unserer kontinuierlichen Qualitätsüberwachung“ entdeckt worden, so der Sprecher. Es hätte in diesem Zusammenhang keine Personenschäden gegeben.

Es ist nicht der erste Rückruf, den Volkswagen in dieser Hinsicht starten muss. Im Januar 2026 wurde über das KBA ein Rückruf gestartet, bei dem es um fehlerhafte Batteriezellen mit einer erhöhten Selbstentladung ging. Dies könne, hieß es damals, zu einer thermischen Überlastung der Module und in der Folge zu einem Brand führen. Dieser Rückruf wird bei Volkswagen unter dem Code 93MU, bei der KBA unter der Referenznummer 15998R geführt.

(mfz)