Deep Dive 211 – Transformers.js mit Nico Martin

Wie hat dir die Folge gefallen?
Gut 👍
Schlecht 👎
(Keine Anmeldung erforderlich)

In dieser Folge begrüßen wir einen alten Bekannten in der programmier.bar: Nico Martin, Machine Learning Engineer bei Hugging Face und gern gesehener Podcast-Gast und programmier.con-Speaker.

Während Nico bei seinen letzten Besuchen noch über WordPress und PWAs sprach, tauchen wir heute tief in die Welt von WebML ein. Wir besprechen, wie ihr mit Transformers.js modernste Machine-Learning-Modelle direkt in euren JavaScript-Anwendungen ausführt – egal ob im Browser, in Node.js, Bun oder Deno.

Warum sollte man ML-Modelle überhaupt lokal beim Team oder den Endnutzenden laufen lassen, statt einfach eine API anzufragen? Nico erklärt uns die Vorteile von On-Device AI: von maximaler Privacy über Offline-Verfügbarkeit bis hin zur Vermeidung von Latenzen bei großen Mediendateien. Wir räumen mit dem Vorurteil auf, dass Machine Learning im Web nur aus Chatbots besteht, und schauen uns spannende Use Cases wie Background Removal, Voice Activity Detection oder lokale Audio-Transkription an.

Und natürlich stellt Nico auch die neusten Updates von Transformers.js vor, das gerade in Version 4 erschienen ist und jetzt unter anderem seine eigene Tokenizer Library mitbringt. Er erklärt uns auch, welche Herausforderungen es bei der Gestaltung der APIs gab und wie Transformers.js es schafft, dutzende Use-Cases, unterschiedliche APIs und eine quasi endlose Anzahl an Modellen zu vereinen und erfolgreich zu abstrahieren.

Außerdem sprechen wir über die zugrundeliegende ONNX Architektur und Runtime und beleuchten, was damit alles geht und was nicht. Wir sprechen über Herausforderungen im Caching, der Bandbreite des Clients und strikte RAM-Limitierungen, insbesondere in mobilen Browsern.

Schreibt uns!
Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.bar

Folgt uns!
Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.

Bluesky
Instagram
LinkedIn
Meetup
YouTube

Musik: Hanimo

Transcript

SPEAKER_00 0:07

Hallo und herzlich willkommen zu einer neuen Deep Dive-Folge hier in der Programmierbar, beziehungsweise bei Garelt in der Programmierbar. Der sitzt nämlich in unserem neuen Studio. Hallo Gareth, schön, dass du da bist. Hallo Jan, ich freue mich auch. Und neben Garet am Start ist heute noch Nico Martin. Nico ist schon ziemlich häufig in der Programmierbar gewesen. Ich glaube, angefangen, irgendwann so 2019, 20 oder sowas, schon sehr lange her, über WordPress damals.

SPEAKER_01 0:37

Klasse 2020.

SPEAKER_00 0:41

Dann 2024 nochmal, glaube ich, war das über PWAs, da waren wir schon zusammen in der Folge. Und 2025 als MVP auf der Programmiercon mit dem bestgerateten Talk von allen. Und dementsprechend 2026 auch wieder auf der Programmiercon. Also eigentlich schon Ehrenmitglied in der Programmierbar. Wow.

SPEAKER_03 1:04

Haben wir gar kein Applaus-Media hier? Wir haben sowas. Weil das. Ich höre nichts.

SPEAKER_00 1:14

Ja, man muss auch auf Play drücken. Oder Riverside sick gerade wieder. Also wir hatten jetzt eigentlich einen Applaus gehabt. Hallo, mega schön hier zu sein. Wow, cool. Ah, hier ist Clapping.

SPEAKER_03 1:29

Okay.

SPEAKER_00 1:30

Ja, aber ich habe auch Clapping gedrückt, aber Clapping klappt nicht bei mir.

SPEAKER_03 1:33

Bei mir auch nicht. Okay, nur so ein kleines Emoji. Wie Nico schon gesagt, einmal mit Profis, ne? Wir sind so gut vorbereitet.

SPEAKER_00 1:41

Also ich habe natürlich vor einer Stunde darauf hingewiesen worden, dass ich diese Podcast-Folge machen soll und bin noch mit neun Stunden gejetlaggt, weil ich noch nicht mal 48 Stunden wieder im Land bin. Garet, was ist deine Ausrede? Ich habe Kinder.

SPEAKER_03 1:56

Ich habe ständig Jetlag, sozusagen.

SPEAKER_00 1:59

Ich habe Kinder, ich habe ständig Jetlag, das ist auch richtig. Dennis hat gesagt, ich soll hier einspringen über diese Folge zu Transformers Jazz. Ich weiß gar nicht viel. Mein Lieblingstransformer ist Bumblebee. Garet, wie sieht es bei dir aus?

SPEAKER_03 2:15

Alter, sorry, ich musste erstmal auf diesen Switch klarkommen. Nicht Optimus Prime, es ist zu leicht. Ich kenne nur Bumblebee. Ich würde es jetzt auch den nehmen.

SPEAKER_01 2:27

Der Geld nehmen.

SPEAKER_03 2:29

Ja, ich glaube schon, oder? Megatron, einfach, ich bin der Böse.

SPEAKER_00 2:33

Das sind aber nicht die Transformer, das sind die, das sind ja alles Transformer. Das eine sind die Autobots, das andere sind die Decepticons. Mensch, Leute, wo ist euer 80er Jahre wissen? Alter, Alter. Mann, Mann, Mann. Ich bin ein bisschen enttäuscht, muss ich sagen. Ich bin ein bisschen enttäuscht. Okay, genial. Wenn wir nicht über Autotransformer reden können, dann müssen wir über andere Transformer reden. Und bevor wir zu Transformer.js einsteigen, vielleicht einmal der initiale Pitch. Und weil Nico bestimmt weiß, was der richtige Pitch ist, frage ich zuallererst Gareth. Der freut sich ja auch immer gerne, wenn er offline und lokale Modelle benutzen kann. Garelt, was ist dein Pitch zu Transformer.js? Was ist das und warum sollte mich das interessieren?

SPEAKER_03 3:15

Stell dir vor, du willst eine App bauen, aber du denkst dir so, wow, das muss schon im Webbereich sein. Und dann fragst du dich aber, warte mal, wir leben doch in dem Zeitalter der AI. Meine App muss auch AI können. Aber kann das das Web überhaupt? Dann googelst du kurz und dann findest du natürlich Nico Martins LinkedIn-Account, wo er über Transforma.js spricht und denkst, das ist die Lösung für alle meine Probleme. Und nutzt Transforma.js, um AI in alle deine Web-Applikationen einzubauen. Egal ob es Sinn ergibt oder nicht. Du solltest es einfach tun. Das ist mein Fitch.

SPEAKER_00 3:50

Egal, ob es Sinn ergibt oder nicht. Wunderbar. Nico, wie nah an der richtigen Antwort war Garel da schon?

SPEAKER_02 3:56

Gar nicht mal so weit weg. Ich würde es in einem Satz zusammenfassen, und Tagline, ist halt State of the Art Machine Learning für JavaScript. So. Das heißt, du kannst Machine Learning-Modelle in allen möglichen Farben und Formen in JavaScript ausführen, heißt also im Browser, aber genauso auch in Node, Bun, Dino, allen möglichen Runtimes. True.

SPEAKER_03 4:25

Wunderbar. Ich glaube, ich habe die meisten Demos irgendwie mit so Web-Applikationen gesehen. Du hast ja auch deine praktisch eher alles im Web gemacht, aber klar, ja, das deckt natürlich vieles ab, wenn es einfach JavaScript ist. Ja, cool. Genau.

SPEAKER_00 4:40

Vielleicht können wir da direkt einspringen mit der ersten Frage, weil du hast jetzt gerade schon so Machine Learning gesagt als großen Übergriff und das heißt ja aber Transformer.js. Und jetzt sind ja Transformer nur so ein Teil von Machine Learning und Machine Learning kann ja noch ganz viele andere Sachen bedeuten. Wenn ich jetzt Transformers.js benutzen will, bin ich dann wirklich so auf Transformer-Modelle beschränkt oder kann ich viel mehr andere Sachen machen, die auch noch so rund um Machine Learning stattfinden?

SPEAKER_02 5:18

Du bist beschränkt, was also erstmal die Transformers-Architektur ist ja so ein bisschen das, was im Moment am sowieso am meisten verwendet wird. Das heißt, genau. Wo du ein bisschen überschränkt bist, ist in dem Framework, was wir nutzen, under the hood, sozusagen, um die Inference auszuführen. Und das ist halt Onyx, also dieser Open Neural Network Exchange Standard. Heißt eigentlich, jedes Modell, was du in Onyx konvertieren kannst, kannst du dann auch mit TransformersJS ausführen. Also dort ist ein bisschen der Bottleneck.

SPEAKER_00 5:54

Okay. Und dann lass uns doch da gleich nochmal ein bisschen genauer drauf schauen. Du hast jetzt einfach so gesagt, na, wir nutzen hier Onyx under the Hood, aber wie kommt denn Onyx überhaupt in eure Runtime rein? So, weil das ist ja jetzt kein JavaScript-Framework per se.

SPEAKER_02 6:11

Genau. Vielleicht fangen wir ganz vorne an eben. Ein Machine Learning-Modell ist ja ein neuronales Netz. Das neuronale Netz hat verschiedene Layer von Neuronen. Du hast Input Layer, du hast Hidden Layer und du hast ein Output-Layer. Innerhalb oder zwischen diesen Layern hast du Operationen, also mathematische Operationen, die werden ausgeführt, bis dann am Ende rauskommt eine Wahrscheinlichkeit für was auch immer dieses Modell dann für was es trainiert wurde. Onyx ist ein Format, was das Modell und die Weights von dem Modell von der Runtime trennt. Und das ist ganz wichtig für uns bei Transformers.js. Du hast Onyx, was das Modell beschreibt. Du hast also, das beschreibt, wo sind die Layer, welche Operationen werden ausgeführt. Und hier sind die Weights, also welche Parameter werden verwendet innerhalb von diesen Operationen, um dann zum rechten Resultat zu kommen. Das ist der eine Layer. Und dann hast du die Runtime. Und bei Onyx ist es so, dass du eigentlich jedes Onyx-Modell in jeder Runtime ausführen kannst. Wir haben zum Beispiel eine Onyx Runtime-Web mit WebGPU oder WebAssembly Runtime. Aber du hast dann auch eine DirectML oder eine CUDA-Runtime, wenn du es in Server-Side-Travoscript ausführen möchtest.

SPEAKER_00 7:39

Wie musst du dir das denn technisch vorstellen, was ist denn, also wenn ich jetzt so ein Modell in Onyx reinschmeiße, reinschmeiße, was kommt da denn überhaupt an? Ist das so was binär zusammenkompiliertes? Ist das nur irgendwie ein maschinenlesbares Format mit ganz vielen Anweisungen drin? Was bekomme ich denn als Modell in diese Ausführung rein?

SPEAKER_02 8:02

