TL;DR

Anstatt sein Geld für die Nutzung von KI-Modellen der großen Anbieter auszugeben, kann es sich vor allem auf Apple-Hardware lohnen, einen genaueren Blick auf Open-Weight-Modelle zu werfen. Aufgrund der Silicon-Architektur, bei der verfügbarer Speicher als RAM und VRAM verwendet werden kann (unified memory), lassen sich diese frei verfügbaren KI-Modelle mit dem Tool ollama einfach lokal auf einem Mac ausführen, ohne extra fette Grafikkarten zu benötigen. Lokal ausgeführte KI-Modelle sparen dabei nicht nur Geld sondern können auch Probleme beim Datenschutz oder mit Compliance-Anforderungen vermeiden.

Gerade in der Software-Entwicklung, wo KI-Modelle zumeist in die IDEs eingebunden werden, um mit intelligenter Code Completion und bei der Fehlervermeidung zu unterstützen, können Open-Weight-Modelle von Vorteil sein. Einige fürs Coding optimierte Modelle kommen dabei sogar mit relativ wenig Speicher aus und laufen problemlos auf Macs mit 32 GB Speicher oder sogar weniger.

Wenn man weiß, worauf man achten muss, ist die lokale Nutzung von KI-Modellen gar nicht so schwierig.

In diesem Artikel erläutere ich, wie man einen KI-Server auf einem Mac einrichtet, welche Modelle im Bereich der Software-Entwicklung besonders gut geeignet sind und worauf man achten muss, wenn man ein Modell für die Nutzung auf seinem Mac auswählt. Dabei gehe ich auf 4 besonders häufig benutzte Modelle ein und zeige, wo ihre Stärken, aber auch ihre Schwächen, liegen. Zum Schluß gebe ich noch einen kleinen Einblick, wie kleine Unternehmen mit überschaubaren Kosten unabhängig von den großen KI-Anbietern eigene KI-Server im Unternehmensnetzwerk betreiben können.

Einleitung

Wenn du als Software-Entwickler mit einem Mac arbeitest, kannst du bei deiner Arbeit in vielen Fällen vermutlich auf teure Dienste wie Claude Code, deren Kosten von deinem Tokenverbrauch abhängen, problemlos verzichten und damit gutes Geld sparen. Letztendlich können sich damit sogar mittelfristig die höheren Preise für Apples Hardware rechnen. Denn eines ist sicher, Tokens werden nicht weiter so billig bleiben. Bereits jetzt ziehen viele KI-Anbieter die Preisschrauben kräftig an und schränken die Tokens in ihren Festpreis-Pakete ein. Auch die Tokens für die neuesten Top-Modelle werden bereits spürbar teurer, als es bisher der Fall war. Die Tokens für Fable 5 sind beispielsweise exakt doppelt so teuer, wie beim Vorgänger-Modell Opus 4.8.

Weil Apple bei seiner Silicon-Architektur CPU und GPU auf denselben Speicher zugreifen lässt, der sogenannte unified memory, und dieser mit einer enormen Speicherbandbreit an das SoC angebunden ist, kannst du auf einem Mac KI-Modelle laufen lassen, für die PC-Nutzer teure Grafikkarten nachrüsten müssten. Bei einer Grafikkarte mit 32 GB VRAM bist du da mit 1000 € und mehr dabei. Auf den meisten Business-Laptops mit Windows, die zumeist auf Architekturen von Intel und AMD basieren, wäre das Ausführen von Modellen, die auf einem aktuellen MacBook Pro problemlos laufen, geradezu undenkbar, weil ihnen der notwendige VRAM fehlt und die Speicherbandbreiten auch nicht ausreichen.

Auf einem Mac mit 48 GB RAM kannst du beispielsweise (unter Abzug von etwas Puffer für das MacOS) Modellen mit bis zu ca. 32 GB Größe problemlos eine Heimat bieten. Doch auch mit weniger RAM, lassen sich bereits gute Modelle lokal nutzen, die für komplexes Code Complete in einer IDE oder für Refactoring kleinerer Projekte zumeist völlig ausreichen.

Vorteile lokal laufender KI-Modelle

Gerade jetzt, wo die Souveränitätsdebatte in Europa große Wellen schlägt, bieten KI-Modelle, die auf dem eigenen Rechner laufen, einige Vorteile in dieser Hinsicht. Denn selbst wenn ein Herr Trump entscheiden würde, dass US-Tech-Firmen mit Europa keinen Handel mehr treiben dürfen und diese kurzerhand ihre APIs dicht machen würden, läuft deine lokale KI einfach weiter. Während jene, die sich von Anthropic, OpenAI oder Google abhängig gemacht haben, erstmal ihre KI-Unterstützung wieder zum Laufen bringen müssen, kannst du mit deiner lokalen KI einfach weiterarbeiten.

