Darkbloom AI im Test: Ist private Inferenz auf freien Macs bereit?

Darkbloom ist ein Public-Alpha-Netzwerk für KI-Inferenz, das OpenAI-kompatible Requests an verifizierte Apple-Silicon-Macs routet. Es liegt zwischen einer normalen Hosted API und einem Modell, das nur auf eigener Hardware läuft. Entwickler ändern die Base URL, Mac-Eigentümer stellen freie Kapazität bereit, und das Netzwerk koordiniert Verschlüsselung, Placement, Attestierung und Zahlung.

Die Kaufentscheidung ist anspruchsvoller als der Claim. Darkbloom kann Integration vereinfachen und Tokenpreise senken. Ein fremder Mac wird dadurch aber nicht automatisch zu einer Confidential-Computing-Enklave. Koordinator und ausgewählter Provider benötigen innerhalb geschützter Laufzeitgrenzen Zugriff auf Klartext. Auch Provider-Erlöse hängen von Nachfrage, Modell-Fit und Uptime ab. Unser Urteil am 25. August 2026: ein sinnvoller, klar begrenzter Test mit nicht sensiblen Workloads, aber noch kein Vertrauensvorschuss für die Produktion.

Was ist Darkbloom AI?

Eigen Labs stellte Project Darkbloom als Forschungsinitiative für verteilte Inferenz auf ungenutzten Macs vor. Ein Koordinator ordnet Requests passenden Provider-Nodes zu. Der Provider nutzt einen gehärteten Prozess auf Apple Silicon und führt das Modell mit MLX im selben Prozess aus.

Das Open-Source-Repository von Darkbloom dokumentiert das System als Public Alpha. Die Control Plane läuft in einer Confidential VM, Provider verbinden sich ausgehend per WebSocket, und Responses streamen über den Koordinator zurück. Öffentliche Endpoints liefern Live-Modellkatalog, Preise und Provider-Attestierung.

Das ist nicht dieselbe Architektur wie in unserem Mesh-LLM-Test. Mesh LLM verteilt ein Modell in Layer-Stages auf Rechner unter eigener Kontrolle. Darkbloom routet normalerweise den gesamten Request zu einem passenden Provider. Klassisches Self-Hosting ist es ebenfalls nicht, denn Koordinator und Remote Provider bleiben Teil der Service Boundary.

Wie funktioniert Darkbloom Privacy wirklich?

1. Anwendung zum Koordinator: TLS schützt den Transport. Optional versiegelt der Client den Body zusätzlich für den X25519-Key des Koordinators.
2. Im Koordinator: Die Confidential VM entschlüsselt für Routing und Billing.
3. Koordinator zum Provider: Ein frischer ephemerer Key verschlüsselt den Body für den attestierten Provider-Key neu.
4. Im Provider: Der gehärtete Prozess entschlüsselt und führt MLX-Inferenz im selben Prozess aus.
5. Response: Verschlüsselte Stream-Chunks laufen zum Koordinator und von dort zum Client.

Das kanonische Verschlüsselungsdokument ist klar: Der Koordinator sieht Prompt-Inhalte kurzzeitig für Routing und Billing, der Provider ist der finale Entschlüsselungspunkt. Damit unterscheidet sich Darkbloom relevant von einem offen beobachtbaren Subprozess. „Verschlüsselt“ bedeutet trotzdem nicht, dass außerhalb des eigenen Unternehmens nie Klartext verarbeitet wird.

Die Privacy Expectations für Nutzer ergänzen: Der Koordinator soll Prompt-Inhalte weder loggen noch speichern und vor dem Verlassen der Confidential VM neu verschlüsseln. Ein Käufer braucht trotzdem Nachweise zur deployten Version, Zugriffssteuerung, Telemetrie, Regionen, Subprozessoren, Incidents und vertraglicher Verantwortung.

Ist Darkbloom Ende-zu-Ende verschlüsselt?

Beide Netzwerkstrecken sind authentifiziert verschlüsselt, aber Koordinator und Provider entschlüsseln innerhalb ihrer geschützten Runtime. Wenn Ende-zu-Ende bedeutet, dass nur ursprünglicher Client und Endnutzer Klartext besitzen, trifft der Begriff nicht zu. Präziser ist: Hop-by-Hop-verschlüsselte private Inferenz mit Confidential Coordinator und attestiertem Provider-Prozess.

Für regulierte Daten ist dieser Unterschied entscheidend. Wenn ein externer Dienst unter keiner Ausführungsbedingung Klartext sehen darf, wähle lokale Inferenz, eine geeignete Kryptografietechnik oder eine geprüfte Confidential-Computing-Plattform. Unser Vergleich von ZK, FHE, MPC und TEE trennt diese Garantien.

