Die KI in Ihrer Fotobibliothek, und warum wir sie auf unsere eigenen GPUs verlagert haben

Wenn Sie Ihre Fotobibliothek nach “Hund im Schnee” durchsuchen und das richtige Bild erscheint, hat bereits etwas dieses Foto für Sie gelesen. Niemand hat es getaggt. Ein Machine-Learning-Modell hat die Pixel betrachtet, entschieden, was im Bild war, und dieses Verständnis gespeichert, damit Sie es später finden können. Wir haben diese Arbeit kürzlich von CPUs auf unsere eigenen GPUs (Graphics Processing Units) verlagert. Dieser Beitrag erklärt, was die KI tatsächlich tut und warum die Hardware darunter eine Rolle spielt.

Die Modelle, die das möglich machen, sind nicht unsere eigenen. Sie stammen aus dem Open-Source-Projekt Immich, auf dem PixelUnion aufgebaut ist. Unser ist hingegen der Ort, an dem sie laufen: auf Hardware, die wir selbst besitzen und betreiben, auf europäischem Boden, nicht in einer fremden KI-Cloud. Die Modelle lesen Ihre Fotos, und uns ist es wichtig, dass sie das in unseren eigenen Racks tun und nirgendwo sonst.

Es gibt eine Unterscheidung, die wir treffen sollten, bevor wir weitergehen, denn sie zählt für Ihre Privatsphäre am meisten. Ein Modell zu verwenden ist nicht dasselbe wie ein Modell zu trainieren. Das Training ist der teure, einmalige Prozess, bei dem ein Modell aus Millionen von Beispielbildern lernt, und es wird von den Autoren des Modells durchgeführt, lange bevor es zu uns gelangt. Was wir tun, ist Inferenz: Wir nehmen ein fertiges, bereits trainiertes Modell und schicken Ihr Foto einmal hindurch, um ein Ergebnis zu erhalten, so wie Sie ein Dokument durch einen Scanner schicken. Ihre Fotos werden niemals verwendet, um den Modellen etwas beizubringen. Sie werden keinem Trainingsdatensatz hinzugefügt, sie verbessern kein gemeinsames Modell, und nichts von ihnen verlässt uns, um eine künftige Version klüger zu machen. Das Modell betrachtet Ihr Foto, liefert seine Antwort und vergisst es wieder.

Drei Aufgaben, ein gemeinsamer Trick: Pixel durchsuchbar machen

Immich betreibt seine KI in einem eigenen Dienst, dem Container immich-machine-learning, dokumentiert in der Machine-Learning-README des Projekts. Er erledigt drei Aufgaben, und jede löst ein anderes Problem:

• Smart Search verwandelt ein Foto in etwas, das Sie mit einfacher Sprache durchsuchen können, mithilfe eines CLIP-Modells.
• Gesichtserkennung findet Gesichter und ermittelt, welche zur selben Person gehören, mithilfe eines Modellpakets wie buffalo_l.
• OCR liest Text, der in Ihren Fotos vorkommt, mithilfe eines PP-OCRv5-Modells.

Es lohnt sich, hier präzise zu sein, denn “drei Modelle” ist eine Vereinfachung. Zwei dieser Aufgaben sind eigentlich ein Paar von Modellen, die nacheinander arbeiten, und jede Aufgabe lässt sich gegen ein anderes Modell austauschen. Die Gesichtserkennung führt ein Erkennungsmodell aus, gefolgt von einem Zuordnungsmodell, und buffalo_l ist ein Bündel, das beide enthält. Immich liefert auch Alternativen wie antelopev2, buffalo_m und buffalo_s. OCR funktioniert genauso, ein Modell zum Finden von Text und ein weiteres zum Lesen. Und CLIP selbst ist ein Paar von Encodern, einer für Bilder und einer für Text, mit vielen austauschbaren Varianten. Es gibt überhaupt kein separates Objekterkennungsmodell: Dass ein Foto einen Hund oder einen Strand enthält, erledigt CLIP, nicht ein eigenes Tagging-Modell.