Außerdem musst du deine Daten nicht an Server von irgendwelchen Unternehmen senden, wo du keine Ahnung hast, was die wirklich damit anstellen. Gerade im Business-Umfeld werden damit auch gleich einige Datenschutzprobleme gelöst. Denn wenn personenbezogene Daten von Kunden oder Mitarbeitern gar nicht erst auf unternehmensfremden Systemen verarbeitet werden, spart man sich das Thema Auftragsverarbeitung und den ganzen Papierkram der damit einher geht. Und auch viele Compliance-Risiken treten damit gar nicht erst auf.

Vor allem in der Software-Entwicklung können lokal laufende KI-Modelle auch eine Menge Geld sparen. Im Schnitt verbrauchen Software-Entwickler Tokens im Wert von 150-250 € im Monat, wenn sie Claude Code nutzen. Das summiert sich also im Jahr mal schnell auf 1800-3000 €. Da hat sich der Preis eines MacBook Pro also in 1-2 Jahren bereits wieder eingespielt, wenn man diese Kosten sparen kann. Zieht man von den vergleichsweise hohen Kosten für solche Apple-Hardware noch die sonst üblichen Kosten ab, die durch andere Laptops entstehen, die in der Software-Entwicklung generell oft etwas besser ausgestattet sind als der klassische Office-Laptop, ist man auch nochmal mit min. 1500 € dabei, die bei dieser Rechnung eingepreist werden müssen.

Und wer wie ich häufiger mal mit der Deutschen Bahn unterwegs ist, der kennt auch die Verbindungsprobleme, wenn man unterwegs ist. Mit einem via API remote genutzten KI-Modell wird das Arbeiten im Zug eher zum Glückspiel. Code Completion erscheint, wenn überhaupt, nur mit großen Zeitverzögerungen und wenn man mal eine komplexere Task laufen lässt, bricht die Verbindung zwischendurch gern mal ab und die Task landet im Nirvana. Mit einem lokalen Modell kann man unabhängig von einer Internet-Verbindung in aller Ruhe arbeiten.

Für mich ist im Bereich IT-Security auch noch ein anderer Faktor interessant. Oft, wenn ich mir ein Exploit zum Validieren einer Sicherheitslücke erstellen will, verweigern die KI-Modelle der großen Anbieter die Zusammenarbeit. Bei einem lokalen Modell kann ich einfach die Guardrails entfernen und damit ohne irgendwelche künstlichen Einschränkungen arbeiten. Die Entwicklung von Exploits oder auch Schwachstellen-Scans im Netzwerk kann ich mit Hilfe solcher "abliterated"-Modelle enorm beschleunigen.

Es gibt also eigentlich viele gute Gründe, auf Open-Weight-Modelle zu setzen, anstatt sein Geld bei den großen Anbietern zu verbrennen. In diesem Beitrag möchte ich mich aber vor allem dem Einsatz von KI-Modellen bei der Software-Entwicklung widmen und den Fokus auf die Integration in IDE-Software richten.

Modelle lokal laufen lassen mit ollama

Die einfachste Möglichkeit, Modelle lokal auf einem Mac laufen zu lassen, ist ein Tool namens ollama. Zwar bietet Ollama eine Desktop-App für den Mac, aber diese nutzt meiner Erfahrung nach die Modelle nicht immer optimal. Außerdem frisst sie mehr Ressourcen als der Standalone-Server und diese Ressourcen will man ja eigentlich für seine lokale KI nutzen.

