Eine Funktion mit künstlicher Intelligenz kann nützlich sein und dennoch für einen bestimmten Vorgang zu langsam oder zu teuer ausfallen. Das Risiko entsteht, wenn jeder Aufruf so behandelt wird, als hätte er dieselben Anforderungen: Einen Text im Hintergrund zusammenzufassen, hat nicht dieselben Auswirkungen wie die Beantwortung einer Anfrage während des Bezahlvorgangs. Um die Kosten und Latenz von KI in PHP zu kontrollieren, empfiehlt es sich, für jeden Anwendungsfall ein operatives Budget festzulegen und im Voraus zu entscheiden, was beim Erreichen der Grenzen geschieht.
Dieses Budget ist weder ein Qualitätsversprechen noch eine Garantie dafür, dass der Anbieter innerhalb einer bestimmten Frist antwortet. Es ist eine Kombination aus Grenzwerten und Produktentscheidungen, mit der sich die Auswirkungen begrenzen, Nutzer informieren und das Verhalten der Anwendung kontrollieren lassen.
Ein eigenes Budget für jeden Vorgang
Ein operatives Budget umfasst die Ressourcen, die eine Funktion verbrauchen darf, und die Zeit, die abzuwarten sinnvoll ist. Dazu können eine maximale Dauer, eine Grenze für die geschätzten Kosten, eine Anzahl von Versuchen, eine Menge verarbeiteten Textes oder eine Kombination dieser Kontrollen gehören. Das Budget sollte an einen im Produkt klar erkennbaren Vorgang gebunden sein und keine abstrakte Konfiguration darstellen, die von allen Aufrufen gemeinsam genutzt wird.
Eine optionale Empfehlung in einem Dashboard kann beispielsweise entfallen, wenn das System zu lange braucht. Ist eine Funktion hingegen Teil eines wesentlichen Ablaufs, muss möglicherweise eine Alternative angeboten werden, mit der sich der Vorgang ohne KI abschließen lässt. Ein Klassifizierungsauftrag im Stapelbetrieb kann eine Warteschlange und einen ausstehenden Status akzeptieren, während eine interaktive Antwort eine strengere Wartezeitgrenze benötigt.
Klären Sie zunächst, welches Ergebnis die Nutzer benötigen, ob es genau zu diesem Zeitpunkt unverzichtbar ist und was geschieht, wenn es nicht verfügbar ist. Trennen Sie außerdem das Budget von der Qualitätsbewertung: Eine schnelle und günstige Antwort kann falsch sein, und eine richtige Antwort kann zu spät eintreffen, um noch nützlich zu sein. Für beide Aspekte sind eigene Messwerte und Kriterien erforderlich.
Erst messen, dann Schwellenwerte festlegen
Ohne eine Ausgangsbasis sind Grenzwerte reine Vermutungen. Erfassen Sie Kennzahlen für die verschiedenen Vorgangsarten und beobachten Sie, wie sie sich mit dem Volumen, der Eingabegröße und den Nutzungsbedingungen verändern. Mindestens sollten Sie die Gesamtdauer, gegebenenfalls die Zeit bis zum ersten brauchbaren Ergebnis, die Nutzungshäufigkeit und die geschätzten Kosten messen. Bei asynchronen Vorgängen sollten Sie auch die Wartezeit in der Warteschlange und die Verarbeitungszeit erfassen.
Ordnen Sie jede Messung einer Vorgangs-ID, einem Ergebnis und nicht sensiblen Kontextdaten zu, etwa der ungefähren Größe der Anfrage oder dem Ausführungsmodus. Vermeiden Sie es, Nutzertext, Geheimnisse, personenbezogene Daten oder vollständige Antworten zu speichern, wenn diese für die Diagnose nicht erforderlich sind. Wenn ein Fall untersucht werden muss, wenden Sie geeignete Zugriffskontrollen sowie Regeln zur Aufbewahrung und Datenminimierung an.
Die geschätzten Kosten sollten auf den für den genutzten Dienst verfügbaren Informationen beruhen und dessen Grenzen berücksichtigen. Verwechseln Sie sie nicht mit einer bestätigten Abrechnung: Preise, abgerechnete Einheiten und abrechenbare Bestandteile können variieren. Kann die Anwendung die Kosten vor dem Aufruf nicht zuverlässig berechnen, verwenden Sie alternative Kontrollen wie Ratenbegrenzungen, eine maximale Größe, Kontingente pro Nutzer oder überwachte Gesamtausgaben.
Budgets in überprüfbare Grenzwerte umsetzen
Legen Sie fest, wo die einzelnen Kontrollen greifen. Ein Limit pro Anfrage verhindert, dass eine einzelne Ausführung zu lange dauert oder zu viele Ressourcen verbraucht. Ein Kontingent pro Nutzer oder Konto begrenzt die wiederholte Nutzung. Ein Limit pro Prozess schützt einen Auftrag, der mehrere Vorgänge umfasst. Um die Gesamtausgaben zu kontrollieren, überwachen Sie außerdem den Gesamtverbrauch; ein individuelles Limit verhindert nicht, dass viele gleichzeitige Anfragen das Systembudget überschreiten.
Legen Sie auch das Verhalten bei erneuten Versuchen fest. Eine automatische Wiederholung kann die Kosten verdoppeln oder die Latenz erhöhen, besonders wenn unklar ist, ob der Dienst die Anfrage bereits verarbeitet hat. Definieren Sie, wie viele Versuche zulässig sind, bei welchen Fehlern sie erfolgen und welche Wartezeit gilt. Verwenden Sie Idempotenzschlüssel, sofern diese unterstützt werden und relevant sind, um doppelte Auswirkungen bei Vorgängen zu vermeiden, die Daten ändern.
Wird ein Schwellenwert erreicht, können Sie die Anfrage abbrechen, ihren Umfang reduzieren, sie in eine Warteschlange verschieben oder zur menschlichen Prüfung weiterleiten. Die passende Wahl hängt vom Anwendungsfall ab. Eine Teilausgabe ist nur dann akzeptabel, wenn die Benutzeroberfläche sie eindeutig kennzeichnet und das Ergebnis weiterhin sicher und nützlich ist. Ist die Aufgabe sensibel oder sind unvollständige Ergebnisse nicht akzeptabel, ist es möglicherweise besser, keine generierte Antwort anzuzeigen.
Kontrollen in einer PHP-Integrationsschicht umsetzen
Bündeln Sie externe Aufrufe in einer Integrationsschicht, die den Vorgang und sein Budget entgegennimmt, die entsprechenden Kontrollen anwendet und ein eindeutiges Ergebnis zurückgibt. So hängt die Geschäftslogik nicht direkt von einem Anbieter ab und interpretiert Wartezeiten und Fehler nicht an jeder Stelle der Anwendung anders.
Das folgende Beispiel erfordert PHP 8.0 oder höher, da es Constructor Property Promotion und benannte Argumente verwendet. Es ist unvollständig: Es prüft die Eingabegröße und übergibt dem Client ein Zeitlimit, implementiert aber weder Kontingente noch Ausgabenlimits oder eine Warteschlange. Diese Kontrollen müssen je nach Anforderungen der Anwendung separat hinzugefügt werden.
final class AiOutcome
{
public function __construct(
public string $status,
public ?string $content = null,
public ?string $reason = null,
) {}
}
function runAiOperation(
AiClient $client,
string $input,
int $timeoutSeconds
): AiOutcome {
if (strlen($input) > 12000) {
return new AiOutcome('rejected', reason: 'input_limit');
}
try {
$response = $client->generate($input, $timeoutSeconds);
return new AiOutcome('completed', $response->text);
} catch (TimeoutException $e) {
return new AiOutcome('timed_out', reason: 'timeout');
} catch (ProviderException $e) {
return new AiOutcome('unavailable', reason: 'provider_error');
}
}Client und Ausnahmen hängen von der gewählten Integration ab. Konfigurieren Sie in der Produktion das Zeitlimit auch im HTTP-Client und prüfen Sie die Größe, bevor Sie Daten senden. Der Status timed_out bedeutet, dass die Anfrage das Zeitlimit überschritten hat; er bedeutet nicht, dass sie in eine Warteschlange gestellt wurde oder fortgesetzt wird. Geben Sie den Status deferred nur zurück, wenn die Anwendung den Auftrag in einer Warteschlange gespeichert hat und über einen Prozess verfügt, der ihn fortsetzen und das Ergebnis mitteilen kann.
Ergänzen Sie die Kontrollebene um Ratenbegrenzungen oder Kontingente mit einem zwischen Prozessen koordinierten Zähler und überwachen Sie die Gesamtausgaben. Müssen Sie vor jedem Aufruf eine Kostenobergrenze durchsetzen, berechnen Sie den geschätzten Verbrauch der Anfrage und vergleichen Sie ihn mit dem verfügbaren Budget. Lässt sich der Verbrauch nicht zuverlässig schätzen, verwenden Sie alternative Grenzwerte und Ausgabenwarnungen. Gemeinsame Kontingente sollten nicht ausschließlich vom Speicher einer einzelnen PHP-Anfrage abhängen.
Geben Sie klar unterscheidbare Statuswerte zurück, zum Beispiel abgeschlossen, aufgrund eines Limits abgelehnt, Zeitüberschreitung oder nicht verfügbar. So kann die Geschäftslogik entscheiden, was angezeigt werden soll, ohne eine langsame Antwort mit einer qualitativ schlechten Antwort oder ein operatives Limit mit einem Anbieterausfall zu verwechseln.
Einen klaren und hilfreichen Fallback gestalten
Ein Fallback bedeutet weder, einen Fehler zu verbergen, noch ein alternatives Ergebnis als gleichwertig darzustellen. Er soll eine verständliche Nutzererfahrung erhalten, wenn die Funktion ihre Aufgabe nicht abschließen kann. Bei einer optionalen Aktion kann der Hinweis genügen, dass die Empfehlung nicht verfügbar ist, während der Vorgang fortgesetzt werden kann. Bei einer länger dauernden Aufgabe können Sie anzeigen, dass sie noch aussteht, und einen abrufbaren Status bereitstellen, sofern die Anwendung diesen zuverlässig verwalten kann.
Wenn sich der Umfang reduzieren lässt, erklären Sie, was ausgelassen wurde. Wird die Aufgabe zur Prüfung weitergeleitet, erwecken Sie nicht den Eindruck, das Ergebnis sei bereits validiert. Wird eine deterministische Alternative verwendet, etwa eine vorhandene Geschäftsregel, erläutern Sie deren Funktion, wenn der Unterschied die Entscheidung der Nutzer beeinflusst. Vermeiden Sie Nachrichten, die eine spätere Bereitstellung versprechen, wenn keine Warteschlange und kein Prozess vorhanden sind, die dieses Versprechen erfüllen können.
Ein Fallback bei Fehlern unterscheidet sich von der Budgetkontrolle: Er wird bei Situationen wie Nichtverfügbarkeit, Netzwerkfehlern oder ungültigen Antworten ausgelöst. Das Budget kann ausgeschöpft sein, obwohl der Dienst ordnungsgemäß funktioniert. Beide Mechanismen müssen getrennt definiert und getestet werden; für jede Ursache sind geeignete Statuswerte und Meldungen erforderlich.
Mit belastbaren Daten testen, warnen und nachjustieren
Testen Sie die Schwellenwerte mit repräsentativen Lasten und ungünstigen Szenarien: großen Eingaben, wiederholten Anfragen, langsamen Antworten, gleichzeitigen Aufrufen, Anbieterfehlern und Kontingentgrenzen. Prüfen Sie, was Nutzer sehen und was protokolliert wird. Beziehen Sie Abbruchfälle ein und stellen Sie sicher, dass eine gestoppte Anfrage nicht unnötig im Hintergrund weiter Ressourcen verbraucht.
Richten Sie Warnmeldungen für betriebliche Auffälligkeiten ein: steigende Latenz, mehr abgelehnte Anfragen, zunehmende geschätzte Ausgaben oder sich anhäufende ausstehende Aufträge. Eine Warnmeldung sollte auf einen Zustand hinweisen, der eine Untersuchung erforderlich macht, und die Analyse nicht ersetzen. Segmentieren Sie die Daten nach Vorgang, damit ein problematischer Ablauf nicht in einem allgemeinen Durchschnitt verborgen bleibt.
Überprüfen Sie die Grenzwerte, wenn sich das Volumen, die Produkterfahrung, die Eingabegrößen oder die technische Integration ändern. Setzen Sie sie nicht einfach herauf, um eine Warnmeldung verschwinden zu lassen: Ermitteln Sie zuerst, ob das Problem auf falsch definierten Erwartungen, eine unerwartete Last, einen Netzwerkausfall oder einen überarbeitungsbedürftigen Vorgang zurückzuführen ist.
Produktions-Checkliste
- Zweck: Für den Vorgang gibt es einen Anwendungsfall, eine Nutzergruppe und eine Alternative, falls die KI nicht antwortet.
- Messung: Dauer, Häufigkeit, Ergebnis und geschätzte Kosten werden erfasst, ohne unnötige sensible Daten zu sammeln.
- Grenzwerte: Es gibt geeignete Obergrenzen pro Anfrage und, falls erforderlich, pro Nutzer, Prozess und System.
- Verhalten: Wiederholungsversuche, Abbruch, Warteschlange und Reaktion auf jeden Schwellenwert sind festgelegt.
- Nutzererfahrung: Statuswerte und Meldungen unterscheiden zwischen Warten, Ablehnung wegen eines Limits und Dienstausfall.
- Betrieb: Es gibt Tests, Warnmeldungen und eine verantwortliche Person oder ein verantwortliches Team, das die Grenzwerte überprüft.
Die Kosten und Latenz von KI in PHP zu kontrollieren bedeutet nicht, eine einzige Wartezeit für die gesamte Anwendung auszuwählen. Vielmehr muss jede Grenze an einen konkreten Bedarf gebunden, ihre Auswirkung gemessen und im Voraus entschieden werden, welche Alternative das Produkt verständlich und sicher hält, wenn die Funktion nicht abgeschlossen werden kann.
