Decider V1.1 27B ist der aktualisierte Entscheidungs-Checkpoint von Perplexity. Er bewertet bereitgestellte Inhalte anhand einer definierten Frage und erzeugt Wahrscheinlichkeiten über die gültigen Antworten. Sein natives Artefakt besitzt einen Entscheidungs-Readout statt eines Sprachgenerierungs-Heads über das gesamte Vokabular. Das nützliche Ergebnis ist eine begrenzte Entscheidungsverteilung und ihre interpretierte Antwort, keine offene Erklärung und keine allgemeine Chat-Antwort.
Perplexity bezeichnet dieses Modell als Aktualisierung von Decider V1 27B, die dasselbe Backbone beibehält, mit Änderungen an der Attention-Konfiguration und mehr Trainingsdaten. Sein Backbone ist Qwen3.8-27B. Die Edition V1.1 sollte ihren eigenen Namen und ihre eigene Konfiguration behalten, statt als austauschbare Kopie des früheren Checkpoints beschrieben zu werden.
Das veröffentlichte Beispiel liefert eine Zeile mit einem Zustand und einer typisierten Auswahlfrage. Die Frage enthält Anweisungen und Kriterien, deren Schlüssel die semantischen Antworten sind und deren Beschreibungen festlegen, wann jede davon zutrifft. Das Modell sagt Wahrscheinlichkeiten vorher, anschließend interpretiert der Antwort-Helper des Herstellers diese Wahrscheinlichkeiten für die Frage. Das Inferenzbeispiel kann eine Liste von Zeilen verarbeiten, wobei jede Entscheidung an die Belege und die Frage ihrer Zeile gebunden ist.
Stellen Sie beim Routing von Anfragen die tatsächliche Nachricht und den relevanten Kontext bereit und definieren Sie dann die verfügbaren Abteilungen oder Kategorien. Eine beispielhafte Aufgabe könnte zwischen einem Integrationsfehler, einem Zugriffsproblem und einer Anfrage nach Produktinformationen unterscheiden. Formulieren Sie jede Beschreibung präzise genug, um einen Grenzfall zu entscheiden, und bewahren Sie die Optionsdefinitionen zusammen mit dem Ergebnis auf. Eine Kategorienverteilung kann dann eine Routing-Entscheidung oder einen Prüfschritt unterstützen, wenn Alternativen nah beieinanderliegen. Das vom Modell gewählte Ergebnis führt die Workflow-Aktion nicht selbst aus.
Die native Implementierung akzeptiert Bilder zusammen mit Zustand und Frage, und zwar als Bilddateien, als Bilder im Arbeitsspeicher oder als kodierte Bilddaten. Stellen Sie bei einem Dokumentbild oder Screenshot den visuellen Beleg bereit und stellen Sie eine geschlossene Frage, deren Optionen die relevanten Ergebnisse beschreiben. Benennen Sie das sichtbare Merkmal, auf das es ankommt, und liefern Sie den Textkontext, der zu seiner Interpretation nötig ist. Klassifizieren Sie beispielsweise, ob ein abgebildeter Artikel zu einer der bereitgestellten Produktkategorien gehört, statt das Entscheidungsmodell eine vollständige Produktbeschreibung schreiben zu lassen.
Der Prozessor erhält beim Skalieren das Seitenverhältnis und rundet die Bildseiten auf Vielfache von 32 Pixeln. Die dokumentierte verarbeitete Fläche beginnt bei 65.536 Pixeln und ist durch ein konfigurierbares Maximum begrenzt; der Standardwert beträgt 4.194.304 Pixel, also 2048 mal 2048. Jeder Patch von 32 mal 32 Pixeln ergibt ein visuelles Token, sodass dieser Standardwert bis zu 4.096 visuelle Tokens pro Bild erlaubt. Diese Werte beschreiben die native Bildaufbereitung des Herstellers, keinen allgemeinen Upload-Vertrag einer Anwendung.
Der dokumentierte Vorbereitungsschritt verlangt, dass Text und alle Bilder einer Entscheidung zusammen in 8.192 Tokens passen. Zu große Eingaben werden abgelehnt, nicht stillschweigend gekürzt. Mehrere Bilder teilen sich dieses Budget mit dem geschriebenen Zustand und der Frage. Reduzieren Sie bei der Vorbereitung einer kombinierten Entscheidung irrelevanten Quelltext oder die Obergrenze der Bildgröße, und behalten Sie dabei das Detail, das die Antwort bestimmt.
Training und berichtete Evaluierung begrenzten Bilder auf 512 mal 512, entsprechend 262.144 Pixeln und bis zu 256 visuellen Tokens. Die konfigurierbare Inferenzgrenze kann mehr Details erhalten, doch die Modellkarte warnt, dass eine höhere Auflösung außerhalb dieser Trainingsverteilung liegt und mehr Speicher und Rechenzeit benötigt. Eine größere Bildeinstellung garantiert daher keine bessere Entscheidung. Halten Sie die Eingabeaufbereitung konsistent mit der Frage und prüfen Sie, ob das benötigte visuelle Merkmal klar dargestellt ist.
Die Full-Attention-Schichten des nativen Checkpoints verwenden einen gespeicherten nicht-kausalen Attention-Modus, während seine Linear-Attention-Schichten ihr eigenes Verhalten beibehalten. Der Hersteller gibt an, dass die standardmäßige kausale Inferenz die evaluierte Konfiguration nicht reproduziert. Seine Vorhersageimplementierung wendet die gespeicherte Kalibrierungstemperatur an; werden Logits direkt verwendet, wird diese Temperatur einmal angewendet und die Wahrscheinlichkeiten werden über die aktuellen gültigen Kandidaten normalisiert. Diese Details gehören zum exakten Entscheidungsprofil und sollten bei der Interpretation seiner numerischen Ausgaben erhalten bleiben.
Der separate Entscheidungs-Readout unterscheidet dieses Artefakt außerdem von einem generativen Export. Eine Konvertierung in eine vokabularbasierte Generierungsschnittstelle benötigt eine explizite Zuordnung und muss das Attention-Verhalten bewahren. Bereiten Sie geschlossene Fragen für das native Entscheidungsprofil vor; verwenden Sie ein geeignetes Generierungsmodell, wenn die Aufgabe Chat, Code, Erklärungen oder Tool-Anfragen erfordert.
Ein nützliches Endartefakt hält Zustand, Frage, zulässige Antworten und die resultierende Verteilung miteinander verknüpft. Definieren Sie die Frage anhand tatsächlich vorhandener Belege, prüfen Sie mehrdeutige Fälle anhand dieser Belege und verwenden Sie gelabelte Beispiele aus der vorgesehenen Aufgabe, um zu entscheiden, wie numerische Ausgaben Routing oder Klassifikation beeinflussen sollen. Das Modell liefert Entscheidungswahrscheinlichkeiten; die Kriterien und die umgebende Anwendung bestimmen, wie aus diesen Wahrscheinlichkeiten eine nützliche Aktion oder ein erfasstes Label wird.
", "aboutText": "Decider V1.1 27B ist der aktualisierte Entscheidungs-Checkpoint von Perplexity. Er bewertet bereitgestellte Inhalte anhand einer definierten Frage und erzeugt Wahrscheinlichkeiten über die gültigen Antworten. Sein natives Artefakt besitzt einen Entscheidungs-Readout statt eines Sprachgenerierungs-Heads über das gesamte Vokabular. Das nützliche Ergebnis ist eine begrenzte Entscheidungsverteilung und ihre interpretierte Antwort, keine offene Erklärung und keine allgemeine Chat-Antwort.\n\n### Was sich in der Edition V1.1 ändert\n\nPerplexity bezeichnet dieses Modell als Aktualisierung von Decider V1 27B, die dasselbe Backbone beibehält, mit Änderungen an der Attention-Konfiguration und mehr Trainingsdaten. Sein Backbone ist Qwen3.8-27B. Die Edition V1.1 sollte ihren eigenen Namen und ihre eigene Konfiguration behalten, statt als austauschbare Kopie des früheren Checkpoints beschrieben zu werden.\n\n### Zustand, Frage und gültige Antworten\n\nDas veröffentlichte Beispiel liefert eine Zeile mit einem Zustand und einer typisierten Auswahlfrage. Die Frage enthält Anweisungen und Kriterien, deren Schlüssel die semantischen Antworten sind und deren Beschreibungen festlegen, wann jede davon zutrifft. Das Modell sagt Wahrscheinlichkeiten vorher, anschließend interpretiert der Antwort-Helper des Herstellers diese Wahrscheinlichkeiten für die Frage. Das Inferenzbeispiel kann eine Liste von Zeilen verarbeiten, wobei jede Entscheidung an die Belege und die Frage ihrer Zeile gebunden ist.\n\nStellen Sie beim Routing von Anfragen die tatsächliche Nachricht und den relevanten Kontext bereit und definieren Sie dann die verfügbaren Abteilungen oder Kategorien. Eine beispielhafte Aufgabe könnte zwischen einem Integrationsfehler, einem Zugriffsproblem und einer Anfrage nach Produktinformationen unterscheiden. Formulieren Sie jede Beschreibung präzise genug, um einen Grenzfall zu entscheiden, und bewahren Sie die Optionsdefinitionen zusammen mit dem Ergebnis auf. Eine Kategorienverteilung kann dann eine Routing-Entscheidung oder einen Prüfschritt unterstützen, wenn Alternativen nah beieinanderliegen. Das vom Modell gewählte Ergebnis führt die Workflow-Aktion nicht selbst aus.\n\n### Text- und Bildbelege\n\nDie native Implementierung akzeptiert Bilder zusammen mit Zustand und Frage, und zwar als Bilddateien, als Bilder im Arbeitsspeicher oder als kodierte Bilddaten. Stellen Sie bei einem Dokumentbild oder Screenshot den visuellen Beleg bereit und stellen Sie eine geschlossene Frage, deren Optionen die relevanten Ergebnisse beschreiben. Benennen Sie das sichtbare Merkmal, auf das es ankommt, und liefern Sie den Textkontext, der zu seiner Interpretation nötig ist. Klassifizieren Sie beispielsweise, ob ein abgebildeter Artikel zu einer der bereitgestellten Produktkategorien gehört, statt das Entscheidungsmodell eine vollständige Produktbeschreibung schreiben zu lassen.\n\nDer Prozessor erhält beim Skalieren das Seitenverhältnis und rundet die Bildseiten auf Vielfache von 32 Pixeln. Die dokumentierte verarbeitete Fläche beginnt bei 65.536 Pixeln und ist durch ein konfigurierbares Maximum begrenzt; der Standardwert beträgt 4.194.304 Pixel, also 2048 mal 2048. Jeder Patch von 32 mal 32 Pixeln ergibt ein visuelles Token, sodass dieser Standardwert bis zu 4.096 visuelle Tokens pro Bild erlaubt. Diese Werte beschreiben die native Bildaufbereitung des Herstellers, keinen allgemeinen Upload-Vertrag einer Anwendung.\n\n### Kombinierte Eingabegrenzen und Auflösungsrahmen\n\nDer dokumentierte Vorbereitungsschritt verlangt, dass Text und alle Bilder einer Entscheidung zusammen in 8.192 Tokens passen. Zu große Eingaben werden abgelehnt, nicht stillschweigend gekürzt. Mehrere Bilder teilen sich dieses Budget mit dem geschriebenen Zustand und der Frage. Reduzieren Sie bei der Vorbereitung einer kombinierten Entscheidung irrelevanten Quelltext oder die Obergrenze der Bildgröße, und behalten Sie dabei das Detail, das die Antwort bestimmt.\n\nTraining und berichtete Evaluierung begrenzten Bilder auf 512 mal 512, entsprechend 262.144 Pixeln und bis zu 256 visuellen Tokens. Die konfigurierbare Inferenzgrenze kann mehr Details erhalten, doch die Modellkarte warnt, dass eine höhere Auflösung außerhalb dieser Trainingsverteilung liegt und mehr Speicher und Rechenzeit benötigt. Eine größere Bildeinstellung garantiert daher keine bessere Entscheidung. Halten Sie die Eingabeaufbereitung konsistent mit der Frage und prüfen Sie, ob das benötigte visuelle Merkmal klar dargestellt ist.\n\n### Attention, Readout und Wahrscheinlichkeitskalibrierung\n\nDie Full-Attention-Schichten des nativen Checkpoints verwenden einen gespeicherten nicht-kausalen Attention-Modus, während seine Linear-Attention-Schichten ihr eigenes Verhalten beibehalten. Der Hersteller gibt an, dass die standardmäßige kausale Inferenz die evaluierte Konfiguration nicht reproduziert. Seine Vorhersageimplementierung wendet die gespeicherte Kalibrierungstemperatur an; werden Logits direkt verwendet, wird diese Temperatur einmal angewendet und die Wahrscheinlichkeiten werden über die aktuellen gültigen Kandidaten normalisiert. Diese Details gehören zum exakten Entscheidungsprofil und sollten bei der Interpretation seiner numerischen Ausgaben erhalten bleiben.\n\nDer separate Entscheidungs-Readout unterscheidet dieses Artefakt außerdem von einem generativen Export. Eine Konvertierung in eine vokabularbasierte Generierungsschnittstelle benötigt eine explizite Zuordnung und muss das Attention-Verhalten bewahren. Bereiten Sie geschlossene Fragen für das native Entscheidungsprofil vor; verwenden Sie ein geeignetes Generierungsmodell, wenn die Aufgabe Chat, Code, Erklärungen oder Tool-Anfragen erfordert.\n\nEin nützliches Endartefakt hält Zustand, Frage, zulässige Antworten und die resultierende Verteilung miteinander verknüpft. Definieren Sie die Frage anhand tatsächlich vorhandener Belege, prüfen Sie mehrdeutige Fälle anhand dieser Belege und verwenden Sie gelabelte Beispiele aus der vorgesehenen Aufgabe, um zu entscheiden, wie numerische Ausgaben Routing oder Klassifikation beeinflussen sollen. Das Modell liefert Entscheidungswahrscheinlichkeiten; die Kriterien und die umgebende Anwendung bestimmen, wie aus diesen Wahrscheinlichkeiten eine nützliche Aktion oder ein erfasstes Label wird.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "8208df39bc726ff4a3245eb92b7cf6cafca0dc20d6414e25ce46e9baffd0dad9", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "de", "methods": [ { "html": "perplexity/pplx-decider-v1.1-27bDecider V1.1 27B von Perplexity bewertet einen bereitgestellten Zustand und eine Frage und gibt Wahrscheinlichkeiten über die zulässigen Antworten zurück. Sein nativer Entscheidungs-Checkpoint unterstützt Text und Bilder, mit einem eigenen Entscheidungs-Readout und dokumentierten Grenzen für die Eingabeaufbereitung statt eines Vertrags für freie Textgenerierung.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Decider V1.1 27B ist der aktualisierte Entscheidungs-Checkpoint von Perplexity. Er bewertet bereitgestellte Inhalte anhand einer definierten Frage und erzeugt Wahrscheinlichkeiten über die gültigen Antworten. Sein natives Artefakt besitzt einen Entscheidungs-Readout statt eines Sprachgenerierungs-Heads über das gesamte Vokabular. Das nützliche Ergebnis ist eine begrenzte Entscheidungsverteilung und ihre interpretierte Antwort, keine offene Erklärung und keine allgemeine Chat-Antwort.
Perplexity bezeichnet dieses Modell als Aktualisierung von Decider V1 27B, die dasselbe Backbone beibehält, mit Änderungen an der Attention-Konfiguration und mehr Trainingsdaten. Sein Backbone ist Qwen3.8-27B. Die Edition V1.1 sollte ihren eigenen Namen und ihre eigene Konfiguration behalten, statt als austauschbare Kopie des früheren Checkpoints beschrieben zu werden.
Das veröffentlichte Beispiel liefert eine Zeile mit einem Zustand und einer typisierten Auswahlfrage. Die Frage enthält Anweisungen und Kriterien, deren Schlüssel die semantischen Antworten sind und deren Beschreibungen festlegen, wann jede davon zutrifft. Das Modell sagt Wahrscheinlichkeiten vorher, anschließend interpretiert der Antwort-Helper des Herstellers diese Wahrscheinlichkeiten für die Frage. Das Inferenzbeispiel kann eine Liste von Zeilen verarbeiten, wobei jede Entscheidung an die Belege und die Frage ihrer Zeile gebunden ist.
Stellen Sie beim Routing von Anfragen die tatsächliche Nachricht und den relevanten Kontext bereit und definieren Sie dann die verfügbaren Abteilungen oder Kategorien. Eine beispielhafte Aufgabe könnte zwischen einem Integrationsfehler, einem Zugriffsproblem und einer Anfrage nach Produktinformationen unterscheiden. Formulieren Sie jede Beschreibung präzise genug, um einen Grenzfall zu entscheiden, und bewahren Sie die Optionsdefinitionen zusammen mit dem Ergebnis auf. Eine Kategorienverteilung kann dann eine Routing-Entscheidung oder einen Prüfschritt unterstützen, wenn Alternativen nah beieinanderliegen. Das vom Modell gewählte Ergebnis führt die Workflow-Aktion nicht selbst aus.
Die native Implementierung akzeptiert Bilder zusammen mit Zustand und Frage, und zwar als Bilddateien, als Bilder im Arbeitsspeicher oder als kodierte Bilddaten. Stellen Sie bei einem Dokumentbild oder Screenshot den visuellen Beleg bereit und stellen Sie eine geschlossene Frage, deren Optionen die relevanten Ergebnisse beschreiben. Benennen Sie das sichtbare Merkmal, auf das es ankommt, und liefern Sie den Textkontext, der zu seiner Interpretation nötig ist. Klassifizieren Sie beispielsweise, ob ein abgebildeter Artikel zu einer der bereitgestellten Produktkategorien gehört, statt das Entscheidungsmodell eine vollständige Produktbeschreibung schreiben zu lassen.
Der Prozessor erhält beim Skalieren das Seitenverhältnis und rundet die Bildseiten auf Vielfache von 32 Pixeln. Die dokumentierte verarbeitete Fläche beginnt bei 65.536 Pixeln und ist durch ein konfigurierbares Maximum begrenzt; der Standardwert beträgt 4.194.304 Pixel, also 2048 mal 2048. Jeder Patch von 32 mal 32 Pixeln ergibt ein visuelles Token, sodass dieser Standardwert bis zu 4.096 visuelle Tokens pro Bild erlaubt. Diese Werte beschreiben die native Bildaufbereitung des Herstellers, keinen allgemeinen Upload-Vertrag einer Anwendung.
Der dokumentierte Vorbereitungsschritt verlangt, dass Text und alle Bilder einer Entscheidung zusammen in 8.192 Tokens passen. Zu große Eingaben werden abgelehnt, nicht stillschweigend gekürzt. Mehrere Bilder teilen sich dieses Budget mit dem geschriebenen Zustand und der Frage. Reduzieren Sie bei der Vorbereitung einer kombinierten Entscheidung irrelevanten Quelltext oder die Obergrenze der Bildgröße, und behalten Sie dabei das Detail, das die Antwort bestimmt.
Training und berichtete Evaluierung begrenzten Bilder auf 512 mal 512, entsprechend 262.144 Pixeln und bis zu 256 visuellen Tokens. Die konfigurierbare Inferenzgrenze kann mehr Details erhalten, doch die Modellkarte warnt, dass eine höhere Auflösung außerhalb dieser Trainingsverteilung liegt und mehr Speicher und Rechenzeit benötigt. Eine größere Bildeinstellung garantiert daher keine bessere Entscheidung. Halten Sie die Eingabeaufbereitung konsistent mit der Frage und prüfen Sie, ob das benötigte visuelle Merkmal klar dargestellt ist.
Die Full-Attention-Schichten des nativen Checkpoints verwenden einen gespeicherten nicht-kausalen Attention-Modus, während seine Linear-Attention-Schichten ihr eigenes Verhalten beibehalten. Der Hersteller gibt an, dass die standardmäßige kausale Inferenz die evaluierte Konfiguration nicht reproduziert. Seine Vorhersageimplementierung wendet die gespeicherte Kalibrierungstemperatur an; werden Logits direkt verwendet, wird diese Temperatur einmal angewendet und die Wahrscheinlichkeiten werden über die aktuellen gültigen Kandidaten normalisiert. Diese Details gehören zum exakten Entscheidungsprofil und sollten bei der Interpretation seiner numerischen Ausgaben erhalten bleiben.
Der separate Entscheidungs-Readout unterscheidet dieses Artefakt außerdem von einem generativen Export. Eine Konvertierung in eine vokabularbasierte Generierungsschnittstelle benötigt eine explizite Zuordnung und muss das Attention-Verhalten bewahren. Bereiten Sie geschlossene Fragen für das native Entscheidungsprofil vor; verwenden Sie ein geeignetes Generierungsmodell, wenn die Aufgabe Chat, Code, Erklärungen oder Tool-Anfragen erfordert.
Ein nützliches Endartefakt hält Zustand, Frage, zulässige Antworten und die resultierende Verteilung miteinander verknüpft. Definieren Sie die Frage anhand tatsächlich vorhandener Belege, prüfen Sie mehrdeutige Fälle anhand dieser Belege und verwenden Sie gelabelte Beispiele aus der vorgesehenen Aufgabe, um zu entscheiden, wie numerische Ausgaben Routing oder Klassifikation beeinflussen sollen. Das Modell liefert Entscheidungswahrscheinlichkeiten; die Kriterien und die umgebende Anwendung bestimmen, wie aus diesen Wahrscheinlichkeiten eine nützliche Aktion oder ein erfasstes Label wird.
POST /v1/systemonetext, imagedecisions| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits perplexity/pplx-decider-v1.1-27b | Standard— |
Feldprovider | Typschema | AnforderungOptional | Werte und Limits | Standard— |
Feldquestions | Typobject | AnforderungErforderlich | Werte und Limits | Standard— |
Feldsession_id | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldstate | Typschema | AnforderungErforderlich | Werte und Limits | Standard— |
Feldtrace | Typschema | AnforderungOptional | Werte und Limits | Standard— |
Felduser | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldquestions.<id>.type | Typstring | AnforderungErforderlich | Werte und Limits noul, choice, score | Standard— |
Feldquestions.<id>.instructions | Typstring|object|array | AnforderungErforderlich | Werte und Limits | Standard— |
Feldquestions.<id>.criteria | Typobject|array | AnforderungOptional | Werte und Limits Bedingungen: choice/score: erforderlich; noul: optional. Bei choice ist criteria ein Objekt; bei score ist es ein Array mit minItems=1. | Standard— |
Feldquestions.<id>.criteria.true | Typstring|object|array | AnforderungErforderlich | Werte und Limits Gilt, wenn: Kriterienobjekt noul bereitgestellt | Standard— |
Feldquestions.<id>.criteria.false | Typstring|object|array | AnforderungErforderlich | Werte und Limits Gilt, wenn: Kriterienobjekt noul bereitgestellt | Standard— |
noul · Erforderlich: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Erforderlich: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Erforderlich: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, state, questions |
Parametermaterial_types | Vertragtext, image |
Parameteroptional_controls | Vertragprovider, session_id, trace, user |
Parametermultimodal_input_binding | VertragVerwenden Sie ausschließlich die exakt deklarierte Zustands-/Dokumentdarstellung. Die Bildfähigkeit des Herstellers allein belegt kein modellspezifisch akzeptiertes Bildtransportformat. |
Lebenszyklus: synchronous
Senden Sie die genaue Modell-ID und bewahren Sie die vollständige native Antwort auf.
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00004 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen — / 1K Token Eingabe · Cache-Schreiben — / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.00004 / 1K Token Ausgabe · Ausgabetoken $0 / 1K Token Eingabe · Cache-Lesen — / 1K Token Eingabe · Cache-Schreiben — / 1K Token Eingabe · Cache-Schreiben, 1 Stunde — / 1K Token |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
{\n "model": "perplexity/pplx-decider-v1.1-27b",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='perplexity/pplx-decider-v1.1-27b'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Jede bereitgestellte Antwort mit Fragen-ID bleibt mit ihrem genauen Typ, ihrem noul/choice/score-Wert, ihrer Konfidenz, ihren Wahrscheinlichkeiten und ihrer Legende erhalten. Das gesamte ursprüngliche JSON wird gespeichert und erst nach der Abrechnung zurückgegeben.
Bewahren Sie den ursprünglichen Vorgang sowie die vollständige oder teilweise Antwort auf; wiederholen Sie POST nicht.
| Feld | Typ |
|---|---|
Feldmodel | Typstring |
Feldid | Typstring |
Feldprovider | Typstring |
Feldanswers.<id>.type | Typstring |
Feldanswers.<id>.noul | Typnumber |
Feldanswers.<id>.choice | Typstring |
Feldanswers.<id>.score | Typnumber |
Feldanswers.<id>.confidence | Typnumber |
Feldanswers.<id>.probabilities | Typobject |
Feldanswers.<id>.legend | Typobject |
Feldusage.input_tokens | Typinteger |
Feldusage.output_tokens | Typinteger |
Feldusage.cost | Typnumber |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungUngültiges Pflichtfeld, ungültige Darstellung oder ungültiger Wert | Nächster SchrittKorrigieren Sie das angegebene Anfragefeld. |
Ailoot Ultra perplexity/pplx-decider-v1.1-27b
Verwenden Sie die oben angezeigten Methodenpfade.