Genau, es ist ein.Onyx-File, was ein Binärformat ist und je nach Größe, hast du dann noch ein Onyx-Data-File oder mehrere Onyx-Data-Files, wo die Weights dann noch gestort werden, weil ich glaube, momentan ist es so, dass ein Onyx-File nicht größer als 2 GB sein darf und deswegen, je nachdem, wie groß das Modell ist, wird es dann halt auf verschiedene Onyx und Onyx Data-Files. Aber das ist ein binäres Dateiformat, was Onyx Runtime dann lesen kann. Also jetzt im Fall von Onyx Runtime Web ist es so, dass wir laden sozusagen die Factory, die dann mit dem Onyx WebAssembly Binary kommuniziert, laden wir einen Browser. Der holt sich dann, oder nee, eigentlich wir holen die Onyx-File, die es braucht, und füttern die dann in dieses WebAssembly-Binary mit rein. WebAssembly deswegen, weil du halt diese Runtime hast, die in verschiedenen auf verschiedenen Devices laufen soll. Und WebAssembly ist eigentlich so der Layer, der das halt möglich macht, dass du es in Java oder dass es so einfach wie möglich in JavaScript nutzen kannst. Heißt aber nicht, dass auch die Kalkulationen dann in WebAssembly laufen. Es gibt eine Onyx Runtime WebAssembly, wo das dann auf dem CPU und WebAssembly passiert, aber in der Regel nutzen wir WebGPU. Das heißt, wir haben dieses WebAssembly, was das Modell einliest, aber dann die Operationen an WebGPU delegiert. Das heißt, die Operationen selber laufen dann auf dem GPU oder über WebGPU im GPU vom Gerät.

SPEAKER_00 9:45

Und Onyx ist aber nicht von euch, das ist, glaube ich, so ein Microsoft-Projekt oder sonst mal gewesen.

SPEAKER_02 9:52

Genau. Ist immer noch Microsoft, also gerade mit dem Onyx Runtime Web-Team, arbeiten wir ziemlich eng zusammen. Und das ist auch so, dass ich wie auch Joshua, wir haben beide schon auch Commits zu Onyx Runtime Web gemacht. Und wir sind, glaube ich, wenn ich es richtig im Kopf habe, zumindest für Onyx Runtime Web bei weitem die größte Library, die das verwendet, von dem ist auch für sie wichtig, aber da sind wir ziemlich eng in der Zusammenarbeit.

SPEAKER_03 10:23

Kannst du vielleicht nochmal dann ganz kurz erklären, was bietet dann Transformer.js? Ist das sozusagen der Rapper für Onyx, dass ich mich nicht darum kümmern muss, wie wird das Model geladen, wie packe ich das in die Runtime und wie, welche Runtime nutze ich überhaupt? Es ist genau. Kann man Convenience Wrapper sagen oder bietet es noch mehr als das?

SPEAKER_02 10:46

Ja, Convenience Wrapper passt, also was Transformers S macht, sind vier Sachen. Das eine ist mal das Handling von den Model-Files. Also sprich, du in der Regel lädst du die Files vom Huggingface Hub, die werden in den Browser geladen, je nachdem, was wir im Caching, wir haben einen Caching-Mechanismus für Node.js, was einfach als File im Filesystem gecached wird, oder dann im Browser in der Cache-API. Das heißt, nach dem ersten Download bleibt es im Browser. Das ist das eine, dass wir das Handling von den Files machen. Dann haben wir Pre-Processing, weil ein Modell erwartet ein Tensor wet. Ein Tensor ist ein numerischer Wert, also es kann eine Zahl sein, kann ein Array von Zahlen sein, also eine Liste von Zahlen, kann aber auch eine Liste von Listen von Zahlen sein oder und so weiter und so fort. Also es ist immer numerische Werte. Und am Ende kommt auch ein Tensor wieder raus. Heißt, wir haben das Pre-Processing, dass wir aus dem Input, den du reingibst, ein Text, ein Bild, was auch immer, die Tensors in dem Shape bauen, wie das Modell dir erwarten würde. Dann haben wir die Inference, der dritte Part, der eigentlich dann an Onyx Runtime delegiert wird oder an Onyx. Und dann der vierte Part ist dann das Post-Processing, dass wir aus dem Tensor dann wieder das machen, was du erwarten würdest. Zum Beispiel, keine Ahnung, ein Text. Wenn du einen LLM verwendest, möchtest du wieder Text zurückbekommen, also ist der Part auch wieder Transformers Jess.

SPEAKER_03 12:19

Wahrscheinlich ist Text auch der allergrößte Use Case für Transformer Jazz, oder? Oder würde, kannst du dir vorstellen, auch ein Image-Model darüber laufen zu lassen?

SPEAKER_02 12:34

Ja, natürlich. Aber was wichtig ist, Machine Learning ist nicht nur Large Language-Modelle. Wenn man an Large-Langlage-Modelle denkt, ja, dann ist wohl der häufigste Use Case, du hast halt einen Text, der Text wird in einen Input-String verwandelt, läuft durch, neue Tokens werden generiert und du bekommst eine Antwort. So, Text-to-Text in der Regel. Das ist ein Task, den wir anbieten, der nennt sich Text Generation. Auf der anderen Seite sind die Modelle, also LLMs, sind halt, auch die kleinen LLMs sind sehr groß. Du hast aber, wenn du außerhalb von Large Language Modellen denkst, hast du halt Tasks, die viel besser geeignet sind für das Web. Das zum Beispiel ein Background Removal Task. Du hast ein Bild, das führt das du rein, wird eingelesen, geht durchs Modell und du bekommst dann einfach nur das Bild zurück vom Vordergrund ohne den Hintergrund. So kleineres Modell läuft relativ gut auf älterer Hardware, bei schlechterer Internetverbindung und solche Sachen. Das heißt, wir haben eigentlich eine API und das ist auf der einen Seite, was so komplex macht, TransformersJess für uns in der Entwicklung, aber auch für die NutzerInnen halt sehr convenient, weil du hast eine API hast und du kannst basically alle möglichen Modelle reinladen und alle möglichen Tasks damit dann ausführen.

SPEAKER_00 14:02

Also wenn man sich mal die README anguckt von Transformers.js, gibt es ja diese Task-Auflistung, was da alles unterstützt wird. Und das war auch. Also ich bin auch so rangegangen wie Garelt, als ich mir das erste Mal angeguckt habe, gedacht, ja, okay, da kann ich so irgendwie Text Generation irgendwie machen, aber das ist ja zwischen Text Generation, Maskierung, Token Classification, Translation, Feature Extraction, Background Removal hast du gerade angesprochen, Depth Estimation, Image-Klassifizierung, Sentiment Analysis, Audio-Klassifizierung, Audiogenerierung, multimodales Zeug, Visual Question Answering, Reinforcement Leute, also das ist ja irgendwie alles drin. Und das ist das, was ich mir, glaube ich, am schwierigsten irgendwie davon vorstelle, weil was ja, glaube ich, eure Aufgabe ist, auch wenn wir das gerade so als Convenience-Rapper irgendwie schon abgestempelt haben, ist ja all diese Feature halt irgendwie so zu abstrahieren, dass sie ja mit jedem beliebigen Modell, in Anführungszeichen, also jedes Modell, was das natürlich auch unterstützen würde, aber jedem beliebigen Modell ja quasi ermöglichen. Und das ist, glaube ich, so der Teil, wo der größte Teil eurer Arbeit drinsteckt, wahrscheinlich am Ende des Tages, oder? Ja.

SPEAKER_02 15:16

Was lustig ist, wir haben ja jetzt gerade vor kurzem die Version 4 rausgebracht und da haben wir relativ viel Refactoring gemacht. In der Version 3 hatten wir einen Models.json, sorry, Models. Also ein Model.js-File. Und in dem Pfeil waren eigentlich nur verschiedene Modellarchitekturen und so wie kleine, so was ist bei dem Modell anders als bei anderen Modellen. Hier kommt noch der Schritt dazu, hier kommt Dashrit dazu. Und das Ding war 8000 Zeilen lang, das Pfeil.

SPEAKER_00 15:49

Also in der README stehen ja auch über 200 Modelle, die ja unterstützen. Also da ist ja auch 8000 ist dann gar nicht mehr so viel eigentlich. Das sind 40 Zeilen pro Modellanweisung.

SPEAKER_02 15:59

Genau, und dann haben wir das Ganze natürlich auseinandergenommen, jetzt haben wir das alles schön in eine schöne Struktur reingebracht und so, aber allein das Pfeil mal durchzulesen und mal zu gucken, okay, ja, war spannend.

SPEAKER_03 16:14

Okay, das heißt ihr, weil ich habe mich gerade gefragt, so wenn ihr das so architekturspezifisch macht, ist es aber schon so, dass ihr nicht jedes Modell einfach, dass man nicht jedes Modell einfach nutzen kann. Es muss schon unterstützt sein. Und sehr wahrscheinlich, wenn man praktisch anfragt, so, hey, könntet ihr das Modell auch unterstützen, müsstet ihr auch was ändern an der Library.

SPEAKER_02 16:36

Kommt drauf an, es geht in der Regel um die Modellarchitektur. Heißt, wenn du ein Modell feintunest, basierend auf einem Modell, was unterstützt wird, mit derselben Architektur, das dann in Onyx exportierst, dann kannst du das problemlos nutzen mit halt deinen gefeintunten Model Weights. Wenn jetzt aber ein neues Modell rauskommt, wie letztens gerade eben Gemma 4, dann ist es in der Regel so, dass wir eigentlich zwei Sachen machen müssen. Erstmal bei der Konvertierung vom Modell zu Onyx, also so wie sie es halt dann rausgeben zu Onyx, das ist ein Teil, wo wir Arbeit reinstecken müssen. Und dann je nachdem, was sich sonst noch im API-Surface geändert hat, müssen wir dort auch noch was anpassen. Aber die Anpassungen in Transformer-Jess sind in der Regel relativ minimal.

SPEAKER_00 17:27

Und das heißt, auch so Sachen wie Quantisation ist dann für euch wahrscheinlich auch kein Problem, solange die Architektur halt einmal drin ist. Also wenn jetzt Gemma 4 rausgekommen ist und es gibt jetzt verschiedene Quantifications davon, dann ist das überhaupt kein Problem, wenn ich sage, ich nehme jetzt eins mit einer geringeren Auflösung oder so, weil ich bin halt hier mobile unterwegs und habe nicht so viel Bandbreite oder nicht so viel Speicher oder so und will halt was Kleines nutzen, das geht dann auch.

SPEAKER_02 17:52

Ja, wobei Quantization schon beim Onyx-Export passiert. Also eigentlich, wenn wir ein Modell hochladen, dann ist es schon in verschiedenen Quantisation-Formaten verfügbar in Hugging Face. Im Repo. Okay.

SPEAKER_03 18:11

Aber ich kenne Hugging Face hauptsächlich über lokale LLMs, die man jetzt in LM Studio oder so laufen lassen kann. Und da kenne ich die Dateiformate GGUF und MLX, wenn man das Dateiformat nennen kann, da kenne ich mich nicht mehr aus. Aber ONNX ist jetzt nochmal dann was anderes, oder? Das ist nichts, was ich jetzt in LM Studio laufen lassen würde, sondern ihr habt das im Repo von diesem Modell, aber das wird nur von Transformer.js benutzt. Verstehst du das?

