Pipecat: Echtzeit-Sprachagenten sind eine Pipeline, kein Monolith

Pipecat: Echtzeit-Sprachagenten sind eine Pipeline, kein Monolith

Ein Sprachagent ist nie eine einzige Sache. Er ist ein Mikrofon, eine Spracherkennung, ein LLM, eine Sprachausgabe und ein Lautsprecher — jedes mit eigener Latenz, eigenen Fehlerbildern und eigenem Anbieter. Das schwierige Problem ist keine einzelne Komponente; es ist, sie in Echtzeit so zu verschalten, dass sich nicht der ganze Stack roboterhaft anfühlt. Pipecats Antwort besteht darin, diese Verschaltung als explizite Pipeline zu modellieren — eine Reihe kombinierbarer Prozessoren, durch die typisierte Datenframes fließen. Dieser erweiterte Durchgang geht in die Architektur, die Latenzzahlen, die Transport-Kompromisse und den Vergleich von Pipecat mit den Alternativen.

Was Pipecat tatsächlich ist

Pipecat ist ein quelloffenes Python-Framework für den Bau von Echtzeit-Sprach- und multimodalen Konversationsagenten, entwickelt und gepflegt von Daily — demselben Unternehmen hinter der WebRTC-Plattform Daily — gemeinsam mit der Pipecat-Entwicklergemeinschaft. Es ist kein einzelnes Modell und nicht das SDK eines einzelnen Anbieters: Es ist eine Orchestrierungsschicht zwischen Ihrer Anwendung und einem Katalog von KI-Diensten (STT, TTS, LLM und mehr), die sie in einen latenzbewussten Verarbeitungsgraphen leitet. (Quelle: pipecat.ai https://www.pipecat.ai/, Pipecat README https://github.com/pipecat-ai/pipecat.)

Die offizielle Dokumentation fasst es präzise zusammen: „Quelloffenes Python-Framework für den Bau von Sprach- und multimodalen KI-Pipelines. Orchestriert über 100 KI-Dienste mit extrem niedriger Latenz.“ (Quelle: Pipecat overview docs https://docs.pipecat.ai/overview/introduction.)

Das wichtigste Wort in diesem Satz ist Pipeline. Sprachagenten sind eine Pipeline, kein Monolith.

Die Architektur: Frames, Prozessoren, Pipelines, Worker

Die Dokumentation baut das gesamte Framework auf vier grundlegenden Konzepten (Quelle: Overview of Pipecat https://docs.pipecat.ai/pipecat/learn/overview):

• Frames — typisierte Datenpakete, die durch die Anwendung wandern: Audio vom Mikrofon, transkribierter Text, LLM-Antworten, synthetisierte Sprache.
• Frame Processors — spezialisierte Bausteine. Ein STT-Prozessor wandelt Audioframes in Textframes; ein LLM-Prozessor wandelt Textframes in Antwortframes; ein TTS-Prozessor wandelt Antwortframes in Audioframes.
• Pipelines — verbinden Prozessoren zu einem Pfad, durch den Frames fließen. Die Pipeline übernimmt die Orchestrierung automatisch.
• Workers — ein Worker führt eine Pipeline aus, und ein Worker, der eine Pipeline besitzt, ist ein Agent. Ein eigenständiger Sprachbot ist ein einzelner PipelineWorker; Pipecat ist ein Multiagenten-System, daher können mehrere Worker laufen, die über einen gemeinsamen Bus koordinieren. Der WorkerRunner startet Worker und verwaltet ihren Lebenszyklus.

Pipecats Workertypen bauen aufeinander auf: BaseWorker (Bus + Lebenszyklus) → PipelineWorker (führt eine Pipeline aus) → LLMWorker (ergänzt eine LLM-Pipeline und die automatische @tool Registrierung) → LLMContextWorker (ergänzt einen eingebauten Kontext und Aggregator) → UIWorker (steuert eine Client-GUI über den RTVI-Kanal). (Quelle: Your First Agent https://docs.pipecat.ai/pipecat/learn/your-first-agent.) Zu beachten: PipelineTask ist heute ein veralteter Alias für PipelineWorker, und PipelineRunner für WorkerRunner — die kanonischen Agententypen in der Namensgebung nach 1.0.

Die kanonische Pipeline

Eine typische Pipecat-Pipeline sieht so aus (Quelle: Pipecat quickstart https://docs.pipecat.ai/pipecat/get-started/quickstart / learn/pipeline https://docs.pipecat.ai/pipecat/learn/pipeline):

pipeline = Pipeline([
    transport.input(),       # Receive audio from the browser/device
    stt,                     # Speech-to-text (e.g. Deepgram)
    user_aggregator,         # Add the user's message to LLM context
    llm,                     # Language model (e.g. OpenAI / Anthropic)
    tts,                     # Text-to-speech (e.g. Cartesia / ElevenLabs)
    transport.output(),      # Send audio back to the device
    assistant_aggregator,    # Add the bot's response to context
])

Die Daten fließen als Frames durch die Pipeline. Die Reihenfolge zählt: Audio muss transkribiert sein, bevor das LLM es sehen kann, und Text muss synthetisiert sein, bevor er abgespielt werden kann. Die Pipeline wird von einem Worker verwaltet:

worker = PipelineWorker(
    pipeline,
    params=PipelineParams(
        enable_metrics=True,
        enable_usage_metrics=True,
    ),
)

Die entscheidende Leistungserkenntnis ist, dass alles parallel läuft. Während das LLM noch die späteren Teile einer Antwort erzeugt, werden die früheren Token bereits in Sprache umgewandelt und an die Nutzer:in gestreamt. Streaming auf jeder Stufe — statt auf vollständige Antworten zu warten — ist das, was die Roundtrip-Zeit sofort wirken lässt. (Quelle: Overview of Pipecat https://docs.pipecat.ai/pipecat/learn/overview.)

Integrationen: die Behauptung von über 100 Diensten, geprüft

Die Behauptung der Dokumentation von „100+ AI services“ hält stand. Ich habe 107 eigenständige Seiten zu Dienstintegrationen im Pipecat README über alle Kategorien hinweg gezählt (Quelle: Pipecat README https://github.com/pipecat-ai/pipecat#-available-services):

• Spracherkennung (22): Deepgram, Whisper/OpenAI, Azure, AssemblyAI, Groq (Whisper), Google, AWS, Cartesia, ElevenLabs, Speechmatics, Soniox, Mistral, NVIDIA und mehr.
• LLMs (25): OpenAI, Anthropic, Gemini, Groq, Mistral, DeepSeek, Ollama, OpenRouter, Perplexity, Cerebras, Qwen, SambaNova, Together und mehr.
• Sprachausgabe (32): ElevenLabs, Cartesia, Deepgram, Azure, OpenAI, MiniMax, Piper, Rime, Resemble, Google, Hume und mehr.
• Speech-to-Speech (5): OpenAI Realtime, Gemini Multimodal Live, Grok Voice Agent, AWS Nova Sonic, Ultravox.
• Transporte (8): Daily (WebRTC), LiveKit (WebRTC), SmallWebRTC, FastAPI-WebSocket, WebSocket-Server, Vonage, WhatsApp, lokal.
• Telefonie-Serializer (6): Twilio, Telnyx, Plivo, Vonage, Genesys, Exotel.
• Dazu Video (HeyGen, Tavus, Simli), Audioverarbeitung (Silero VAD, Krisp Viva, Koala, RNNoise), Vision/Bild und mehr.

Das Schöne am Pipeline-Design ist, dass diese Dienste austauschbar sind. Sie können Deepgram gegen Soniox, OpenAI gegen Anthropic oder Cartesia gegen ElevenLabs tauschen, ohne den übrigen Code anzufassen — die Integrationsgrenzen werden von den Frametypen gezogen, nicht von einem einzelnen Anbieter. (Quelle: Pipecat quickstart https://docs.pipecat.ai/pipecat/get-started/quickstart.)

Warum niedrige Latenz zählt — und die konkreten Zahlen

Echtzeit-Sprache verzeiht nichts. Die akzeptierte Messlatte für ein „natürliches“ Gespräch liegt bei ungefähr unter einer Sekunde von Ende zu Ende, und Stille von mehr als einem Takt wirkt wie ein Fehler. Pipecats eigene Dokumentation nennt das Ziel direkt:

„Typische Sprachinteraktionen dauern für natürliche Gespräche 500–800 ms.“ (Quelle: Overview of Pipecat https://docs.pipecat.ai/pipecat/learn/overview)

Und der Quickstart wiederholt den Punkt: „Jeder Schritt erfolgt mit minimaler Latenz und schließt den vollen Roundtrip typischerweise in unter einer Sekunde ab.“ (Quelle: Pipecat quickstart https://docs.pipecat.ai/pipecat/get-started/quickstart.)

Weil Latenz eine erstklassige Angelegenheit ist, stellt Pipecat eingebaute Leistungsmetriken bereit, die sich mit enable_metrics=True aktivieren lassen (Quelle: Pipecat metrics docs https://docs.pipecat.ai/pipecat/fundamentals/metrics):

Metric               | Meaning                                                   
---------------------------------------------------------------------------------
TTFB             | Time To First Byte, in seconds                            
TTFA             | Time To First Audio (TTS services only)                   
Processing Time  | Time taken by the service to respond                      
Text Aggregation | Time from first LLM token to first complete sentence (TTS)

Die Beispielausgabe der Dokumentation zeigt, wie realistische Zahlen aussehen (Quelle: Pipecat metrics docs https://docs.pipecat.ai/pipecat/fundamentals/metrics):

AnthropicLLMService#0 TTFB: 0.8378
CartesiaTTSService#0 TTFB: 0.1717
CartesiaTTSService#0 text aggregation time: 0.2134
AnthropicLLMService#0 processing time: 2.4927

Der TTFB liegt also bei einigen hundert Millisekunden — die vollständige Generierung des LLM (2,5 s) spielt keine Rolle, weil das Streaming mit dem ersten Token beginnt, Audio abzuspielen. Das ist das ganze Spiel: nicht die Gesamtzeit bis zum letzten Token optimieren, sondern den TTFB.

Unterbrechungen und Turn-Erkennung

Natürliche Gespräche sind voller Unterbrechungen, und ein Sprachagent, der nicht unterbrochen werden kann, ist ein schlechter Sprachagent. Wenn die Nutzer:in zu sprechen beginnt, während der Bot spricht, sendet Pipecat ein UserStartedSpeakingFrame aus, das eine Unterbrechung auslösen kann — die aktuelle TTS-Ausgabe stoppen und die Nutzer:in das Wort übernehmen lassen.

In Pipecat 1.0 wanderte diese Mechanik von einem einzigen Pipeline-Flag allow_interruptions zu einer Reihe kombinierbarer Turn-Strategien (Quelle: Migration to 1.0 https://docs.pipecat.ai/pipecat/migration/migration-1.0, Turn Detection docs https://docs.pipecat.ai/pipecat/learn/speech-input):

• Turn-Start-Strategien erkennen den Sprechbeginn: VADUserTurnStartStrategy (VAD-basiert) und TranscriptionUserTurnStartStrategy (transkriptionsbasiert).
• Turn-Stopp-Strategien entscheiden, wann die Nutzer:in fertig ist, etwa TurnAnalyzerUserTurnStopStrategy gestützt auf ein Modell wie LocalSmartTurnAnalyzerV3.

VAD (Voice Activity Detection) ist das Signal auf unterster Ebene — es erkennt Sprache gegen Stille, nicht Bedeutung — und wird am Nutzerkontext-Aggregator über SileroVADAnalyzer konfiguriert. Die wichtigsten Parameter und ihre Standardwerte (Quelle: Silero VAD docs https://docs.pipecat.ai/api-reference/server/utilities/audio/silero-vad-analyzer):

• start_secs (Standardwert 0,2) — wie lange die Nutzer:in sprechen muss, bevor VAD Sprache als begonnen bestätigt. Niedriger bedeutet reaktionsschneller, aber empfindlicher; höher bedeutet weniger sensibel, kann aber ein schnelles „ja“/„nein“/„ok“ verpassen.
• stop_secs (Standardwert 0,2) — wie viel Stille bestätigt, dass die Nutzer:in aufgehört hat. Entscheidend für den Turn-Wechsel: ein kürzerer Wert lässt die STT früher abschließen. Die Dokumentation merkt an, dass die eingebauten STT-P99-Latenzwerte mit stop_secs=0.2.
• confidence und min_volume — Schwellenwerte, die nur die Latte dafür höher legen, was als Sprache gilt.

Ein nützlicher Tipp direkt aus der Dokumentation: Wenn der Bot übermäßig auf Hintergrundgeräusche reagiert, drehen Sie nicht an der VAD — entfernen Sie das Rauschen vorgelagert mit einem Audiofilter (Krisp VIVA, ai-coustics oder RNNoise), bevor das Audio VAD und STT erreicht. (Quelle: VAD Configuration https://docs.pipecat.ai/pipecat/learn/speech-input.)

WebRTC gegen WebSocket: die Transport-Kompromisse

Latenz ist nur so gut wie die Leitung, die das Audio trägt, und Pipecat unterstützt mehrere Transporte — DailyTransport, LiveKitTransport, SmallWebRTCTransport, FastAPIWebsocketTransport, WebsocketTransport, plus Telefonie-WebSocket-Transporte mit Provider-Serializern. (Quelle: Transports docs https://docs.pipecat.ai/pipecat/learn/transports.)

Die Dokumentation ist bei der Wahl eindeutig: Für jede Sprach-Anwendung von Client zu Server ist WebRTC die richtige Wahl. WebSocket wirkt einfacher, baut aber auf TCP auf, das für Echtzeit-Audio schlecht geeignet ist (Quelle: Choosing a Transport https://docs.pipecat.ai/client/concepts/choosing-a-transport):

• Head-of-Line-Blocking: TCP überträgt verlorene Pakete erneut und blockiert alles dahinter. Bei Audio ist ein verworfenes Paket besser als ein erwartetes — eine kurze Lücke klingt weit besser als ein Stocken.
• Kopplung an den Opus-Codec: Die Vorwärtsfehlerkorrektur und die Verschleierung von Paketverlusten bei Opus setzen das Zustellmodell von UDP voraus; auf TCP hilft diese Maschinerie nicht und kann schaden.
• Keine automatischen Zeitstempel: WebRTC übernimmt RTP-Zeitstempel und Jitter-Pufferung; bei WebSocket bleibt das Ihnen überlassen.
• Keine eingebaute Echounterdrückung: Die Browser-AEC ist in den WebRTC-Stack eingebaut und steht beliebigen WebSocket-Streams nicht zur Verfügung.
• Komplexität der Wiederverbindung: WebRTC behandelt ICE-Neustarts und Netzwerkwechsel; die Wiederverbindung von WebSocket (Ruhezustand und Aufwachen mobiler Geräte, Netzwerkwechsel) müssen Sie selbst nachbauen.

WebSocket ist geeignet für Server-zu-Server-Verbindungen (beide Seiten in stabilen Netzen), Telefonie-Anbieter (Twilio, Telnyx usw. streamen Medien über WebSocket mit einem FrameSerializer) oder reine Text-Bots. Die Folge: Ein geteiltes Konversationsnetz wie Twilio, bei dem Audio über den Anbieter per WebSocket zu Ihrem Server fließt, hat andere Latenzeigenschaften als ein direkter WebRTC-Browseranruf. (Quelle: Transports docs https://docs.pipecat.ai/pipecat/learn/transports.)

Multiagenten- und Sprachpipeline-Muster

Weil jede Pipeline ein Agent ist, skaliert Pipecat vom einzelnen Bot bis zu vollständigen Multiagenten-Systemen, in denen Spezialisten „übergeben, parallel auffächern und über einen gemeinsamen Bus koordinieren“. (Quelle: Pipecat README https://github.com/pipecat-ai/pipecat.) Der WorkerRunner erzeugt standardmäßig einen prozessinternen AsyncQueueBus; für verteilte Aufbauten übergibt man einen Netzwerkbus wie RedisBus oder PgmqBus. (Quelle: Your First Agent https://docs.pipecat.ai/pipecat/learn/your-first-agent.)

Dokumentierte Muster sind unter anderem (Quelle: Pipecat learning docs https://docs.pipecat.ai/pipecat/learn/overview):

• Mehrere LLM-Agenten — jeder Agent besitzt sein eigenes LLM, seine Werkzeuge und seinen Gesprächskontext.
• Agenten-Übergabe — Kontrolle zwischen Agenten übergeben, mit Aktivierung, Deaktivierung und Übergabe.
• Job-Koordination — Arbeit von einem Agenten an andere verteilen und Ergebnisse einsammeln.
• Verteilte Agenten — Agenten über Prozesse und Maschinen hinweg betreiben, die am selben Bus hängen.
• Proxy-Agenten — Agenten an verschiedenen Bussen über Prozessgrenzen hinweg verbinden.
• BusBridge — leitet Frames zwischen der Transport-Pipeline und dem Agentenbus weiter.

Das ist das Muster echten Pipeline-Denkens: Agenten als kombinierbare Rohre in einem Graphen statt als maßgeschneiderter Monolith pro Funktion.

Wie sich Pipecat mit den Alternativen vergleicht

Um Pipecat gerecht zu beurteilen, muss man es neben das halten, was es sonst am Markt gibt:

Framework               | Positioning                                                            | Transport                      | Tradeoffs                                                                                                                   
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Pipecat (Daily)     | Open-source orchestration framework, provider-agnostic                 | WebRTC + WebSocket + telephony | You assemble STT/LLM/TTS yourself; self-hosted or via Pipecat Cloud. Total control, most flexibility.                       
LiveKit Agents      | Open-source framework tightly coupled to LiveKit's WebRTC media server | WebRTC-first                   | First-class job dispatch, semantic turn detection, MCP support, telephony via LiveKit SIP; assumes you run a LiveKit server.
OpenAI Realtime API | Proprietary, hosted speech-to-speech API                               | WebRTC / WebSocket / SIP       | Lowest setup for speech-to-speech, streaming reasoning; but locked to OpenAI models and no provider mixing.                 
Vocode              | Open-source library for voice LLM apps                                 | Phone / Zoom / system audio    | Easy streaming with LLMs, telephony focus; historically has been "looking for community maintainers."                       
Vapi                | Paid hosted developer platform                                         | Phone calls + web              | Managed infrastructure, make/receive calls, dozens of providers, but it's a SaaS — you deploy on Vapi, not your own stack.  

LiveKit Agents

Das Agent Framework von LiveKit (auch livekit-agents) ist „für den Bau von Echtzeit-, programmierbaren Teilnehmern konzipiert, die auf Servern laufen“ — konversationelle, multimodale Sprachagenten. Stärken: ein vollständiges Plugin-Ökosystem (OpenAI, Deepgram, Cartesia), eingebaute Job-Planung und -Verteilung, semantische Turn-Erkennung (ein Transformermodell, das erkennt, wann die Nutzer:in fertig ist, und damit Unterbrechungen reduziert), native MCP-Unterstützung und enge Telefonie-Anbindung über den SIP-Stack von LiveKit. Es ist vollständig quelloffen und stark an die WebRTC-Infrastruktur von LiveKit gekoppelt. (Quelle: LiveKit Agents README https://github.com/livekit/agents.)

OpenAI Realtime API

Die Realtime API von OpenAI ist ein Speech-to-Speech-Ansatz: Statt STT → LLM → TTS zu verketten, streamt man rohes Audio an gpt-realtime-Modelle und erhält Audio zurück, mit Verbindungsoptionen über WebRTC, WebSocket und SIP. Sie glänzt bei Live-Audio mit geringer Latenz und minimalem Integrationsaufwand, und neuere Modelle ergänzen Reasoning in Speech-to-Speech-Abläufen. Der Kompromiss: ein anbieterspezifischer, geschlossener Stack — Deepgram-STT oder Cartesia-TTS lassen sich nicht einmischen, und auf einem eigenen Medienserver läuft er nicht. OpenAIs eigene Empfehlung lautet, die Realtime API für Live-Audio mit geringer Latenz zu nutzen und anfragebasierte Audio-APIs für Dateien und begrenzte Anfragen. (Quelle: OpenAI Realtime docs https://platform.openai.com/docs/guides/realtime.)

Vocode

Vocode ist eine quelloffene Python-Bibliothek, um „voice-based LLM apps in minutes“ zu bauen und sie auf Telefonanrufe, Zoom oder Systemaudio zu bringen, mit Streaming-Gesprächen. Ohne weitere Einrichtung integriert sie viele STT-, LLM- und TTS-Anbieter. Sie ist leichtgewichtiger als die Orchestrierung von Pipecat und weist historisch darauf hin, dass sie „aktiv nach Community-Maintainern sucht“ — sie ist also kleiner und wird im Wettbewerb der Frameworks weniger aktiv gepflegt. (Quelle: Vocode README https://github.com/vocodedev/vocode-python.)

Vapi

Vapi ist eine kommerzielle Entwicklerplattform, die „die komplexe Infrastruktur übernimmt, damit Sie sich auf großartige Sprach-Erlebnisse konzentrieren können“, mit Sprachagenten, die Anrufe annehmen und tätigen können. Man wählt aus Dutzenden STT-, LLM- und TTS-Anbietern und verwendet Primitive wie Assistants, Squads und einen Composer, um Agenten zu konfigurieren. Alles wird verwaltet — der schnellste Weg zu einem gehosteten Telefonagenten, aber die Bereitstellung erfolgt auf Vapis Plattform statt auf der eigenen Pipeline. (Quelle: Vapi intro https://docs.vapi.ai/quickstart/introduction.)

Das Fazit

Der Wandel in der Sprach-KI geht von Modellen zu Pipelines. Ein einziges aufrufbares LLM mit Audio rein und raus ist der Monolith im OpenAI-Stil — schnell als Demo, aber geschlossen und nicht über Anbieter hinweg skalierbar. Ein Pipeline-Framework wie Pipecat liefert die Architektur: typisierte Frames, austauschbare Anbieter, gestreamtes Parallelarbeiten, unterbrechbare Turn-Wechsel und Transporte, die zu Ihrem Netz passen. Es sind mehr Teile zu verdrahten, aber genau darin liegt der Unterschied zwischen einer Demo und einem Sprachagenten, den Sie tatsächlich formen können.

mic → input → STT → user_agg → LLM → TTS → output → speaker → assistant_agg
            └────── each stage streams, in parallel ──────┘

Quellen

1. Pipecat-Startseite (Ersteller und Maintainer): https://www.pipecat.ai/ — „Open source framework for voice and multimodal conversational AI. Maintained by Daily and the Pipecat developer community.“
2. Pipecat README (Architektur, Dienste, Multiagenten): https://github.com/pipecat-ai/pipecat
3. Pipecat-Übersichtsdokumentation (über 100 Dienste, extrem niedrige Latenz): https://docs.pipecat.ai/overview/introduction
4. Overview of Pipecat (Frames/Processors/Pipelines/Workers, 500–800 ms): https://docs.pipecat.ai/pipecat/learn/overview
5. Your First Agent (Workertypen, WorkerRunner, Busse): https://docs.pipecat.ai/pipecat/learn/your-first-agent
6. Pipeline & Frame Processing: https://docs.pipecat.ai/pipecat/learn/pipeline
7. Quickstart (kanonische Pipeline, Roundtrip unter 1 s, Kontext-Aggregatoren, RTVI): https://docs.pipecat.ai/pipecat/get-started/quickstart
8. Metrik-Dokumentation (TTFB/TTFA/Processing/Text Aggregation, Beispielzahlen): https://docs.pipecat.ai/pipecat/fundamentals/metrics
9. Migration auf 1.0 (allow_interruptions → Turn-Strategien): https://docs.pipecat.ai/pipecat/migration/migration-1.0
10. Spracheingabe, Turn-Erkennung und VAD (Parameter von SileroVADAnalyzer, Hinweis zu Rauschfiltern): https://docs.pipecat.ai/pipecat/learn/speech-input
11. Referenz zum Silero VAD Analyzer: https://docs.pipecat.ai/api-reference/server/utilities/audio/silero-vad-analyzer
12. Transport-Dokumentation (Transporttypen, WebRTC gegen WebSocket, Telefonie): https://docs.pipecat.ai/pipecat/learn/transports
13. Choosing a Transport (Kompromisse zwischen WebRTC und WebSocket im Client): https://docs.pipecat.ai/client/concepts/choosing-a-transport
14. LiveKit Agents README: https://github.com/livekit/agents
15. OpenAI Realtime — Dokumentation: https://platform.openai.com/docs/guides/realtime
16. Vocode README: https://github.com/vocodedev/vocode-python
17. Vapi — Einführung: https://docs.vapi.ai/quickstart/introduction

Alle Angaben oben wurden gegen die offizielle Pipecat-Dokumentation (docs.pipecat.ai), die Seite pipecat.ai, das GitHub-README von pipecat und die verlinkten Quellen der Wettbewerber geprüft. Die Behauptung „100+ services“ wird durch die 107 im Pipecat README gelisteten Seiten zu Dienstintegrationen gestützt (22 STT, 25 LLM, 32 TTS sowie Speech-to-Speech, Transporte, Serializer, Video, Audio, Vision, Memory und Analytics).