Plattformgrenzen

Die Grenzen kennen

Die Mistral Workflows-Plattform befindet sich im Public Preview (Stand April 2026). Wie jedes Orchestrierungssystem unterliegt sie technischen Beschränkungen, die Sie verstehen müssen, um robuste Workflows zu entwerfen. Diese Grenzen sind nicht nur Fußnoten in der Dokumentation; sie treten in der Produktion auf, oft spät im Spiel, als Serialisierungsfehler oder unerwartet abgebrochene Workflows ohne Warnung in Ihrem Code. Das Wissen darüber im Voraus verändert, wie Sie Ihre Verarbeitungslogik strukturieren.

Die folgende Tabelle fasst die wichtigsten Beschränkungen und die konkreten Konsequenzen eines Überschreitens zusammen.

Zwei Sekunden zwischen jeder Aktivität

Die Plattform erzwingt eine Mindestverzögerung von 2 Sekunden zwischen Aktivitätsaufrufen. Diese Latenz ist kein Einrichtungsproblem; sie ist inhärent für die Orchestrierungsarchitektur, die jedes Ereignis persistiert, bevor sie fortfährt. Es ist der Preis für Dauerhaftigkeit.

Die Auswirkung ist leicht zu berechnen und oft überraschend. Ein Workflow, der zehn sequenzielle Aktivitäten verknüpft, verbraucht mindestens zwanzig Sekunden Orchestrierungszeit, unabhängig davon, wie lange die Aktivitäten selbst benötigen. Wenn jede Aktivität in fünfzig Millisekunden läuft, haben Sie eine Aufgabe entworfen, die nur eine halbe Sekunde dauert, aber zwanzig Sekunden benötigt, um ein Ergebnis zurückzugeben.

Die Lösung besteht darin, Operationen, die nicht getrennt sein müssen, in einer einzigen Aktivität zu bündeln. Vergleichen Sie diese beiden Versionen desselben NLP-Pipelines.

# SUBOPTIMAL: 3 Aktivitäten = 6 Sekunden Orchestrierungs-Latenz
@workflows.workflow.define(name="pipeline_lent")
class SlowPipeline:
    @workflows.workflow.entrypoint
    async def run(self, text: str) -> dict:
        tokens = await tokenize(text)
        embeddings = await calculate_embeddings(tokens)
        clusters = await cluster(embeddings)
        return clusters

# OPTIMIZED: 1 Aktivität = 2 Sekunden Orchestrierungs-Latenz
@workflows.activity()
async def complete_nlp_processing(text: str) -> dict:
    tokens = tokenize_local(text)
    embeddings = calculate_embeddings_local(tokens)
    clusters = cluster_local(embeddings)
    return {"clusters": clusters}

@workflows.workflow.define(name="pipeline_rapide")
class FastPipeline:
    @workflows.workflow.entrypoint
    async def run(self, text: str) -> dict:
        return await complete_nlp_processing(text)

Die Regel für die Aufteilung wird einfach: Erstellen Sie eine separate Aktivität nur dann, wenn Sie die Persistenzgarantie zwischen zwei Operationen benötigen. Wenn zwei Operationen gemeinsam versagen können, ohne Probleme zu verursachen – wie lokale Tokenisierung und Embedding-Berechnung, die im Speicher verknüpft sind – bündeln Sie sie.

Zwei Megabyte pro Aufruf

Jeder Aktivitätsaufruf ist auf 2 MB für die Eingabe und 2 MB für die Ausgabe beschränkt, basierend auf der serialisierten JSON-Darstellung der Daten. Ein PDF-Bericht, eine Reihe von Bildern oder eine große CSV-Exportdatei überschreiten dies leicht und führen dazu, dass der Workflow mit einem Serialisierungsfehler fehlschlägt.