SPEAKER_02 18:38

Ja, oder? Also hauptsächlich von Transformer JS, aber theoretisch könnte jede Onyx Runtime die Modelle dann verwenden. Okay, ja. Wir haben in Haging Face eine Org, die nennt sich Onyx Community. Und dort sind eigentlich die Modelle, die wir jeweils konvertieren, die laden wir dann jeweils in diese Onyx Community und wer sie dann nutzt, ist dann, ich denke mal, die meisten über Transformers Jazz, aber können genauso gut auch über direkt Onyx verwendet werden.

SPEAKER_03 19:10

Ah, das habe ich mich nämlich auch schon aufgefragt. Das ist vielleicht ein kleiner Exkurs, aber bei LM Studio, wenn man da Modelle unter dieser, zum Beispiel MLX-Community findet, dann ist das eigentlich von euch gemacht. Weil Community klingt für mich immer so, das haben halt andere User von High Gang Face erstellt.

SPEAKER_02 19:29

Beides. Also bei Onyx Community weiß ich jetzt gar nicht, wer da alles mitarbeitet, aber das sind zum Teil Modelle von uns, aber zum Teil sicher auch Modelle von. Oder auch Modelle, wenn Slab zum Beispiel selber eine Onyx Conversion rausbringt, dann kann man auch die nutzen. Also das muss nicht im Onyx Community Org sein, das kann auch. Ich glaube, Liquid AI hat ihre Modelle in ihrer eigenen Org drin. Das ist egal, woher die kommen.

SPEAKER_00 20:06

Okay. Jetzt hast du schon gesagt, Quantisation ist im Prinzip wird auch schon von euch erledigt. Modelle werden von euch bereitgestellt. Was muss ich denn selbst noch tun, außer Transformers.js als Dependency hinzuzufügen und zu sagen, ich brauche dieses Modell. Muss ich noch irgendwas anderes machen?

SPEAKER_02 20:33

Nee. Also was wir haben, wir haben die sogenannte Pipeline API. Und Pipeline, also vielleicht noch ein Stück zurück, Transformers.js ist ja oder lehnt sich stark an der Transformers Python Library an. Deswegen sind eigentlich alle, alles, was wir exposen, ist, sieht sehr ähnlich aus wie Index Transformers Python Library. Und die hatten auch dieses Konzept von Pipeline, da hast du eine Task-ID, was möchtest du damit machen, dann das Modell und dann ein paar Options und so. Deswegen, wenn du die Pipeline-Function verwendest, dann importierst du die von TransformersJS, baust dir dann eine Pipe, heißt du erstmal definierst du, welchen Task möchtest du verwenden, bleiben bei Text Generation, also bei LLMs, würdest du sagen, Text Generation. Dann als zweiten Parameter sagst du, welches Modell du verwenden möchtest. Und das ist in der Regel einfach der Pfad im Hugging Face-Hub drin. Also von mir ist jetzt Onyx Community, Gemma 4, E2B, Onyx, irgendwas, damit Transformer weiss, wo das Modell runtergeladen wird. Und dann kannst du noch in den Options angeben, möchtest du es in WebGPU laufen lassen, welche Quantizierung, also welchen D-Type möchtest du verwenden? Und du bekommst auch ein Progress Callback als Option, wo du dann den Download-Progress tracken kannst. Also der Part ist relativ wichtig, dass du auch zeigen kannst, was im Moment gerade passiert, weil je nachdem hast du ein LLM, was ein paar Gigabyte groß ist, dauert einen Moment, bis es runtergeladen ist und dann bekommst du halt so ein Progress-Event, wo du dann zeigen kannst, hey, wir sind da 10, 20, 30%, wir sind da runterladen. Und dann hast du die Pipe. Und dann bist irgendwie eine Text Generation, Pipe oder was auch immer. Und dann kannst du je nach Task, jede oder jeder Task returned ein anderes, eine andere Pipe in dem Sinn. Bei Text Generation wäre es jetzt so, dass du diese Pipe-Funktion aufrufst mit einem Array von Messages und der Minimalfall Array von Messages und dann bekommst du die Antwort zurück. Also es ist wirklich, wenn man bei der Pipeline bleibt, ist es mega wenig Code, den du selber schreiben musst.

SPEAKER_00 23:03

Du hast ja auch gesagt, also Gareth matt ja so AI im Browser irgendwie an den Start zu bringen mit TransformersJase. Du hast dann direkt darauf hingewiesen, dass es ja auch andere Runtimes gibt, serverseitig, die auch unterstützt werden. Wo seht ihr denn aktuell die größte Usage? Also sind es wirklich mehr Leute, die das in ihr Dino-Node, Whatever-Projekt, Backend-Seitig bringen wollen, oder ist es wirklich mehr im Browser, wo es direkt kleinseitig ausgeführt wird?

SPEAKER_02 23:32

Schon im Browser. Weil sobald du einen Server hast, wenn du irgendwie deinen eigenen, keine Ahnung, hast einen Vektor-Embedding-Service, dort hast du ja in der Regel, kannst du selber entscheiden, welche Software dort drauf läuft. Und dann hast du effizientere Wege, dein Modell laufen zu lassen als JavaScript und Onyx. Das ist ja da müssen wir ehrlich bleiben.

SPEAKER_00 24:05

Fair. Fair. Und die meisten, die das dann jetzt browser-seitig benutzen, was machen die damit? Was sind so die größten Use Cases davon? Weil ich muss ehrlicherweise sagen, ich habe jetzt noch kein Projekt gesehen, wo ich zumindest für mich so direkt offensichtlich gesehen habe, ah, hier wird irgendwie Transformers.js genutzt, um dieses oder jenes Feature anzubieten. Deshalb muss ich ganz doof fragen, was machen die Leute damit?

SPEAKER_02 24:35

Ich würde sagen, es sind oder dort, wo ich auch das meiste Potenzial sehe, sind halt wirklich kleinere Tasks. Weil ein Large Language Modell, es ist cool, dass es funktioniert und funktioniert super als Demo, aber du musst halt damit rechnen, dass wenn du das in deine Webapplikation integrierst, müssen deine NutzerInnen erstmal ein paar Gigabyte Daten runterladen, die erste Hürde, und dann muss auch die Hardware entsprechend sein, damit du das flüssig nutzen kannst. Also auf einem MacBook kommst du bei einem LLM gut mal auf irgendwie 20, 30, 40, 50 Tokens pro Sekunde, aber bei einem älteren Windows-Gerät bist du dann bei zwei, drei Tokens pro Sekunde. Das macht dann nicht viel Spaß. Wo du aber, wo aber viel Potenzial ist, ist bei kleineren Modellen, wo du nicht nur, wo es nicht, oder anders, wo die Latency auch wieder eine Rolle spielt. Bei einem LLM sendest du Text an einen Server und bekommst Text zurück. Es ist, also da hast du ja kaum Daten, die du hin und her schicken musst. Also das geht relativ schnell und die Verarbeitung auf dem Server ist auch schnell, alles gut. Sobald du dann aber Bilder oder Audio verschicken musst, hast du größere Datenpakete und dann spielt es sich eine Rolle, wo oder was musst du mit dieser, wohin werden die Datenpakete geschickt, und dann ist die Balance zwischen Zeit, die es braucht für die Inference und Zeit, die es braucht für die Kommunikation mit dem Server, die Balance sieht dann ganz anders aus. Und das beste Beispiel finde ich Voice Activity Detection. Voice Activity Detection sind in der Regel sehr kleine Modelle, also wirklich ein paar Megabyte, und die auch sehr schnell ausgeführt werden können. Und da ist die Idee, dass du halt einen kleinen Audio-Snippet ans Modell schickst und dann bekommst du zurück, ob da jemand am Reden ist oder nicht. Und das macht vor allem deswegen Sinn, dass, wenn du sagen will, du hast ein Chatbot, brauchst du irgendeinen Trigger, wo der Chatbot erkennt, ah, da redet gerade jemand, also ja, ich muss die Aufnahme starten, oder ah, ist jetzt gerade fertig, das heißt, ich kann den Audio, den ich jetzt aufgenommen habe, kann ich irgendwo hinschicken. Das ist so ein mini-kleines Modell und das macht halt überhaupt keinen Sinn, dass jedes kleine X-Millisekunden-Snippet an den Server zu schicken und dann die Antwort abzuwarten, das ist viel schneller, wenn du das direkt auf dem Gerät machst und dann erst das Audio, was aufgenommen wurde, an den Server schickst. Oder dass du sogar dann den zweiten Schritt, die Audio Transcription, auch auf dem Gerät machst. Heißt, dass du erst erkennst, ob jemand redet, dann die Aufnahme machst und dann aus der Aufnahme den Text extrahierst, also das Transkript von dem, was gesagt wurde, dass du das auch schon auf dem Gerät machst, was unter Umständen auch schneller ist, als wenn du erst das Audio hochschickst, dort die Influence machen lässt und dann das Transkript zurückbekommst.

SPEAKER_00 27:41

Also, was da so ein bisschen meine Sorge ist, warum ich das gefragt habe, ist, das hat ja schon sehr hohe initiale Kosten. Also ich bin voll bei dir zu sagen, lokale Audio Transcription ist halt super schnell und mittlerweile auch sehr zuverlässig eigentlich. Ich habe ja auch ein kleines Projekt laufen, auch mit Transformer.js, was lokale Audio Transcription macht. Das läuft, aber das erfordert halt auch, dass ich beim Starten irgendwie, ich weiß nicht, wie groß Whisper ist, 200, 300 Megabyte oder so mal runterlade. Und das ist ja schon was, was für wahrscheinlich viele Endnutzerinnen da draußen sehr intransparent ist. Die kommen dann jetzt auf meine Chatbot-Seite oder sowas und werden gefragt, so, hey, willst du irgendwie das Audio-Feature nutzen? Ja oder nein? Dann drücken sie auf Ja und dann lädt erstmal so 200, 300 Megabyte. Und das ist ja vielleicht gerade auf mobilen, vielleicht auch datenlimitierten Verbindungen oder sowas, ist ja schon auch nicht ohne. Und da mache ich mir so eher Gedanken, das ist kein technisches Problem, wo jetzt Transformer-Store erst dran schuld ist, aber es ist, glaube ich, so ein UX-Problem, was man halt irgendwie lösen muss. Wie bietet man das einem Benutzer, eine Benutzerin am Ende des Tages an, zu sagen, wir haben hier ein cooles Feature für dich, aber das kostet dich halt, weiß ich nicht, ne, 200 Megabyte und erstmal runterladen musst. Keine Ahnung, du willst auf irgendeiner Social Network-Seite ein neues Foto hochladen und kannst dein Hintergrund automatisch freigestellt bekommen. Aber ich muss dafür erst ein komisches Modell runterladen. Um mein 1-Megabyte-Bild irgendwie freizustellen, lade ich 200 Megabyte Modell runter. Das ist halt komisch. Und das ist, glaube ich, was, wo wir irgendwie so einen Weg finden müssen, das richtig anzubieten. Ja.

