Echtzeitanbieter
ADK-Rust unterstützt zwei Echtzeit-Backends über dieselbe RealtimeModel-Schnittstelle,
sodass eine Anwendung beide anbieten und pro Sitzung wechseln kann. Diese Seite behandelt die
Modelle, Stimmen, Endpunkte, Authentifizierung und die Auswahl.
OpenAI Realtime (GA)
use adk_realtime::openai::OpenAIRealtimeModel;
use adk_realtime::model::BoxedModel;
use std::sync::Arc;
let model: BoxedModel = Arc::new(OpenAIRealtimeModel::new(
std::env::var("OPENAI_API_KEY")?,
"gpt-realtime-2.1",
));
| Modell | Verwendung |
|---|---|
gpt-realtime-2.1 | Aktuelles Speech-to-Speech-Produktionsmodell und Standardwahl. |
gpt-realtime-translate | Dedizierter Übersetzungsinterpreter (anderer Endpunkt; siehe Beispiel für Live-Übersetzung). |
- Transport: WebSocket (
openai-Funktion) oder WebRTC (openai-webrtc, benötigtcmake). - Audio: 24 kHz PCM16 ein- und ausgehend.
- Stimmen:
marin(eine natürliche GA-Stimme),alloyund weitere; festgelegt mitRealtimeConfig::with_voice("marin"). - Authentifizierung:
OPENAI_API_KEY. Der Schlüssel befindet sich auf Ihrem Server (niemals im Browser).
Gemini Live
use adk_realtime::gemini::{GeminiLiveBackend, GeminiRealtimeModel};
let model: BoxedModel = Arc::new(GeminiRealtimeModel::new(
GeminiLiveBackend::studio(std::env::var("GEMINI_API_KEY")?),
"models/gemini-3.1-flash-live-preview",
));
| Modell | Verwendung |
|---|---|
models/gemini-3.1-flash-live-preview | Live-Modell mit halber Kaskade. Ruft Tools zuverlässig auf und akzeptiert Videoframes. Standardauswahl. |
models/gemini-live-2.5-flash-native-audio | Modell mit nativem Audio – die natürlichste Stimme und das Modell, das affektiven Dialog unterstützt. Schwächere Tool-Aufrufe. |
models/gemini-3.5-live-translate-preview | Dediziertes Übersetzungsmodell (siehe das Übersetzungsbeispiel). |
- Transport: WebSocket (Funktion
gemini, AI Studio) oder Vertex AI Live (vertex-live, OAuth2 / ADC — siehe Echtzeit-Agenten). - Audio: 16 kHz PCM16 Eingang, 24 kHz PCM16 Ausgang.
- Stimmen:
Koreund weitere;with_voice("Kore"). - Authentifizierung:
GEMINI_API_KEY(oderGOOGLE_API_KEY).
Modellnamen unterscheiden sich je nach Endpunkt. AI Studio (API-Schlüssel) verwendet Namen wie
models/gemini-3.1-flash-live-preview; Vertex/Agent Platform verwendet andere Namen. Die Crate-ImplementierungGeminiLiveBackend::studio(...)verwendet AI Studio über denv1alpha-Endpunkt (der auch für affektiven Dialog erforderlich ist).
Ein Modell auswählen
- Allgemeine Sprachinteraktion + Tools →
gpt-realtime-2.1odergemini-3.1-flash-live-preview. Beide rufen Tools zuverlässig auf. Gemini eignet sich besser für kontinuierliches Video. - Natürlichste Stimme / emotionsbewusst → Gemini native-audio
(
gemini-live-2.5-flash-native-audio) mit affektivem Dialog — mit einer gewissen Einbuße bei der Zuverlässigkeit von Tool-Aufrufen. - Schwerpunkt auf Schlussfolgerungen →
gpt-realtime-2.1. - Übersetzung → die dedizierten Übersetzungsmodelle (mit eigenem Protokoll).
Einen Anbieter pro Sitzung auswählen
Anwendungen lesen den Anbieter typischerweise aus einer Anfrage und erstellen das passende Modell. Da sich die Audio-Raten unterscheiden, sollten auch diese offengelegt werden:
#[derive(Clone, Copy)]
enum Provider { OpenAI, Gemini }
impl Provider {
fn audio_rates(self) -> (u32, u32) { // (input, output)
match self {
Provider::OpenAI => (24_000, 24_000),
Provider::Gemini => (16_000, 24_000),
}
}
}
fn build_model(p: Provider) -> anyhow::Result<(BoxedModel, &'static str)> {
Ok(match p {
Provider::OpenAI => (
Arc::new(OpenAIRealtimeModel::new(std::env::var("OPENAI_API_KEY")?, "gpt-realtime-2.1")),
"marin",
),
Provider::Gemini => (
Arc::new(GeminiRealtimeModel::new(
GeminiLiveBackend::studio(std::env::var("GEMINI_API_KEY")?),
"models/gemini-3.1-flash-live-preview",
)),
"Kore",
),
})
}
Die Beispiele ermöglichen es, all diese Werte mit Umgebungsvariablen
(OPENAI_REALTIME_MODEL, GEMINI_REALTIME_MODEL) zu überschreiben, sodass du ein Modell festlegen kannst, ohne
neu zu kompilieren.
Fähigkeitsmatrix
OpenAI gpt-realtime-2.1 | Gemini 3.1-flash-live | Gemini native-audio | |
|---|---|---|---|
| Stimme (Audio ein/aus) | ✅ | ✅ | ✅ |
| Live-Transkripte | ✅ | ✅ | ✅ |
| Serverseitige Tools | ✅ (zuverlässig) | ✅ (zuverlässig) | ⚠️ (schwächer) |
| Videobilder | ✅ (Bildelemente) | ✅ (kontinuierlich) | ✅ (kontinuierlich) |
| Affektiver Dialog | ❌ | ❌ | ✅ |
Weiter: Tools →
Diagnose und Datenschutz für Payloads
Echtzeit-Frames enthalten Transkripte, Tool-Argumente, Tool-Ergebnisse und Identifikatoren. Wenn die Deserialisierung eines erkannten Ereignisses fehlschlägt – aufgrund einer Schemaabweichung beim Anbieter –, meldet die Warnung eine feldsichere Zusammenfassung und hält den Frame zurück:
| Feld | Inhalt |
|---|---|
event_type | Der Ereignistyp des Providers, bei dem ein Fehler aufgetreten ist |
error | Der Deserialisierungsfehler |
payload.bytes | Framegröße in Bytes |
payload.digest | Kurzer Digest zur Zuordnung von Wiederholungen derselben Abweichung |
payload.raw | <redacted>, sofern die Payload-Aufzeichnung nicht einkompiliert ist |
Hinweis: Der Digest gruppiert Protokollzeilen innerhalb eines Laufs. Er ist kein kryptografischer Digest und nicht prozessübergreifend stabil.
Um Drift mit dem vorliegenden Frame zu diagnostizieren, kompilieren Sie adk-realtime mit dem
Feature record-payloads, das die ersten 300 Bytes aufzeichnet:
[dependencies]
adk-realtime = { version = "2.1.0", features = ["openai", "record-payloads"] }
Das Feature ist standardmäßig deaktiviert. Dies ist eine bewusste Entscheidung pro Build, da Schema-Drift genau der Zeitpunkt ist, an dem Betreiber die Protokollerfassung und -aufbewahrung ausweiten.