Jev API Alternative: Laya als kostenlose Web-API

In unserem letzten Artikel haben wir Laya AI als Alternative zum ausgebuchten Jev getestet. Das Ergebnis war eindeutig: laya-typed-decisions hat ohne jede Anpassung 81 % der Fälle richtig gelöst, in durchschnittlich 47 Millisekunden.

Nur einen Haken hatte die Sache: Wer Laya selbst betreiben will, braucht Python, PyTorch und rund 800 MB Modelldateien auf dem Server. Für ein klassisches Webprojekt mit PHP, Node oder einem Shared Hosting ist das ein echtes Hindernis. Niemand möchte für eine Ticket-Kategorisierung einen eigenen Python-Server pflegen.

Also haben wir das Problem für uns gelöst und daraus ein Angebot für alle gemacht: laya-api.de, eine Jev-API-Alternative, die sich in jedes Webprojekt einbinden lässt.

TL;DR

• Die Laya API stellt laya-typed-decisions als gehostete Web-API bereit: kein Python, kein PyTorch, keine GPU, ein HTTP-Aufruf aus jeder Sprache genügt.

• Kostenlos in der offenen Beta, 60 Anfragen pro Minute, später werden nur Input-Tokens berechnet.

• Hosting und Verarbeitung in Deutschland, Löschung nach spätestens 7 Tagen, AV-Vertrag verfügbar.

• Gleiches Request- und Antwortformat wie Jev: Der Umstieg kostet zwei Zeilen (Basis-URL und Modell).

• Im Test rund 1,7 Sekunden und etwa 85 Tokens pro Entscheidung, schnell genug für Tickets, Mails und Formulare.

Die Jev-Alternative als Web-API

Die Laya API stellt das offene Laya-Modell als gehosteten Dienst bereit. Im Hintergrund läuft die Variante typed-decisions, also genau das Modell, das in unserem Test am besten abgeschnitten hat. Man schickt einen Text und eine oder mehrere Fragen per HTTP, zurück kommt sauberes JSON mit Entscheidung und Wahrscheinlichkeiten.

Das Wichtigste auf einen Blick:

• Kostenlos in der offenen Beta. Registrieren, API-Key erzeugen, loslegen. Keine Kreditkarte, keine Warteliste.

• 60 Anfragen pro Minute pro Key. Für die meisten Webprojekte reicht das locker.

• Datenschutzkonform. Hosting und Verarbeitung in Deutschland, Löschung nach spätestens 7 Tagen. Mehr dazu weiter unten.

• Nur Input-Tokens. Wenn die Beta endet, werden nur die eingehenden Tokens berechnet. Die Antwort ist ohnehin nur ein kleines Stück JSON.

• Keine Infrastruktur. Kein Python, kein PyTorch, keine GPU, keine Modelldateien. Ein HTTP-Aufruf aus jeder Sprache genügt.

Datenschutz: in Deutschland verarbeitet, nach 7 Tagen gelöscht

Wer Tickets und E-Mails von einer KI einordnen lässt, schickt personenbezogene Daten an einen Dienst: Namen, E-Mail-Adressen, Kundennummern, manchmal auch Vertrags- oder Zahlungsdetails. Genau deshalb war uns der Datenschutz bei der Laya API von Anfang an wichtig.

• Hosting und Verarbeitung in Deutschland. Die Server stehen in Deutschland, und dort werden die Anfragen auch verarbeitet. Kein Umweg über Rechenzentren außerhalb Deutschlands.

• Löschung nach spätestens 7 Tagen. Anfragen und Ergebnisse werden nicht dauerhaft gespeichert. Spätestens nach sieben Tagen sind sie gelöscht.

• DSGVO-konform mit AV-Vertrag. Für den Einsatz im Unternehmen stellen wir einen Auftragsverarbeitungsvertrag bereit.

Für uns selbst war das die Voraussetzung, überhaupt unseren Posteingang durch die API zu schicken. Und für viele Kunden ist es der Punkt, an dem eine KI-Lösung überhaupt erst in Frage kommt.