SPEAKER_02 29:29

Was ich gerne empfehle, ist, dass man, dass man es optional macht. Zum Beispiel, ähm, bleib mir bei einem Chatbot oder bei einem irgendeinem Agent, der dir was auf deiner Seite erklären kann. Du kannst sagen, hey, das Ding funktioniert on-Device, sprich, das funktioniert, wenn du offline bist, das funktioniert ohne dass, das haben wir noch gar nicht angeguckt, Privacy, also sprich, dass die Daten bleiben immer auf dem Gerät. Du kannst es nutzen, heißt aber, du musst 3 GB an Daten runterladen. Oder du nutzt unseren Cloud-Dienst. Keine Ahnung, wo der ist, keine Ahnung, wo die Daten hingeschickt werden, aber ist halt dann, ist unter Umständen more convenient. So.

SPEAKER_00 30:15

Ich finde die, sorry ganz kurz. Erpunkt mich noch. Die andere Alternative, wo ich nämlich aktuell drauf hängen geblieben bin, ist zu sagen, naja, wir bieten halt, je nachdem, wie du gerade unterwegs bist, andere Modelle an. Ich bin jetzt hier in dieser Anwendung, die ich gebaut habe und du bist irgendwie auf einem Desktop und lokal, bla, und dann kriegst du halt ein Gemma 4-Modell runtergeladen. Das sind irgendwie, weiß ich nicht, 2, 3 Gigabyte, so, kannst du zu Hause am Rechner mit genug Strom und fester Internetverbindung überhaupt kein Thema. Du besuchst dieselbe Seite irgendwie auf einer mobilen Verbindung, auf einem kleinen Gerät. Boah, dann kriegst du, ich weiß gar nicht, was habe ich hier dann reingebaut? Weiß nicht mehr, bei irgendwie so ein super kleines 200 Megabyte-Textmodell oder sowas. Aber es ist dann halt auch schlechter, ne? Also das gehört ja dann auch irgendwie dazu. Und das ist auch wieder was, was man so ein bisschen mitkommunizieren muss, dann zu sagen, so, hey, ich kann dir gerade, also ich habe es tatsächlich versucht, ich kann dir mobil keinen Gemma 4 anbieten, weil dein Browser halt abschmiert. Also ich habe wirklich vielleicht ein kleiner Bugreport hier zu Transformer-Stress. Es ist wirklich super schwierig, diese großen Modelle mobil zum Laufen zu bringen, weil halt irgendwie RAM-Limit und dein Browser schmeißt dich raus, wenn dein Prozess zu lange läuft und dein Download zu groß wird und sowas, da könnt ihr nichts für. Aber es ist halt was, was als Developer auf einmal so eine ganz neue Hürde ist, weil wir sehr lange und sehr wenig damit beschäftigen mussten. Als diese ganzen, als so Mobile, Internet irgendwie neu war, da war noch so, boah, RAM und wir müssen aufpassen und Assets dürfen nicht so groß sein und bla. Und irgendwann sind Smartphones so geil geworden, dass es überhaupt kein Problem mehr ist. Und jetzt müssen wir uns auf einmal wieder irgendwie darum kümmern, weil halt irgendwie mit Jamma 4, 2 Gigabyte RAM in einem Safari-Tab anzufragen, mobil, halt nicht so geil ist und dann killt Safari dich halt so.

SPEAKER_01 32:01

Ja.

SPEAKER_02 32:04

Voll. Also es ist, ich, komm, du meinte ich das vorher mit den Tasks. LLMs sind mega cool, um eine Demo zu bauen, zum zeigen. Ich habe jetzt vor ein paar Tagen habe ich gerade eine Chrome-Extension released als kleine Demo, wo du eigentlich mit Gemma 4 gewisse Tasks innerhalb von deinem Browser ausführen kannst. Ist cool, weil die Chrome Extension ist in der Regel auf deinem Desktop-PC. Du weißt, es ist nicht, also jemand lädt das runter und nutzt es dann auf verschiedenen Seiten, das ist nicht eigentlich Pro Origin, sondern nach deine Extension einmal runtergeladen ist dort und kann, also gerade Gemma 4 ist ein mega, mega gutes Modell, was Tool-Calling angeht. Egal welche Tools ich da reinschmeiße, ich kann meine eigenen Tools dafür bauen, die mir in meinem Browser irgendwas machen und es funktioniert dann einfach. Das funktioniert als Demo super. Aber würde ich jetzt ein LLM in meiner Production-Applikation für meinen Webshop einbauen als Customer Support Agent, auf gar keinen Fall. Also so. Aber du hast dann halt andere Tasks, die, wie gesagt, Voice Activity Detection geht nur on Device. Es macht überhaupt keinen Sinn, das in der Cloud zu machen. Background Removal oder auch Automatic Speech Recognition sind so Sachen, wo du halt gucken musst, wie ist die Qualität, wie ist die Größe vom Modell, welche Quantisierung. Das sind Trade-offs und da kommst du zum einen oder zum anderen Schluss. Und ich denke, je weiter wir in die Zukunft denken, desto besser wird die Hardware und desto öfter wird die Entscheidung dann zugunsten von On-Device ausfallen. Aber doch, du hast ein Trade-off und als EntwicklerIn musst du dir halt überlegen, was ist mir wichtig? Ist Privacy wichtig für mich? Ist es wichtig für mich, dass ich keinen Speech Recognition-Server am Laufen halten muss, sondern ich möchte einfach meine Applikation chippen und möchte, dass das Zeug bei meinen NutzerInnen läuft. Das sind die Überlegungen, die du halt machen musst, wenn du Transformers Jazz verwenden möchtest, gegenüber irgendwelchen Cloud-Cloud-Anbietern.

SPEAKER_00 34:13

Gareth, wir hätten mal Benni einladen müssen. Der hat doch auch dieses Translation-Tool gebaut, was komplett im Browser läuft. Das wäre ja auch eigentlich ein cooler Use Case gewesen, um da mal drüber zu sprechen.

SPEAKER_03 34:22

Ich meine, gerade diese User Experience ist, glaube ich, auch sehr abhängig davon, was das eigentlich für eine Applikation ist. Also würde ich jetzt auf eine Shopping-Seite gehen, wo ich ein Chatbot öffne und der sagt mir erstmal, ja, du musst erstmal 3 Gigabyte runterladen, auf gar keinen Fall. Aber habe ich eine Web-App, wo ich mich irgendwo anmelde, mir einen Account erstelle und weiß, okay, hier kommt jetzt praktisch eine Funktion und da wird ja oft auch irgendwie gesagt, okay, wir initialisieren was auch immer, dann würde ich schon viel eher akzeptieren, dass da auch mal was geladen wird oder so. Klar, vielleicht auch mit einer Nachfrage oder so. Aber das kommt ja auch sehr praktisch auf den Bereich an, wo man es einsetzt, wie bereit ich dann bin, noch Dinge zu tun. Oder Nico, wie du schon sagst, eine Extension ist auch wieder was anderes, ist selber Bereich, aber da wäre es für mich auch komplett verständlich, wenn da irgendwas runtergeladen wird. Aber was ich noch spannend finde, ist dieses Thema, Jan, du meinst eben, man kann das Text nicht gar nicht so richtig lösen, aber ich frage mich, ob man es zumindest ein bisschen verbessern kann, indem man guckt, okay, was ist das hier für ein Gerät? Und kann, also habt ihr irgendwelche Features sozusagen, die erkennen können, okay, das Gerät hat nicht genügend Megabyte und dann fange ich erst gar nicht an, das zu laden. Und man hat als Entwickler die Möglichkeit, dann eben darauf zu reagieren und zu sagen, okay, sorry, das Feature ist nicht verfügbar, weil dein Gerät nicht stark genug ist. Weil das wäre für mich wahrscheinlich sogar noch am sinnvollsten für UX, dann sagen sie können, okay, das Gerät muss mindestens so gut sein, sonst bringt das Feature auch, also macht das gar keinen Sinn.

SPEAKER_02 35:57

Haben wir im Moment noch nicht. Was wir haben, ist, wir haben mit Version 4 einen Feature rausgemacht, das nennt sich Model Registry. Und innerhalb von der Model Registry hast du verschiedene Helper-Funktionen, um zu überprüfen, ob ein Model schon gecached ist, ob ein Model die großen Model ist und solche Sachen. Und dort haben wir auch eine Funktion, die dir zurückgibt, welche Quantisierungen verfügbar sind für ein Modell. Damit du zumindest mal weißt, ja, hier könnte ich Q4F16 verwenden. Oder vielleicht gibt es das auch gar nicht bei dem Modell. Wo wir im Moment gerade dran sind, ist so eine Art automatische Device Detection einzubauen, dass man auch einfach Device-Auto eingeben kann und dann würde es das beste Device, vielleicht WebGPU CUDA, was auch immer, verwenden für das Gerät. Das Problem hier ist aber, dass es, man kann nicht einfach sagen, wenn WebGPU vorhanden, dann WebGPU sonst WebAssembly, sondern je nach Modell, es gibt Modelle, die performen besser in der einen oder anderen Device, deswegen sind wir da noch nicht so weit. Es ist ein bisschen komplexer, dass es von außen aussieht. Aber da sind wir dran. Und dann, was das größte Problem ist, ist die Geschichte mit dem RAM. Also sprich, selbst wenn ich genügend RAM hätte, um ein Modell zu laden, ist ja immer noch die Frage, wie viel brauche ich, um es auszuführen. Gerade bei einer längeren Konversation, also wenn wir einen LLM nehmen, hast du, je länger die Konversation wird, desto mehr, desto größer ist dein KB Cash jedes Mal, wenn der neue nächste Token generiert wird. Irgendwann erreichst du halt dann ein Limit. Und ich weiß auch nicht, wie gut die Detection ist. Ich weiß nicht, ob der Browser dir einfach so sagt, wie viel Rahmen zur Verfügung steht oder noch frei ist. Es gibt diverse APIs, aber ich weiß auch, dass sie footprint-mäßig sehr konservativ sind. Ja. Das Einfachste ist sicher mal, nee, es ist auf keinen Fall einfach. Und dann hast du, ja. Mit Mac ist es einfacher, weil du halt wenig Geräte hast und wenig Konfiguration. Aber sobald du es dann öffnest zu Mobile und Windows und so, dann hast du so viele verschiedene Konfigurationen. Und ja, der Browser ist ein guter Abstraction-Layer, um die ganzen Device-Eigenschaften ein bisschen wegzuabstrahieren. Aber das Grundproblem bleibt, dass du so viele verschiedene Hardware hast, dass du gar nicht genau sagen kannst, wie was auf welcher Hardware funktionieren.

SPEAKER_00 38:52