Wenn du die volle Kontrolle willst, solltest du dir ollama über Homebrew installieren. Homebrew ist ein Paketmanager, mit dem sich jede Menge Open-Source-Software auf deinem Mac installieren lässt. Du findest eine Anleitung zur Installation direkt auf der Startseite der Projekt-Homepage. (Beachte dabei, dass dein Terminal evtl. Paste Bracketing aktiviert hat, um unbedachtes Copy&Paste von Befehlen aus dem Internet zu verhindern. Du musst also ggf. Steuersequenzen wie ~[0 bzw. ~[1 am Anfang und Ende des Befehls entfernen, wenn du ihn per Copy&Paste von der Website übernimmst.)

Sobald du Homebrew installiert hast, kannst du ollama mittels brew install ollama installieren. Danach kannst du im Terminal - installiere dir iTerm2, falls du ein besseres Terminal haben willst, als das von MacOS mitgelieferte - deinen lokalen KI-Server mittels ollama serve starten. 

Der Server steht nach einer kurzen Startphase per Default auf 127.0.0.1:11434 zur Verfügung. Willst du, dass ollama auch über das Netzwerk auf einem Rechner erreichbar ist, kannst du die Umgebungsvariable OLLAMA_HOST verwenden, um Host und Port anzugeben:

OLLAMA_HOST=0.0.0.0:11434 ollama serve

Für die lokale Entwicklung solltest du aber aus Sicherheitsgründen darauf verzichten und den Zugriff nur über 127.0.0.1 (localhost) zulassen.

Nun ist dein Setup bereit. Willst du ein bestimmtes Modell laden, kannst du einfach folgenden Befehl im Terminal verwenden:

ollama run <model name>

Beispiel:

ollama run deepseek-coder-v2

Sofern das Modell noch nicht auf deinem Rechner ist, wird es von ollama automatisch heruntergeladen und lokal auf deinem Rechner unter ~/.ollama/models gespeichert, so dass es bei einem erneuten Aufruf nicht erneut geladen werden muss. Nach dem Download öffnet sich automatisch ein Chat mit dem gewählten Modell, sofern der Chat vom Modell unterstützt wird. Es gibt jedoch auch Modelle wie nomic-embed-text, die keinen Chat unterstützen. 

Tipp: Falls du einen Editor suchst, der out-of-the-box gut mit KI umgehen kann, schaue dir mal Zed an. In diesem kannst du ollama einfach als lokale KI auswählen, ohne dass du erst nach passenden Erweiterungen suchen und diese konfigurieren musst. Wenn dein ollama-Server läuft, erkennt der Editor automatisch, welche Modelle bereits auf deinen Rechner geladen wurden und bietet sie in den Einstellungen als Dropdown-Menü zur Auswahl an. Du musst also nur sicherstellen, dass das von dir gewünschte Modell bereits heruntergeladen wurde. Ansonsten findest du natürlich auch für andere gängige Editoren wie VSCode, Sublime Text oder BBEdit viele Anleitungen im Netz, wie du mit diesen eine lokal laufende KI verwenden kannst.

Wenn du vorhast, besonders große Modelle laufen zu lassen und dabei feststellst, dass dein System dadurch langsam wird und heftig anfängt Swap-Speicher zu nutzen, kann es manchmal hilfreich sein, das Limit für den VRAM manuell zu erhöhen, damit die GPU mehr von deinem RAM als VRAM nutzen kann. Dies geht ganz einfach mit diesem Befehl:

sudo sysctl iogpu.wired_limit_mb=40960

Wie der Name vermuten lässt, wird damit angegeben, wie viele Megabyte des Arbeitsspeichers als VRAM verwendet werden können. 

Hinweis: Die Einstellungen werden nach einem Reboot wieder auf den Default-Wert zurückgesetzt, der auf modernen Systemen normalerweise 0 ist. Indem du den Wert 0 mit dem Befehl selbst setzt, kannst du aber auch manuell das übliche Speicherverhalten deines Macs wiederherstellen, sobald du mit der Arbeit mit einem großen Modell fertig bist. Du musst dafür also nicht extra rebooten.

Das richtige Modell auswählen

Als nächstes musst du ein passendes Modell finden, das du für die Entwicklung nutzen möchtest und das für deine Hardware passt. Hierbei ist nicht nur die Performance, vor allem der RAM-Verbrauch, zu beachten, sondern auch rechtliche Aspekte und Compliance-Risiken können eine Rolle spielen. 

Für die Performance gilt als Grundsatz: Nutze ein Modell mit Q4-Quantisierung, wenn du weniger als 32 GB RAM hast. Ab 32 GB RAM können auch einige Modelle mit Q8-Quantisierung gut funktionieren, was aber von ihrer Anzahl an Parametern abhängig ist. 

Generell gilt: Die Speicherbedarf (in GB) entspricht X Milliarden Parametern mal Bitgröße durch 8 mal 1,15.

Der Teiler 8 rechnet die Bits in Bytes um. Der Faktor 1,15 schlägt einen realistischen Puffer von ca. 15 % auf. Denn jedes Modell benötigt zusätzlich RAM für die System-Metadaten der Modellarchitektur (die sogenannten Tensor-Overheads).

Beispiel: Nehmen wir das Devstral-2 Modell mit 24 Milliarden Parametern in der 8-Bit (Q8_0) Version. 24 (Milliarden) × 8 (Bit) = 192 Milliarden Bit = 24 GB × 1,15 = 27,6 GB. Das Modell belegt also knapp 28 GB RAM im Leerlauf. Hinzu kommt der Kontext-Cache, der für den verarbeiteten Code und den Chat-Verlauf benötigt wird. Für diesen gilt als Faustregel: Pro 10.000 Token Kontext (das sind etwa 30-40 Seiten Code) muss zusätzlich mit 1-2 GB RAM gerechnet werden. Für ein 24B-Q8-Modell wäre ein System mit 32 GB RAM also bereits ziemlich knapp bemessen. Ein 16B-Q8-Modell kann hingegen problemlos auf 32 GB RAM laufen.

Der Vorteil eines Q8-Modells ist, dass es fast 100% der mathematischen Präzision des unkomprimierten Originalmodells hat. Bei einem Q4-Modell geht etwas Präzision durch Rundungen verloren, was aber für Code Complete in einer IDE normalerweise trotzdem noch völlig ausreichend ist. Selbst für Refactoring kleinerer Projekte reicht ein Q4-Modell zumeist noch aus. 

Die Quantisierung spielt allerdings vor allem dann eine Rolle, wenn es sich nicht um ein MoE-Modell (Mixture of Experts) handelt. Denn ein MoE-Modell nimmt durch die Art, wie es funktioniert, selbst eine Art Skalierungen vor, weil es nur einen bestimmten Teil seiner Daten in den Speicher lädt, wenn diese gebraucht werden. So ein MoE-Modell besteht im Prinzip aus vielen kleinen "Experten"-Netzwerken. Wenn du eine Frage stellst, werden dadurch nicht alle Parameter aktiv, sondern immer nur ein kleiner Teil, der für diese spezifische Aufgabe am besten geeignet ist. Wenn du beispielsweise gerade in Java programmierst, müssen die “Experten” für andere Programmiersprachen normalerweise nicht geladen werden. So sind bei einem MoE-Modell mit  30 Milliarden Parametern oft nur 4 bis 8 Milliarden Parameter aktiv, was den RAM-Verbrauch natürlich massiv senkt. MoE-Modelle sind daher selbst auf Geräten mit relativ wenig RAM noch gut zu nutzen.

Außerdem spielt das Kontextfenster (context length) eine wichtige Rolle bei der Auswahl eines Modells, vor allem, wenn man größere Codebases bearbeiten muss. Es definiert, wie groß und komplex Projekte sein können, die ein Modell laden kann. Beispielsweise kann ein Kontextfenster von 262.144 Token ca. 200.000 Wörter laden, womit eine ziemlich große Codebase geladen werden kann, ohne dass die am Anfang geladenen Daten wieder vergessen werden. Wenn du also mal das Gefühl hast, dass das Modell in deiner IDE nur die Hälfte deines Codes im Blick behält oder vergessen hat, was du am Anfang im Chat geschrieben hast, liegt dies zumeist an einem zu kleinen Kontextfenster.

Ollama setzt das Kontextfenster in Abhängigkeit von der Größe des verfügbaren VRAM:

• < 24 GB VRAM: 4k context
• 24-48 GB VRAM: 32k context
• >= 48 GB VRAM: 256k context

Allerdings kann man auch einen gewünschten Wert beim Start des Ollama-Servers als Umgebungsvariable setzen, muss dann jedoch sicherstellen, dass das System auch genug VRAM dafür zur Verfügung hat.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Nicht zuletzt spielen die Fähigkeiten (Capabilities) eines Modells bei der Software-Entwicklung eine Rolle. Ein Modell, das in fortgeschrittenen IDE-Erweiterungen genutzt werden soll, muss zumeist “Tool Calling” unterstützen (capabilities: tools). Nur damit kann das Modell selbständig Dateien lesen, Terminal-Befehle vorschlagen oder Tools fürs Debugging aufrufen und funktioniert mit MCP-Servern. Für das Auto Complete in einer IDE ist natürlich Completion (capabilities: completion) notwendig. Welche Fähigkeiten ein bestimmtes Modell, das du dir heruntergeladen hast, unterstützt, kannst du mittels ollama show überprüfen. Beispiel:

ollama show qwen3-coder

Dieser Befehl zeigt dir neben den Fähigkeiten auch noch einige andere interessante Infos zu dem jeweiligen Modell an, wie z.B. die Lizenz, das Kontextfenster, die Quantisierung oder Parameter, die sich über die API einstellen lassen.

Modelle für deine IDE

Damit du einen Einblick in die wichtigsten Vor- und Nachteilen verschiedener Modelle bekommst (Stand Juni 2026), folgt nun eine kleine Übersicht über die am weitesten verbreiteten Modelle, die im Rahmen von IDEs eingesetzt werden.

Qwen3-Coder

Qwen3-Coder ist ein 32B-MoE-Modell, das aktuell (Stand Juni 2026) fast schon als Gold-Standard für lokale Entwicklung gilt. Selbst auf Systemen mit 32 GB RAM oder weniger läuft es noch flüssig. Du kannst es einfach mit dem Befehl ollama run qwen3-coder laden. Im Gegensatz zu seinem Vorgänger in der 2.5er-Version beherrscht die Qwen3-Architektur komplexeres, mehrschrittiges Denken ("Reasoning") deutlich besser. Das merkst du vor allem, wenn du ganze Systemarchitekturen planst oder komplexe Bugs über mehrere Dateien hinweg suchst.

Qwen3 geht auch weitaus großzügiger mit dem Kontextfenster um als seine Vorgänger und liefert 256k Token Kontext. Für dich bedeutet das: Du kannst deutlich mehr Codezeilen, Dokumentationen oder Fehlermeldungen auf einmal in deinen Prompt werfen, ohne dass das Modell "vergisst", was oben stand.

Generell steht Qwen3-Coder unter der Apache 2.0 Lizenz. Damit ist der Einsatz auch in einem kommerziellen Umfeld problemlos und uneingeschränkt möglich.

Allerdings sollte beachtet werden, dass Qwen von Alibaba aus China entwickelt wurde. Auch wenn die Gewichte (Weights) Open Source sind, ist die genaue Zusammensetzung der Trainingsdaten (data provenance) und der Filterung eine Blackbox. Alibaba muss sich naturgemäß an chinesische Gesetze und KI-Regulierungen halten (z. B. die Vorgaben der CAC bezüglich der "Zensur" und Ausrichtung von Modellen). Zwar betrifft dich das bei einem lokal laufenden Modell für die Softwareentwicklung funktional kaum, aber es kann eine Rolle spielen, wenn das Modell für Code-Audits eingesetzt wird und bestimmte Schwachstellen oder Themen durch das Alignment des Herstellers voreingenommen bewertet oder "übersehen" werden. 

Außerdem gibt es keine Haftungsfreistellung, was vor allem bei unbekannter Zusammensetzung der Traingsdaten kritisch zu betrachten ist. Wenn das Modell eine patentierte oder geschützte Code-Sequenz eins-zu-eins reproduziert und Entwickler/innen diese in ihren Code einbauen, liegt das Risiko komplett bei den Entwickler/innen bzw. den Unternehmen, für die sie arbeiten. Daher sollte immer geprüft werden, ob generierter Code evtl. irgendwo im Netz in identischer Form bereits veröffentlicht wurde, bevor er in einer Software verwendet wird, die öffentlich erreichbar ist oder mit externen Parteien geteilt wird. Dies sollte man auch dann einhalten, wenn die Quelltexte der Software theoretisch nicht direkt einsehbar sind, wie es z.B. bei Applikationsservern der Fall ist. Oft kann man nämlich durch das Verhalten einer Software auf die darin verbauten Algorithmen Rückschlüsse ziehen, wofür es verschiedenste Möglichkeiten gibt (Iteratives Reverse-Engineering von Black-Box-Funktionen via Neural Program Synthesis, L-Algorithmus, Timing Attacks & Cache-Algorithmen, semantische Reduktionstheoreme etc.).

• Funktionalität: Modernes Hybrid-Modell mit integriertem Thinking Mode (Chain-of-Thought) und nativem MCP/Tool-Support für autonome Agents.
• Stärken: Extrem schnelle Antworten dank MoE-Architektur (nur 3.3B Parameter gleichzeitig aktiv). Meisterhaft im logischen Umdenken und Verstehen von komplexen Fehler-Stacktraces über riesige Kontexte (256k Token).
• Schwächen: Neigt durch den "Thinking Mode" bei falschen Einstellungen in manchen IDE-Erweiterungen dazu, zu viele Token mit internen Überlegungen zu verschwenden, bevor es den eigentlichen Code ausgibt ("Thinking Leakage").

Codestral

Codestral stammt von dem europäischen Unternehmen Mistral und eignet sich besonders auf Rechnern mit relativ wenig RAM. Codestral ist ein 22B-Modell, das standardmäßig in einer Q4_0 Quantisierung daher kommt und für über 80 Programmiersprachen trainiert wurde. Wenn man etwas mehr RAM zur Verfügung hat, kann man aber auch ein Modell mit Q8-Quantisierung laden, indem man statt ollama run codestral einfach ollama run codestral:22b-v0.1-q8_0 aufruft, um das Modell zu laden. 

Bei Codestral ist unbedingt zu beachten, dass es unter der Mistral AI Non-Production License (MNPL) steht. Damit ist ein Einsatz für kommerzielle Software-Entwicklung nicht gestattet. Für Forschungszwecke, für die private Nutzung oder auch zur Validierung von Ergebnissen anderer Modelle, kann es jedoch ganz nützlich sein.

In nicht-kommerziellen Projekten, z.B. OSS, spielt Codestral seine Stärken vor allem beim Auto Complete in der IDE aus. Es kann Funktionen im Code vervollständigen, Tests schreiben und unvollständigen Code jeglicher Art ergänzen.

• Funktionalität: Klassischer Code-Fulfiller (Fill-in-the-Middle) von Mistral AI, primär optimiert als schneller Autocomplete-Assistent direkt in der Zeile.
• Stärken: Sehr stabile Syntax-Vorschläge bei Standard-Sprachen (z.B. Python, Java, C++, JavaScript). Extrem reife und vorhersagbare Codeausgabe.
• Schwächen: Mit 32k Token ein im Vergleich sehr kleines Kontextfenster. 

Devstral

Mit Devstral gibt es aber eine gute Alternative zu Codestral, die ebenfalls von Mistral ist und problemlos kommerziell genutzt werden kann. Dabei handelt es sich um Weiterentwicklungen bzw. Fine-Tunes auf Basis der kommerziell erlaubten Mistral-Modelle (wie Mistral Small), die unter der Apache 2.0 Lizenz stehen, wodurch sie für den Einsatz in Unternehmen unbedenklich sind.

Allerdings gilt auch bei Devstral, dass man vorsichtig beim generierten Code sein muss, da die Trainingsdaten nicht komplett offen liegen. Bekannt ist nur, dass es über spezielle Code-Scaffolds gezielt auf echten GitHub-Repositories und Software-Engineering-Issues trainiert wurde. Welche Repositories dabei zum Einsatz kamen und welche Lizenzen diese verwenden ist jedoch nicht bekannt. Das ist aber ein generelles Problem der meisten Open-Weight-Modelle.

Wer etwas weniger RAM hat, kann sich mit devstral-small-2 ein 24B-Modell mit Q4 Quantisierung auf seinen Rechner holen. Mit etwas mehr RAM lohnt sich das Modell mit Q8 Quantisierung, das man mit ollama unter dem Bezeichner devstral-small-2:24b-instruct-2512-q8_0 bekommt. 

Devstral wurde speziell für Coding Agents trainiert. Es glänzt vor allem im Multi-Step-Reasoning, da es logische Ketten bilden, Werkzeuge (Tools) nutzen und komplexe Dateiabhängigkeiten auflösen kann.

Devstral schluckt außerdem mit einem Kontext von 128k Tokens ganze Codebases, umfangreiche APIs und seitenlange Sicherheitsdokumentationen auf einmal, ohne den Faden zu verlieren. Devstral-Small-2 mit Q8 Quantisierung hat sogar ein Kontextfenster von 384k Tokens. In Industrie-Benchmarks lässt Devstral zum Teil sogar Schwergewichte wie GPT-4o mini oder Claude 3.5 Haiku hinter sich.

• Funktionalität: Der dichte (Dense) Nachfolger von Mistral für "Agentic Coding". Speziell darauf trainiert, nicht nur Code zu schreiben, sondern als System-Agent ganze Dateiabhängigkeiten zu manipulieren.
• Stärken: Keine "Rundungsfehler" bei logischen Pfaden, da es ein dichtes Modell ist (alle 24B Parameter prüfen den Code). Massiver Kontext (bis zu 384k).
• Schwächen: Rechnet auf Systemen mit weniger RAM schwerer als die MoE-Konkurrenz.

Deepseek-Coder

Mit Deepseek-Coder gibt es ein weiteres MoE-Modell aus China, das mittlerweile in seiner Version 2 verfügbar ist (deepseek-coder-v2). Es ist vor allem für seine Fähigkeiten bei komplexen logischen Architekturen und mathematischen Programmierproblemen bekannt geworden. Bei codespezifischen Aufgaben erreicht es eine Performance, die mit GPT4-Turbo vergleichbar ist.

Allerdings ist auch hier wieder das Gleiche zu beachten wie bei Qwen3, da es sich um ein chinesisches Modell handelt. 

• Funktionalität: Ein hocheffizientes MoE-Modell, das speziell für mathematisch anspruchsvolle Programmierprobleme und komplexe Compiler-Optimierungen trainiert wurde. Deepseek-Coder wurde für über 300 Programmiersprachen trainiert.
• Stärken: Extrem ressourcenschonend. Die 16B-Lite-Version läuft selbst als unkomprimierte Q8-Variante absolut flüssig auf fast jeder Hardware und schlägt bei mathematischer Logik oft größere Modelle.
• Schwächen: Der Support für europäische Sprachen außerhalb von Englisch in der Dokumentations-Generierung ist manchmal etwas hölzern. Tool Calling wird nicht unterstützt.

Vergleich der Modelle

| Kriterium | Qwen3-Coder | Codestral | Devstral-Small-2 | DeepSeek-Coder-V2 |
| Architektur | MoE | Dense | Dense | MoE |
| Parameter | 30,5 Mrd. | 22 Mrd. | 24 Mrd. | 16 Mrd. |
| Aktivierte Parameter | ~3.3 Mrd. | 22 Mrd. | 24. Mrd | ~2.4 Mrd. |
| Empfohlene Quantisierung | Q4_K_M | Q8_0 | Q8_0 | Q8_0 |
| Dateigröße (RAM) | ca. 18-20 GB | ca. 23 GB (bei Q8) | ca. 26 GB (bei Q8) | ca. 17 GB (bei Q8) |
| Systeme mit <= 32GB RAM | sehr gut | Knapp bei Q8, flüssig bei Q4 | Perfekt als Q4 | Sehr gut |
| Systeme mit > 32GB RAM | Exzellent (maximaler Kontext-Buffer) | Flüssig (als Q8 nutzbar) | Exzellent als Q8 | Herausragend |
| Lizenz | Apache 2.0 | MNPL | Apache 2.0 | DeepSeek License (Frei bis 500M Nutzer) |

Weitere Coding-Modelle

Natürlich sind das bei weitem nicht alle Modelle, die fürs Coding verwendet werden können. Über die Suche auf der Ollama-Homepage findet man mit dem Suchbegriff coder noch weitere, wie z.B. deepcoder, opencoder, starcoder uvm.. Manche davon, wie z.B. sqlcoder, sind auf spezifische Sprachen spezialisiert. Andere, wie z.B. codellama, sind eher darauf ausgelegt, dass man sich in natürlicher Sprache mit ihnen über Code unterhalten oder Code von ihnen analysieren lassen kann, was zum Programmieren lernen oft sehr hilfreich ist.

Vorsicht bei Community-Modellen

Von den meisten Modellen gibt es auf Hugging Face und damit über Ollama auch noch Derivate, die von Community-Membern erstellt wurden. Oft handelt es sich dabei um spezielle Tweaks. Allerdings ist nicht immer ganz transparent, was im Detail verändert wurde. Daher ist es immer ratsam, die Modelle der Original-Hersteller zu verwenden und Community-Modelle mit Vorsicht zu genießen. 

Ein Ausnahme gibt es, wenn man Sicherheitstests machen muss oder Exploits entwickelt, bei denen bestimmte Guardrails im Weg sind. In solchen Fällen können sogenannte Abliterated-Modelle hilfreich sein, bei denen die Guardrails deaktiviert sind. Abliteration, eine Wortschöpfung aus „Ablation“ [Abtragung/Entfernung] und „Obliteration“ [Auslöschung/Vernichtung], bezeichnet eine Methode, bei der bestimmte Fähigkeiten oder Sicherheitsbarrieren, z.B. Weigerungshaltungen oder Zensurmechanismen, gezielt aus einem vortrainierten KI-Modell entfernt werden, ohne dass ein vollständiges neues Training erforderlich ist. Allerdings sollte man dann die entsprechenden User kennen, bevor man solche Modelle einsetzt. Ansonsten ist es ratsam, selbst die Guardrails mittels Tools wie Heretic aus einem Modell zu entfernen. 

Zentrale KI-Server in Unternehmen

Wie oben bei der Einrichtung von ollama bereits gezeigt, kann man den ollama-Server auch in einem Netzwerk verfügbar machen. So kann der Server von mehreren Entwicklern gleichzeitig verwendet werden. Für diesen Zweck werden gern Mac Mini oder Mac Studio verwendet, da diese über Ethernet-Anschlüsse verfügen, so dass man sie einfach im Serverraum des Büros an einen Switch anschließen kann. Mit ausreichend Arbeitsspeicher können darauf auch verschiedene Modelle parallel betrieben werden, so dass bspw. ein/e System-Architekt/in ein anderes Modell nutzen kann als die Programmierer/innen, die den Code produzieren, oder die DevOps Engineers, die mittels KI ihre Deployment-Pipelines überwachen und automatisiert optimieren. 

Doch nicht nur für die Software-Entwicklung kann ein ollama-Server im Netzwerk interessant sein. Es gibt auch genug Open-Weight-Modelle, die nicht nur auf Coding ausgelegt sind sondern auch andere Aufgaben von agentischer KI (agentic AI) übernehmen können. Anstatt also teure KI-Agenten irgendwo als Service einzukaufen, wo sie auf Basis der verbrauchten Token abgerechnet werden, kann man sich seine KI-Agenten, mit denen Mitarbeiter Arbeitsabläufe optimieren und automatisieren können, einfach auf solche Rechner im eigenen Netzwerk holen. Selbst ein zentraler KI-Chat für Mitarbeiter lässt sich so im eigenen Netzwerk betreiben, der für die meisten Anfragen im beruflichen Kontext oft vollkommen ausreicht. Eine Anleitung, wie man einen solchen KI-Chat mit einem Webinterface ausstatten kann (ähnlich zu dem von ChatGPT & Co), habe ich bereits vor einiger Zeit auf meiner privaten Website verfasst.

Allerdings sollte beachtet werden, dass der ollama-Server nicht auf eine Nutzung in einem Netzwerk ausgelegt ist, da er weder Verschlüsselung noch Authentifizierung unterstützt. Ohne weitere Schutzmaßnahmen sollte er daher nur innerhalb eines vertrauenswürdigen Netzwerks freigegeben werden. Man kann jedoch vor den ollama-Server auch einen Proxy-Server, z.B. mit Nginx, schalten, der sich um Dinge wie SSL-Verschlüsselung der API oder eine Authentifizierung mittels HTTP-Basic-Auth kümmert. So kann man den Server zumindest grundlegend etwas absichern.

Der größte Vorteil solcher lokalen KI-Systeme im Unternehmensnetzwerk liegt sicherlich in der besseren Kostenkontrolle. Neben den Hardwarekosten kommen noch die Stromkosten hinzu, die sich jedoch bei Apples Silicon-Chips im Vergleich zu großen KI-Servern in Grenzen halten. Man hat also einen halbwegs festen Preis, mit dem man rechnen kann. Im Netz häufen sich hingegen Berichte von Entwickler/innen, die sich KI-Agenten bauen und dann entsetzt sind, als die erste Rechnung der KI-Anbieter kommt. Denn auch wenn der Token-Verbrauch für einzelne Aufrufe gering sein mag, wird oft unterschätzt, wie viele Aufrufe ein KI-Agent letztendlich selbst für einfache Workflows macht. Es hat seine Gründe, warum immer häufiger Berichte von Unternehmen auftauchen, in denen KI-Agenten letztendlich wieder durch menschliche Arbeitskräfte ersetzt werden. Denn diese sind zumeist ähnlich teuer, ihre Ergebnisse sind allerdings auch oft besser. Denn schließlich muss auch die Arbeit von KI-Agenten überwacht werden (human-in-the-loop), um Fehlverhalten von KI zu erkennen und rechtzeitig gegenzusteuern. 

Gleichzeitig bieten lokale KI-Systeme im Unternehmensnetzwerk auch oft eine größere Flexibilität bei weniger Arbeit für das Controlling. Anstatt für die verschiedenen Einsatzzwecke die passenden KI-Anbieter zu finden, mit denen individuelle Verträge abgeschlossen werden und die alle ihre Rechnungen am Monatsende einreichen, können spezialisierte Modelle auf lokalen KI-Servern nach Bedarf geladen und ausgeführt werden. Der organisatorische Aufwand verringert sich dadurch enorm, selbst wenn man die Arbeit der IT-Administratoren in die Rechnung aufnimmt. Die hält sich übrigens in Grenzen, solange die Systeme nicht überlastet und mit einer MDM-Lösung zentral verwaltet werden.

Die größte Herausforderung beim Einsatz lokaler KI-Server liegt darin, die passenden Modelle für verschiedene Anwendungszwecke zu finden und deren Einsatz sinnvoll auf die zur Verfügung stehende Hardware zu verteilen. Hierfür sollte man eine Evalutationsphase einplanen, in der man verschiedene Modelle genauer betrachtet und ihren Einsatzzweck im Unternehmen sowie die zugehörigen Use-Cases dokumentiert.

Außerdem kann die IT-Security zur Herausforderung werden, wenn die Sicherheit der Systeme nicht von Anfang an mitgedacht wird. 

Abschließende Worte

Die Nutzung von frei verfügbaren Open-Weight-Modellen auf der richtigen Hardware, kann für Unternehmen nicht nur ein Produktivitätsboost sein, sondern ein echter Vorteil, wenn es um Kostenkontrolle, Datenschutz und Souveränität geht. Anstatt sich von großen Big-Techs abhängig zu machen, können solche Modelle direkt auf den Rechnern der Mitarbeiter oder zentral im Netzwerk des Unternehmens ausgeführt werden. Während andere Unternehmen zuschauen, wie ihre KI-Kosten immer weiter steigen und teilweise sogar regelrecht explodieren, können Unternehmen, die ihre KIs lokal laufen lassen, beruhigt in die Zukunft schauen.

Egal ob ein US-Präsident der Meinung ist, dass amerikanische KI-Systeme zuerst für US-Unternehmen da sein sollen, egal ob Investoren irgendwann aufhören immer neue Milliarden in KI-Unternehmen zu pumpen und egal, ob die Token-Kosten plötzlich massiv steigen, weil die Energiekosten der großen KI-Systeme irgendwann gedeckt werden müssen... wer möglichst viele Aufgaben an lokale KI-Systeme übergibt anstatt sie mit den großen Modellen auszuführen, die für diese Aufgaben eigentlich totaler Overkill sind, kann etwas beruhigter in die Zukunft schauen und minimiert Risiken, bevor sie überhaupt entstehen.

Gleichzeitig müssen sich Unternehmen, die auf lokale Open-Weight-Modelle setzen, keine Gedanken darum machen, ob und welche Daten die Mitarbeiter in die KI-Systeme füttern, denn die Daten bleiben im Unternehmen. Dabei braucht man dafür nichtmal teure KI-Server, wenn die Mitarbeiter mit den richtigen Rechnern ausgestattet sind oder wenn im Vergleich zu KI-Servern relativ preiswerte Hardware von Apple verwendet wird, die sich aufgrund ihrer Architektur für die Nutzung mit KI regelrecht anbietet. Vor allem im Bereich der Software-Entwicklung können Open-Weight-Modelle mit gängigen Modellen großer Anbieter oft mithalten. Die wenigsten Software-Entwickler reizen die Fähigkeiten der großen LLM wirklich aus.