[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-offering-angebot-leistungen":3,"reazon-offering-angebot-zielgruppen":20,"reazon-angebot-subnav":21,"reazon-mainnav":22,"reazon-page-\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht":32,"reazon-footernav":59,"reazon-articles-\u002Fde\u002Fwissen":76},[4,8,12,16],{"title":5,"href":6,"description":7},"DGX Spark mieten","\u002Fde\u002Fdgx-spark","Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":9,"href":10,"description":11},"Bare Metal GPU","\u002Fde\u002Fbare-metal","DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":13,"href":14,"description":15},"Managed Inference","\u002Fde\u002Fmanaged-inference","LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":17,"href":18,"description":19},"Hermes Agents","\u002Fde\u002Fagents","Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben.",[],[],[23,26,29],{"title":24,"href":25},"Preise","\u002Fde\u002Fpreise",{"title":27,"href":28},"Wissen","\u002Fde\u002Fwissen",{"title":30,"href":31},"Über Twentyone","\u002Fde\u002Fueber-uns",{"data":33},{"id":34,"path":35,"slug":36,"published_at":37,"page_type":38,"no_index":41,"fields":42,"blocks":58},1331,"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","2026-07-07T12:09:44.660Z",{"identifier":39,"name":40},"article","Blog Post",false,{"title":43,"summary":44,"publication_date":45,"big5_category":46,"primary_service":47,"related_articles":53,"meta_title":54,"meta_description":55,"body":56,"body_html":57},"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.","2026-06-30T00:00:00Z","reviews",{"id":48,"slug":49,"path":6,"page_type":50,"published":51,"type":52},674,"dgx-spark","service",true,"Cms::Page",null,"DGX Spark im Praxistest: Erfahrungen nach drei Monaten | Twentyone","Nüchterner Erfahrungsbericht zur DGX Spark: 128 GB Unified Memory im Alltag, wo sie glänzt, wo ihre Grenzen liegen und für welche Workloads sie sich wirklich lohnt.","## Der erste Tag im Rack\n\nAls die Maschine zum ersten Mal bei uns im Rack stand, war das auffälligste an ihr, wie **unauffällig** sie war. Kein dröhnendes Server-Chassis, kein Rack voller GPUs, sondern ein kompaktes Gerät, das eher nach kräftigem Desktop aussieht als nach Rechenzentrum. Eine knappe Stunde später lief das erste **70-Milliarden-Parameter-Modell** darauf, am Stück, **ohne Sharding**, ohne dass wir irgendetwas über mehrere Karten verteilen mussten. Genau dieser Moment fasst zusammen, worum es bei der DGX Spark geht. Datenblätter erzählen, was eine Maschine können soll; der Alltag erzählt, was sie wirklich tut. Wir betreiben sie seit Monaten für eigene und für Kunden-Workloads, und das hier ist die **ungeschönte Version**, inklusive der Stellen, an denen sie das falsche Werkzeug ist.\n\n## Was die Maschine technisch wirklich ist\n\nDie meisten Missverständnisse über die DGX Spark entstehen, weil sie mit der **falschen Erwartung** gekauft wird. Im Kern steckt ein **GB10-Superchip** aus der **Grace-Blackwell-Klasse**: eine Blackwell-GPU und ein Grace-ARM-CPU-Teil auf einem Package, gekoppelt über einen schnellen internen Link. Das Besondere sind die **128 GB Unified Memory** auf **LPDDR5x**-Basis, die sich CPU und GPU physisch teilen. Es gibt keinen getrennten VRAM-Pool, in den du Daten erst über PCIe schaufeln musst, beide Recheneinheiten sehen denselben Speicher. Für die Praxis heisst das: Ein grosses Modell liegt **am Stück** im Speicher, und du verbringst keine Zeit damit, Gewichte zwischen Host- und GPU-RAM hin- und herzuschieben.\n\nHier liegt aber auch der Punkt, den man verstehen muss, sonst kauft man falsch. LPDDR5x liefert **viel Kapazität**, aber **deutlich weniger Speicherbandbreite** als der **HBM3**-Speicher einer H100. Die H100 hat weniger Kapazität, dafür ein Vielfaches an Bandbreite. Die Spark tauscht also bewusst **Tempo pro Byte gegen Menge an Bytes**, keine Schwäche im Design, sondern eine Entscheidung. Ob sie für dich richtig ist, hängt vollständig daran, ob dein Workload **Kapazität oder Bandbreite** braucht.\n\nWarum das bei LLM-Inferenz so zentral ist, sieht man, wenn man die zwei Phasen auseinanderhält. Das **Prefill**, bei dem der Prompt eingelesen wird, ist rechenlastig und parallel. Der **Decode** dagegen, bei dem Token für Token erzeugt wird, ist **speicherbandbreiten-limitiert**: Für jedes einzelne Token müssen die relevanten Modellgewichte aus dem Speicher gelesen werden. Die **Tokens pro Sekunde** im Decode hängen damit primär an der Bandbreite, nicht an der rohen Rechenleistung. Deshalb spürst du den **HBM-Vorteil der H100** bei kleinen Modellen sofort als höhere Tokens\u002Fs, und deshalb relativiert sich dieser Vorteil, sobald das Modell so gross wird, dass es auf der H100 gar nicht mehr am Stück in den Speicher passt.\n\n## Das Speicher-Argument, durchgerechnet\n\nDie **128 GB** sind der eigentliche Grund, die Maschine überhaupt in Betracht zu ziehen, und es lohnt sich, das in Modellgrössen zu übersetzen. Als grobe Faustregel braucht ein Modell pro Milliarde Parameter etwa **2 GB in 16-bit**, rund **1 GB in 8-bit** und etwa **0,5 GB in 4-bit**, dazu kommt der KV-Cache für den Kontext. Ein **70B-Modell** liegt damit in 4-bit bei grob **35 bis 40 GB** und in 8-bit bei grob **70 GB**, beides passt mit Reserve für Kontext und Batching. Selbst sehr grosse Modelle **jenseits von 100B** werden quantisiert handhabbar, solange du bei der Präzision Kompromisse eingehst. Du hast also echten Spielraum, mit Modellgrösse und Quantisierung zu spielen, ohne sofort an eine Wand zu laufen.\n\nDieselbe Rechnung auf einer klassischen Karte erzählt die Gegengeschichte. Auf einer **24- oder 48-GB-Karte** ist bei einem 70B-Modell schon in moderater Quantisierung Schluss: Du musst es über mehrere GPUs **sharden**, mit Tensor-Parallelismus, abgestimmten Treibern und der entsprechenden Verkabelung. Selbst eine **80-GB-H100** trägt ein 70B-Modell zwar, lässt aber bei grösseren Modellen oder grosszügigem KV-Cache wenig Luft. Die Spark ersetzt diese **Multi-GPU-Akrobatik** durch simple Kapazität: ein Gerät, ein Speicher, kein Sharding. Dieser **Wegfall an Komplexität** ist im Alltag mehr wert, als das Datenblatt vermuten lässt.\n\n## Wo die Maschine im Betrieb glänzt\n\nNach Wochen Dauerbetrieb kristallisieren sich klare Stärken heraus. Die Zahlen hier sind **Grössenordnungen** aus unserem Betrieb, keine zertifizierten Benchmarks. Der grösste praktische Gewinn ist banal und wichtig zugleich: Du lädst ein grosses Modell, und es läuft, **ohne es zu zerschneiden**, ohne Parallelismus-Konfiguration, ohne abgestimmte Multi-GPU-Topologie. Ein anderes Modell ausprobieren heisst, ein anderes Modell laden, nicht die halbe Infrastruktur umbauen. Bei uns hat das die Zeit zwischen „wir wollen Modell X testen“ und „Modell X antwortet“ **von Stunden auf Minuten** gedrückt.\n\nDamit hängt ein **unterschätzter zweiter Vorteil** zusammen. Weil grosse Modelle am Stück passen, können Entwickler lokal gegen **dasselbe Modell** arbeiten, das später produktiv läuft, nicht gegen ein geschrumpftes Surrogat, das sich im Ernstfall anders verhält. Das verkürzt die Schleife zwischen Idee, Test und Deployment spürbar und nimmt eine ganze Klasse von **„lief lokal, brach in Prod“**-Überraschungen heraus. Für Teams, die Prompts und Pipelines iterieren, ist das oft mehr wert als ein paar Tokens pro Sekunde mehr.\n\nUnd dann ist da die **Ruhe im Dauerlauf**, die uns am meisten überrascht hat. Im Vergleich zu einem rohen Multi-GPU-H100-Setup ist die Spark **sparsam und unaufgeregt**: Sie zieht in der Grössenordnung eines **kräftigen Desktops** statt eines Server-Racks, bleibt thermisch und akustisch zurückhaltend und lässt sich entsprechend unkompliziert platzieren. Über die Laufzeit war die **Stabilität** genau das, was man sich wünscht, sie läuft, ohne dass man nachts daran denken muss. Für konstante Inferenzlast über Wochen ist das die ruhigere Wahl, auch bei der Stromrechnung.\n\n## Wo die Grenzen liegen\n\nOffenheit heisst, die Schwächen genauso klar zu benennen, denn niemand sollte die Maschine für etwas einsetzen, wofür sie nicht gebaut ist. Das Wichtigste vorweg: Die Spark ist **kein Trainings-Kraftwerk**. Geht es um **Fine-Tuning** grosser Modelle oder um Training mit hohem Durchsatz, zeigt sie ihre Grenze, weil Training sowohl rechen- als auch bandbreitenhungrig ist und genau die **Speicherbandbreite** hier der Flaschenhals gegenüber HBM3 wird. Für ernsthafte Trainingslast nimmst du eine [H100 bare metal](\u002Fde\u002Fbare-metal) oder mehrere davon, die spielen in einer anderen Liga. Wer trainieren will, ist auf der Spark am falschen Profil.\n\nAuch beim Durchsatz gibt es eine **Obergrenze**. Bei sehr vielen gleichzeitigen Nutzern und hohem aggregiertem Token-Durchsatz stösst die Maschine früher an Grenzen als ein auf Durchsatz getrimmtes Multi-GPU-Setup, weil sich die **Bandbreite, die den Decode limitiert**, auf alle parallelen Anfragen aufteilt. Für die meisten produktiven Lasten reicht das komfortabel, für **extreme Skalierung** mit Tausenden gleichzeitigen Streams brauchst du mehrere Maschinen oder echte HBM-Hardware. Und schliesslich der klarste Punkt: Wenn dein Modell **klein genug** ist, um ohnehin bequem in den HBM einer H100 zu passen, gibt dir die Spark keinen Vorteil, im Gegenteil, die H100 liefert dank höherer Bandbreite **mehr Tokens\u002Fs**. Der Kapazitätsvorteil verpufft, sobald Kapazität nicht das Problem ist. Ihre Stärke ist die **Tiefe in einer Disziplin**, nicht die Breite über alle.\n\n## Für wen sich die Maschine lohnt\n\nAus diesem Profil ergibt sich ziemlich klar, wer profitiert. Der **ideale Fall**: Du betreibst ein grosses, offenes Modell als **stabilen Inferenz-Endpoint** mit konstanter Last, willst die **Kosten planen** und deine **Daten in der Schweiz** halten, und du schätzt es, ein grosses Modell ohne Sharding-Aufwand zu fahren und bei Bedarf zu wechseln. Genau dafür ist die Maschine gebaut, und genau da spielt sie ihren Vorteil voll aus.\n\nWann du woanders besser aufgehoben bist, lässt sich knapp zusammenfassen:\n\n- **Training oder Fine-Tuning grosser Modelle** → eine [H100 bare metal](\u002Fde\u002Fbare-metal) mit HBM-Bandbreite.\n- **Extreme Durchsatzspitzen über sehr viele parallele Nutzer** → mehrere Maschinen oder dedizierte HBM-Hardware.\n- **Kurze, unvorhersehbare Lastpeaks** → die elastische Cloud, die du minutenweise hoch- und runterfährst.\n\nDen ganzen Abwägungsraum, inklusive Datenhoheit und Kosten, haben wir im Vergleich [DGX Spark gegen Cloud-GPU](\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu) aufgemacht.\n\n## Grosse Modelle ruhig und planbar betreiben\n\nDie DGX Spark macht eine Sache sehr gut: ein **grosses Modell** ruhig, **planbar** und **souverän in der Schweiz** betreiben, ohne Multi-GPU-Zirkus. Sie ist bewusst **kein Alleskönner**: Sie tauscht **Bandbreite gegen Kapazität**, und ob das für dich aufgeht, entscheidet dein Workload, nicht das Marketing. Für konstante Inferenz grosser, offener Modelle ist sie die unaufgeregteste Wahl, die wir kennen; für **Training und extreme Durchsatzspitzen** ist sie es nicht.\n\nWir mieten sie **monatsweise als planbare Pauschale**, sodass du den Vorteil **ohne Kapitalbindung** und ohne Veralterungsrisiko bekommst, die [DGX Spark](\u002Fde\u002Fdgx-spark) im Detail. Im Zweifel **rechnen wir deinen konkreten Fall durch** und sagen offen, ob die Spark, eine [H100 bare metal](\u002Fde\u002Fbare-metal) oder die Cloud die richtige Wahl ist.","\u003Ch2>Der erste Tag im Rack\u003C\u002Fh2>\n\n\u003Cp>Als die Maschine zum ersten Mal bei uns im Rack stand, war das auffälligste an ihr, wie \u003Cstrong>unauffällig\u003C\u002Fstrong> sie war. Kein dröhnendes Server-Chassis, kein Rack voller GPUs, sondern ein kompaktes Gerät, das eher nach kräftigem Desktop aussieht als nach Rechenzentrum. Eine knappe Stunde später lief das erste \u003Cstrong>70-Milliarden-Parameter-Modell\u003C\u002Fstrong> darauf, am Stück, \u003Cstrong>ohne Sharding\u003C\u002Fstrong>, ohne dass wir irgendetwas über mehrere Karten verteilen mussten. Genau dieser Moment fasst zusammen, worum es bei der DGX Spark geht. Datenblätter erzählen, was eine Maschine können soll; der Alltag erzählt, was sie wirklich tut. Wir betreiben sie seit Monaten für eigene und für Kunden-Workloads, und das hier ist die \u003Cstrong>ungeschönte Version\u003C\u002Fstrong>, inklusive der Stellen, an denen sie das falsche Werkzeug ist.\u003C\u002Fp>\n\n\u003Ch2>Was die Maschine technisch wirklich ist\u003C\u002Fh2>\n\n\u003Cp>Die meisten Missverständnisse über die DGX Spark entstehen, weil sie mit der \u003Cstrong>falschen Erwartung\u003C\u002Fstrong> gekauft wird. Im Kern steckt ein \u003Cstrong>GB10-Superchip\u003C\u002Fstrong> aus der \u003Cstrong>Grace-Blackwell-Klasse\u003C\u002Fstrong>: eine Blackwell-GPU und ein Grace-ARM-CPU-Teil auf einem Package, gekoppelt über einen schnellen internen Link. Das Besondere sind die \u003Cstrong>128 GB Unified Memory\u003C\u002Fstrong> auf \u003Cstrong>LPDDR5x\u003C\u002Fstrong>-Basis, die sich CPU und GPU physisch teilen. Es gibt keinen getrennten VRAM-Pool, in den du Daten erst über PCIe schaufeln musst, beide Recheneinheiten sehen denselben Speicher. Für die Praxis heisst das: Ein grosses Modell liegt \u003Cstrong>am Stück\u003C\u002Fstrong> im Speicher, und du verbringst keine Zeit damit, Gewichte zwischen Host- und GPU-RAM hin- und herzuschieben.\u003C\u002Fp>\n\n\u003Cp>Hier liegt aber auch der Punkt, den man verstehen muss, sonst kauft man falsch. LPDDR5x liefert \u003Cstrong>viel Kapazität\u003C\u002Fstrong>, aber \u003Cstrong>deutlich weniger Speicherbandbreite\u003C\u002Fstrong> als der \u003Cstrong>HBM3\u003C\u002Fstrong>-Speicher einer H100. Die H100 hat weniger Kapazität, dafür ein Vielfaches an Bandbreite. Die Spark tauscht also bewusst \u003Cstrong>Tempo pro Byte gegen Menge an Bytes\u003C\u002Fstrong>, keine Schwäche im Design, sondern eine Entscheidung. Ob sie für dich richtig ist, hängt vollständig daran, ob dein Workload \u003Cstrong>Kapazität oder Bandbreite\u003C\u002Fstrong> braucht.\u003C\u002Fp>\n\n\u003Cp>Warum das bei LLM-Inferenz so zentral ist, sieht man, wenn man die zwei Phasen auseinanderhält. Das \u003Cstrong>Prefill\u003C\u002Fstrong>, bei dem der Prompt eingelesen wird, ist rechenlastig und parallel. Der \u003Cstrong>Decode\u003C\u002Fstrong> dagegen, bei dem Token für Token erzeugt wird, ist \u003Cstrong>speicherbandbreiten-limitiert\u003C\u002Fstrong>: Für jedes einzelne Token müssen die relevanten Modellgewichte aus dem Speicher gelesen werden. Die \u003Cstrong>Tokens pro Sekunde\u003C\u002Fstrong> im Decode hängen damit primär an der Bandbreite, nicht an der rohen Rechenleistung. Deshalb spürst du den \u003Cstrong>HBM-Vorteil der H100\u003C\u002Fstrong> bei kleinen Modellen sofort als höhere Tokens\u002Fs, und deshalb relativiert sich dieser Vorteil, sobald das Modell so gross wird, dass es auf der H100 gar nicht mehr am Stück in den Speicher passt.\u003C\u002Fp>\n\n\u003Ch2>Das Speicher-Argument, durchgerechnet\u003C\u002Fh2>\n\n\u003Cp>Die \u003Cstrong>128 GB\u003C\u002Fstrong> sind der eigentliche Grund, die Maschine überhaupt in Betracht zu ziehen, und es lohnt sich, das in Modellgrössen zu übersetzen. Als grobe Faustregel braucht ein Modell pro Milliarde Parameter etwa \u003Cstrong>2 GB in 16-bit\u003C\u002Fstrong>, rund \u003Cstrong>1 GB in 8-bit\u003C\u002Fstrong> und etwa \u003Cstrong>0,5 GB in 4-bit\u003C\u002Fstrong>, dazu kommt der KV-Cache für den Kontext. Ein \u003Cstrong>70B-Modell\u003C\u002Fstrong> liegt damit in 4-bit bei grob \u003Cstrong>35 bis 40 GB\u003C\u002Fstrong> und in 8-bit bei grob \u003Cstrong>70 GB\u003C\u002Fstrong>, beides passt mit Reserve für Kontext und Batching. Selbst sehr grosse Modelle \u003Cstrong>jenseits von 100B\u003C\u002Fstrong> werden quantisiert handhabbar, solange du bei der Präzision Kompromisse eingehst. Du hast also echten Spielraum, mit Modellgrösse und Quantisierung zu spielen, ohne sofort an eine Wand zu laufen.\u003C\u002Fp>\n\n\u003Cp>Dieselbe Rechnung auf einer klassischen Karte erzählt die Gegengeschichte. Auf einer \u003Cstrong>24- oder 48-GB-Karte\u003C\u002Fstrong> ist bei einem 70B-Modell schon in moderater Quantisierung Schluss: Du musst es über mehrere GPUs \u003Cstrong>sharden\u003C\u002Fstrong>, mit Tensor-Parallelismus, abgestimmten Treibern und der entsprechenden Verkabelung. Selbst eine \u003Cstrong>80-GB-H100\u003C\u002Fstrong> trägt ein 70B-Modell zwar, lässt aber bei grösseren Modellen oder grosszügigem KV-Cache wenig Luft. Die Spark ersetzt diese \u003Cstrong>Multi-GPU-Akrobatik\u003C\u002Fstrong> durch simple Kapazität: ein Gerät, ein Speicher, kein Sharding. Dieser \u003Cstrong>Wegfall an Komplexität\u003C\u002Fstrong> ist im Alltag mehr wert, als das Datenblatt vermuten lässt.\u003C\u002Fp>\n\n\u003Ch2>Wo die Maschine im Betrieb glänzt\u003C\u002Fh2>\n\n\u003Cp>Nach Wochen Dauerbetrieb kristallisieren sich klare Stärken heraus. Die Zahlen hier sind \u003Cstrong>Grössenordnungen\u003C\u002Fstrong> aus unserem Betrieb, keine zertifizierten Benchmarks. Der grösste praktische Gewinn ist banal und wichtig zugleich: Du lädst ein grosses Modell, und es läuft, \u003Cstrong>ohne es zu zerschneiden\u003C\u002Fstrong>, ohne Parallelismus-Konfiguration, ohne abgestimmte Multi-GPU-Topologie. Ein anderes Modell ausprobieren heisst, ein anderes Modell laden, nicht die halbe Infrastruktur umbauen. Bei uns hat das die Zeit zwischen „wir wollen Modell X testen“ und „Modell X antwortet“ \u003Cstrong>von Stunden auf Minuten\u003C\u002Fstrong> gedrückt.\u003C\u002Fp>\n\n\u003Cp>Damit hängt ein \u003Cstrong>unterschätzter zweiter Vorteil\u003C\u002Fstrong> zusammen. Weil grosse Modelle am Stück passen, können Entwickler lokal gegen \u003Cstrong>dasselbe Modell\u003C\u002Fstrong> arbeiten, das später produktiv läuft, nicht gegen ein geschrumpftes Surrogat, das sich im Ernstfall anders verhält. Das verkürzt die Schleife zwischen Idee, Test und Deployment spürbar und nimmt eine ganze Klasse von \u003Cstrong>„lief lokal, brach in Prod“\u003C\u002Fstrong>-Überraschungen heraus. Für Teams, die Prompts und Pipelines iterieren, ist das oft mehr wert als ein paar Tokens pro Sekunde mehr.\u003C\u002Fp>\n\n\u003Cp>Und dann ist da die \u003Cstrong>Ruhe im Dauerlauf\u003C\u002Fstrong>, die uns am meisten überrascht hat. Im Vergleich zu einem rohen Multi-GPU-H100-Setup ist die Spark \u003Cstrong>sparsam und unaufgeregt\u003C\u002Fstrong>: Sie zieht in der Grössenordnung eines \u003Cstrong>kräftigen Desktops\u003C\u002Fstrong> statt eines Server-Racks, bleibt thermisch und akustisch zurückhaltend und lässt sich entsprechend unkompliziert platzieren. Über die Laufzeit war die \u003Cstrong>Stabilität\u003C\u002Fstrong> genau das, was man sich wünscht, sie läuft, ohne dass man nachts daran denken muss. Für konstante Inferenzlast über Wochen ist das die ruhigere Wahl, auch bei der Stromrechnung.\u003C\u002Fp>\n\n\u003Ch2>Wo die Grenzen liegen\u003C\u002Fh2>\n\n\u003Cp>Offenheit heisst, die Schwächen genauso klar zu benennen, denn niemand sollte die Maschine für etwas einsetzen, wofür sie nicht gebaut ist. Das Wichtigste vorweg: Die Spark ist \u003Cstrong>kein Trainings-Kraftwerk\u003C\u002Fstrong>. Geht es um \u003Cstrong>Fine-Tuning\u003C\u002Fstrong> grosser Modelle oder um Training mit hohem Durchsatz, zeigt sie ihre Grenze, weil Training sowohl rechen- als auch bandbreitenhungrig ist und genau die \u003Cstrong>Speicherbandbreite\u003C\u002Fstrong> hier der Flaschenhals gegenüber HBM3 wird. Für ernsthafte Trainingslast nimmst du eine \u003Ca href=\"\u002Fde\u002Fbare-metal\">H100 bare metal\u003C\u002Fa> oder mehrere davon, die spielen in einer anderen Liga. Wer trainieren will, ist auf der Spark am falschen Profil.\u003C\u002Fp>\n\n\u003Cp>Auch beim Durchsatz gibt es eine \u003Cstrong>Obergrenze\u003C\u002Fstrong>. Bei sehr vielen gleichzeitigen Nutzern und hohem aggregiertem Token-Durchsatz stösst die Maschine früher an Grenzen als ein auf Durchsatz getrimmtes Multi-GPU-Setup, weil sich die \u003Cstrong>Bandbreite, die den Decode limitiert\u003C\u002Fstrong>, auf alle parallelen Anfragen aufteilt. Für die meisten produktiven Lasten reicht das komfortabel, für \u003Cstrong>extreme Skalierung\u003C\u002Fstrong> mit Tausenden gleichzeitigen Streams brauchst du mehrere Maschinen oder echte HBM-Hardware. Und schliesslich der klarste Punkt: Wenn dein Modell \u003Cstrong>klein genug\u003C\u002Fstrong> ist, um ohnehin bequem in den HBM einer H100 zu passen, gibt dir die Spark keinen Vorteil, im Gegenteil, die H100 liefert dank höherer Bandbreite \u003Cstrong>mehr Tokens\u002Fs\u003C\u002Fstrong>. Der Kapazitätsvorteil verpufft, sobald Kapazität nicht das Problem ist. Ihre Stärke ist die \u003Cstrong>Tiefe in einer Disziplin\u003C\u002Fstrong>, nicht die Breite über alle.\u003C\u002Fp>\n\n\u003Ch2>Für wen sich die Maschine lohnt\u003C\u002Fh2>\n\n\u003Cp>Aus diesem Profil ergibt sich ziemlich klar, wer profitiert. Der \u003Cstrong>ideale Fall\u003C\u002Fstrong>: Du betreibst ein grosses, offenes Modell als \u003Cstrong>stabilen Inferenz-Endpoint\u003C\u002Fstrong> mit konstanter Last, willst die \u003Cstrong>Kosten planen\u003C\u002Fstrong> und deine \u003Cstrong>Daten in der Schweiz\u003C\u002Fstrong> halten, und du schätzt es, ein grosses Modell ohne Sharding-Aufwand zu fahren und bei Bedarf zu wechseln. Genau dafür ist die Maschine gebaut, und genau da spielt sie ihren Vorteil voll aus.\u003C\u002Fp>\n\n\u003Cp>Wann du woanders besser aufgehoben bist, lässt sich knapp zusammenfassen:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>Training oder Fine-Tuning grosser Modelle\u003C\u002Fstrong> → eine \u003Ca href=\"\u002Fde\u002Fbare-metal\">H100 bare metal\u003C\u002Fa> mit HBM-Bandbreite.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Extreme Durchsatzspitzen über sehr viele parallele Nutzer\u003C\u002Fstrong> → mehrere Maschinen oder dedizierte HBM-Hardware.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kurze, unvorhersehbare Lastpeaks\u003C\u002Fstrong> → die elastische Cloud, die du minutenweise hoch- und runterfährst.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Den ganzen Abwägungsraum, inklusive Datenhoheit 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>Grosse Modelle ruhig und planbar betreiben\u003C\u002Fh2>\n\n\u003Cp>Die DGX Spark macht eine Sache sehr gut: ein \u003Cstrong>grosses Modell\u003C\u002Fstrong> ruhig, \u003Cstrong>planbar\u003C\u002Fstrong> und \u003Cstrong>souverän in der Schweiz\u003C\u002Fstrong> betreiben, ohne Multi-GPU-Zirkus. Sie ist bewusst \u003Cstrong>kein Alleskönner\u003C\u002Fstrong>: Sie tauscht \u003Cstrong>Bandbreite gegen Kapazität\u003C\u002Fstrong>, und ob das für dich aufgeht, entscheidet dein Workload, nicht das Marketing. Für konstante Inferenz grosser, offener Modelle ist sie die unaufgeregteste Wahl, die wir kennen; für \u003Cstrong>Training und extreme Durchsatzspitzen\u003C\u002Fstrong> ist sie es nicht.\u003C\u002Fp>\n\n\u003Cp>Wir mieten sie \u003Cstrong>monatsweise als planbare Pauschale\u003C\u002Fstrong>, sodass du den Vorteil \u003Cstrong>ohne Kapitalbindung\u003C\u002Fstrong> und ohne Veralterungsrisiko bekommst, die \u003Ca href=\"\u002Fde\u002Fdgx-spark\">DGX Spark\u003C\u002Fa> im Detail. Im Zweifel \u003Cstrong>rechnen wir deinen konkreten Fall durch\u003C\u002Fstrong> und sagen offen, ob die Spark, eine \u003Ca href=\"\u002Fde\u002Fbare-metal\">H100 bare metal\u003C\u002Fa> oder die Cloud die richtige Wahl ist.\u003C\u002Fp>\n",[],[60,67],{"title":61,"links":62},"Leistungen",[63,64,65,66],{"title":5,"href":6},{"title":9,"href":10},{"title":13,"href":14},{"title":17,"href":18},{"title":68,"links":69},"Unternehmen",[70,71,72,73],{"title":30,"href":31},{"title":27,"href":28},{"title":24,"href":25},{"title":74,"href":75},"Kontakt","\u002Fde\u002Fkontakt",[77,87,98,107,115,123,130,137,143,149,155,161,167,169,175,181,187,194],{"path":78,"slug":79,"title":80,"summary":81,"image":53,"publication_date":82,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":84},"\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",[85],{"slug":86,"title":13},"managed-inference",{"path":88,"slug":89,"title":90,"summary":91,"image":53,"publication_date":82,"big5_category":92,"primary_hub":53,"cluster":53,"pillar":53,"hubs":93},"\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.","bestof",[94,97],{"slug":95,"title":96},"bare-metal","Bare Metal GPU mit Root-Zugriff",{"slug":49,"title":5},{"path":99,"slug":100,"title":101,"summary":102,"image":53,"publication_date":82,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":103},"\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.",[104],{"slug":105,"title":106},"agents","Hermes Agents as a Service",{"path":108,"slug":109,"title":110,"summary":111,"image":53,"publication_date":82,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":113},"\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",[114],{"slug":86,"title":13},{"path":116,"slug":117,"title":118,"summary":119,"image":53,"publication_date":82,"big5_category":120,"primary_hub":53,"cluster":53,"pillar":53,"hubs":121},"\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",[122],{"slug":86,"title":13},{"path":124,"slug":125,"title":126,"summary":127,"image":53,"publication_date":128,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":129},"\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":131,"slug":132,"title":133,"summary":134,"image":53,"publication_date":128,"big5_category":135,"primary_hub":53,"cluster":53,"pillar":53,"hubs":136},"\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":138,"slug":139,"title":140,"summary":141,"image":53,"publication_date":128,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":142},"\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":144,"slug":145,"title":146,"summary":147,"image":53,"publication_date":128,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":148},"\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":150,"slug":151,"title":152,"summary":153,"image":53,"publication_date":128,"big5_category":135,"primary_hub":53,"cluster":53,"pillar":53,"hubs":154},"\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":156,"slug":157,"title":158,"summary":159,"image":53,"publication_date":45,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":160},"\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":162,"slug":163,"title":164,"summary":165,"image":53,"publication_date":45,"big5_category":112,"primary_hub":53,"cluster":53,"pillar":53,"hubs":166},"\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":35,"slug":36,"title":43,"summary":44,"image":53,"publication_date":45,"big5_category":46,"primary_hub":53,"cluster":53,"pillar":53,"hubs":168},[],{"path":170,"slug":171,"title":172,"summary":173,"image":53,"publication_date":45,"big5_category":135,"primary_hub":53,"cluster":53,"pillar":53,"hubs":174},"\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":176,"slug":177,"title":178,"summary":179,"image":53,"publication_date":45,"big5_category":92,"primary_hub":53,"cluster":53,"pillar":53,"hubs":180},"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","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.",[],{"path":182,"slug":183,"title":184,"summary":185,"image":53,"publication_date":45,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":186},"\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":188,"slug":189,"title":190,"summary":191,"image":53,"publication_date":192,"big5_category":83,"primary_hub":53,"cluster":53,"pillar":53,"hubs":193},"\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":195,"slug":196,"title":197,"summary":198,"image":53,"publication_date":192,"big5_category":120,"primary_hub":53,"cluster":53,"pillar":53,"hubs":199},"\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.",[]]