Also es gibt ja so Webseiten wie can Iuse LLM.com und localLLM.run, die im Prinzip genau sowas versuchen, gehst mit deinem Browser drauf, dann kommt so eine Model Registry und da kannst du reingucken und sagen, hier, ich habe jetzt mal bei can Iuse LLM.com Gemma 4 eingegeben und dann sagt er so, naja, du solltest mindestens 4 Gigabyte RAM haben und du solltest irgendwie GPU mitbringen und bla bla bla. Und da siehst du aber schon, dass mein Mac nur mit 32 Gigabyte RAM hier gerade erkannt wird. Was halt Mucks ist, weil ich habe 100, also 96 Gigabyte so, ja, und irgendwie scheint der Browser davon nicht alles mitzubekommen oder vielleicht vom System auch gar nicht alles zu kriegen. Also tricky, so, ne? Aber zeigt nur, was Nico gesagt hat, sowas ist halt sehr schwierig, so voll zu automatisieren. Und ich glaube, Gareth, das ist halt das, was wir als Entwickler, Entwicklerinnen am Ende des Tages noch mitbringen müssen. Also aktuell und vielleicht niemals ist es halt nicht die Aufgabe von Transformer.js, das irgendwie gerade zu entscheiden. Weil das musst du halt auch machen, basierend auf, was willst du von deinem Model, was brauchst du da überhaupt? Was ist dir wichtiger? Ist dir am Ende wichtiger, dass es irgendwie ein maximal großes Modell reinpasst, weil du halt viel Wissen drin haben willst? Oder ist dir wichtiger, dass es maximal schnell performt und mehr Tokens pro Sekunde irgendwie ausspucken kann? Das ist ja auch wieder eine Use Case oder eine produktspezifische Entscheidung am Ende, die ja gar nicht technisch bedingt ist.

SPEAKER_03 40:23

Na klar, aber Pattig, wenn meine Antwort ist, ich will die maximale Qualität, dann muss ich ja immer noch drüber nachdenken, was mache ich mit Usern, die das gar nicht ausführen können. Und dann möchte ich ja eigentlich auch nicht sagen, ja, probier's mal runterzuladen und wenn du abstürzt, dann sage ich dir halt, ja, es geht nicht. Also das wäre schon irgendwie auch nett, wenn man es halt schon vorher irgendwie abfangen kann.

SPEAKER_00 40:46

Ja, und leider muss man da halt auch sagen, also wie gesagt, ich kann jetzt nur über Safari sprechen, weil ich es ja auf Mobile iOS probiert habe. Das Browserverhalten ist halt auch nicht gerade developerfreundlich an der Stelle. Also in dem Fall, was ich hier probiert habe, als ich, wie gesagt, das mit Gemma einem sehr großen Modell halt versucht habe im Browser, der schießt halt einfach deinen Tab ab und lädt ihn neu. So, und du kriegst halt als Web-Anwendung nicht mit, dass das passiert ist und warum das passiert ist und bla, und kannst du halt auf keinste Weise drauf reagieren. Das Einzige, was du machen kannst, ist halt Brute Force nochmal zu versuchen. Und vielleicht kommst du nochmal genauso weit oder vielleicht wirst du vorher abgeschossen. Aber das ist halt super schwierig. Bei nativen Anwendungen kriegst du irgendwie eine Memory-Warnung vom Betriebssystem, hast so eine Chance, nochmal was aufzuräumen, was anders zu machen, bla bla bla. Und an der Stelle hat der Browser halt einfach so, ja, nö. So. Und das ist halt was, wo es ein bisschen schwierig ist gerade noch, ne?

SPEAKER_02 41:39

Ja. Ich meine, unterm Strich ist ja alles, was on Device läuft, bist du davon abhängig, was das Device ist. Und gerade wenn du es im Web machst, ist es noch viel schlimmer, weil du nicht kontrollierst, wer deine Webseite nutzt, weil jemand, jeder gibt die URL ein, kommt drauf und du hast keine Ahnung, was deine NutzerInnen für Hardware mitbringen. Und das, ja, wie gesagt, das ist ein bisschen gut.

SPEAKER_00 42:06

Das kann ja auf die Ablehnung scheiße sein. Also stell dir vor, das Gerät ist mega gut, aber der hat halt einen super schlechten Empfang und dann hilft es dir ja auch nichts, zu sagen, hey, dieses Background-Removal-Model, was nur, weiß nicht, 20, 50 Megabyte groß ist oder sowas, ja, könnte locker auf deinem Gerät funktionieren, dauert aber gerade zwei Stunden, bis es irgendwie da ist. Hilft ja auch jemandem.

SPEAKER_02 42:30

Ja. Nee, deswegen, guck, was du dann, welchen Task du damit lösen möchtest. Schau, welche Modelle verfügbar sind, wie groß sind die Modelle, welche Quantisierungen. Ich habe auch, also es gibt Modelle, da gibt es zwar eine Q4, also 4-Bit-Quisierung, aber eigentlich unbrauchbar dann. Guck dir die Qualität an und dann musst du halt entscheiden, ist es was, was du so shippen möchtest mit deiner Web App oder ist es halt noch nicht so weit oder wird nie so weit sein, keine Ahnung. Was ich aber krass finde, ist, gerade bei LLMs, wie sich die Qualität in den letzten paar Jahren verbessert hat. Also du hast jetzt gerade Gemma 4 so viel besser, das 2B-Modell, als ein Mistral 7B, was ich vor zwei, drei Jahren getestet hat. Also Lichtjahre so. Und dann überlegt, wie, und es gibt auch kleinere Modelle, es gibt ein Gemma 3, 270M, also da passiert so viel, dass ich jetzt nicht einen Status quo nehmen möchte und sagen, ja, guck, funktioniert nicht, deswegen wird es nie was.

SPEAKER_03 43:42

Es ist so wild, was die so in so kleine Modelle dann auf einmal für so viel bessere Qualität packen. Also ich sag mal, die großen Cloud-Modelle, die werden ja meistens besser, weil sie einfach noch größer gemacht werden. Und dass es in die Einrichtung aber auch geht, das verwundert mich jedes Mal wieder. Ich finde es richtig krass. Also ja, absolut. Ich finde ein bisschen anderes Thema interessiert mich noch. Es ist ja, also, das ist eine krasse Library, die Endnutzern extrem viel bietet. Ihr bietet diese Modell-Downloads an und trotzdem ist es alles Open Source and for free, oder? Habe ich da irgendwas übersehen? Das finde ich krass. Wie könnt ihr sowas zur Verfügung stellen? Das ist vielleicht ein bisschen ein anderes Thema, aber das finde ich interessant.

SPEAKER_02 44:31

Das hat viel mit der Philosophie von Hugging Face zu tun. Also Joshua und ich sind ja beide angestellt bei Hugging Face und sind beide 100% für die Library angestellt. Und die Philosophie von Hugging Face ist halt, dass sie über Open Source ihre Plattform nicht nur promoten, sondern auch ganz viel von den Open Source-Projekten aktiv nutzen. Wir haben eigentlich drei Arme, kann man sagen, bei Hugging Face. Wir haben auf der einen Seite den Hub, die Plattform, also eigentlich dieses ganze Team, was die Plattform verwaltet. Aber das ist auch von den Mitarbeitenden, glaube ich, ungefähr ein Drittel. Und die anderen zwei Bereiche sind dann Research, was auch ein großer Teil ist. Also selber sich selber Modelle bauen, selber Architekturen überlegen, selber in Datasets investieren, also wie kommt man zu qualitativ hoofrating Latests und so weiter und so fort. Und dann hast du noch den Open Source Arm. Und Transformers.js zum Beispiel bringt jetzt nicht direkt der Plattform was, außer Visibility natürlich. Aber die Transformers Python Library oder auch die anderen Open Source Libraries, sind halt Sachen, die wir aktiv in der Plattform selber auch nutzen. Und deswegen sind das wie Elemente von Hugging Face, die aber dann auch Open Source zur Verfügung gestellt werden.

SPEAKER_03 46:04

Ja, okay. Und die Datasets, die macht ihr, von denen macht ihr auch viele Open Source und öffentlich, oder? Also das ist ja auch ein großer Teil von Hugging Face.

SPEAKER_02 46:14

Aber nicht nur, also die meisten Datasets sind auch wieder Community-Projekte, wie auch die meisten Modelle. Also als Google, doof, das ist ja immer das Beispiel, aber es war halt gerade erst vor kurzem. Wenn Google Jammer 4 released, dann machen die das auf Hugging Phase. Dann sind die Weights und Modelle sind auf Hugging Phase in der Regel. Genauso wie wenn Research Labs ihre Datasets open sourcen, dann ist es in der Regel auch über Hugging Phase. Und je nach Lizenz kann man die Datasets dann auch für seine eigenen Modelle oder fürs eigene Feintuning verwenden.

SPEAKER_00 46:49

Aber trotzdem, also ja, die Arbeit kommt von der Community oder von großen Firmen, aber am Ende bleibt ja 90% der Traffic-Kosten bei euch irgendwie hängen. Und das ist ja auch nicht gerade wenig. Also ich weiß nicht, wie oft ich jetzt hier während meinen Versuchen einfach mal so Jamma 4 runtergeladen habe, aber das sind halt jedes Mal ein paar Gigabytes so und das geht alles irgendwie auf eure Kappe. Und da habe ich schon auch so am Ende so ein bisschen schlechtes Gewissen irgendwie. Weil du sagst so, die Arbeit machen ja die anderen, aber ich meine, die Infrastruktur betreibt ihr ja schon. Das muss man ja schon mal irgendwie sagen.

SPEAKER_02 47:23

Nee, also wir machen viel Arbeit, das ist überhaupt nicht so gemeint, dass wir nichts machen müssen, als wenn der Community kommt. Ich weiß nicht, unterm Strich das Business Modell geht auf. Also man hat, wir haben, wie man halt hast du halt diese Pro-Accounts, die du haben kannst, und das ist eigentlich so die, soweit ich weiß, die Haupt, aber ich bin, das ist echt nicht mein Fachgebiet. Aber grundsätzlich haben wir diese Pro-Accounts, genau wie GitHub zum Beispiel auch, wo du grundsätzlich Open Source Software zur Verfügung stellen kannst, aber wenn du Modelle nur in deinem Team sharen möchtest, private Modelle oder private Datasets haben möchtest und auch größere Datasets hochladen möchtest, dann brauchst du halt einen Pro-Account und da haben wir dann halt mit verschiedenen Labs, arbeiten wir zusammen, dass die das dann auch finanzieren und über das finanziert sich dann die ganze Plattform und die ganzen Projekte rundherum. Krass.

SPEAKER_03 48:25

Das finde ich echt ein besonderes, also besonderes Konzept, wie ihr das hinbekommen habt, dass ihr so viel anbieten könnt und dass vielleicht trotzdem aufgeht. Also Respekt.

SPEAKER_00 48:36

Ja, hoffen wir, dass das nicht lange so weiter funktioniert wie uns alle.

SPEAKER_02 48:40

Ich bin erst seit einem halben Jahr dabei, von dem ich kann jetzt nicht da aus dem Nähcasting plaudern, wie das alles war von Anfang an, aber ich finde es genauso krass wie ihr auch.

SPEAKER_00 48:51