Für das Verständnis zählt, dass alle drei Aufgaben einen gemeinsamen zugrunde liegenden Trick teilen. Diesen Trick verstehen wir also zuerst. Danach ergeben die Unterschiede Sinn.

CLIP: nach Bedeutung suchen, nicht nach Tags

Die alte Fotosuche funktionierte über Dateinamen und manuelle Tags. Wenn Sie “Strand” nicht in eine Bildunterschrift getippt hatten, fand die Suche nach “Strand” nichts. CLIP, ein ursprünglich von OpenAI veröffentlichtes Modell (Paper hier), beseitigt diese Einschränkung. Es betrachtet den tatsächlichen Inhalt eines Bildes.

Hier ist der Teil, an dem sich viele stoßen, einfach erklärt. CLIP speichert keine Wortliste für jedes Foto. Es wandelt jedes Foto in einen Vektor um: eine lange Liste von Zahlen, ein paar Hundert davon, die zusammen die Bedeutung des Bildes beschreiben. Ein Bild eines Huskys im frischen Schnee und ein Bild eines anderen Hundes im Schnee erhalten ähnliche Zahlenlisten, weil sie Ähnliches bedeuten. Eine solche Liste heißt Embedding.

Was Vektorsuche tatsächlich ist

Sobald jedes Foto in Ihrer Bibliothek ein Vektor ist, speichern wir all diese Vektoren in einer Datenbank. Die Suche läuft so ab:

1. Sie tippen “Hund im Schnee”.
2. Dasselbe Modell wandelt Ihre Wörter in einen Vektor um, im selben Zahlensystem wie die Fotos.
3. Die Datenbank vergleicht Ihren Suchvektor mit den gespeicherten Fotovektoren und misst, wie nah jeder liegt.
4. Die nächstliegenden Treffer kommen zuerst zurück.

“Nah” ist hier Mathematik. Jeder Vektor ist ein Punkt im Raum, und das System misst den Abstand zwischen Ihrer Suchanfrage und jedem Foto. In der einfachsten Form ist das Brute Force: den Abstand zu jedem einzelnen Foto prüfen, nach dem nächstgelegenen sortieren. In diesem Prozess kommt nirgends ein Tag-Abgleich oder eine Stichwortsuche vor. Ein Foto ohne Bildunterschrift, ohne Dateinamen und ohne Beschreibung taucht trotzdem auf, weil seine Bedeutung in den Zahlen steckt.

Dieser Brute-Force-Vergleich ist die ehrliche Variante, und für eine normale Bibliothek funktioniert er gut. Er benennt auch die Kosten. Eine einzelne Suchanfrage mit Millionen von Vektoren zu vergleichen, einen nach dem anderen, wird langsam. Bei großem Umfang wechseln Sie zu intelligenteren Indizes, der Approximate-Nearest-Neighbor-Suche, die die meisten Vergleiche überspringt und trotzdem die richtigen Treffer findet. Welchen Ansatz Sie brauchen, hängt von der Bibliotheksgröße ab, aber das Prinzip bleibt gleich: alles in Vektoren umwandeln, dann die nächstliegenden finden.

Noch etwas, das in Europa zählt. Das Standard-CLIP-Modell kommt mit Englisch gut zurecht und mit anderen Sprachen schlecht. Es gibt mehrsprachige Varianten, und Immich lässt Sie sie austauschen, wie der Leitfaden zur Modellauswahl beschreibt. Der Kompromiss ist real: Die besseren mehrsprachigen Modelle sind größer und brauchen mehr Speicher, um zu laufen. Dieser Speicherdruck ist einer der Gründe, warum die Wahl der Hardware zu zählen beginnt, dazu kommen wir noch.

buffalo_l: dieselbe Person über all Ihre Fotos hinweg finden