Die Lösung ist in einem Satz zusammengefasst: Überweisen Sie Referenzen, niemals Lasten. Die Aktivität lädt die Daten vom externen Speicher herunter, verarbeitet sie lokal (wo sie nur durch den Arbeitsspeicher des Workers begrenzt ist) und gibt die Ergebnis-URL zurück.

@workflows.activity()
async def traiter_gros_fichier(fichier_url: str) -> dict:
    """Download, process, and re-upload the file.
    Only URLs pass through the workflow."""
    async with httpx.AsyncClient() as client:
        # Download from S3/GCS
        response = await client.get(fichier_url)
        contenu = response.content  # Could be 100 MB

        # Process the file
        resultat = traiter(contenu)

        # Upload the result
        await client.put(
            "https://storage.example.com/résultats/output.json",
            content=resultat
        )

    return {"url_resultat": "https://storage.example.com/résultats/output.json"}

Das Ereignis- und Volumenbudget

Jede Ausführung ist auf 51.200 Ereignisse begrenzt. Die Plattform generiert ein Ereignis für den Start jeder Aktivität, die Fertigstellung jeder Aktivität, jedes empfangenen Signals und jedes ausgelösten Timers. In der Praxis kostet ein Aktivitätsaufruf etwa zwei bis drei Ereignisse, sobald Metadaten berücksichtigt werden, was einen Workflow mit hundert Aktivitäten auf etwa 250 bis 300 Ereignisse bringt. Mit anderen Worten, die Obergrenze erlaubt fünfzehn bis zwanzigtausend Aktivitätsaufrufe pro Ausführung: weit über das hinaus, was die meisten Anwendungsfälle erfordern.

Sie werden diese Grenze nur bei der Verarbeitung großer Mengen erreichen – zum Beispiel beim Durchlaufen von fünfzigtausend Dokumenten in einer einzigen Ausführung. Das Fortsetzungs-Muster, das in der nächsten Lektion detailliert wird, löst dies: Der Workflow verarbeitet eine Charge und startet dann einen neuen Workflow für die nächste Charge, wodurch der Ereignis-Zähler zurückgesetzt wird.

Die zweite Grenze betrifft das Volumen: Das kumulative Volumen aller Ereignisse in einer Ausführung darf 50 MB nicht überschreiten. Dies füllt sich schneller auf, wenn Ihre Aktivitäten reiche Objekte zurückgeben, da jedes Ergebnis in das Protokoll geschrieben wird. Dieselbe Reflexion gilt hier – geben Sie eine Kennung zurück statt einer vollständigen Struktur, speichern Sie Zwischenergebnisse in einem externen Dienst, paginate die Verarbeitung in Chargen – und dies reicht in den meisten Fällen aus.

Kein I/O im Workflow

Die letzte Zeile der Tabelle ist keine Größenbeschränkung, sondern eine Designregel, die bereits unter Determinismus behandelt wurde. Workflow-Code darf keine Eingabe- oder Ausgabeoperationen enthalten: keine Netzwerkkommunikation (httpx, aiohttp, requests), kein Lesen oder Schreiben von Dateien (open, aiofiles), kein Datenbankzugriff und kein Lesen von Umgebungsvariablen zur Steuerung von Verzweigungen. All diese Operationen leben in Aktivitäten, deren Ergebnisse protokolliert und daher identisch wiedergespielt werden können.

Kernaussagen

• Mindestlatenz von 2 Sekunden zwischen jeder Aktivität – bündeln Sie verwandte Operationen
• Maximale Eingabe/Ausgabe von 2 MB pro Aktivität – verwenden Sie externen Speicher für große Datenmengen
• 51.200 Ereignisse und 50 MB maximal pro Ausführung – verwenden Sie das Fortsetzungs-Muster für sehr lange Workflows
• Kein I/O im Workflow-Code – alles geht in Aktivitäten
• Diese Beschränkungen ergeben sich aus der zugrunde liegenden Temporal-Architektur und dem Status Public Preview