Wir kommen vielleicht noch einmal ganz kurz, oder halb zurück zu Transformer.js. Weil ich glaube, ein Thema, über das wir auch sprechen müssen, ist so ein bisschen die, ich will nicht sagen, die Konkurrenz, aber vielleicht die Alternative dazu. Weil gerade, wenn wir jetzt bei diesem Thema Runtime im Browser bleiben, gibt es ja auch so die Entwicklung, ich glaube, maßgeblich getrieben von Google, abstrahierte Gen AI-APIs vom Browser aus anzubieten. Wo die Idee ist, du hast auf deinem Window halt so ein AI-Property und da kannst du halt auch sagen, ne, hier, ich mache ein bisschen Textinference, ich mache Builder Generation, ich weiß nicht, was da gerade alles noch so drin ist, aber die Idee ist halt dahinter, es muss nicht jeder sein eigenes Modell mitbringen und runterladen und verwalten, sondern wir schippen halt mit dem Browser irgendwie ein Modell oder zwei, je nach Use Case, whatever, und das kannst du halt fragen, so, hey, hier ist Text und prompte mir mal was und mach mal was so. Und das ist halt im Prinzip noch eine viel geringere Hemmschwelle, weil ich den ganzen Infrastrukturteil an den Browser irgendwie abgeben kann und nur noch in Anführungszeichen Anwender irgendwie davon sein kann. Wie guckt ihr da drauf? Ich habe da auch eine Meinung, aber ich würde erstmal deine interessieren.

SPEAKER_02 50:08

Ich finde das Projekt super. Also ich habe viel mit der Prompt API gemacht, gerade am Anfang, als sie den ersten Draft mal rausgebracht haben. Und die Idee ist, dass der Browser, also genau wie du gesagt hast, das Window-Objekt verschiedene AI-Funktionen zur Verfügung stellt und dass ich dann als Entwickler nur noch sagen muss, hey, ich möchte gern, ich weiß nicht mehr, wie es heißt, ich glaube, irgendwas, keine Ahnung, Text Generation verwenden oder so, gebe meine Messages rein und der Browser generiert mir das dann entweder, weil der Browser eine Modelle geladen hat und ausführt oder weil der Browser das weitergibt an, keine Ahnung, ein Apple Intelligence, was auf dem Gerät läuft oder was auch immer. Dass er dann die Frage, wie das der Browser implementieren möchte. So, finde ich, ähde ich gut, dass es ist. Wo ich ein kleines Problem sehe, ist, dass ich als Entwickler dann nicht mehr sagen oder nicht mehr kontrollieren kann, welches Modell verwendet wird. Weil jetzt im Fall von Chrome ist es ja das Gemini Nano, was im Hintergrund läuft. Erstens ist das Modell nicht mehr das Jüngste. Das ist auch schon ein paar Monate bisher, ein paar Jahre alt und sicher auch schlechter als das Gemma 4. Und ich weiß jetzt, dass Chrome zwar Gemini Nano verwendet, aber angenommen, Apple hat das auch drin, dann gibt es, keine Ahnung, iOS gibt es dann vielleicht das Apple Intelligence weiter und dort hinten dran ist ein sonstiger Modell, ich weiß nicht, was sie verwenden. Oder Firefox hat dann noch ein Quen-Modell, weil keine Ahnung was. Und ich als Entwickler sehe halt nicht, wird jetzt der Request von Gemini verarbeitet oder von Quen oder von was auch immer. Und je nachdem, welches Modell ich verwende, gibt es halt schon Unterschiede. Und kann sein, dass die Unterschiede mit der Zeit, dass die sich immer weiter annähern. Dass man keinen Unterschiede mehr zwischen einem Quen und einem Gemmer. Kann sein, aber ich habe keine Kontrolle über das Modell. Das finde ich einen Nachteil.

SPEAKER_03 52:26

Wahrscheinlich, Qualitäten wird wahrscheinlich sich annähern, aber trotzdem haben die ja oft Eigenheiten. Also man merkt ja schon, ob man mit OpenRL-Modellen oder mit Anthropic-Modellen redet, ne? Und die antworten halt anders. Das ist dann nicht so konsistent, ja.

SPEAKER_00 52:41

Ja, und auch, das Modell selbst ist das eine, ne? Zu sagen, hier bei Firefox ist es irgendwie ein Gwen und in Chrome ist es irgendwie Gemma oder sowas hintendran. Aber was ich viel schwieriger finde, wäre dann zu sagen, ich weiß ja nicht mal, welche Version von diesem Modell oder wann das aktualisiert wird oder sowas. Weil ich könnte natürlich sagen, na gut, wenn ich in einem Firefox bin, das kann ich irgendwie rausfinden, dann passe ich meinen Prompt irgendwie an. Wenn ich in einem Chrome bin, mache ich halt dieses so ein bisschen ein paar Weichen in die in die Prompting-Strategie reinbekommen. Aber es kann mir halt passieren, dass von heute auf morgen alle Chrome-Browser irgendwie mit einem anderen Modell daherkommen und ich halt überhaupt keine Chance hatte, das quasi zu testen, meine Prompts anzupassen, die Evals anzupassen, etc. etc. Und du gibst dann quasi so einen sehr großen Teil von deiner Infrastruktur aus der Hand. Was ja gerade so bei nicht deterministischen Features schon schwierig sein kann. Das finde ich den viel schwierigeren Teil. Also dass jeder sein anderes Model mitbringt, damit könnte ich wahrscheinlich noch leben, aber dass ich überhaupt keine Garantie gerade habe, dass es keinen Contract gibt zu sagen, hey, wenn ich diese API benutze, dann würde ich gerne diese Version von diesem Model irgendwie haben. Von der ich weiß, wie sie funktioniert und wie sie reagiert. Das finde ich so aus Production-Sicht viel schwieriger als die Auswahl des Models.

SPEAKER_03 54:04

Obwohl ich mir da ja schon vorstellen könnte, dass die Browser auch, wenn sie ein Update machen, dann das alte Modell noch eine Zeit lang anbieten und man so eine Übergangszeit hat, oder? Also ich meine.

SPEAKER_00 54:14

Aber die API sieht es halt gerade nicht vor. Also wie Nico gesagt hat, die API ist halt window.ai.generateText, sage ich jetzt mal ganz vereinfacht. Und da gibt es halt keine Metadaten.

SPEAKER_02 54:24

Das ist halt wirklich so, nutze sie, so wie sie jetzt ist, aber du hast keine Ahnung, was hinten dran läuft. Vielleicht ändert sich das auch noch. Also wie gesagt, ich habe sie viel verwendet, gerade am Anfang, weil ich es ein spannendes Thema finde und ich finde es auch immer noch spannend. Ich finde das super, wenn man sich so Sachen überlegt, auch als Standardisierungslayer, auch wenn das nicht die Prompt API wird, aber dass man zumindest Teile davon rausnehmen kann und sagen kann, hey, das ist ein gutes Konzept, das werden wir weiterhin verwenden. Ich glaube, Stand jetzt ist sie ja auch noch nicht in einem normalen Chrome, wenn ich es recht im Kopf habe, bisher erst, oder wenn überhaupt, dann behind the flag und alles mögliche. Nur hinter dem Flagge. Also das ist sehr, es ist immer noch in einem sehr, sehr frühen Stadion.

SPEAKER_00 55:13

Was ich hingegen gut finde an dieser Implementierung, ist zum einen, dass es natürlich hardware-näher läuft. Also mein Browser ist halt einfach viel mehr an meiner Hardware dran, als meine Webseite jemals sein kann, so auch mit WebGPU und WebAssembly. Und das nimmt mir als Endnutzer so ein bisschen die Sorge, wie gut sich Leute halt benehmen am Ende damit. Also wenn jede Webseite Worst-Case, sag ich mal, ein Gemma-4-Modell runterladen kann, dann wird ja irgendwann meine Festplatte zugespammt, so damit. So, wenn jeder jetzt anfängt, seine eigenen LLMs runterzuladen und zu cachen und auf Dauer vorzuhalten und nicht ordentlich hinter sich aufräumt, dann habe ich irgendwann einen Browser-Cache, der halt hunderte Gigabyte groß ist. Und das wahrscheinlich nicht mal übertrieben, weil ich meine, guckt ja an, wie viele unterschiedliche Webseiten wir alle benutzen und wenn jeder nur 20 oder 50 oder 100 Megabyte davon irgendwie nutzt, für so Features, dann geht das halt schnell hoch. Und das ist natürlich was, was vermieden werden kann, wenn man sagt, na gut, wir teilen uns alle ein Modell und müssen nicht pro Origin, wie Nico vorhin gesagt hat, das halt irgendwie neu runterladen, sondern wir können da irgendwie eine gescherte Architektur verwenden. Das wäre halt auch noch irgendwie ein Punkt zu sagen, das lohnt sich, das irgendwie sich mal anzuschauen.

SPEAKER_02 56:31

Ja, wenn ich kurz ein Punkt dazu sagen kann, es stimmt, was du sagst. Es ist so, weil wir halt diese Cross-Origin oder Origin Isolation haben in den Browsern, ist es so, dass wenn, wenn meine Webseite nico.dev ein Modell runterlädt vom Huginface Hub, dann und die andere Webseite, Amazon.com oder was auch immer, es dasselbe Modell auch runterlädt, dann ist es nicht geshared, sondern jede Origin hat seine eigenen Storage. Aber Stand jetzt ist es so. Was ich weiß, ist, dass auch jetzt Chrome, die arbeiten an einer Cross-Origin Storage API. Auch da ist Early Stage, aber da ist dann die Idee, dass man in bestimmten Konstellationen erlaubt, also Storage zu sharen zwischen Origins. Wir haben in Transformers Jazz eingebaut, heißt wenn dein Browser Cross-Origin Storage unterstützt, was im Moment erst über einen Chrome, äh, über eine Chrome-Extension geht, ist auch so Ihr erster Wurf ist mal eine Chrome-Extension, dann können EntwicklerInnen, die sich interessieren, können mal installieren und das mal ausprobieren. Und wenn du die Chrome-Extension hast, dann kannst du in Transformer Stress einen Flag auf True setzen und dann wird die Cross-Origin Storage API als Cache verwendet. So. Und das löst das Problem, aber es löst halt nichts Problem, dass du immer noch verschiedene Devices hast und in deiner Webseite es drin läuft und so weiter und so fort.

SPEAKER_00 58:14

Cool, ich habe so ein bisschen Angst, wie das für Tracking missbraucht werden kann, wenn das irgendwann mal wirklich so als weitverbreitetes Feature kommt, aber ich sehe für euren Use Case auf alle Fälle die Nützlichkeit da drin.

SPEAKER_02 58:26

Sie haben sich viele Gedanken gemacht, zum Beispiel du musst den Hash vom File wissen, was du runterladen möchtest, und nicht die URL. Das ist der Key zu dem Story ist nicht die URL, sondern der Hash vom File-Content. Das heißt, du musst den Content eigentlich kennen. Es reicht nicht einfach zu gucken, was ist denn da, was liegt denn da so rum, sondern du musst halt genau den Hash kennen. Und es ist auch noch nicht, eben wie gesagt, es ist noch nicht mal als noch nicht mal in einem Canary oder so drin. Also wirklich, aber das ist so sehr, sehr early stage. Und genau die Frage.

SPEAKER_00 59:03