Die Gesichtserkennung in Immich verwendet buffalo_l, ein Modellpaket aus dem InsightFace-Projekt, für Immich gehostet auf Hugging Face. Es läuft in zwei Stufen, und beide lohnen sich zu verstehen, weil oft angenommen wird, es tue etwas, das es nicht tut.

Stufe eins ist die Erkennung. Das Modell scannt das Bild und ermittelt, wo die Gesichter sind. Denken Sie an das Fokusquadrat, das eine Kamera um ein Gesicht zeichnet, nur dass das Modell es nachträglich tut, auf jedem Foto. Das Ergebnis ist eine Reihe von Kästen: hier ein Gesicht, hier noch eines.

Stufe zwei ist die Zuordnung. Für jedes gefundene Gesicht erzeugt das Modell einen Vektor, dieselbe Idee wie bei CLIP, aber auf Gesichter abgestimmt. Sie können ihn sich als numerischen Fingerabdruck dieses Gesichts vorstellen. Zwei Fotos derselben Person, in anderem Licht und aus anderen Winkeln, ergeben Vektoren, die nah beieinander liegen. Zwei verschiedene Personen liegen weit auseinander.

Das ist der gesamte Mechanismus hinter “Personen” in Ihrer Bibliothek. Wir schlagen Ihr Gesicht in keiner externen Datenbank nach, und an nichts hängt ein Name, bis Sie selbst eine Person benennen. Das Modell misst die Geometrie eines Gesichts und wandelt sie in Zahlen um, dann gruppiert es die Zahlen, die nah beieinander liegen. Immichs eigener Leitfaden zu Gesichtsclustern beschreibt, wie sich diese Gruppierung feinjustieren lässt. Die Fingerabdrücke bleiben in unserem System, auf unserer Hardware. Sie sind niemals das Produkt.

PP-OCRv5: den Text in Ihren Bildern lesen

Die neueste der drei ist OCR, optische Zeichenerkennung, hinzugefügt in Immich Version 2.2. Sie verwendet PP-OCRv5, ein Modell aus Baidus PaddleOCR-Projekt. OCR ist das, was Sie nach Wörtern suchen lässt, die in einem Foto vorkommen: ein Straßenschild, eine Ladenfront, ein Whiteboard, das Etikett auf einer Flasche.

Auch das funktioniert in zwei Stufen, und die Aufteilung spiegelt die Gesichtserkennung wider.

Zuerst erkennt es Text. Das Modell findet die Bildbereiche, die Schrift enthalten, und zeichnet Kästen darum, so wie das Gesichtsmodell Gesichter umrahmt. Ein Foto einer Straße kann an fünf Stellen Text haben: ein Schild, ein Nummernschild, ein Plakat, eine Speisekarte, ein Bus. Jedes wird zu einem Kasten.

Dann liest es. Für jeden Kasten ermittelt ein zweites Modell, welche Zeichen tatsächlich dort stehen, und wandelt sie in echten, maschinenlesbaren Text um. Dieser Text geht in den Suchindex, sodass Sie später nach “Pizzeria” suchen und das Foto der Restaurantfront finden können, obwohl Sie nie eine Bildunterschrift getippt haben.

Der Kompromiss ist so ein typisches Marc-Detail, das erwähnt werden sollte: OCR ist gut bei klarem gedrucktem Text in unterstützten Schriften und deutlich schwächer bei Handschrift oder stark stilisierten Schriftarten. Immich unterstützt offiziell Englisch, Chinesisch und Japanisch, wobei Sprachen mit lateinischer Schrift in der Regel mit etwas geringerer Genauigkeit funktionieren, wie im OCR-Sprachthread des Projekts erörtert. Es ist eine wirklich nützliche Funktion, keine magische.

Warum all das auf einer GPU so viel besser läuft

Jedes Modell oben führt im Kern dieselbe Art von Rechenoperation aus: enorme Mengen kleiner Multiplikationen und Additionen, angeordnet als Matrixmathematik. Ein Foto in einen Vektor umzuwandeln sind Millionen dieser Operationen. Diese eine Tatsache erklärt die gesamte Hardwaregeschichte.

