Vielen Dank für den guten Beitrag. Der von Ihnen genannte Punkt, dass ein State zur Verringerung der Latenz erforderlich ist, trifft genau den zentralen Trade-off unserer Architektur.
Zunächst zur Abfrage-Latenz: In unseren Benchmarks liegt das P99 (99. Perzentil) bei etwa 130–210 ms. Der Hinweis auf einen Faktor 100 bezieht sich vermutlich auf den im Beitrag erwähnten Worst Case, bei dem ein „Cold Start“ mehrere Sekunden dauern kann. Wie Sie richtig anmerken, ist dies eindeutig ein Nachteil unserer Architektur; wie im Beitrag erwähnt, tritt er in Produktionsumgebungen bei weniger als 0,01 % (P99.99) auf. Im Übrigen sind die meisten anderen Abfragen so ausgelegt, dass sie den lokalen Speicher- und Festplatten-Cache jeder Lambda nutzen, um stabile Leistung zu gewährleisten.
Wie Sie zu Recht anmerkten, kann diese Architektur für ultra-latency Finanzhandelssysteme, bei denen für alle Abfragen eine Latenz unter 10 ms garantiert werden muss, möglicherweise nicht geeignet sein. Für die meisten KI-basierten Such- und Empfehlungssysteme ist jedoch eine Latenz im Bereich von 100–200 ms auf P99-Basis bereits eine sehr gute Leistung. Ich denke, der Vorteil, die Infrastrukturkosten und den Betriebsaufwand um mehr als 90 % zu senken, ist deutlich größer.
Nochmals vielen Dank für Ihren tiefgehenden Beitrag.
Das ist wohl auch so ein Dienst, den ich selbst mal ausprobieren wollte, aber dann doch nicht gemacht habe … haha.
Ist das vielleicht mit n8n aufgebaut worden??
Mit den Entwicklern, die angeblich nicht besorgt sind, sind vermutlich Seniors gemeint, die bereits ein gewisses Maß an Berufserfahrung aufgebaut haben. Aus Sicht der Unternehmen gibt es ohnehin immer weniger Gründe, Berufseinsteiger einzustellen, und jetzt ist auch noch AI dazugekommen; außerdem liegt es auf der Hand, dass Seniors AI besser nutzen werden....
Das Problem ist, dass Junioren die Welle nicht erwischen, und selbst wenn man sie reitet und tiefer hineingeht, droht man von der Welle mitgerissen zu werden.
Die Idee ist gut, aber für die Verringerung der Abfrageverzögerung wird zwangsläufig ein State benötigt. Im Vergleich zu MySQL, PostgreSQL usw. ist die Abfrageverzögerung fast hundertmal höher. Es wirkt fast wie die Ein- und Ausgabe in einem Dateisystem.
Beim Lesen des Artikels musste ich an die TaskPaper-App denken. Sie basiert auf Plain Text und arbeitet im Stil eines Outliners ...
Ich selbst nutze seit etwas mehr als 10 Jahren nur Things, und das ist für mich am bequemsten.
Unter den Funktionen von Things für macOS ist Quick Entry Autofill einfach unglaublich attraktiv ...
Vielen Dank, das wird sicher sehr hilfreich sein ✌️
Anfangs habe ich es mit n8n aufgebaut, dann aber auf AWS Lambda + @ umgestellt 🙇♂️
So verwalte ich das gerade, haha.
Ich kann nur empfehlen, so etwas einmal selbst zu bauen — macht Spaß 👍
Vielen Dank für den guten Beitrag. Der von Ihnen genannte Punkt, dass ein State zur Verringerung der Latenz erforderlich ist, trifft genau den zentralen Trade-off unserer Architektur.
Zunächst zur Abfrage-Latenz: In unseren Benchmarks liegt das P99 (99. Perzentil) bei etwa 130–210 ms. Der Hinweis auf einen Faktor 100 bezieht sich vermutlich auf den im Beitrag erwähnten Worst Case, bei dem ein „Cold Start“ mehrere Sekunden dauern kann. Wie Sie richtig anmerken, ist dies eindeutig ein Nachteil unserer Architektur; wie im Beitrag erwähnt, tritt er in Produktionsumgebungen bei weniger als 0,01 % (P99.99) auf. Im Übrigen sind die meisten anderen Abfragen so ausgelegt, dass sie den lokalen Speicher- und Festplatten-Cache jeder Lambda nutzen, um stabile Leistung zu gewährleisten.
Wie Sie zu Recht anmerkten, kann diese Architektur für ultra-latency Finanzhandelssysteme, bei denen für alle Abfragen eine Latenz unter 10 ms garantiert werden muss, möglicherweise nicht geeignet sein. Für die meisten KI-basierten Such- und Empfehlungssysteme ist jedoch eine Latenz im Bereich von 100–200 ms auf P99-Basis bereits eine sehr gute Leistung. Ich denke, der Vorteil, die Infrastrukturkosten und den Betriebsaufwand um mehr als 90 % zu senken, ist deutlich größer.
Nochmals vielen Dank für Ihren tiefgehenden Beitrag.
Weil es 65 GB sind … schade. schluchz
Das ist wohl auch so ein Dienst, den ich selbst mal ausprobieren wollte, aber dann doch nicht gemacht habe … haha.
Ist das vielleicht mit n8n aufgebaut worden??
Mit den Entwicklern, die angeblich nicht besorgt sind, sind vermutlich Seniors gemeint, die bereits ein gewisses Maß an Berufserfahrung aufgebaut haben. Aus Sicht der Unternehmen gibt es ohnehin immer weniger Gründe, Berufseinsteiger einzustellen, und jetzt ist auch noch AI dazugekommen; außerdem liegt es auf der Hand, dass Seniors AI besser nutzen werden....
Das Problem ist, dass Junioren die Welle nicht erwischen, und selbst wenn man sie reitet und tiefer hineingeht, droht man von der Welle mitgerissen zu werden.
Aber AEO und GEO überschneiden sich letztlich auch mit SEO ...
Dann gibt es ja jeden Morgen etwas zu lesen. Ich habe es abonniert.
Wer sich der Welle entgegenstellt oder vor ihr davonläuft, wird von ihr mitgerissen — und wer auf ihr reitet, wird sie genießen..
Sieht so aus, als wäre es mit einem LLM als Bild erstellt worden, aber es sieht gut aus.
Das möchte ich wohl auch mal ähnlich ausprobieren.
Vielen Dank 👏
Ich dachte, 32 GB würden ausreichen ...
encoding/jsonv1 und v2 in Go 1.25: https://gosuda.org/ko/blog/…Läuft jedenfalls auf dem lm studio M4 max 64gb nicht wein
Einfach ist am besten!
Ich habe mich angemeldet. 👍
Die Idee ist gut, aber für die Verringerung der Abfrageverzögerung wird zwangsläufig ein State benötigt. Im Vergleich zu MySQL, PostgreSQL usw. ist die Abfrageverzögerung fast hundertmal höher. Es wirkt fast wie die Ein- und Ausgabe in einem Dateisystem.
Beim Lesen des Artikels musste ich an die TaskPaper-App denken. Sie basiert auf Plain Text und arbeitet im Stil eines Outliners ...
Ich selbst nutze seit etwas mehr als 10 Jahren nur Things, und das ist für mich am bequemsten.
Unter den Funktionen von Things für macOS ist Quick Entry Autofill einfach unglaublich attraktiv ...