[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-page-\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl":3,"reazon-angebot-subnav":31,"reazon-mainnav":32,"reazon-offering-angebot-leistungen":42,"reazon-footernav":58,"reazon-articles-\u002Fde\u002Fwissen":75,"reazon-offering-angebot-zielgruppen":199},{"data":4},{"id":5,"path":6,"slug":7,"published_at":8,"page_type":9,"no_index":12,"fields":13,"blocks":30},1326,"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","2026-07-07T12:08:06.427Z",{"identifier":10,"name":11},"article","Blog Post",false,{"related_articles":14,"meta_title":15,"meta_description":16,"body":17,"body_html":18,"title":19,"summary":20,"publication_date":21,"big5_category":22,"primary_service":23},null,"Welches offene LLM für welche Aufgabe? | Twentyone","Llama, Qwen, Mistral, Gemma: offene Modelle nach Aufgabe, Grösse und Lizenz auswählen. Wie du das passende Modell findest, statt dem grössten Benchmark zu folgen.","## Warum die Bestenliste die falsche Frage beantwortet\n\nStell dir vor, jemand schreibt dir ins Team-Chat: „Lass uns das neue Top-Modell vom Leaderboard nehmen, das schlägt alles.“ Drei Wochen später steht die Rechnung für eine **GPU, die viermal so gross ist wie nötig**, der Durchsatz ist mässig, weil das Modell kaum in den Speicher passt, und die Rechtsabteilung meldet, dass die **Lizenz** den kommerziellen Einsatz in eurem Fall gar nicht deckt. Das ist kein erfundenes Schreckensbild, sondern der Normalfall, wenn die Modellwahl bei der Frage „welches ist das beste“ beginnt. Die bessere Frage lautet **„welches passt“**, und sie entscheidet sich entlang von drei Achsen: **Speicher, Aufgabe und Lizenz**. Der Rest ist Geschmack.\n\n## Speicher zuerst: die Mathematik, die alles vorentscheidet\n\nBevor du über Qualität auch nur nachdenkst, klär, was überhaupt in deinen Speicher passt. Das ist keine Geschmacksfrage, sondern **Arithmetik**, und sie schneidet die Kandidatenliste in Sekunden zusammen. Der Speicherbedarf der Gewichte ist ungefähr **Parameter mal Bytes pro Parameter**. In **FP16** (16 Bit) sind das 2 Bytes pro Parameter, in **8-Bit** 1 Byte, in **4-Bit** rund 0,5 Bytes. Ein **8B-Modell** braucht also grob 16 GB in FP16, 8 GB in 8-Bit, 4 GB in 4-Bit. Dazu kommt Overhead für den **KV-Cache**, der mit Kontextlänge und der Zahl gleichzeitiger Anfragen wächst, sowie für Aktivierungen; als grobe Daumenregel rechne mit dem **rund 1,2-fachen** des reinen Gewichtsbedarfs, bei langen Kontexten und vielen parallelen Nutzern auch deutlich mehr.\n\nWie sehr das die Wahl bestimmt, zeigt der Sprung nach oben. Ein **70B-Modell in FP16** belegt rund **140 GB** allein an Gewichten. Das passt auf keine einzelne gängige Karte und auch nicht ungequetscht auf eine [DGX Spark](\u002Fde\u002Fdgx-spark) mit **128 GB Unified Memory**. In **4-Bit** schrumpft dasselbe Modell auf etwa **35 bis 40 GB**, und genau hier wird es interessant: 35 GB plus KV-Cache laufen komfortabel auf 128 GB Unified Memory, mit reichlich Luft für lange Kontexte und mehrere Anfragen. Auf einer **24-GB-Karte** ist ein 4-Bit-70B dagegen ausser Reichweite; dort landest du realistisch bei 7B\u002F8B-Modellen oder kleinen Quantisierungen mittlerer Grössen. Eine **48-GB-Karte** trägt ein 4-Bit-70B knapp, ohne viel Spielraum, eine **80-GB-Karte** komfortabel. Der Engpass ist eben fast immer der **Speicher, nicht die Rechenleistung**, und wenn CPU und GPU sich wie bei der DGX Spark 128 GB teilen, passt ein grosses Modell **am Stück** hinein, ohne ständig über PCIe nachzuladen. Das ist der Grund, warum eine speicherstarke Maschine grosse, quantisierte Modelle ruhig betreibt, an denen eine rechenstärkere, aber speicherärmere Karte scheitert. Die ganze Abwägung zwischen Speicher, Durchsatz und Kosten haben wir im Vergleich [DGX Spark gegen Cloud-GPU](\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu) aufgemacht.\n\n## Quantisierung: kleiner machen, ohne dumm zu machen\n\nQuantisierung speichert die Gewichte mit **weniger Bits** und ist damit der **stärkste Hebel** überhaupt, um ein gutes Modell auf bezahlbare Hardware zu bringen, meist deutlich klüger, als reflexhaft eine grössere GPU zu kaufen. Zur Orientierung: **8-Bit ist praktisch verlustfrei**, den Unterschied zu FP16 misst du eher im Benchmark als im Alltag. **4-Bit** ist für die allermeisten produktiven Fälle gut nutzbar, mit minimalen Einbussen. Darunter, bei **3-Bit oder 2-Bit**, wird es heikel, da bröckelt die Qualität sicht- und messbar. Die wichtigste Konsequenz daraus: Ein in 4-Bit quantisiertes **grosses** Modell schlägt fast immer ein kleineres Modell in voller Präzision bei gleichem Speicherbudget. **Mehr Parameter, grob komprimiert, sind oft besser** als wenige Parameter, fein aufgelöst.\n\nWelches Format du dabei wählst, hängt an deiner Inference-Engine, denn nicht jede Engine spricht jedes Format. **GPTQ** und **AWQ** sind Post-Training-Quantisierungen, die auf GPU-Inferenz optimiert sind; AWQ schützt gezielt die wichtigsten Gewichte und hält die Qualität bei 4-Bit gut. **GGUF** mit den sogenannten k-quants, etwa Q4_K_M, stammt aus dem llama.cpp-Umfeld, läuft auch auf **CPU und Apple Silicon** und ist der Standard für lokale Setups. **bitsandbytes** schliesslich bietet On-the-fly-Quantisierung direkt beim Laden über die gängigen Bibliotheken, ist dafür aber oft etwas langsamer als die vorquantisierten Formate.\n\n## Die Modellfamilien und ihr echtes Profil\n\nStatt Versionsnummern, die in Monaten veralten, lohnt der Blick auf die Familien und ihren Charakter. Metas **Llama**-Familie ist der breite Default: das **grösste Ökosystem**, die beste Tool-Unterstützung, Varianten von klein bis sehr gross. Wenn du nicht weisst, wo du anfängst, ist eine Llama-Variante selten falsch; der Haken sitzt in der Lizenz, dazu gleich mehr. Die **Qwen**-Familie glänzt bei **mehrsprachigen Aufgaben und beim Coding** und bietet oft ein hervorragendes Verhältnis von Grösse zu Leistung, viele Varianten stehen unter dem bequemen **Apache-2.0**. Für produktive Fälle holt ein mittelgrosses Qwen häufig mehr heraus als ein grösseres Modell einer anderen Familie. **Mistrals** dichte Modelle sind kompakt und effizient, spannender aber ist das **MoE-Prinzip** (Mixture of Experts) der Mixtral-Linie: Das Modell hat viele totale Parameter, aktiviert pro Token aber nur einen Bruchteil davon. Du brauchst also den **Speicher für alle Parameter**, zahlst bei der Rechenzeit jedoch **nur für die aktiven**, und bekommst praktisch Qualität nahe an einem grossen dichten Modell bei deutlich höherem Durchsatz, wenn der Speicher reicht. Und Googles **Gemma**-Familie zielt auf **kleine, effiziente Modelle**, die auch auf bescheidener oder edge-naher Hardware laufen, ein günstiger Default für einfache, klar umrissene Aufgaben.\n\nQuer zu allen Familien laufen drei Unterscheidungen, die wichtiger sind als der Name. Eine **Base**-Variante ist roh und sagt nur das nächste Token voraus; für Anwendungen willst du fast immer die **Instruct- oder Chat-Variante**, die auf Anweisungsbefolgung trainiert ist. **Reasoning**-Varianten „denken“ vor der Antwort in Zwischenschritten und sind stark bei Logik und Mathematik, dafür langsamer und teurer pro Antwort. Und prüf das **Kontextfenster**, bevor du dich festlegst: Ein Modell mit 8K Kontext sprengt deine RAG-Pipeline, sobald deine Dokumente länger sind.\n\n## Vom Modell zur Aufgabe\n\nDefiniere die Aufgabe eng, dann ergibt sich die Grösse fast von selbst. Für **Extraktion und Klassifikation**, also strukturierte Daten aus Text ziehen, Tickets einsortieren, Sentiment bestimmen, reicht ein **kleines Modell mit 7B oder 8B**, gern quantisiert, zuverlässig aus; ein grosses Modell ist hier teure Verschwendung ohne messbaren Mehrwert. Bei **RAG und Q&A** über deine Wissensbasis zählen zwei Dinge: ein ausreichend **langes Kontextfenster**, damit die abgerufenen Passagen hineinpassen, und gutes **Instruction-Following**, damit das Modell bei der Quelle bleibt statt zu fabulieren. Ein gut gewähltes mittelgrosses Instruct-Modell genügt meist, und die Qualität deiner Retrieval-Pipeline entscheidet oft mehr als die letzten Parameter-Milliarden. Für **Codegenerierung** schlagen **code-spezialisierte Modelle** generische gleicher Grösse deutlich; hier lohnt ein mittleres bis grosses, auf Code trainiertes Modell mit langem Kontext, damit es ganze Dateien überblickt. Für flüssigen **Dialog** reicht ein solides Instruct-Modell mittlerer Grösse, und nur für echtes mehrstufiges **Reasoning**, also komplexe Logik, Mathematik, verschachtelte Planung, lohnt der Sprung zu grösseren oder dedizierten Reasoning-Modellen. Aber wirklich nur dann, denn für eine simple Klassifikation ist ein Reasoning-Modell langsam und teuer ohne Gegenwert.\n\n## Lizenz prüfen, bevor du baust\n\n**„Offen“ heisst nicht automatisch „frei für jeden Zweck“**, und das ist kein Detail für die Rechtsabteilung am Schluss, sondern eine **Vorab-Entscheidung**. Grob gibt es drei Lager. **Apache-2.0** und ähnlich permissive Lizenzen sind der bequeme Fall: kommerziell nutzbar, kaum Auflagen, viele Qwen- und Mistral-Modelle liegen hier. Die **Llama Community License** ist grosszügig, aber bedingt; sie knüpft Auflagen an **sehr grosse Deployments**, etwa eine Nutzerschwelle, ab der du eine gesonderte Erlaubnis brauchst, dazu ein paar Namens- und Nutzungsklauseln. Für die meisten ist das irrelevant, für ein Produkt mit Millionen Nutzern nicht. Und **nicht-kommerzielle Lizenzen**, etwa research-only, verbieten den produktiven Einsatz schlicht; solche Modelle sind super zum Prototyping und gehören trotzdem nicht in dein Produkt. Prüf das, **bevor** du Architektur und Prompts um ein Modell herum baust, denn ein Lizenzwechsel im Nachhinein ist teuer.\n\n## Eine pragmatische Auswahlstrategie\n\nAus alldem folgt kein Orakel, sondern eine **Iteration**. Statt vorab das vermeintlich beste Modell zu erraten, taste dich in vier Schritten heran:\n\n- **Klein starten.** Nimm das kleinste Modell, das die Aufgabe plausibel lösen könnte.\n- **An eigenen Daten messen.** Bau dir ein kleines Eval-Set aus echten Fällen mit erwarteten Ergebnissen und miss daran, nicht an fremden Benchmarks. Dein Use-Case ist nicht das Leaderboard.\n- **Nur bei Bedarf hoch.** Steig erst dann eine Stufe höher, wenn das Eval-Set einen konkreten Mangel zeigt.\n- **Quantisierung vor GPU-Upgrade.** Bevor du in mehr Speicher investierst, prüf, ob ein quantisiertes grösseres Modell auf der vorhandenen Hardware reicht.\n\nDie Modellwahl ist damit der **Anfang, nicht das Ziel**. Danach kommen Engine, Quantisierungsformat, Hardware und der laufende Betrieb, und die Frage, ob das Ganze die Schweiz verlässt. Wenn du ein passendes Modell auf souveräner Infrastruktur betreiben willst, ohne den Stack selbst zu pflegen, ist [Managed Inference](\u002Fde\u002Fmanaged-inference) der direkte Weg. Und wenn du unsicher bist, welches Modell für deinen Fall reicht: **Wir testen zwei, drei Kandidaten an deinen echten Daten** und sagen dir ungeschönt, welcher die Aufgabe löst, oft ist es ein kleinerer, als du denkst.","\u003Ch2>Warum die Bestenliste die falsche Frage beantwortet\u003C\u002Fh2>\n\n\u003Cp>Stell dir vor, jemand schreibt dir ins Team-Chat: „Lass uns das neue Top-Modell vom Leaderboard nehmen, das schlägt alles.“ Drei Wochen später steht die Rechnung für eine \u003Cstrong>GPU, die viermal so gross ist wie nötig\u003C\u002Fstrong>, der Durchsatz ist mässig, weil das Modell kaum in den Speicher passt, und die Rechtsabteilung meldet, dass die \u003Cstrong>Lizenz\u003C\u002Fstrong> den kommerziellen Einsatz in eurem Fall gar nicht deckt. Das ist kein erfundenes Schreckensbild, sondern der Normalfall, wenn die Modellwahl bei der Frage „welches ist das beste“ beginnt. Die bessere Frage lautet \u003Cstrong>„welches passt“\u003C\u002Fstrong>, und sie entscheidet sich entlang von drei Achsen: \u003Cstrong>Speicher, Aufgabe und Lizenz\u003C\u002Fstrong>. Der Rest ist Geschmack.\u003C\u002Fp>\n\n\u003Ch2>Speicher zuerst: die Mathematik, die alles vorentscheidet\u003C\u002Fh2>\n\n\u003Cp>Bevor du über Qualität auch nur nachdenkst, klär, was überhaupt in deinen Speicher passt. Das ist keine Geschmacksfrage, sondern \u003Cstrong>Arithmetik\u003C\u002Fstrong>, und sie schneidet die Kandidatenliste in Sekunden zusammen. Der Speicherbedarf der Gewichte ist ungefähr \u003Cstrong>Parameter mal Bytes pro Parameter\u003C\u002Fstrong>. In \u003Cstrong>FP16\u003C\u002Fstrong> (16 Bit) sind das 2 Bytes pro Parameter, in \u003Cstrong>8-Bit\u003C\u002Fstrong> 1 Byte, in \u003Cstrong>4-Bit\u003C\u002Fstrong> rund 0,5 Bytes. Ein \u003Cstrong>8B-Modell\u003C\u002Fstrong> braucht also grob 16 GB in FP16, 8 GB in 8-Bit, 4 GB in 4-Bit. Dazu kommt Overhead für den \u003Cstrong>KV-Cache\u003C\u002Fstrong>, der mit Kontextlänge und der Zahl gleichzeitiger Anfragen wächst, sowie für Aktivierungen; als grobe Daumenregel rechne mit dem \u003Cstrong>rund 1,2-fachen\u003C\u002Fstrong> des reinen Gewichtsbedarfs, bei langen Kontexten und vielen parallelen Nutzern auch deutlich mehr.\u003C\u002Fp>\n\n\u003Cp>Wie sehr das die Wahl bestimmt, zeigt der Sprung nach oben. Ein \u003Cstrong>70B-Modell in FP16\u003C\u002Fstrong> belegt rund \u003Cstrong>140 GB\u003C\u002Fstrong> allein an Gewichten. Das passt auf keine einzelne gängige Karte und auch nicht ungequetscht auf eine \u003Ca href=\"\u002Fde\u002Fdgx-spark\">DGX Spark\u003C\u002Fa> mit \u003Cstrong>128 GB Unified Memory\u003C\u002Fstrong>. In \u003Cstrong>4-Bit\u003C\u002Fstrong> schrumpft dasselbe Modell auf etwa \u003Cstrong>35 bis 40 GB\u003C\u002Fstrong>, und genau hier wird es interessant: 35 GB plus KV-Cache laufen komfortabel auf 128 GB Unified Memory, mit reichlich Luft für lange Kontexte und mehrere Anfragen. Auf einer \u003Cstrong>24-GB-Karte\u003C\u002Fstrong> ist ein 4-Bit-70B dagegen ausser Reichweite; dort landest du realistisch bei 7B\u002F8B-Modellen oder kleinen Quantisierungen mittlerer Grössen. Eine \u003Cstrong>48-GB-Karte\u003C\u002Fstrong> trägt ein 4-Bit-70B knapp, ohne viel Spielraum, eine \u003Cstrong>80-GB-Karte\u003C\u002Fstrong> komfortabel. Der Engpass ist eben fast immer der \u003Cstrong>Speicher, nicht die Rechenleistung\u003C\u002Fstrong>, und wenn CPU und GPU sich wie bei der DGX Spark 128 GB teilen, passt ein grosses Modell \u003Cstrong>am Stück\u003C\u002Fstrong> hinein, ohne ständig über PCIe nachzuladen. Das ist der Grund, warum eine speicherstarke Maschine grosse, quantisierte Modelle ruhig betreibt, an denen eine rechenstärkere, aber speicherärmere Karte scheitert. Die ganze Abwägung zwischen Speicher, Durchsatz und Kosten haben wir im Vergleich \u003Ca href=\"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu\">DGX Spark gegen Cloud-GPU\u003C\u002Fa> aufgemacht.\u003C\u002Fp>\n\n\u003Ch2>Quantisierung: kleiner machen, ohne dumm zu machen\u003C\u002Fh2>\n\n\u003Cp>Quantisierung speichert die Gewichte mit \u003Cstrong>weniger Bits\u003C\u002Fstrong> und ist damit der \u003Cstrong>stärkste Hebel\u003C\u002Fstrong> überhaupt, um ein gutes Modell auf bezahlbare Hardware zu bringen, meist deutlich klüger, als reflexhaft eine grössere GPU zu kaufen. Zur Orientierung: \u003Cstrong>8-Bit ist praktisch verlustfrei\u003C\u002Fstrong>, den Unterschied zu FP16 misst du eher im Benchmark als im Alltag. \u003Cstrong>4-Bit\u003C\u002Fstrong> ist für die allermeisten produktiven Fälle gut nutzbar, mit minimalen Einbussen. Darunter, bei \u003Cstrong>3-Bit oder 2-Bit\u003C\u002Fstrong>, wird es heikel, da bröckelt die Qualität sicht- und messbar. Die wichtigste Konsequenz daraus: Ein in 4-Bit quantisiertes \u003Cstrong>grosses\u003C\u002Fstrong> Modell schlägt fast immer ein kleineres Modell in voller Präzision bei gleichem Speicherbudget. \u003Cstrong>Mehr Parameter, grob komprimiert, sind oft besser\u003C\u002Fstrong> als wenige Parameter, fein aufgelöst.\u003C\u002Fp>\n\n\u003Cp>Welches Format du dabei wählst, hängt an deiner Inference-Engine, denn nicht jede Engine spricht jedes Format. \u003Cstrong>GPTQ\u003C\u002Fstrong> und \u003Cstrong>AWQ\u003C\u002Fstrong> sind Post-Training-Quantisierungen, die auf GPU-Inferenz optimiert sind; AWQ schützt gezielt die wichtigsten Gewichte und hält die Qualität bei 4-Bit gut. \u003Cstrong>GGUF\u003C\u002Fstrong> mit den sogenannten k-quants, etwa Q4\u003Cu>K\u003C\u002Fu>M, stammt aus dem llama.cpp-Umfeld, läuft auch auf \u003Cstrong>CPU und Apple Silicon\u003C\u002Fstrong> und ist der Standard für lokale Setups. \u003Cstrong>bitsandbytes\u003C\u002Fstrong> schliesslich bietet On-the-fly-Quantisierung direkt beim Laden über die gängigen Bibliotheken, ist dafür aber oft etwas langsamer als die vorquantisierten Formate.\u003C\u002Fp>\n\n\u003Ch2>Die Modellfamilien und ihr echtes Profil\u003C\u002Fh2>\n\n\u003Cp>Statt Versionsnummern, die in Monaten veralten, lohnt der Blick auf die Familien und ihren Charakter. Metas \u003Cstrong>Llama\u003C\u002Fstrong>-Familie ist der breite Default: das \u003Cstrong>grösste Ökosystem\u003C\u002Fstrong>, die beste Tool-Unterstützung, Varianten von klein bis sehr gross. Wenn du nicht weisst, wo du anfängst, ist eine Llama-Variante selten falsch; der Haken sitzt in der Lizenz, dazu gleich mehr. Die \u003Cstrong>Qwen\u003C\u002Fstrong>-Familie glänzt bei \u003Cstrong>mehrsprachigen Aufgaben und beim Coding\u003C\u002Fstrong> und bietet oft ein hervorragendes Verhältnis von Grösse zu Leistung, viele Varianten stehen unter dem bequemen \u003Cstrong>Apache-2.0\u003C\u002Fstrong>. Für produktive Fälle holt ein mittelgrosses Qwen häufig mehr heraus als ein grösseres Modell einer anderen Familie. \u003Cstrong>Mistrals\u003C\u002Fstrong> dichte Modelle sind kompakt und effizient, spannender aber ist das \u003Cstrong>MoE-Prinzip\u003C\u002Fstrong> (Mixture of Experts) der Mixtral-Linie: Das Modell hat viele totale Parameter, aktiviert pro Token aber nur einen Bruchteil davon. Du brauchst also den \u003Cstrong>Speicher für alle Parameter\u003C\u002Fstrong>, zahlst bei der Rechenzeit jedoch \u003Cstrong>nur für die aktiven\u003C\u002Fstrong>, und bekommst praktisch Qualität nahe an einem grossen dichten Modell bei deutlich höherem Durchsatz, wenn der Speicher reicht. Und Googles \u003Cstrong>Gemma\u003C\u002Fstrong>-Familie zielt auf \u003Cstrong>kleine, effiziente Modelle\u003C\u002Fstrong>, die auch auf bescheidener oder edge-naher Hardware laufen, ein günstiger Default für einfache, klar umrissene Aufgaben.\u003C\u002Fp>\n\n\u003Cp>Quer zu allen Familien laufen drei Unterscheidungen, die wichtiger sind als der Name. Eine \u003Cstrong>Base\u003C\u002Fstrong>-Variante ist roh und sagt nur das nächste Token voraus; für Anwendungen willst du fast immer die \u003Cstrong>Instruct- oder Chat-Variante\u003C\u002Fstrong>, die auf Anweisungsbefolgung trainiert ist. \u003Cstrong>Reasoning\u003C\u002Fstrong>-Varianten „denken“ vor der Antwort in Zwischenschritten und sind stark bei Logik und Mathematik, dafür langsamer und teurer pro Antwort. Und prüf das \u003Cstrong>Kontextfenster\u003C\u002Fstrong>, bevor du dich festlegst: Ein Modell mit 8K Kontext sprengt deine RAG-Pipeline, sobald deine Dokumente länger sind.\u003C\u002Fp>\n\n\u003Ch2>Vom Modell zur Aufgabe\u003C\u002Fh2>\n\n\u003Cp>Definiere die Aufgabe eng, dann ergibt sich die Grösse fast von selbst. Für \u003Cstrong>Extraktion und Klassifikation\u003C\u002Fstrong>, also strukturierte Daten aus Text ziehen, Tickets einsortieren, Sentiment bestimmen, reicht ein \u003Cstrong>kleines Modell mit 7B oder 8B\u003C\u002Fstrong>, gern quantisiert, zuverlässig aus; ein grosses Modell ist hier teure Verschwendung ohne messbaren Mehrwert. Bei \u003Cstrong>RAG und Q&A\u003C\u002Fstrong> über deine Wissensbasis zählen zwei Dinge: ein ausreichend \u003Cstrong>langes Kontextfenster\u003C\u002Fstrong>, damit die abgerufenen Passagen hineinpassen, und gutes \u003Cstrong>Instruction-Following\u003C\u002Fstrong>, damit das Modell bei der Quelle bleibt statt zu fabulieren. Ein gut gewähltes mittelgrosses Instruct-Modell genügt meist, und die Qualität deiner Retrieval-Pipeline entscheidet oft mehr als die letzten Parameter-Milliarden. Für \u003Cstrong>Codegenerierung\u003C\u002Fstrong> schlagen \u003Cstrong>code-spezialisierte Modelle\u003C\u002Fstrong> generische gleicher Grösse deutlich; hier lohnt ein mittleres bis grosses, auf Code trainiertes Modell mit langem Kontext, damit es ganze Dateien überblickt. Für flüssigen \u003Cstrong>Dialog\u003C\u002Fstrong> reicht ein solides Instruct-Modell mittlerer Grösse, und nur für echtes mehrstufiges \u003Cstrong>Reasoning\u003C\u002Fstrong>, also komplexe Logik, Mathematik, verschachtelte Planung, lohnt der Sprung zu grösseren oder dedizierten Reasoning-Modellen. Aber wirklich nur dann, denn für eine simple Klassifikation ist ein Reasoning-Modell langsam und teuer ohne Gegenwert.\u003C\u002Fp>\n\n\u003Ch2>Lizenz prüfen, bevor du baust\u003C\u002Fh2>\n\n\u003Cp>\u003Cstrong>„Offen“ heisst nicht automatisch „frei für jeden Zweck“\u003C\u002Fstrong>, und das ist kein Detail für die Rechtsabteilung am Schluss, sondern eine \u003Cstrong>Vorab-Entscheidung\u003C\u002Fstrong>. Grob gibt es drei Lager. \u003Cstrong>Apache-2.0\u003C\u002Fstrong> und ähnlich permissive Lizenzen sind der bequeme Fall: kommerziell nutzbar, kaum Auflagen, viele Qwen- und Mistral-Modelle liegen hier. Die \u003Cstrong>Llama Community License\u003C\u002Fstrong> ist grosszügig, aber bedingt; sie knüpft Auflagen an \u003Cstrong>sehr grosse Deployments\u003C\u002Fstrong>, etwa eine Nutzerschwelle, ab der du eine gesonderte Erlaubnis brauchst, dazu ein paar Namens- und Nutzungsklauseln. Für die meisten ist das irrelevant, für ein Produkt mit Millionen Nutzern nicht. Und \u003Cstrong>nicht-kommerzielle Lizenzen\u003C\u002Fstrong>, etwa research-only, verbieten den produktiven Einsatz schlicht; solche Modelle sind super zum Prototyping und gehören trotzdem nicht in dein Produkt. Prüf das, \u003Cstrong>bevor\u003C\u002Fstrong> du Architektur und Prompts um ein Modell herum baust, denn ein Lizenzwechsel im Nachhinein ist teuer.\u003C\u002Fp>\n\n\u003Ch2>Eine pragmatische Auswahlstrategie\u003C\u002Fh2>\n\n\u003Cp>Aus alldem folgt kein Orakel, sondern eine \u003Cstrong>Iteration\u003C\u002Fstrong>. Statt vorab das vermeintlich beste Modell zu erraten, taste dich in vier Schritten heran:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>Klein starten.\u003C\u002Fstrong> Nimm das kleinste Modell, das die Aufgabe plausibel lösen könnte.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>An eigenen Daten messen.\u003C\u002Fstrong> Bau dir ein kleines Eval-Set aus echten Fällen mit erwarteten Ergebnissen und miss daran, nicht an fremden Benchmarks. Dein Use-Case ist nicht das Leaderboard.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Nur bei Bedarf hoch.\u003C\u002Fstrong> Steig erst dann eine Stufe höher, wenn das Eval-Set einen konkreten Mangel zeigt.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Quantisierung vor GPU-Upgrade.\u003C\u002Fstrong> Bevor du in mehr Speicher investierst, prüf, ob ein quantisiertes grösseres Modell auf der vorhandenen Hardware reicht.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Die Modellwahl ist damit der \u003Cstrong>Anfang, nicht das Ziel\u003C\u002Fstrong>. Danach kommen Engine, Quantisierungsformat, Hardware und der laufende Betrieb, und die Frage, ob das Ganze die Schweiz verlässt. Wenn du ein passendes Modell auf souveräner Infrastruktur betreiben willst, ohne den Stack selbst zu pflegen, ist \u003Ca href=\"\u002Fde\u002Fmanaged-inference\">Managed Inference\u003C\u002Fa> der direkte Weg. Und wenn du unsicher bist, welches Modell für deinen Fall reicht: \u003Cstrong>Wir testen zwei, drei Kandidaten an deinen echten Daten\u003C\u002Fstrong> und sagen dir ungeschönt, welcher die Aufgabe löst, oft ist es ein kleinerer, als du denkst.\u003C\u002Fp>\n","Welches offene Modell für welche Aufgabe? Llama, Qwen, Mistral & Co.","Nicht das grösste Modell gewinnt, sondern das passende. Wie du offene Modelle nach Aufgabe, Speicherbedarf und Lizenz auswählst, statt Benchmarks hinterherzulaufen.","2026-06-30T00:00:00Z","bestof",{"id":24,"slug":25,"path":26,"page_type":27,"published":28,"type":29},676,"managed-inference","\u002Fde\u002Fmanaged-inference","service",true,"Cms::Page",[],[],[33,36,39],{"title":34,"href":35},"Preise","\u002Fde\u002Fpreise",{"title":37,"href":38},"Wissen","\u002Fde\u002Fwissen",{"title":40,"href":41},"Über Twentyone","\u002Fde\u002Fueber-uns",[43,47,51,54],{"title":44,"href":45,"description":46},"DGX Spark mieten","\u002Fde\u002Fdgx-spark","Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":48,"href":49,"description":50},"Bare Metal GPU","\u002Fde\u002Fbare-metal","DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":52,"href":26,"description":53},"Managed Inference","LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":55,"href":56,"description":57},"Hermes Agents","\u002Fde\u002Fagents","Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben.",[59,66],{"title":60,"links":61},"Leistungen",[62,63,64,65],{"title":44,"href":45},{"title":48,"href":49},{"title":52,"href":26},{"title":55,"href":56},{"title":67,"links":68},"Unternehmen",[69,70,71,72],{"title":40,"href":41},{"title":37,"href":38},{"title":34,"href":35},{"title":73,"href":74},"Kontakt","\u002Fde\u002Fkontakt",[76,85,96,106,114,122,129,136,142,148,154,160,166,172,178,180,186,193],{"path":77,"slug":78,"title":79,"summary":80,"image":14,"publication_date":81,"big5_category":82,"primary_hub":14,"cluster":14,"pillar":14,"hubs":83},"\u002Fde\u002Fwissen\u002Fazure-openai-bedrock-alternative-schweiz","azure-openai-bedrock-alternative-schweiz","Souveräne Inferenz gegen Azure OpenAI und AWS Bedrock: was sich im Alltag ändert","Azure OpenAI und AWS Bedrock gegen einen souverän betriebenen Endpoint: warum der Schweizer Serverstandort der Hyperscaler das Kernproblem nicht löst und was der Unterschied im Betrieb bedeutet.","2026-07-13T00:00:00Z","comparisons",[84],{"slug":25,"title":52},{"path":86,"slug":87,"title":88,"summary":89,"image":14,"publication_date":81,"big5_category":22,"primary_hub":14,"cluster":14,"pillar":14,"hubs":90},"\u002Fde\u002Fwissen\u002Fbeste-gpu-llm-inferenz","beste-gpu-llm-inferenz","Die beste GPU für LLM-Inferenz: DGX Spark, H100, L40S und RTX im Vergleich","Welche GPU für eigene Inferenz? DGX Spark, H100, L40S und RTX 4090 nach dem, was zählt: wie viel Modell hineinpasst, wie viel Durchsatz herauskommt und was der Monat kostet.",[91,94],{"slug":92,"title":93},"bare-metal","Bare Metal GPU mit Root-Zugriff",{"slug":95,"title":44},"dgx-spark",{"path":97,"slug":98,"title":99,"summary":100,"image":14,"publication_date":81,"big5_category":101,"primary_hub":14,"cluster":14,"pillar":14,"hubs":102},"\u002Fde\u002Fwissen\u002Fhermes-agent-erfahrungsbericht","hermes-agent-erfahrungsbericht","Hermes-Agent im Realbetrieb: was ein souveräner Agent wirklich leistet","Ein Erfahrungsbericht statt Hochglanzprospekt: wie sich ein souverän betriebener Hermes-Agent im täglichen Einsatz verhält, wo er glänzt und wo die Begleitung anfängt.","reviews",[103],{"slug":104,"title":105},"agents","Hermes Agents as a Service",{"path":107,"slug":108,"title":109,"summary":110,"image":14,"publication_date":81,"big5_category":111,"primary_hub":14,"cluster":14,"pillar":14,"hubs":112},"\u002Fde\u002Fwissen\u002Fki-regulierte-daten-schweiz","ki-regulierte-daten-schweiz","KI mit regulierten Daten: LLMs nutzen, ohne dass die Daten die Schweiz verlassen","Für Branchen, in denen Daten das Land nicht verlassen dürfen: was revDSG, Berufsgeheimnis und der CLOUD Act für KI-Projekte bedeuten, und wie souveräne Inferenz den Rahmen einhält.","problems",[113],{"slug":25,"title":52},{"path":115,"slug":116,"title":117,"summary":118,"image":14,"publication_date":81,"big5_category":119,"primary_hub":14,"cluster":14,"pillar":14,"hubs":120},"\u002Fde\u002Fwissen\u002Fopenai-api-kosten-vs-eigener-endpoint","openai-api-kosten-vs-eigener-endpoint","Ab welchem Volumen sich ein eigener Endpoint gegen die API rechnet","Die Pay-per-Token-API ist günstig, bis sie es nicht mehr ist. Wo genau der Break-even zu einem reservierten Endpoint mit fester Monatspauschale liegt, an einem konkreten Beispiel durchgerechnet.","cost",[121],{"slug":25,"title":52},{"path":123,"slug":124,"title":125,"summary":126,"image":14,"publication_date":127,"big5_category":82,"primary_hub":14,"cluster":14,"pillar":14,"hubs":128},"\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt","fine-tuning-rag-prompt","Fine-Tuning, RAG oder besserer Prompt? Die klare Entscheidungsregel","Fine-Tuning ist meistens nicht die Antwort auf „das Modell kennt unsere Daten nicht“. Wann Prompting, RAG oder Fine-Tuning wirklich das richtige Werkzeug sind und wie du die Eskalationsleiter korrekt durchläufst.","2026-07-07T00:00:00Z",[],{"path":130,"slug":131,"title":132,"summary":133,"image":14,"publication_date":127,"big5_category":134,"primary_hub":14,"cluster":14,"pillar":14,"hubs":135},"\u002Fde\u002Fwissen\u002Fopenai-api-migration","openai-api-migration","Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis","Der Umstieg von OpenAI oder Anthropic auf ein selbst betriebenes offenes Modell in der Schweiz sieht dank OpenAI-kompatibler Endpoints nach einer Ein-Zeilen-Änderung aus, ist aber doch mehr. Wo Prompts, Tool-Calling und Feature-Lücken zur Stolperfalle werden.","how-to",[],{"path":137,"slug":138,"title":139,"summary":140,"image":14,"publication_date":127,"big5_category":111,"primary_hub":14,"cluster":14,"pillar":14,"hubs":141},"\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf","quantisierung-int4-int8-awq-gptq-gguf","Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Wir zeigen dir ungeschönt, was Quantisierung wirklich kostet und wo GPTQ, AWQ, GGUF und bitsandbytes hingehören.",[],{"path":143,"slug":144,"title":145,"summary":146,"image":14,"publication_date":127,"big5_category":111,"primary_hub":14,"cluster":14,"pillar":14,"hubs":147},"\u002Fde\u002Fwissen\u002Frag-schlechte-antworten","rag-schlechte-antworten","RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt","Die meisten RAG-Systeme scheitern nicht am Sprachmodell, sondern am Retrieval davor. Wir zeigen die häufigsten Fehlerquellen bei Chunking, Embeddings und Retrieval-Strategie sowie, wie du Retrieval- und Generationsfehler sauber auseinanderhältst.",[],{"path":149,"slug":150,"title":151,"summary":152,"image":14,"publication_date":127,"big5_category":134,"primary_hub":14,"cluster":14,"pillar":14,"hubs":153},"\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen","vram-modell-gpu-berechnen","Welches Modell passt auf welche GPU? VRAM richtig berechnen","Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.",[],{"path":155,"slug":156,"title":157,"summary":158,"image":14,"publication_date":21,"big5_category":111,"primary_hub":14,"cluster":14,"pillar":14,"hubs":159},"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint","agent-oder-endpoint","Braucht ihr wirklich einen Agent oder reicht ein Endpoint?","Agenten sind im Trend, aber oft die teurere und fragilere Lösung für ein Problem, das ein einfacher Endpoint löst. Wann sich der Aufwand lohnt und wann nicht.",[],{"path":161,"slug":162,"title":163,"summary":164,"image":14,"publication_date":21,"big5_category":111,"primary_hub":14,"cluster":14,"pillar":14,"hubs":165},"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das","datenhoheit-was-bedeutet-das","Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen","Datenhoheit ist mehr als ein Hosting-Standort. Was rechtlich, technisch und vertraglich dahintersteckt, und welche Fragen du jedem AI-Anbieter stellen solltest.",[],{"path":167,"slug":168,"title":169,"summary":170,"image":14,"publication_date":21,"big5_category":101,"primary_hub":14,"cluster":14,"pillar":14,"hubs":171},"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann","Kein Datenblatt, sondern ein Erfahrungsbericht. Wo die DGX Spark im täglichen Betrieb glänzt, wo ihre Grenzen liegen und für wen sich die Maschine lohnt.",[],{"path":173,"slug":174,"title":175,"summary":176,"image":14,"publication_date":21,"big5_category":134,"primary_hub":14,"cluster":14,"pillar":14,"hubs":177},"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","Eigenen LLM Endpoint aufsetzen: von der GPU zum ersten Token","Ein realistischer Weg vom blanken Server zum produktiven Inferenz-Endpoint. Die Schritte, die Reihenfolge und die Stolpersteine, die zwischen „läuft lokal“ und „läuft produktiv“ liegen.",[],{"path":6,"slug":7,"title":19,"summary":20,"image":14,"publication_date":21,"big5_category":22,"primary_hub":14,"cluster":14,"pillar":14,"hubs":179},[],{"path":181,"slug":182,"title":183,"summary":184,"image":14,"publication_date":21,"big5_category":82,"primary_hub":14,"cluster":14,"pillar":14,"hubs":185},"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","vLLM, Ollama oder TGI: welche Inference Engine für welchen Fall","Die Engine entscheidet über Durchsatz, Latenz und Betriebsaufwand. Ein nüchterner Vergleich der drei verbreitetsten Optionen, inklusive der Fälle, in denen die einfache Lösung gewinnt.",[],{"path":187,"slug":188,"title":189,"summary":190,"image":14,"publication_date":191,"big5_category":82,"primary_hub":14,"cluster":14,"pillar":14,"hubs":192},"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu","dgx-spark-vs-cloud-gpu","DGX Spark gegen Cloud-GPU: wann sich eigene Hardware lohnt","Unified Memory gegen rohen Durchsatz, Schweizer Hardware gegen Hyperscaler. Ein nüchterner Vergleich, inklusive der Fälle, in denen die Cloud gewinnt.","2026-06-18T00:00:00Z",[],{"path":194,"slug":195,"title":196,"summary":197,"image":14,"publication_date":191,"big5_category":119,"primary_hub":14,"cluster":14,"pillar":14,"hubs":198},"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten","llm-selbst-betreiben-kosten","Was kostet es, ein LLM selbst zu betreiben?","Die nüchterne Rechnung hinter eigenen LLM-Endpoints: Hardware, Betrieb und der Punkt, ab dem sich Selbermachen wirklich lohnt.",[],[]]