Dinge, die einen Tag gekostet haben

Warum diese und nicht die anderen

Die internen Notizen der Engine umfassen ein paar Dutzend Einträge, und nicht alle gehören auf eine öffentliche Seite. Zwei Regeln entscheiden darüber.

Veröffentlicht wird, was zur Bibliothek eines anderen gehört. Wie MLX sich verhält, was mlx-lm voraussetzt, was in der config.json eines Modells stehen kann. Dieses Wissen gehört nicht uns: es ist der Preis dafür, eine fremde Bibliothek sorgfältig gelesen zu haben, und irgendjemand sucht in genau diesem Moment danach, weil er vor derselben Wand steht.

Behalten wird, was uns gehört. Der Entwurf des seitenweise verwalteten Caches, die Art, wie das Sampling seine Kandidaten materialisiert, die Entscheidung, vor der letzten Projektion zu schneiden. Diese Dinge haben Messungen gekostet, und sie sind der Vorsprung der Engine, keine allgemeine Tatsache über MLX.

Diese Grenze zieht nicht die Geheimhaltung um ihrer selbst willen. Sie zieht der Unterschied zwischen Wissen, das die Nutzer einer fremden Bibliothek brauchen, und Arbeit.

Für wen sie geschrieben sind

Für drei Sorten von Leserinnen und Lesern, und der erste Absatz jeder Notiz sagt, welche davon gemeint ist.

Wer eine Modellarchitektur portiert — aus mlx-lm oder aus irgendeiner Referenzimplementierung in irgendeine Sprache —, findet in zwei dieser Notizen genau die Fallen beschrieben, in die er laufen wird, und in der dritten die Grenze, die er bauen muss, um seine Arbeit aus einer Anwendung heraus aufzurufen.

Wer MLX aus C oder Rust benutzt statt aus Python, spart mit der Notiz zum Loader einen Tag, und die Notiz zur C-Grenze beschreibt eine Fehlerklasse, die umso schlimmer wird, je länger niemand gezielt nach ihr sucht.

Wer weder das eine noch das andere tut, für den lohnt sich immer noch eine davon: dass ein Fehler mit plausibler Rückgabe teurer ist als einer, der abstürzt, gilt nicht nur für Inferenz-Engines, und was daraus folgt, auch nicht.

Was sie nicht sind

Sie sind keine Tutorials. Es gibt hier kein Einstiegsmaterial, und keine davon erklärt, was ein Transformer ist oder wie man irgendetwas installiert — dieses Material existiert, es ist anderswo gut geschrieben, und es zu wiederholen hieße Seiten hinzuzufügen, die niemand braucht.

Sie sind auch keine Versionshinweise. Nichts hier kündigt eine Funktion an. Jede einzelne ist ein Fehler, dessen Suche lange genug gedauert hat, dass das Aufschreiben billiger schien, als die nächste Person denselben Tag verlieren zu lassen.

Wie oft sie erscheinen

Langsam, und das ist Absicht und kein Mangel an Material.

Eine Notiz geht online, wenn der Fehler gut genug verstanden ist, um in einem Satz gesagt zu werden, und keinen Tag früher. Die halbe Wirkung des Schreibens liegt in genau diesem Zwang: Wenn der Aufschrieb drei Absätze Absicherung braucht, um zu beschreiben, was schiefgegangen ist, war die Untersuchung nicht fertig, und die richtige Antwort ist, sie zu Ende zu bringen, statt die Absicherung zu veröffentlichen.

Es gibt also keinen Zeitplan. Wer wissen will, wann eine erscheint: das Abonnement hat eine Kategorie für genau das und für nichts sonst.

Wie das hier geprüft wird

Hinter jeder Behauptung in diesen Notizen steht eine Zahl oder eine Reproduktion, und wo eine Zahl steht, steht das Datum ihrer Messung daneben.

Diese Gewohnheit hat das Projekt teuer gelernt. Drei von Hand geschriebene Werte in einem internen Dokument stellten sich beim Nachmessen als 33 statt 32 heraus, als 26 statt 24 und als 1294 statt 605 — der letzte um mehr als das Doppelte daneben. Eine Zahl in einem Fließtext hat niemanden, der sie pflegt. Also tragen die Zahlen hier ihr Datum, und wenn eine davon abgewandert ist, ist genau dieses Datum die Warnung.