Eine CPU hat eine kleine Anzahl sehr leistungsfähiger Kerne, eine Handvoll bis zu ein paar Dutzend. Jeder Kern ist flexibel und schnell und arbeitet Aufgaben weitgehend nacheinander ab. Dieses Design ist hervorragend für die abwechslungsreiche, verzweigte Arbeit, die ein Server den ganzen Tag leistet. Es passt schlecht dazu, dieselbe einfache Multiplikation ein paar Millionen Mal hintereinander auszuführen.

Eine GPU ist das Gegenteil. Sie hat Tausende einfacherer Kerne, gebaut, um dieselbe Operation gleichzeitig über riesige Zahlenmengen auszuführen, parallel. Grafikkarten wurden entworfen, um Millionen von Pixeln gleichzeitig einzufärben, und es stellt sich heraus, dass Machine-Learning-Inferenz dieselbe Art von Problem ist: dieselbe Mathematik, über viele Daten wiederholt. Statt dass die Millionen Operationen eines Fotos Welle für Welle durch ein paar CPU-Kerne rieseln, verteilen sie sich gemeinsam über Tausende von GPU-Kernen.

Das Ergebnis ist keine kleine Verbesserung, es ist eine andere Größenordnung an Geschwindigkeit für genau diese Arbeitslast. Immich bietet genau dafür etwas in seiner Dokumentation zur Hardwarebeschleunigung, die es dem Machine-Learning-Dienst erlaubt, auf CUDA, ROCm oder OpenVINO statt auf der CPU zu laufen. Berichte aus der Community geben ein Gefühl für die Größenordnung. Auf der CPU ist Smart Search durchweg die langsamste der Machine-Learning-Aufgaben, und Nutzer beschreiben sie als Engpass beim Indexieren einer großen Bibliothek. Auf bescheidener GPU-Hardware dokumentiert ein Bericht das Embedding von rund 300.000 Fotos in weniger als einer Nacht. Das sind externe Zahlen aus fremden Aufbauten, nicht unsere eigenen, aber die Richtung ist überall konsistent: Die GPU arbeitet den Rückstand in einem Bruchteil der Zeit ab.

Die Karten, die wir dafür gewählt haben, sind ältere Consumer-Grafikkarten, keine neuen Rechenzentrums-Beschleuniger. Das ist eine bewusste Entscheidung, und sie bringt Kompromisse mit sich, die erwähnenswert sind. Eine solche Karte hat immer noch Tausende paralleler Kerne und genug internen Speicher, um diese Modelle bequem zu halten, und mehr braucht diese Arbeitslast nicht. Die Modelle sind nach heutigen Maßstäben nicht groß. CLIP ist das schwerste der drei, während die Gesichts- und OCR-Modelle vergleichsweise leicht sind. Leistungsfähige ältere Hardware wiederzuverwenden hält gutes Silizium im Dienst, statt es ins Regal zu stellen, und es hält die gesamte Pipeline auf Geräten, die uns vollständig gehören.

Auf der anderen Seite der Rechnung stehen echte Kosten, und etwas anderes zu behaupten wäre unehrlich. Eine GPU zieht unter Last mehr Strom als eine untätige CPU, und eigene Hardware zu betreiben bedeutet, dass wir die Wartung, die Treiber und den Strom tragen. Wir halten das für den richtigen Kompromiss. Pro verarbeitetem Foto erledigt die GPU die Arbeit mit weit besserer Effizienz, und es bedeutet, dass die KI, die Ihre Erinnerungen liest, auf Maschinen läuft, die wir kontrollieren, nach europäischem Recht, statt in die Cloud eines anderen zur Verarbeitung geschickt zu werden.

