Mastra ergänzt TTFC- und TTFT-Metriken für die Agentenbeobachtung
Mastra hat seiner Plattform und seinem Studio Latenzmetriken für jeden Agenten- und Modellaufruf hinzugefügt. Damit können Entwickler messen, wie lange Nutzer auf eine Antwort warten und wie schnell ein Modell mit der Generierung beginnt. Die Metriken TTFC und TTFT lassen sich außerdem über Mastras CLI, Client SDK und Observability-Endpunkte abfragen.
- Mastra erfasst TTFC und TTFT jetzt in jedem Span.
- Plattform und Studio können Traces nach beiden Metriken filtern und sortieren.
- Selbst gehostete Projekte können DuckDB, PostgreSQL oder ClickHouse als Speicher verwenden.
- Latenzdaten sind über die CLI, das Client SDK und Observability-Endpunkte verfügbar.
Zwei Metriken für unterschiedliche Teile der Wartezeit
TTFC (Time to First Chunk) misst, wie lange ein Nutzer wartet, bevor überhaupt etwas angezeigt wird. TTFT (Time to First Token) misst, wie lange das Modell braucht, um mit der Antwort zu beginnen. Mastra zufolge helfen die beiden Metriken gemeinsam dabei, langsame Stellen in einem Agenten zu identifizieren und einen Messwert zu erhalten, den Teams gezielt verbessern können.
Das Unternehmen vergleicht den Ansatz mit Website-Performance-Metriken wie „Time to First Byte“ und „First Contentful Paint“. Bisher konnten Mastra-Nutzer durationMs verwenden, um die Gesamtdauer eines Laufs zu sehen. Sie konnten jedoch nicht feststellen, wie lange ein Nutzer auf die erste Antwort wartete oder ob die Verzögerung vom Modell oder vom eigenen Code verursacht wurde.
Metriken sind in Traces und Spans verfügbar
Mastra erfasst TTFC und TTFT jetzt in jedem Span, vom Modellaufruf bis zum Agentenlauf. Beide Werte stehen als Felder in Trace- und Span-Abfragen zur Verfügung, zusammen mit Status, Umgebung und Agentenname.
Auf der Mastra-Plattform und in Studio unterstützt der Tab „Traces“ die Filterung und Sortierung nach der Zeit bis zum ersten Chunk und der Zeit bis zum ersten Token. Auf der Plattform können Nutzer die entsprechenden Spalten in den Spalteneinstellungen aktivieren. Mastras Beschreibung des Ablaufs zeigt außerdem einen Coding-Agenten, der dieselben Daten abfragt, eine Latenzlücke auf einen langsamen Eingabeverarbeiter zurückführt und drei Lösungen vorschlägt.
Die Latenzmetriken funktionieren auf der Mastra-Plattform sowie in selbst gehosteten Mastra-Projekten, bei denen storage.observability DuckDB, PostgreSQL oder ClickHouse verwendet. Entwickler mit Trace-Daten außerhalb von Mastra können bestehende Historien über Trace-Importe übernehmen.
Vier Möglichkeiten zum Abfragen der Latenzdaten
Mastra nennt vier Zugangswege: Mastra CLI, Mastra-Plattform und Studio, Mastra Client SDK sowie Observability-Endpunkte. Die Beispiele in der Ankündigung suchen nach Läufen aus den vergangenen 7 Tagen, bei denen Nutzer mehr als 10 Sekunden auf den ersten Chunk warten mussten, sowie nach Läufen, bei denen das Modell mehr als 3 Sekunden zum Beginn der Antwort benötigte.
Für die CLI ist [email protected] oder neuer erforderlich. Studio benötigt [email protected] und @mastra/[email protected] oder neuer, während das Client SDK @mastra/[email protected] oder neuer voraussetzt. Für Anfragen sind ein Plattformzugriffstoken und eine Projekt-ID erforderlich. Mastra stellt separate Observability-Basis-URLs für die Regionen USA und EU bereit: https://observability.mastra.ai und https://observability.eu.mastra.ai.
Für Entwickler, die Agenten betreiben, bietet das Update eine Möglichkeit, Verzögerungen beim Start des Modells von Verzögerungen durch Anwendungscode zu trennen. Das kann Trace-Daten bei der Untersuchung langsamer Läufe aussagekräftiger machen. Die gleichen Latenzfelder stehen dabei sowohl über gehostete als auch über unterstützte selbst gehostete Bereitstellungen zur Verfügung.