So ein Read-only Storage, ne? Also wenn ich den Hash kennen muss, dann kann ich ja nicht die Datei wieder umschreiben, oder? Weil sonst kann ja der andere, der die runtergeladen hat, nicht mehr drauf zugreifen, weil der Hash hat sich ja gerade geändert.

SPEAKER_02 59:15

Ja, okay, du kannst es nicht, genau, du kannst es nicht überschreiben, aber du kannst halt eine neue Version ablegen. Ah, okay. Das muss ich mal angucken, ich mache hier mal anders sitzt. Und bei uns ist es so, dass du kannst über ein Hug-Inface Hub kannst du einen kleinen Request machen, der dir den Hash zurückgibt. So Metaininformationen übers File. Und dann hast du den Schar-Hash und kannst dann gucken, ist der im Cross-Erration-Shash drin? Wenn ja, gib mir das zurück. Wenn nicht, lade es runter und pack es dann in Starge rein. Cool.

SPEAKER_00 59:54

So, Garelt, hast du jetzt Bock auf Transformers.js?

SPEAKER_03 59:57

Musst du mal benutzen? Boah, ich habe eh Bock. Also ich hatte auch schon einen kleinen Use Case, wo ich ONNX, also Onix heißt es ja, ne? Aber man schreibt das ONNX, oder?

SPEAKER_02 1:00:06

Es ist Open Neural Network Exchange Standard, also Onyx.

SPEAKER_00 1:00:11

Also du kannst es auch Onks aussprechen.

SPEAKER_03 1:00:15

Also ich habe auch Ongs schon mal so Barbones verwendet, weil es aber auch in der React Native App war, und zwar in der Programmierkon-App. Und da hat es praktisch die Bilder, die man gemacht hat von der Folie, hat es probiert, die Folie zu extrahieren, sodass man nur die Folie als Bild hatte.

SPEAKER_00 1:00:33

Ah, I see.

SPEAKER_03 1:00:34

Und das war ein echt cooler Use Case, weil da dachte ich auch so, oh, so eine Konferenz-App hat man oft kein Internet. Ich fände es cool, wenn das lokal läuft. Und wollte natürlich auch keinen Server dafür irgendwie zur Verfügung stellen. Da war es schon sehr spannend, ich weiß gar nicht, React Native und Transformer.js würde wahrscheinlich nicht so gut funktionieren. Naja, du fühlst schon den Kopf. Naja, noch nicht.

SPEAKER_02 1:00:58

Wir haben ein paar Tasks offen oder Issues offen, um halt so Cross-Platform-Frameworks zu unterstützen. Und es ist immer so ein Ja, machen wir mal, aber es ist jetzt noch, ist halt nicht wirklich urgent.

SPEAKER_03 1:01:14

Wir haben Sachen, die uns wichtiger sind im Moment. Ja, klar, ich glaube, das würde auch kein, also der Use, wie sagt man, die Nutzung davon wäre wahrscheinlich nicht sehr hoch. So, für mich wäre es geil, aber wahrscheinlich nicht so viele Leute. Und ich finde einfach diesen Gedanken, deswegen wäre es wirklich cool, Benni, eigentlich da gehabt zu haben, weil der hat ja so eine App gebaut, wo man sich die App nicht mehr über so ein Menü konfiguriert, sondern über den Chat sozusagen. Also der Chat lokal hat Tools bekommen, die dann lokal die Version sozusagen konfiguriert. Und das finde ich so eine coole Idee, weil ich habe das.

SPEAKER_00 1:01:52

Ich muss nochmal genauer erklären, wofür die Karte.

SPEAKER_03 1:01:56

Ich erkläre es jetzt nochmal, also in einem Use Case, wo ich dachte, das wäre total geil, ich habe mir jetzt Image, ich glaube, das hast du mal als Pick of the Day gepitzt, Jan. Das ist praktisch eine Open Source Bilder, wie sagt man, Software-Kotz-Kotz-Kotzone. Google Fotos eigentlich. Google-Fotos klonen, den du auf deinen NAS packst und damit so deine Bilder verwaltest. Und da ist halt so, die haben dann so eine Verwaltungsseite und da sind halt, keine Ahnung, 30 Dinge, die du machen kannst. Und ich denke mir so, als würde eine spezielle Sache machen. Und da sind dann LNMs meistens auch irgendwie nicht so smart, weil die nicht genau wissen, wo diese Option ist. Da konnten sie mir echt nicht gut helfen, aber wie geil wäre es denn, wenn anstatt dieser riesigen Liste da ein Chat ist und ich sage, hey, ich würde gerne, keine Ahnung, mal meinen User aufräumen. Und der sagt, klar, mach ich. Und das ist so ein geiler Use Case, den ich gern mehr explorieren wollen würde, weil ich brauche nicht diese 30 Optionen. Ich will einfach, was, dass der was macht. Und deswegen habe ich extrem Bock drauf bekommen und werde auf jeden Fall mal weiter explorieren, was man damit so besser machen könnte.

SPEAKER_00 1:03:04

Nice.

SPEAKER_03 1:03:04

Ich habe Bock. Cool.

SPEAKER_02 1:03:08

Cool. Also gerade so Agenda.

SPEAKER_00 1:03:12

Approval-Stempel drauf.

SPEAKER_02 1:03:14

Cool. Nee, ich meine, die meisten Uweys, die man hat, um irgendwelche Einstellungen vorzunehmen, ist halt irgendwo, du möchtest alles für dich reinpacken, aber weißt halt auch nicht, wie es übersichtlich wird und so. Und mit sowas, hey, man kann es probieren. Eben gerade, sogar so Single-Tool-Use Cases sind halt kleine Modelle mega gut. Du musst mir nicht erklären können, wie die Welt funktioniert, du musst einfach gucken, habe ich ein Tool, was mein Dark-Mode ein- oder ausmacht und dann dieses Tool betätigen.

SPEAKER_03 1:03:48

Das ist easy. Oder stell dir vor, du hast einfach eine Liste von Daten und gar keinen Filterbutton mehr, sondern sagst ihm einfach, hey, filter mir mal das nach da, also, keine Ahnung, nach dem Namen oder so. Und dann erstellt er dir JavaScript, der das einfach filtert, sozusagen. Also du kannst neue Use Cases, wo er dir dann irgendwas erstellt.

SPEAKER_02 1:04:08

Ja, das wird dann komplexer, weil du dann ja ein Tool hast, was Code generiert, um, also klar, das ist eigentlich die Grundlage von einem Pi oder von jedem Agentic-Framework, klar. Aber jetzt gerade für kleine Modelle müsste man sicher ausprobieren. Und ich weiß auch nicht, wie stark man dem Output vertrauen kann, dass man einfach so JavaScript, was aus einem Gema 4, 2W rauskommt, einfach so mal laufen lässt im eigenen Text.

SPEAKER_03 1:04:36

Auf jeden Fall, das sind Hürden, die zu nehmen sind, aber wie du schon gesagt hast, du würdest nicht vertrauen, dass es in der Zukunft vielleicht auch mit einem kleinen Modell extrem gut geht. Und ja, Safeguards auf jeden Fall Thema so, aber weiß nicht, das ist so eine Sache für mich, die sich irgendwie, die macht bespaßt. Also da passiert was in mir, wenn ich so denke, ja, man muss es gar nicht mehr entwickeln, sondern das macht dann der User sozusagen selbst mit seinem LLM. Das ist schon geil.

SPEAKER_00 1:05:06

Nico, hast du noch Fragen, von denen du dir gewünscht hättest, dass wir sie gefragt hätten und jetzt denkst, keiner hat mich gefragt zu Thema XY, ich wollte unbedingt darüber reden.

SPEAKER_02 1:05:19

Nee, ich glaube, wir haben alles gecovert. Nee, vielleicht explizit noch ein Hinweis auf Transformers.js Version 4. Die ist recht cool. Die ist vor einem Monat plus minus rausgekommen. Und da haben wir gerade under the hood extrem vieles verbessert. Zudem haben wir eine neue Library, die nennt sich uh Tokenizers.js. And da haben wir den Tokenizer, den we just in Transformers.js drin hatten, um from the Messages Arrays and Chat-Template zu code. From the Chat Template to the Input Tensors and so the Tokenizer have we extracted in our eye library, but we have seen that this is not Transformers Chess verwended, but there are Projekte that have not Transformers Chess verwended um den Tokenizer to the Gemma 4 Tokenizer is the gleiche, obviously with Transformers Chess und Onyx verwende oder ob ich meine eigene Runtime dafür baue. Den haben wir vor kurzem oder mit oder vor Version 4 auch noch released, aber sonst haben wir alles.

SPEAKER_00 1:06:39

Wunderbar. Wir haben aber noch nicht ganz alles, weil, was fehlt noch, Geld?

SPEAKER_03 1:06:43

Deepicks of the Day.

SPEAKER_00 1:07:02

Und da stellt sich zuallererst die spannende Frage. Waren, ich muss kurz auf die Uhr gucken, 68 Minuten genug Zeit, dass Gareth einen Pick auf der Day überlegt hat.

SPEAKER_03 1:07:13

Auf jeden Fall, aber ich musste mir gar keinen überlegen. Ich hatte, Bretti, ich bringe den von letztem mit, den ich dann nicht gemacht habe. Ah, Recycling, das ist gut. Recycling. Und zwar lustigerweise, Nico, du hast ihn ungefähr vor fünf Minuten genannt, aber ich glaube, es geht unter, weil dieser Name so unscheinbar ist. Und zwar hast du Pi gesagt. Und ich bin mir ziemlich sicher, dass du den, den oder das Pi meinst, was ich als Pick mitgebracht habe. Und zwar gerade, wenn wir auch heute über lokale Modelle gesprochen haben, ich experimentiere sehr gerne auch mit Coding-Agents rum. Und dann ist halt die Frage, okay, wie lässt man die laufen? Weil Cloud Code ist ja ja nicht so freundlich, was andere Modelle angeht. Und es gibt ja Open Code, was ich auch eine Zeit lang benutzt habe, was irgendwie so Batteries included ist, aber deswegen auch irgendwie sehr heavy und bei mir auch oft irgendwie langsam und buggy. Und Pi ist da so der Gegenansatz. Der ist super Barebones, kommt mit sehr minimalen Dingen, aber funktioniert erstaunlich gut. Und gerade irgendwie mit lokalen Modellen habe ich da sehr gute Erfahrungen. Und das Coole ist irgendwie, es ist sehr darauf ausgelegt, dass man es selbst erweitert, indem man ihn fragt, es sich selbst zu erweitern. Und das ist irgendwie, weiß nicht, das macht was mit mir. Und es ist natürlich nicht nur mit lokalen Modellen, sondern auch mit allen, die ihr kennt, nutzbar. Enthropic ist ja immer so ein bisschen, muss man aufpassen, dass man da nicht gesperrt wird, aber OpenAL-Modelle alles kein Problem. Checkt denn aus, sehr cool, ist von einem Österreicher entwickelt. Ich hoffe, wir quatschen irgendwann auch mal mit dem. Der Mario Zechner, ist der, glaube ich, Zechner. Genau, das wäre mein Pick. Irgendwie finde ich das nice. Also es ist ein cooles Projekt. Auch übrigens Fun Fact, Open Claw basiert auf Pi sozusagen. Open Claw ist ja wahrscheinlich vielen ein Begriff.