Wie kompatibel ist die Darkbloom API?

Der Consumer Quickstart dokumentiert eine OpenAI Base URL, Bearer Auth, Streaming Chat Completions und Anthropic Messages. Das Repository nennt auch Responses API, Tool Calling, Vision und Reasoning Models. Embeddings gelten derzeit als nicht implementiert, und Aliasse können im Zeitverlauf auf andere Builds zeigen.

Kompatibel heißt hier: gute Migrationsfläche, nicht vollständige Verhaltensgleichheit. Teste Endpoint, Streaming, Tool-Call-Schema, Timeouts, Fehlerformate, Rate Limits, Alias-Wechsel und deine SDK-Version. Für Policy, Observability und Fallback kann ein internes Gateway sinnvoll sein. Unser Vergleich von LLM Gateways und Routern deckt diese Control Layer ab.

Was kostet Darkbloom?

Das Repository dokumentiert aktuell Fallback-Rates von 0,05 US-Dollar pro Million Input-Token, 0,20 US-Dollar pro Million Output-Token und 0,0001 US-Dollar Mindestgebühr pro Request. Die Plattformgebühr liegt während der Public Alpha bei 0%. Modellabhängige Live-Rates liefert GET /v1/pricing. Archiviere die Live-Preise am Anfang und Ende jedes Tests.

Vergleiche nicht nur Tokenpreis, sondern Qualität, Kosten pro akzeptierter Aufgabe, Time to First Token, Tail Latency, Retries, Fallback, Engineering, Security Review und Ausfallkosten. Unser Break-even-Modell für lokale LLMs gegen APIs berechnet diese Vollkosten. Darkbloom kombiniert API-Komfort mit verteilter Consumer-Hardware als Supply.

Kann man mit Darkbloom auf einem Mac Geld verdienen?

Möglich, aber nur bei gematchter Nachfrage. Das Provider Setup verlangt Apple Silicon, macOS 14 oder neuer, stabiles Internet und genug Unified Memory für ein unterstütztes Modell. Das Repository empfiehlt 32 GB oder mehr für größere oder mehrere Modelle und mindestens 100 GB freien Speicher.

Aus einem Earnings Calculator darf kein Hardware-Business-Case werden. Ein öffentliches Provider-Issue meldete mehr als einen Tag ohne Inferenzjobs trotz verbundenem Mac. Das ist ein einzelner Bericht, keine Messung der gesamten Flotte. Er zeigt aber das zentrale Risiko: Eligibility und Uptime erzeugen keine Kundennachfrage.

Starte mit vorhandener Hardware. Miss Jobs, verrechenbare Token, Auszahlung, zusätzliche Leistungsaufnahme, Memory Pressure, Disk, Netzwerk, Unterbrechung und Supportzeit. Berechne Nettoerlös pro verfügbarer und pro aktiver Stunde. Hochrechnungen aus Launch-Incentives oder kurzen Traffic-Spitzen sind nicht belastbar.

Welche Produktionsrisiken sind entscheidend?

Der letzte Punkt ist real. Ein öffentliches Issue dokumentiert extremen Metal Memory Pressure auf einem M3 Ultra mit 256 GB unter anhaltendem Provider-Traffic. Es betrifft eine bestimmte Version und Konfiguration und beweist keinen generellen Fehler. Dennoch sollten Physical Footprint, Memory Compression, Terminierung und Recovery statt nur RSS gemessen werden.

Darkbloom vs. lokale KI vs. Hosted API

Darkbloom in sieben Schritten testen

1. Low-Risk-Workload wählen: keine personenbezogenen Daten, Secrets, Kundencode oder regulierten Records.
2. Entscheidungsfläche einfrieren: Endpoint, Alias, Build, Preis, Repository-Revision, Trust Header und Policies dokumentieren.
3. Qualitätsbaseline erstellen: 50 bis 200 repräsentative Aufgaben mit Akzeptanzrubrik vergleichen.
4. Service messen: First Token, Gesamtlatenz, Durchsatz, Fehler, Retries, Tool Calls und Kosten pro akzeptiertem Ergebnis.
5. Boundary prüfen: Verschlüsselung, Attestierung, Logs, Telemetrie, Rollen, Regionen und Incident Response.
6. Route brechen: Provider-Ausfall, Koordinatorfehler, fehlendes Modell, langsame Streams und Fallback testen.
7. Mit Scorecard entscheiden: Nur bei bestandenen Gates für Qualität, Privacy, Latenz, Reliability und Kosten erweitern.