Von Jev zu Laya in zwei Zeilen

Beim Bau der API haben wir uns bewusst am Design von Jev orientiert. Der Request-Body ist derselbe, das answers-Objekt in der Antwort auch. Wer bereits eine Integration für Jev geschrieben hat oder eine Anleitung für Jev nachbaut, muss nur zwei Dinge ändern: die Basis-URL und das Modell.

const BASE_URL = "https://laya-api.de/api/v1"; // statt der Jev-URL
const MODEL = "laya-latest";                   // statt des Jev-Modells

const job = await fetch(`${BASE_URL}/systemone?wait=10`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.LAYA_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ state, model: MODEL, questions }),
}).then((r) => r.json());

Fragen, Kriterien und die Auswertung der Antworten bleiben unverändert. Der einzige Unterschied: Laya verpackt das Ergebnis in ein Job-Objekt. Mit ?wait=10 wartet die API bis zu zehn Sekunden auf das Ergebnis und liefert es direkt mit. In der Praxis ist die Antwort fast immer schon da.

Umgekehrt funktioniert das genauso. Wer heute mit Laya startet und später doch einen Platz bei Jev bekommt, kann mit denselben zwei Zeilen wechseln. Man bindet sich also an keinen Anbieter.

So sieht ein Aufruf aus

Ein Aufruf besteht aus dem Text (state), dem Modell und bis zu 32 benannten Fragen. Alle drei Antworttypen aus unserem Test sind verfügbar: Ja/Nein (noul), Auswahl (choice) und Skala (score). Ein Support-Ticket lässt sich so in einem einzigen Durchgang einordnen:

{
  "state": "Hallo, mir wurde der März doppelt abgebucht. Bitte um schnelle Erstattung.",
  "model": "laya-latest",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Welches Team ist zuständig?",
      "criteria": {
        "billing": "Zahlungen und Erstattungen",
        "support": "Fehler und technische Probleme",
        "sales": "Tarife und Preise"
      }
    },
    "dringend": {
      "type": "noul",
      "instructions": "Ist das Anliegen zeitkritisch?",
      "criteria": {
        "true": "Ausdrücklich eilig",
        "false": "Keine Dringlichkeit erkennbar"
      }
    },
    "stimmung": {
      "type": "score",
      "instructions": "Wie ist die Stimmung des Kunden?",
      "criteria": ["Verärgert", "Neutral", "Freundlich"]
    }
  }
}

Die Antwort enthält für jede Frage einen Wert, den der Code direkt weiterverarbeiten kann:

{
  "status": "completed",
  "result": {
    "answers": {
      "team": {
        "type": "choice",
        "choice": "billing",
        "probabilities": { "billing": 0.91, "support": 0.06, "sales": 0.03 },
        "confidence": 0.93
      },
      "dringend": { "type": "noul", "noul": 0.88 },
      "stimmung": {
        "type": "score",
        "score": 0.6,
        "probabilities": { "0": 0.45, "1": 0.5, "2": 0.05 },
        "legend": { "0": "Verärgert", "1": "Neutral", "2": "Freundlich" },
        "confidence": 0.8
      }
    }
  }
}

Kein Fließtext, kein Parsen, keine kaputten Antworten. Ein choice steuert das Routing, ein noul über einem Schwellenwert setzt eine Priorität, ein score landet als Zahl im System.

Wie schnell ist die API?

Wir haben die API unter echten Bedingungen gemessen: zehn Anfragen nacheinander, jeweils vom Absenden bis zur fertigen Antwort beim Client, inklusive Warteschlange.

Zum Vergleich: Lokal auf dem MacBook M1 brauchte Laya in unserem ersten Test im Schnitt nur 47 ms. Der Unterschied ist kein Geheimnis. Lokal rechnet das Modell direkt im selben Prozess. Bei der API reist jede Anfrage vom Client zum Dienst, von dort zu einem Worker, der das Modell ausführt, zurück zum Dienst und dann zum Client. Jede dieser Stationen kostet Zeit, und das Modell selbst macht davon nur einen kleinen Teil aus.

