Chrome Prompt API

 (developer.chrome.com)
5 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine browsernative API, die natürlichsprachliche Anfragen an das in Chrome integrierte Gemini Nano-Modell sendet und AI-Inferenz auf dem Gerät ohne Server-Roundtrip ausführt
  • Vielfältige Einsatzmöglichkeiten wie AI-gestützte Suche, personalisierte Feeds durch Nachrichtenklassifizierung, Inhaltsfilterung, Erstellung von Kalendereinträgen und Extraktion von Kontakten
  • Mit prompt() ist eine Antwort auf einmal möglich oder mit promptStreaming() eine Streaming-Antwort auf Basis von ReadableStream
  • Bietet feingranulare Sitzungssteuerung wie sitzungsbasiertes Kontextmanagement, Streaming-Antworten und Sitzungsklone
  • Da die AI-Inferenz ohne Server-Roundtrip im Browser erfolgt, ist sie vorteilhaft für Datenschutz und minimale Antwortlatenz
  • Eingebaute multimodale Funktionen mit Unterstützung nicht nur für Text, sondern auch für Bild- und Audioeingaben
    • Audio: AudioBuffer, ArrayBuffer, Blob usw.
    • Bild: HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob usw.
  • Über das Feld responseConstraint kann ein JSON-Schema übergeben werden, um das Ausgabeformat des Modells auf boolean, eine bestimmte JSON-Struktur usw. zu beschränken
  • Mit initialPrompts lassen sich System-Prompts und vorheriger Gesprächskontext einfügen, und mit append() kann auch nach Erstellung der Sitzung zusätzlicher Kontext vorab gesendet werden
  • Wenn einer nachfolgenden assistant-Nachricht prefix: true hinzugefügt wird, kann das Modell dazu veranlasst werden, eine Antwort in einem bestimmten Format zu beginnen
  • Unterstützung für die Verwaltung des Kontextfensters pro Sitzung: Mit contextUsage/contextWindow lässt sich der Token-Verbrauch prüfen, und bei Overflow werden frühe Gespräche automatisch gelöscht (der System-Prompt bleibt erhalten)
  • Mit clone() lassen sich Sitzungen verzweigen, mit destroy() Ressourcen freigeben, und mit AbortSignal können Sitzung und Prompt vorzeitig abgebrochen werden
  • Mit expectedInputs/expectedOutputs lassen sich Ein-/Ausgabeformate und Sprache festlegen (derzeit unterstützt: en, ja, es)
  • Hardware-Anforderungen: Windows 10+/macOS 13+/Linux/ChromeOS, mindestens 22 GB Speicherplatz, mehr als 4 GB GPU-VRAM oder mindestens 16 GB CPU-RAM plus mindestens 4 Kerne
  • Für iframes mit fremder Origin kann der Zugriff über das Attribut allow="language-model" delegiert werden, in Web Workern derzeit nicht unterstützt
  • Seit Chrome 138 als Origin Trial verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare

  • Diese API scheint perfekt zu der de-snarkifier-Idee zu passen, über die ich schon lange nachdenke
    Social Media kann intellektuell anregend sein und man kann dabei etwas lernen, aber man wird leicht in ideologische Wortgefechte und Flamewars hineingezogen, auch wenn man das gar nicht will. Sich im Internet mit Unbekannten emotional aufzureiben, kommt fast einer Verschwendung von Humankapital gleich
    Mit so einer API könnte man wohl eine Browser-Erweiterung bauen, die vor dem Anzeigen eines Textes nur aggressive oder spöttische Formulierungen entschärft und die sachlichen Informationen unverändert lässt. Man könnte sogar noch weiter gehen und einen aggressiven Ton umso lächerlicher oder inkompetenter klingen lassen, je schärfer er ist
    Dann wären Lesende vor persönlichen Angriffen Fremder geschützt, und Schreibende hätten keinen Anreiz mehr, sich unhöflich zu verhalten. Wenn alle solche Filter nutzen, gibt es auch keinen Grund mehr, darum zu konkurrieren, wer gemeiner ist

    • Das ist wie Soylent für schriftliche Kommunikation
      Alle Nährstoffe sind drin, aber geschmacklich ist es eher nichts Besonderes
    • Auf so ein Tool freue ich mich wirklich. Es könnte die leeren Kalorien des Internets herausfiltern und die Nutzung heutiger populärer Plattformen deutlich verringern
      Ich will im Grunde nur Clickbait-Überschriften und Werbung entfernen und stattdessen trockene, faktenbasierte Titel sehen
      Zu jedem Thema reicht mir ein zentraler Artikel und ein paar brauchbare Kommentare, der Rest ist meist nur Rauschen, das ich gar nicht sehen will
      Der Zustand von Social Media ist inzwischen so schlecht, dass ich es fast gar nicht mehr nutze, und HN war die einzige Ausnahme, aber auch hier scheint es wegen der AI-Sättigung in eine ähnliche Richtung zu gehen. Trotzdem verliere ich etwa alle zwei Wochen ein paar Stunden daran, und selbst das würde ich gern komplett abstellen
      Idealerweise würden 98 % der Inhalte herausgefiltert oder zusammengefasst verschwinden, und mit der Zeit würde ich das Internet nur noch für gezielte Suche nutzen. Im Grunde möchte ich den Unterhaltungscharakter des Internets größtenteils entfernen und Zeit und Energie wieder in die reale Welt und hochwertige Quellen wie Bücher stecken
    • Für YouTube gibt es schon etwas Ähnliches, und ich nutze DeArrow
      Die Erweiterung versucht per Crowdsourcing, Sensationsmache zu reduzieren, wobei ich den Eindruck habe, dass einige der Top-Beitragenden auch LLM-Bots sein könnten
    • Eine interessante Idee, die es wert scheint, weiter erkundet zu werden
      Allerdings sind solche Dinge in der Realität schwer vorhersehbar, und selbst wenn es funktioniert, wird es wahrscheinlich ziemlich anders laufen, als man es sich anfangs vorgestellt hat
    • Ich bin PM für die built-in AI APIs von Chrome, und diese de-snarkifier-Idee gefällt mir wirklich sehr und scheint auch breiteres Interesse zu wecken
      Ich konnte nicht widerstehen und habe hastig einen Snarknada-Prototyp gebaut, um mir gleichzeitig Low-Latency-Muster und die mögliche Genauigkeit anzusehen
      Genau deshalb halte ich on-device bei solchen Anwendungsfällen für richtig. Wenn man einen endlosen Scroll-Feed komplett über eine Cloud-API entschärfen wollte, würden die Token-Kosten für Entwickler untragbar werden. Außerdem ist es völlig nachvollziehbar, dass niemand seinen persönlichen Feed oder DMs zur Tonbereinigung an einen Drittserver schicken will
      Wenn man das ins Gerät verlagert, könnten hochfrequente Semantic Mutation-Anwendungen kosten- und technikseitig erstmals realistisch werden. Falls jemand daraus etwas Ernsthafteres macht als meinen spielzeughaften PM-Prototyp und dabei auf konkrete Reibungspunkte stößt, würde ich das sehr gern hören. Das hilft bei der Priorisierung der Roadmap
      [1]: Wenn ihr Coding-Agenten (Cursor, Claude Code usw.) nutzt, würde ich empfehlen, auf https://www.npmjs.com/package/built-in-ai-skills-md-agent-md zu verweisen. Viele Modelle wurden noch mit dem inzwischen veralteten Namespace window.ai trainiert, und diese Skill-Datei hilft ihnen, die aktuelle API korrekt zu verwenden

  • Ich habe die Designarbeit für diese API geleitet und vor meinem Ruhestand auch einen Beitrag zu den entsprechenden Designüberlegungen geschrieben
    https://domenic.me/builtin-ai-api-design/

    • Mich würde interessieren, wie du die Ziel-Anwendungsfälle dieser API kurz- und langfristig siehst
      Und auch, ob Browser bei solchen Dingen eher praktisch untereinander auf gemeinsame Nenner hinarbeiten, statt das auf W3C-Ebene zu koordinieren. Die Branche ist am Ende ja doch ziemlich klein
    • Glückwunsch zum Ruhestand

  • Das funktioniert tatsächlich, und ich habe es bereits für local inference produktiv eingesetzt
    Für einfache LLM-Aufgaben wie Suche konnte man es als eine Art ollama für Leute mit kleinem Budget verwenden. Der größte Vorteil ist, dass es kostenlos ist, die Privatsphäre wahrt und von Nutzern fast nichts verlangt, was es gut geeignet macht, nichttechnischen Nutzern lokale Inferenz zu geben
    Die tatsächliche User Experience ist allerdings nicht gut. Der Model-Download ist um Größenordnungen größer als der Browser selbst, und man muss diesen Prozess abschließen, bevor man das erste Token bekommt
    Das scheint schwer lösbar, solange das Betriebssystem nicht zuverlässig vorinstallierte Modelle bereitstellt, an die sich solche APIs anhängen können

    • Das ist ein einmaliger Download, den alle Websites teilen, die die Prompt API verwenden
      Das größere Problem ist, dass die Modelle auf den meisten normalen PCs zu klein und zu langsam sind. Ich wollte einmal die Sätze eines infocom-Textadventures in Echtzeit umschreiben, aber dafür ist es auf vielen heutigen PCs einfach zu langsam, um praktisch zu sein
    • Der nächste große Trend könnte ein Software-Abo-Premium sein, das gleich mehrere 5090er mitverkauft
    • Bei einem MoE-Modell könnte man Experten-Layer bei Bedarf per HTTP-Range-Query aus dem Netzwerk nachladen
      Ähnlich wie bei bittorrent, wo Dateifragmente von mehreren Hosts kommen. Gemeinsame Layer müssten zwar weiterhin heruntergeladen werden, aber die Zeit bis zum ersten Token könnte dann proportional zur aktiv genutzten statt zur gesamten Größe werden
      Natürlich wäre das dann keine vollständig Offline-Inferenz mehr, aber für eine Browser-Webfunktion muss das vielleicht kein zentrales Kriterium sein
    • Ich hoffe, wir landen nicht in einer Welt, in der das Betriebssystem vorinstallierte Modelle zuverlässig mitliefert
    • Wirklich gut
      Wenn das Modell aber viel größer als der Browser ist und vor dem ersten Token heruntergeladen werden muss, frage ich mich, ob das Lazy Downloading bedeutet. Falls Erstnutzer beim ersten Aufruf warten müssen, bis der Download abgeschlossen ist, klingt das nach einer ziemlich schrecklichen User Experience
      Ich frage mich auch, ob Chrome so etwas wie einen Download-Statusdialog anzeigt, um Verwirrung zu vermeiden, und wie hoch der Speicherplatzverbrauch ist

  • Oberflächlich sieht es so aus, als würde hier Gemini Nano verwendet, aber das aktuelle Gemma 4 E2B/E4B scheint deutlich besser zu sein, daher wäre es kurzfristig vielleicht sinnvoller, quantisierte Versionen über Erweiterungen auszuliefern

    • Gemini Nano-1: 46 % MMLU, 1.8B
    • Gemini Nano-2: 56 % MMLU, 3.25B
    • Gemma4 E2B: 60.0 % MMLU, 2.3B
    • Gemma4 E4B: 69.4 % MMLU, 4.5B
      Quelle:
    • https://huggingface.co/google/gemma-4-E2B-it
    • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
    • Ich kenne die aktuelle interne Lage nicht, aber als ich noch in diesem Team war, haben wir die neuesten kleinen Google-Modelle sehr schnell in Chrome eingebracht
      Wenn Gemma 4 oder das entsprechende Gemini Nano noch nicht in Chrome ist, würde ich erwarten, dass es bald kommt
      Und dieser Beitrag wurde zuletzt am 2025-09-21 aktualisiert, damals war man bereits bei Gemini Nano 3
    • Ja
      Es heißt, dass die Prompt API einfach natürlichsprachliche Anfragen an Gemini Nano im Browser sendet
    • Die Prompt API verwendet das Modell, das im Browser verfügbar ist
      In Edge dürfte das vermutlich Phi4 sein

  • Das wirkt auch wie ein guter Weg, bösartige JS-Skripte nichtsahnende Besucher Token erzeugen zu lassen
    Interessant wäre auch, ob sich durch Zerlegung größerer Prompts in kleine Teile, verteilt über viele Browser, mit einem Subagent-Pattern oder einer RLM-ähnlichen Struktur etwas Nützliches als verteiltes System bauen ließe

    • Das wirkt nach viel Aufwand für wenig Ertrag
      Technisch und geschäftlich würde die Infrastruktur extrem komplex, und wenn man Prompts wirklich an Nutzerbrowser auslagern will, wäre es vermutlich sinnvoller, einfach die Chrome API direkt sauber zu nutzen. Ich bezweifle auch, wie oft das serverseitige Offloading auf solche schwachen Modelle tatsächlich einen nennenswerten Nutzen bringt
      Und wenn man das wirklich wollte, gibt es WebGPU ohnehin schon seit Langem
    • Die Token-Generierung kleiner Modelle ist fast wertlos

  • Das sieht wie ein Schritt hin zu einer echten Model API aus, aber bislang eben nur ein kleiner Schritt
    Es erinnert auch an Apples Foundation Models
    Viele AI-Integrationen konzentrieren sich auf Textkommunikation oder Chat-Stil, aber tatsächlich gibt es auch viel Software, die eher von nichttextuellen Interfaces profitiert
    Letztlich sollten Betriebssystem und Browser APIs bereitstellen, die Modelle verwalten, sodass Apps per einfacher Schnittstelle auf on-device- und Remote-Modelle zugreifen können
    Wenn das plattformübergreifend standardisiert würde, wäre das großartig, und da auch Mobile dazugehören muss, wären Apple und Google wohl realistischerweise die Akteure, die so etwas am ehesten vorantreiben könnten. Meta könnte folgen oder umgekehrt sogar zuerst aktiv werden
    Entscheidend ist, dass es nicht an ein bestimmtes Werbemodell gebunden sein darf
    Apps sollten anfragen können und dann ein geeignetes Modell auswählen
    (1) https://developer.apple.com/documentation/foundationmodels

    • Apples Foundation Models sehen in der Dokumentation gut aus, aber in der Praxis fällt sofort das 4k-Kontextfenster auf
      Natürlich ist das alles noch in einer frühen Phase

  • https://github.com/mozilla/standards-positions/issues/1067

  • Wir nutzen das für Hackday-Retrospektiven-Zusammenfassungen
    https://remotehack.space/previous-hacks/
    Ein kleines Skript, das RSS-Feeds liest und daraus Zusammenfassungen für den Haupttext erzeugt; das passt ziemlich gut zu statischen Websites. Irgendwann würde ich es gern erweitern, um zum selben Inhalt auch andere Fragen stellen zu können

  • Ein im Browser zugängliches lokales LLM ist gut für die Privatsphäre, aber wenn hinter dieser API je nach Browser unterschiedliche Modelle hängen, könnte das Testen noch viel schlimmer werden als ohnehin schon
    Wahrscheinlich würden sich die meisten Implementierungen am Ende an Gemini Nano ausrichten, daher frage ich mich, ob das Nutzer noch stärker in Richtung Chrome ziehen könnte

    • Test-Fragmentierung ist wirklich das Kernproblem
      Prompts sind in der Praxis eben nicht modellagnostisch, daher kann ein sorgfältig auf Gemini Nano 3 v2025 abgestimmter Prompt bei einem Gecko-Modell stillschweigend deutlich schlechter funktionieren. Die API bietet aber nicht einmal Capability Detection, um darauf zu reagieren
      Das ist noch schlechter als bei WebGL, wo man wenigstens verfügbare Erweiterungen abfragen konnte. Funktionen auf Prompt-Qualität eines hinter dem Browser verborgenen Modells auszurollen, ohne Namen oder Version zu kennen, ist ungefähr so, als würde man Software veröffentlichen, deren Features davon abhängen, welches Wörterbuch der Nutzer installiert hat

  • Soweit ich weiß, ist Gemini Nano anders als Gemma kein Open-Weights-Modell
    Falls das nicht schon jemand getan hat, würde ich die Modellgewichte gern dumpen