Vorerst betreiben wir die Standardmodelle von Immich, dieselben, die jeder Immich-Nutzer von Haus aus bekommt. Der Grund, warum dieser Hardwareschritt über Geschwindigkeit hinausgeht, ist Spielraum. Größere Modelle brauchen in der Regel mehr Rechenleistung und mehr Speicher, um in einem brauchbaren Tempo zu laufen, genau das, was eine CPU nicht liefern konnte. Mit unseren eigenen GPUs an Ort und Stelle wird eine größere CLIP-Variante für schärfere Suche oder ein schwereres Gesichtsmodell für bessere Clusterbildung zu einer praktikablen Option statt zu einem Ding der Unmöglichkeit. Wir machen hier keine Versprechen zu konkreten Modellen. Der Punkt ist, dass dieser Schritt die Tür öffnet, und bessere Ergebnisse für unsere Kunden sind der Grund, hindurchzugehen.

Es gibt einen Haken beim Wechsel zu einem größeren Modell, und darüber sollten wir offen sein. Ein anderes Modell erzeugt andere Vektoren. Die Zahlen, die ein CLIP-Modell einem Foto zuweist, bedeuten einem anderen CLIP-Modell nichts, Sie können Alt und Neu also nicht mischen. Sollten wir jemals zu einem größeren Modell wechseln, müssten wir die Embeddings für jedes Foto in der Bibliothek jedes Nutzers von Grund auf neu berechnen, auf unseren eigenen GPUs. Für eine große Nutzerbasis ist das eine enorme Menge Rechenarbeit, und es ist genau die Art von Aufgabe, die auf CPUs aussichtslos und auf GPUs nur eine große Aufgabe ist. Dieser Schritt bringt uns der Bereitschaft dafür näher, aber wir sind noch nicht so weit. Wenn es so weit ist, ist das einen eigenen Blogbeitrag wert.

Warum wir es selbst tun

Keines dieser Modelle ist exotisch, und keines ist geheim. Das ist die Natur des Bauens auf Open Source: Sie können genau nachlesen, was CLIP, buffalo_l und PP-OCRv5 tun, und wir auch. Die Entscheidung, die Ihre Privatsphäre wirklich prägt, ist nicht, welches Modell läuft, sondern wo es läuft und wer es betreibt.

Wir betreiben sie auf unseren eigenen GPUs, in unserer eigenen Umgebung, auf europäischem Boden. Ihre Fotos werden von Maschinen gelesen, für die wir verantwortlich sind, und die Vektoren und Fingerabdrücke, die aus diesem Prozess hervorgehen, bleiben bei uns und werden niemals verkauft. Das ist der Teil, den Big Tech Ihnen nicht bieten wird, denn für sie ist das Lesen Ihrer Fotos das Geschäftsmodell, keine Funktion.

Um klar zu sagen, wo wir stehen: Das ist ein erster Schritt, nicht das fertige Bild. Die Machine-Learning-Modelle laufen jetzt auf unseren eigenen GPUs, aber noch läuft nicht unsere gesamte Plattform auf Hardware, die uns gehört. Selbst betriebene Infrastruktur bauen wir Stück für Stück auf, und die KI, die Ihre Fotos liest, war ein bewusster Startpunkt, weil sie der sensibelste Teil ist. Wir sagen Ihnen lieber genau, was heute wo läuft, als vorzugeben, weiter zu sein, als wir sind. Rechnen Sie damit, dass wir das in künftigen Beiträgen ausbauen, wenn mehr vom Stack auf unsere eigene Hardware umzieht.

Wenn Sie eine Fotobibliothek mit einer so leistungsfähigen Suche möchten, ohne die zugrunde liegenden Daten an ein Unternehmen zu geben, das damit Geld verdient, dann ist das genau das, was wir bauen.

Sehen Sie, was wir bieten →

Ein Hinweis zu den Bildern: Die Infografiken in diesem Beitrag wurden mit KI erstellt. Wir finden, dass sie ihren Platz verdienen, weil sie diese Ideen anschaulicher machen.