Knapp 1,7 Sekunden sind trotzdem schnell, und zwar für genau die Aufgaben, für die wir die API gebaut haben. Ein Ticket, das in zwei Sekunden kategorisiert und zugewiesen ist, ist sortiert, bevor überhaupt jemand draufschaut. Eine Mail hat ihre Tags, lange bevor man den Posteingang öffnet. Wer dagegen in Echtzeit entscheiden muss, etwa einen Anrufer noch während des Gesprächs weiterleiten, fährt mit einem lokal betriebenen Laya besser.

Und die Kosten? 845 Input-Tokens für zehn Anfragen sind rund 85 Tokens pro Entscheidung. Weil keine Output-Tokens berechnet werden, zahlt man nur diese knapp hundert Tokens für den Text und die Frage. Ein Sprachmodell, das seine Antwort erst in ganzen Sätzen ausformuliert, kostet für dieselbe Entscheidung ein Vielfaches. Während der Beta ist die Nutzung ohnehin kostenlos.

Wie wir die API selbst einsetzen

Wir haben laya-api.de nicht auf dem Reißbrett entworfen, sondern zuerst für unseren eigenen Alltag gebaut. Zwei Einsatzzwecke laufen bei uns inzwischen jeden Tag.

Tickets zuordnen, bevor sie jemand anfasst

Jedes neue Ticket geht beim Eingang einmal durch die Laya API. Das Modell entscheidet, um welche Kategorie es sich handelt und wer zuständig ist. Das Ticket landet dann bereits kategorisiert und zugewiesen bei der richtigen Person.

Früher hat jemand jedes Ticket geöffnet, gelesen, eingeordnet und weitergeleitet. Heute öffnet man ein Ticket erst dann, wenn man es auch bearbeitet. Die Sortierarbeit am Morgen entfällt komplett.

Den Posteingang taggen

Die zweite Aufgabe ist der E-Mail-Posteingang. Jede eingehende Mail bekommt passende Tags, etwa Anfrage, Rechnung, Bewerbung, Newsletter oder Kundenprojekt. Die Mails bleiben dabei im Posteingang, nichts wird automatisch verschoben.

Der Effekt ist größer, als man denkt: Mit farbigen Tags lässt sich der Posteingang mit einem Blick überfliegen. Man sieht sofort, was eine Kundenanfrage ist und was bis nach der Mittagspause warten kann, ohne jede Betreffzeile lesen zu müssen.

Spam markieren, aber noch nicht wegräumen

Auch Spam erkennt das Modell zuverlässig und markiert ihn mit einem eigenen Tag. In den Spam-Ordner verschieben wir diese Mails aber bewusst noch nicht. Sie bleiben im Posteingang und werden von Hand geprüft.

Der Grund ist einfach: Eine fälschlich als Spam erkannte Kundenanfrage, die ungesehen im Spam-Ordner verschwindet, kostet mehr als hundert Spam-Mails, die man mit einem Klick löscht. Erst wenn sich das Modell über einen längeren Zeitraum bewährt hat, lassen wir es automatisch verschieben, und dann auch nur ab einer hohen Konfidenz.

Was man damit bauen kann

Weil die API nur einen HTTP-Aufruf braucht, passt sie in praktisch jedes Webprojekt: in eine Laravel- oder Symfony-Anwendung, ein WordPress-Plugin, einen Node-Service oder ein No-Code-Tool, das Webhooks unterstützt. Ein paar Ideen:

Mehrere Fragen lassen sich in einem Aufruf kombinieren. Eine Nachricht aus dem Kontaktformular bekommt so in einem Durchgang Kategorie, Dringlichkeit und Spam-Verdacht zugewiesen, und das Formular kann direkt die passende Person benachrichtigen.

In einer Laravel-Anwendung sieht das zum Beispiel so aus:

