Donnerstag, 16:40 Uhr, in einem Fenster ist ein Vertragsentwurf offen. Eine KI soll die Formulierungen glätten, aber das Dokument darf deinen Laptop nicht verlassen, und du weißt nicht, welches der hundert offenen Modelle auf Hugging Face mit 16 GB Speicher überhaupt laden würde. Den Abend im Terminal zu verbringen, um das herauszufinden, hast du auch keine Lust.
Eine Sidebar-Gruppe für alles, was du mit offenen Modellen machst
Local Model ist der Teil von osFoundry, der sich um Open-Weight-Modelle auf Hardware kümmert, die du selbst kontrollierst. In der Sidebar der Desktop-App ist es eine eigene Kategorie mit drei Unterüberschriften: Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks) und Measure (Eval, Benchmarks, Safety). Wer Ollama oder LM Studio kennt, findet sich in der Run-Hälfte sofort zurecht: Modell suchen, herunterladen, damit chatten. Der Unterschied: In derselben Gruppe kannst du ein Modell auch verkleinern, mit eigenen Beispielen fine-tunen und mit eigenen Fragen testen. Der ganze Lebenszyklus eines Modells bleibt also in einer App. Die Inferenz auf dem Gerät läuft über einen mitgelieferten llama.cpp-Server, eine separate Installation ist nicht nötig. Dieser Guide behandelt die neun Screens, die die meisten nutzen: Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval und Benchmarks.
Ein erster Blick auf Explore
Mit Explore fangen die meisten an, und das Layout zeigt, wie die ganze Kategorie denkt: zuerst dein Rechner, dann die Modelle.
- Die Filters-Leiste links gruppiert die Hugging-Face-Tasks (Text Generation, Summarization, Translation, Embeddings sowie die Gruppen Multimodal, Vision und Audio) und hat ein Suchfeld.
- Das Banner oben liest deinen Rechner aus, bevor es irgendetwas anzeigt. Im Beispiel oben steht dort: 16 GB Unified Memory, etwa 12 GB nutzbar für ein Modell, gerade etwa 9 GB frei, und die Schätzungen gehen von Q4_K_M und 4K Kontext aus.
- Jede Modellkarte trägt ein Badge, ob das Modell passt: grün Fits, gelb Tight, rot Too big, jeweils mit geschätztem Speicherbedarf. Nichts wird ausgeblendet; passende Modelle stehen einfach oben.
- Die Buttons Providers und My Registry oben rechts führen zu Cloud-API-Anbietern und zu Modellen, die du schon hast.
- Ein Klick auf eine Karte öffnet die Detailansicht. Dort lädt Install Locally eine Version des Modells herunter, meist ein quantisiertes GGUF, das zum Badge passt.
Drei Leute, drei Arten, es zu nutzen
Eine Solo-Entwicklerin mit einem Laptop
Maya baut Side-Projects auf einem MacBook mit 16 GB. Sie möchte ein lokales Modell für Commit-Messages und kurze Notizen, vor allem, um im Zug offline arbeiten zu können.
Sie öffnet Explore, filtert auf Text Generation und überspringt alles mit rotem Badge. Zwei Kandidaten sind grün, also installiert sie beide mit Install Locally. Dann öffnet sie Playground, tippt einen Prompt und fügt beide Modelle als Panels hinzu. Playground schickt denselben Prompt an zwei bis vier Modelle gleichzeitig und zeigt die Antworten nebeneinander, mit Time to First Token und Wortanzahl unter jedem Panel.
Später findet sie ein Modell, das ihr gefällt, das es aber nur als F16-Datei in voller Präzision gibt. Rund 15 GB, zu groß für ihren Laptop. In Quantize wählt sie es unter "The model to shrink" aus, nimmt Q4_K_M, die Stufe, die die App den meisten empfiehlt, und startet. Das mitgelieferte llama-quantize schreibt die Datei auf ihrem Rechner neu; hochgeladen wird nichts.
Im Beispiel oben ist das Ergebnis 4.58 GiB groß, 3.3-mal kleiner als das Original. Bevor sie ihm vertraut, klickt sie auf Measure quality. Das vergleicht die neue Datei mit dem Original und füllt in der Compare-Tabelle die Spalten "same top token" und mittlere KLD. Danach Measure speed für die Tokens pro Sekunde. Ein Klick auf Try it in Playground stellt es wieder neben die anderen beiden. Am Ende des Abends hat sie ein Modell, das passt, Zahlen dazu, was das Verkleinern gekostet hat, und keine Terminal-History.
Ein kleines Team mit einem starken Desktop
Eine Agentur mit vier Leuten hat im Büro einen Desktop mit viel Speicher und mehrere dünne Laptops. Große Modelle passen nur auf den Desktop, nutzen wollen sie aber alle.
Am Desktop öffnet jemand Servers, wählt This Mac und geht auf den Tab Access. Dort wird "Allow access from other devices on the local network (LAN)" angehakt und Remote Access aktiviert. Das Panel listet dann alle lokalen Modelle, die der Rechner bereitstellt. Unter Device keys klickt man auf New key, benennt den Key nach dem Laptop einer Kollegin und klickt Create key. Jeder Key lässt sich einzeln widerrufen, und ein reiner Inferenz-Key kann Modelle ausführen, kommt aber nicht an Agent-Sessions heran.
Auf jedem Laptop öffnet die Kollegin Servers, klickt Add Server, gibt die Adresse des Desktops ein, fügt den Key ein und nutzt Test Connection. Sobald die Verbindung steht, tauchen die Modelle des Desktops im Model-Picker des Laptops auf wie jedes andere Modell. Die App weist selbst darauf hin, dass dieser Traffic unverschlüsseltes HTTP ist. Gedacht ist das also für Netze, denen du vertraust, etwa das Büro-LAN.
Dann öffnet jemand Benchmarks, klickt New Benchmark, wählt das Modell und lässt die Quick-Suite stehen. Der Lauf misst Tokens pro Sekunde, Time to First Token und Latenz. So weiß das Team, ob das geteilte Modell schnell genug für die Nutzung während Calls ist oder nur für nächtliche Batches taugt. Wirkt es zu langsam, gibt es in Servers noch einen Config-Tab: Dort lässt sich unter Speculative Decoding ein kleines Draft-Modell eintragen, danach Restart now, und der Benchmark kann zum Vergleich noch einmal laufen.
Am Ende hat das Team einen Rechner, der die schwere Arbeit macht, einen Key pro Laptop, der sich zurückziehen lässt, ohne die anderen zu stören, und eine gemessene Antwort auf "Ist es schnell genug?".
Ein Operations-Lead, der nicht programmiert
Ken leitet den Kundensupport eines kleinen Onlineshops. Er hat zwei Fragen: Welches Modell liest Rechnungssummen richtig aus, und kann ein Modell lernen, im Ton des Shops zu antworten?
Für die erste geht er in Eval und klickt Custom Benchmark. Er gibt einen Namen ein, fügt zehn Rechnungen mit der jeweils erwarteten Summe ein, lässt Exact Match stehen und klickt Create Benchmark. Dann New Eval Run: Er hakt zwei Modelle auf seinem Rechner an, hakt seinen Benchmark an und klickt Start Evaluation. Die Fragen gehen auf seinem eigenen Rechner an jedes Modell.
In diesem Beispiel kommt ein Modell auf 90, das andere auf 70, und die Diff-Spalte zeigt den Abstand von 20 Punkten. Das ist ein Ergebnis auf seinen eigenen Dokumenten, nicht das Leaderboard von jemand anderem.
Für die Tonfrage sammelt er ein paar hundert alte Kundennachrichten mit den Antworten, die das Team tatsächlich verschickt hat, ein Paar pro Zeile. In Datasets kann er diese Datei importieren oder über den Hub-Tab nach öffentlichen Daten suchen und sie mit "Use for Training" weitergeben. In Training klickt er New Job und geht die vier Schritte durch: Base Model, Dataset, Config und Review. Unter Training Target wählt er Local (This Device), laut Screen läuft das auf der GPU des Geräts und ist kostenlos, mit LoRA als Methode.
Nach Start Training zeigt der Job während des Laufs seinen Loss. Ist er fertig, erscheint der trainierte Adapter in My Models neben dem Basismodell, aus dem er stammt, und "Chat with your model" beim abgeschlossenen Lauf bereitet ihn für die Runtime auf dem Gerät vor, damit Ken ihm in Playground eine Frage stellen kann. Am Ende hat er ein kleines, privates Modell und einen Benchmark, den er jedes Mal wieder laufen lassen kann, wenn er ein neues Modell in Betracht zieht.
Wo Local Model übergibt
Die Kategorie steht nicht für sich allein. Modelle, die du installierst oder verbindest, erscheinen in derselben Modellliste, die auch der Chat nutzt. Ein lokales Modell kann also ein normales Gespräch beantworten oder in Playground gegen ein Cloud-Modell antreten, das du unter Providers hinzugefügt hast. Aus Explore heraus öffnet "Use in Notebook" ein für dieses Modell eingerichtetes JupyterLab-Notebook, lokal oder auf einer gehosteten Instanz. Braucht ein Modell eine echte GPU statt deines Laptops, übernehmen Deployments und Cloud GPU und stellen es auf einen verwalteten Endpoint. Bevor ein Modell auf Kunden losgelassen wird, lässt Safety Red-Team-Testsuites gegen ein deploytes Modell laufen. Die Seite zur lokalen Inferenz geht genauer auf die Engine auf dem Gerät ein, die Seite zum LoRA-Fine-Tuning auf das Training.
Was die meisten zuerst fragen
Brauche ich eine GPU oder einen Gaming-PC?
Nein. Ein aktueller Laptop reicht für kleine und mittelgroße Modelle; die Badges in Explore zeigen dir vor dem Download, was auf deinen Rechner passt. Ein stärkerer Desktop oder ein Remote-Server macht die Liste einfach länger.
Wird irgendetwas in die Cloud geschickt?
Lokale Inferenz, Quantize und lokales Training laufen auf deinem Rechner. Training auf Cloud GPU, Cloud-GPU-Endpoints und Providers sind die Teile, die externe Dienste nutzen, und die Screens kennzeichnen das, zum Beispiel mit "Managed cloud GPU · needs credits" im Trainingsdialog.
Was ist der Unterschied zwischen Eval und Benchmarks?
Eval bewertet die Qualität der Antworten anhand von Fragen, die du selbst festlegst. Benchmarks misst Geschwindigkeit und Speicher: Tokens pro Sekunde, Time to First Token und Latenz.
Wo bekomme ich die App?
Local Model läuft in der Desktop-App, die du unter osfoundry.io/de/download bekommst.
Top comments (0)