Ein Server oder zwei? So platzieren Sie eine KI-Anwendung und ihren Inferenzdienst

Beginnen Sie mit den beiden Bereitstellungsmustern

Bei einer gemeinsamen Bereitstellung laufen die nutzerseitige KI-Anwendung und der Dienst für die Modellinferenz auf demselben Server. Sie können weiterhin getrennte Softwareprozesse oder Container sein, verwenden aber denselben Host.

Bei einer getrennten Bereitstellung sendet die Anwendung Inferenzanfragen an einen Dienst auf einem anderen Server oder an einen verwalteten Endpunkt. Microsoft beschreibt ein Muster, bei dem Remoteclients einen zentral betriebenen Modellendpunkt gemeinsam nutzen ([Microsoft-Dokumentation](https://learn.microsoft.com/en-us/windows-server/ai/local-ai-inference)). Das belegt dieses spezifische Muster; es vergleicht nicht die beiden Anordnungen und legt auch nicht fest, welche vorzuziehen ist.

Die folgenden Fragen helfen Ihnen dabei, Ihre eigenen Anforderungen zu untersuchen. Sie sind keine allgemeingültigen Empfehlungen dazu, welche Topologie leistungsfähiger oder einfacher zu betreiben ist.

• Gemeinsame Bereitstellung: Was würde es für Ihre Ressourcen, Wartungsarbeiten und Wiederherstellungsmaßnahmen bedeuten, einen Host gemeinsam zu nutzen?
• Getrennte Bereitstellung: Von welchen Netzwerken, Endpunkten und Zuständigkeiten wäre die Anwendung abhängig?

Erfassen Sie die Komponenten und zu prüfenden Fragen

Stellen Sie das System als Komponenten und Verbindungen dar, nicht nur als Liste von Servern. Berücksichtigen Sie die nutzerseitige Anwendung, die Inferenzlaufzeit, Modelldateien, Datenbank, Datei- oder Objektspeicher, externe APIs, Identitätssysteme und Hintergrundaufgaben. Kennzeichnen Sie, welche Komponenten eine Anfrage benötigt und welche optional sind.

Notieren Sie für jede Komponente, wo sie ausgeführt wird, wer sie betreut, welche Ressourcen sie nutzt und was Nutzer bei einem Ausfall erleben würden. Prüfen Sie diese Punkte anhand der unterstützten Konfiguration Ihrer Anwendung und Ihrer eigenen Betriebsanforderungen. Sie ergeben sich nicht automatisch aus der gewählten Anordnung.

Halten Sie fest, welche Aufgaben Nutzer ausführen, welche gleichzeitige Nutzung Sie erwarten und ob Anfragen in Schüben eintreffen. Wenn Ihnen diese Werte nicht bekannt sind, behandeln Sie sie als offene Fragen für einen Pilotversuch, statt fehlende Angaben mit allgemeinen Leistungsschätzungen zu ersetzen.

• Listen Sie Anwendung, Inferenzdienst, Datenbank, Speicher, geplante Aufgaben und externe APIs auf.
• Notieren Sie für jede Verbindung ihren Zweck, ihre Richtung, die verwendeten Zugangsdaten und das erwartete Verhalten, wenn die Abhängigkeit nicht verfügbar ist.
• Ermitteln Sie mögliche gemeinsam genutzte Ressourcen, die Sie genauer untersuchen sollten, etwa die Nutzung derselben CPU-, Arbeitsspeicher-, Beschleuniger-, Speicherplatz- oder Netzwerkkapazität durch Anwendungsaktivitäten und Modellausführung.
• Halten Sie fest, wo Modelldateien, Prompts, hochgeladene Dokumente, generierte Antworten und Anwendungsdatensätze gespeichert werden.

Fragen zur gemeinsamen Bereitstellung

Eine gemeinsame Bereitstellung kommt infrage, wenn Sie erwägen, beide Dienste auf einem Host zu betreiben. Prüfen Sie vor der Entscheidung, ob Ihre Anwendung die vorgesehene Verbindung unterstützt, ob die Modelldateien in Ihren Speicherplan passen und ob Ihr Team beide Komponenten überwachen und wiederherstellen kann.

Fragen Sie sich, was geschieht, wenn Anwendungsaktivitäten und Inferenz um Ressourcen konkurrieren oder wenn ein Wartungsereignis beziehungsweise ein Problem mit dem Host beide Dienste betrifft. Die Antwort hängt von Ihrer Konfiguration und dem für Sie akzeptablen Nutzererlebnis ab; allein aus der Anordnung lässt sich die Auswirkung nicht ableiten.

• Ist es für Sie akzeptabel, dass Anwendung und Inferenz denselben Host und dessen Wartungsabläufe nutzen?
• Wie überprüfen Sie das Verhalten der Anwendung, während repräsentative Inferenzaufgaben ausgeführt werden?
• Was sollen Nutzer erleben, wenn die Inferenz ausgelastet oder nicht verfügbar ist, und können sie weiterhin die nicht KI-gestützten Teile der Anwendung verwenden?

Fragen zur getrennten Bereitstellung

Ein separater Inferenzdienst schafft eine eigene Dienst- und Netzwerkgrenze. Prüfen Sie, ob diese Grenze einer konkreten Anforderung dient, etwa unterschiedlichen Wartungsabläufen, Ressourcenverwaltung oder Administration. Die Trennung allein belegt weder Isolation noch Sicherheit oder eine bessere Leistung.

Microsoft dokumentiert einen zentral betriebenen Inferenzendpunkt, den Remoteclients gemeinsam nutzen. Wenn Sie dieses Muster erwägen, prüfen Sie, wer den Endpunkt aufrufen darf, wie der Zugriff gewährt und entzogen wird und ob die Anwendungen dieselben Datenkategorien senden dürfen.

Überlegen Sie, wie sich die Anwendung verhalten soll, wenn sie den Endpunkt nicht erreichen kann, Zugangsdaten ungültig sind oder der Endpunkt einen Fehler zurückgibt. Legen Sie bei der Bewertung des Designs auch fest, wer für Überwachung, Wartung und Wiederherstellung des Endpunkts verantwortlich ist.

• Welche Anforderung soll eine separate Dienstgrenze erfüllen?
• Wer ist für den Endpunkt, die Zugriffskontrolle, die Wartung und die Reaktion auf Vorfälle zuständig?
• Wie werden Netzwerk- und Endpunktfehler behandelt und den Nutzern mitgeteilt?

Datenflüsse und Zuständigkeiten nachvollziehen

Zeichnen Sie den Datenpfad für eine konkrete Aufgabe auf. Er kann Nutzereingaben, Anweisungen der Anwendung, abgerufene Dokumente oder anderen Kontext, eine Anfrage an den Inferenzdienst und eine Antwort umfassen. Der tatsächliche Datenpfad hängt von der Anwendung und ihrer Konfiguration ab. Prüfen Sie daher, was tatsächlich gesendet wird, statt es anzunehmen.

Fragen Sie für jedes Datenelement, ob es eine Dienstgrenze überschreitet, wo es verarbeitet wird und ob es in Anwendungsdatensätzen, Dienstprotokollen, Sicherungen oder einem anderen System gespeichert wird. Leiten Sie Protokollierungs- oder Aufbewahrungsverhalten nicht daraus ab, wo die Dienste ausgeführt werden.

Halten Sie fest, wer auf Daten und Zugangsdaten zugreifen kann, welche Aufbewahrungseinstellungen gelten und wie Sicherungen gehandhabt werden. Prüfen Sie Aufrufe externer APIs gesondert: Eine Architektur mit zwei Servern bedeutet nicht, dass die gesamte Verarbeitung auf diese Server beschränkt bleibt.

• Verfolgen Sie Eingaben, abgerufenen Kontext, Anhänge, Ausgaben, Kennungen und Zugangsdaten getrennt.
• Prüfen Sie für jede Komponente, was protokolliert werden kann, was aufbewahrt wird, wer darauf zugreifen kann und wie lange die Daten gespeichert bleiben.
• Klären Sie, welche Anwendungsdaten und Konfigurationen in Sicherungen enthalten sind; dokumentieren Sie separat, wie Modelldateien und andere große Assets verwaltet werden.
• Benennen Sie Zuständige für Entscheidungen zu Daten, Zugriff und Aufbewahrung.

Beantworten Sie offene Fragen mit einem Pilotversuch

Ein Pilotversuch kann Ihnen helfen, Ihre Anwendung, Modellkonfiguration, Daten und Betriebsbedingungen einzuschätzen. Allgemeine Benchmark-Aussagen können nicht belegen, ob Ihre eigenen Aufgaben, das Muster gleichzeitiger Nutzung oder Ihre Erwartungen an das Fehlerverhalten akzeptabel sind.

Führen Sie repräsentative Aufgaben mit der Anordnung oder den Anordnungen aus, die Sie erwägen. Berücksichtigen Sie den normalen Betrieb sowie den stärksten realistischen Nutzungszeitraum, den Sie nachbilden können. Legen Sie vorab fest, was Sie beobachten möchten – etwa das Verhalten der Anwendung, den Abschluss der Inferenz, die Ressourcennutzung und die Eignung der Ergebnisse – und definieren Sie Akzeptanzkriterien für Ihren Anwendungsfall.

Testen Sie, sofern es für Ihre Umgebung angemessen ist, relevante Fehler unter kontrollierten Bedingungen, zum Beispiel einen nicht verfügbaren Endpunkt, eine unterbrochene Netzwerkverbindung oder ungültige Zugangsdaten. Dokumentieren Sie das beobachtete Verhalten und die Wiederherstellungsschritte, statt das Systemverhalten vorauszusetzen.

• Wählen Sie repräsentative Aufgaben und Eingaben aus, einschließlich relevanter Dokumentensuche oder externer API-Schritte.
• Testen Sie das erwartete Nutzungsmuster und alle realistischen gleichzeitigen Aktivitäten, die Sie nachbilden können.
• Beobachten Sie das Verhalten von Anwendung und Inferenz, während Anfragen ausgeführt werden.
• Definieren Sie im Voraus Akzeptanzkriterien, einschließlich Aufgabenerfüllung, Nutzererlebnis, Datenverarbeitung und Wiederherstellbarkeit.
• Dokumentieren Sie Konfiguration, Annahmen und Ergebnisse, damit Sie diese nach Änderungen vergleichen können.

Dokumentieren Sie die Entscheidung und überprüfen Sie sie bei veränderten Anforderungen

Dokumentieren Sie die gewählte Topologie, die damit zu erfüllenden Anforderungen und die der Entscheidung zugrunde liegenden Annahmen. Führen Sie Zuständige für Komponenten, Datenpfade, relevantes Fehlerverhalten und Ergebnisse des Pilotversuchs auf. Überprüfen Sie die Entscheidung erneut, wenn sich Arbeitslast, Wartungsabläufe, Zugriffsanforderungen oder Erwartungen an die Wiederherstellung ändern. Bewerten Sie die neue Anforderung, statt davon auszugehen, dass ein größeres Design automatisch besser ist.

Airbip bietet die verwaltete Bereitstellung von Kataloganwendungen als Docker-Workloads auf Airbip-Cloudservern, automatisiertes Routing und TLS-Zertifikate über Traefik und Let’s Encrypt, DNS-Prüfungen, Verwaltung des Dienstlebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Sicherungen. Diese Infrastrukturleistungen bestimmen nicht, wo ein bestimmter Inferenzdienst ausgeführt werden sollte, und entbinden Kunden nicht von ihrer Verantwortung für Entscheidungen zu Daten, Zugriff und Governance. Vergewissern Sie sich vor der Auswahl eines Bereitstellungsmodells, dass die gewünschte Anwendungskonfiguration und Anordnung des Inferenzdienstes Ihren Anforderungen entsprechen.

• Gewählte Anordnung und die Anforderung, die sie erfüllen soll.
• Annahmen zu Arbeitslast, gleichzeitiger Nutzung, Datenspeicherort und externen Abhängigkeiten.
• Daten, die Dienstgrenzen überschreiten, Entscheidungen zur Aufbewahrung und Zuständige für den Zugriff.
• Zuständigkeiten, relevantes Fehlerverhalten, Wiederherstellungsverfahren und Ergebnisse des Pilotversuchs.
• Bedingungen, unter denen die Entscheidung überprüft werden sollte.