$response = Http::withToken(config('services.laya.key'))
    ->post('https://laya-api.de/api/v1/systemone?wait=10', [
        'state' => $message->body,
        'model' => 'laya-latest',
        'questions' => [
            'kategorie' => [
                'type' => 'choice',
                'instructions' => 'Worum geht es in der Nachricht?',
                'criteria' => [
                    'anfrage' => 'Anfrage zu einem Projekt oder Angebot',
                    'bewerbung' => 'Bewerbung auf eine Stelle',
                    'werbung' => 'Werbung oder Kaltakquise',
                ],
            ],
            'spam' => [
                'type' => 'noul',
                'instructions' => 'Ist die Nachricht Spam oder Phishing?',
                'criteria' => [
                    'true' => 'Spam, Phishing oder automatisierter Müll',
                    'false' => 'Echte Nachricht eines Menschen',
                ],
            ],
        ],
    ]);

$answers = $response->json('result.answers');

$message->update([
    'category' => $answers['kategorie']['choice'],
    'is_spam' => $answers['spam']['noul'] > 0.9,
]);

Worauf man achten sollte

• Den API-Key nie ins Frontend. Der Key gehört auf den Server. Wer die API direkt aus Browser-JavaScript aufruft, macht seinen Key für jeden Besucher sichtbar.

• Mit echten Daten testen. Unser Test hat gezeigt: Etwa jede fünfte Antwort war falsch. Vor dem Einsatz sollte man die eigenen Fragen mit echten Beispielen durchspielen.

• Schwellenwerte bewusst setzen. Automatisch handeln sollte die Anwendung nur bei hoher Konfidenz. Alles darunter bekommt einen Hinweis und landet beim Menschen, so wie unser Spam.

• Auffang-Optionen prüfen. Eine Option wie „keiner passt“ ist sinnvoll, kann aber die Trefferquote senken. Das lohnt sich vorher auszuprobieren.

• Im Hintergrund aufrufen. Mit rund 1,7 Sekunden pro Anfrage sollte der Aufruf nicht das Absenden eines Formulars blockieren. Besser ist ein Queue-Job, der die Nachricht nach dem Speichern einordnet.

• Mit längeren Laufzeiten rechnen. Kommt das Ergebnis nicht innerhalb der Wartezeit, antwortet die API mit 202 Accepted. Das Ergebnis lässt sich dann über GET /api/v1/jobs/{id} abholen.

• Es ist eine Beta. Das Rate Limit liegt bei 60 Anfragen pro Minute. Für einen Massenimport von Tausenden Altdaten muss man die Aufrufe entsprechend verteilen.

Unser Fazit

Wer eine Jev-API-Alternative sucht, muss nicht mehr warten. Mit der Laya API wird aus einem spannenden Forschungsmodell ein Werkzeug, das jedes Webprojekt nutzen kann. Kein Python-Server, keine Modelldateien, keine Warteliste und während der Beta auch keine Kosten. Die Daten werden in Deutschland verarbeitet und nach spätestens sieben Tagen gelöscht. Wer Jev bereits kennt, ist mit zwei geänderten Zeilen startklar.

Eine lokale Installation ist schneller, das ist klar. Mit rund 1,7 Sekunden pro Anfrage und etwa 85 berechneten Tokens pro Entscheidung ist die API aber schnell genug für Tickets, Mails und Formulare, und dabei spottbillig.

Bei uns sortiert die API jeden Tag Tickets, bevor sie jemand öffnet, und macht den Posteingang auf einen Blick lesbar. Unsere Empfehlung: klein anfangen, mit einer einzigen Frage wie „Ist das Spam?“ oder „Welches Team ist zuständig?“, die Ergebnisse eine Weile nur markieren statt automatisch handeln, und erst dann mehr automatisieren.

Den kostenlosen Beta-Key gibt es unter laya-api.de/register.

Quellen

• Laya API: Startseite

• Laya API: Dokumentation

• Laya API: Kostenlosen Beta-Key registrieren

• Laya: Offizielle Website von Convai Innovations

• Laya typed-decisions auf Hugging Face

• Jev: Offizielle Website von TypeSafe AI

• TypeSafe AI Blog: Introducing System One Models & Jev