SPEAKER_00 1:09:00

Also Mario, wenn du uns zuhörst, schreib uns mal an podcast.programmier.bar. Wir machen die Aufnahme dann.

SPEAKER_03 1:09:07

Nice.

SPEAKER_00 1:09:09

Einfach mal die Leute im Podcast einladen. Vielleicht funktioniert das ja.

SPEAKER_03 1:09:12

Ah, im Podcast zum Podcast einladen, ja, perfekt.

SPEAKER_00 1:09:16

Du weißt ja nie, wer so alles zuhört. Vielleicht ist es nicht Mario, aber vielleicht, weiß ich nicht, seine Schwiegermutter oder so, ihn dann anschreibt, so, hey, wahrscheinlich. Mario, ich hab's schon bei mir mal gehört. Solltest du dich mal bei den Jungs melden. Nice. Pi, ja, mega cool. Ich bin gespannt. Ich will auch mal was dazu hören. Vielleicht kannst du mal einen Talk bei uns machen, gar nicht zum Thema Pi. Gerne. Nico, was hast du so am Start für uns?

SPEAKER_02 1:09:41

Ich hab's ein bisschen schwer gemacht, weil, als ich in 2020 da war, ging es ja um WordPress. Und wisst ihr, was damals beim Pick of the Day war? Ich kann es nachgucken, aber ich weiß es nicht mehr. Ich auch nicht. Mein Pick of the Day war, mein Projekt, das hat sich PW Advent genannt. Das ist ging um einen Adventskalender mit Progressive Weber Features. Das zweite Mal als ich da war, ging es um PWAs.

unknown 1:10:09

Ja.

SPEAKER_02 1:10:09

Und wisst ihr, was mein Pick of the Jetzt war?

SPEAKER_00 1:10:11

Und das weiß ich noch, Transformers Chess, weil da war ich schon stark.

SPEAKER_02 1:10:14

Mein Pick of the Day, Transformer Chess Version 3. Heißt, das, was ich jetzt als Pick of the Day nenne, wird wohl das Thema sein. Genau, genau. Und deswegen habe ich absichtlich was genommen, was ganz sicher nicht mein Pick of the Day oder mein nächstes Thema sein wird, sondern einfach was Kleines, was ich mega nützlich finde. Und zwar habe ich mir vor einem Jahr oder so einen so einen Charger gekauft, einen 4-Port-Charger, der bis zu 130 Watt, glaube ich, laden kann. Hat zwei Pole, sprich, gerade als Schweiz ist es ein bisschen mühsam, weil wir haben eben diese dreipoligen Stecker und der passt halt dann überhaupt gar nirgends. Und die zweipoligen, die passen halt dann in den meisten Steckdosen in Europa passen die auch so ohne Adapter rein. Und ich kann damit gleichzeitig meine Uhr, mein Smartphone und meinen Laptop laden. Und das ganze Ding ist auch kleiner als mein MacBook-Charger. Von dem her habe ich mir gekauft und bin seitdem mega zufrieden, gerade auch weil ich relativ viel unterwegs bin. Bestes Gadget, was ich in den letzten Jahren gekauft habe. Ich kann einen Link dazu in den Show notes tun, wobei das ist ein ich jetzt gekauft, ist ein Produkt von Digitech. Das ist eine online-Plattform, Online-Shop für die Schweiz. Und es ist ein hauseigenes Produkt, aber ich denke mal, es gibt jede Menge solcher Wearport-Adapter oder Mehrport-Charger. Kann ich wärmstens empfehlen.

SPEAKER_00 1:11:53

Guter Charger, so viel Geld wert.

SPEAKER_02 1:11:55

Wirklich.

SPEAKER_00 1:11:56

Auf jeden Fall.

SPEAKER_02 1:11:57

Und unbedingt den großen, weil Garten MacBook zieht halt relativ viel Strom.

SPEAKER_00 1:12:03

Ah, siehst du, da würde ich jetzt hier den Gegenpunkt machen. Ich hatte nämlich auch ganz lange als Reiseadapter, ich habe ihn gerade nicht griffbereit, aber so einen 200 Watt 4-Port-Charger, auch mit so einem Universal-Stecker-Ding vorne dran für über alle auf der Welt. Und konnte damit auch, ne, da kannst du irgendwie deinen Laptop und dein iPad und dein Handy und deine Uhr halt irgendwie alles gleichzeitig laden und funktioniert und so. Und jetzt bin ich aber auf einen gewechselt, der nur noch ein Drittel so groß ist, nur noch drei Ports hat und maximal 80 Watt macht, glaube ich. Und ja, dein MacBook Pro lädt unter Vollerst halt nicht mehr auf damit, aber wenn du es halt über Nacht auf dem Schreibtisch neben im Hotelzimmer lädst oder so, reicht es ja trotzdem zum Vollladen damit. Aber das Ding ist halt so viel kleiner und leichter. Deswegen wäre mein Gegenpick sozusagen zu überlegen, braucht ihr wirklich die volle Leistung an Charger, um so einen Plotz mit euch rumzuschleppen? Oder tut es nicht ein kleinerer Charger, der in der Tasche ganz unauffällig ist, aber dafür euer Übernacht halt auch alles vollladen kann?

SPEAKER_02 1:13:04

Ich dachte gar nicht, dass wir da so einen Dispute drin haben, dass es wirklich für die nächste Folge dann reichen würde, aber wir lassen es jetzt mal bei dem. Ich würde es jetzt einfach mal sagen.

SPEAKER_00 1:13:14

Vielleicht wechselst du in zwei, drei Jahren in irgendein Electric Engineering Up oder sowas. Und dann reden wir darüber. Also Hunaus.

SPEAKER_03 1:13:24

Für generelle Kaufberatung von Tech-Produkten meldet es bei Programmier.bar oder bei hast du eine eigene? Sagen wir mal Podcast at Programmier.bar dann mit dem Kopf.

SPEAKER_00 1:13:33

Ich kann es auch die anderen Programmierpunkt, aber wir können auch gerne im Discord-Channel weiter darüber quatschen. Ich habe auch noch einen Pick, keinen Charger. Ich habe einen anderen Pick, über den ich letzte Woche gestolpert bin. Und zwar gibt es ja so das Problem, dass man diese ganzen AI-Tools, die man so länger verwendet, egal ob es jetzt Cloud Code oder Codex oder Mistrad oder was auch immer man halt irgendwie so haben will, ist manchmal hat man ja so das Gefühl, irgendwie diese Tools werden schlechter über Zeit. Und man kann das nicht so ganz quantifizieren, aber man hat so den Eindruck, man nutzt jetzt irgendwie Codex schon ein paar Wochen, ein paar Monate und irgendwie hat das am Anfang besser funktioniert als jetzt gerade. Und dann denkt man sich so, naja, bin ich der Einzige? Ist das so ein subjektives Ding oder geht das objektiv allen da draußen so? Wie verhält sich das so? Und da habe ich eine Webseite gefunden, die nennt sich disappointed.club, also so wie Disappointed, aber halt mit AI drin, disappointed. Und wenn man die aufruft, sieht man im Prinzip wie so ein Chart, welche AI funktioniert gerade besonders schlecht und worüber regen sich Leute halt irgendwie gerade auf. So, und da kann man dann halt sehen, dass es irgendwie manchmal halt Cursor ist, wo die Leute das Gefühl haben, dass es schlechter wird. In den letzten paar Wochen ist da sehr viel Claude irgendwie ganz oben, gefolgt von irgendwie Gemini. Und das ist irgendwie interessant zu sehen, um so seine eigenen Eindrücke mal so ein bisschen cross zu checken. So, hey, ich will mir das hier einfach mal angucken. Man muss da vorsichtig sein. Das UI ist nicht so sonderlich durchdacht, muss ich sagen. Wenn man oben diese großen Buttons hat für Claude, Gemini, ChatGPT und so weiter, ich dachte, das wären Filter-Buttons, aber nein, sobald du drauf drückst, hast du dich schon über so ein AI-Model beschwert. Also dann zählt es schon quasi als Vot gegen eines dieser Modelle. Aber trotzdem fand ich das ganz hilfreich. Das ist jetzt noch nicht mega groß und die machen das noch nicht mega lang. Aber so ein bisschen dieses Gefühl, ist dieses Tool gerade gut oder wird es schlechter oder wird das besser, das so ein bisschen zu crowdsourcen, fand ich eigentlich nicht verkehrt als Ansatz. Ja. Deswegen, dass mein Pick of the Day, disappointed Punkt Club. Verlinken wir auch nochmal in den Shownotes dann. Gut, dann bleibt mir nicht viel zu sagen, außer tausend Dank, Nico, dass du mit am Start warst, dass du wieder die Zeit für uns gehabt hast, zum 37. Mal in der Programmierbar hier am Start zu sein. Jederzeit an deinem Wissen teilhaben lässt. Ja, mal mindestens das nächste Mal dann im November, wenn wir uns wieder für die Programmierkon alle sehen. Und wir erwarten wieder coole Tech-Demos und fahrende Autos. Oder sowas ähnliches. No pressure.

SPEAKER_02 1:16:39

Ja, ich muss das fahrende Auto irgendwie toppen. Muss ihr was überlegen.

SPEAKER_00 1:16:45

Ja, also ich meine, Drohnen, Drohnen auch immer cool, ja. Also Drohnen und AI zu kombinieren, da kriegst du auch Venture Capital gerade hinterhergeschmissen. Also vielleicht. Hot Topic im Moment, glaube ich. Aber ja. Wunderbar. Dann danke Gerald, dass du mit am Start warst, live zugeschaltet aus der Saline.

SPEAKER_03 1:17:05

Danke, Jan, dass du Dennis so kurzfristig vertreten hast. Und so hervorragend auch.

SPEAKER_00 1:17:12

Ja, das ist, also mit, solange ich ein bisschen Volllauf habe, kriege ich das ja noch hin. Dennis hat mir nur heute Morgen geschrieben, hast du Zeit? Und ich dachte so, für was? Für was? Was willst du von mir? Ja. Kriegen wir alles, kriegen wir alles hin. Wunderbar, dann hören wir uns.

SPEAKER_03 1:17:31

Und warte, warte, warte, auch danke an Nico oder habe ich das verpasst?

SPEAKER_00 1:17:36

Habe ich gerade schon gesagt und ihn gleichzeitig genötigt, noch mehr abzuliefern, wenn er wieder. Ach, das war davor.

SPEAKER_03 1:17:43

Ich habe auch so ein Hamstergedächtnis. Jetlag mit Kindern habe ich vorhin gehört. Das ist ganz schlimm. Aber von mir auch nochmal danke, Nico. Es war ein richtig cooles Gespräch.

SPEAKER_01 1:17:55

Ja.

SPEAKER_00 1:17:55

Sehr, sehr gerne hat es Spaß gemacht. Jedes Mal. Wunderbar. Dann bis bald zusammen. Dann ciao.