DeepSeek-H200-Test stellt die Behauptung „80-mal günstiger“ infrage
DeepSeek wurde einem praktischen Kostentest unterzogen, nachdem The Call Center Doctors vier Nvidia-H200-GPUs gemietet hatte, um die Behauptung des Modells, „80-mal günstiger“ zu sein, zu überprüfen.
Die Beratung versuchte, DeepSeek V4.1 Flash für ihre Coding-Agenten bereitzustellen, statt Claude Opus 5.5 über Claude Code zu nutzen. Ihr ursprünglicher Test ergab, dass günstige Modellgewichte kein kostengünstiges funktionierendes System ergeben.
Der DeepSeek-H200-Test zeigte eine Lücke zwischen Token-Preisen und den Kosten, reale Softwarearbeit abzuschließen. Der gemietete Server bewältigte synthetische Workloads schnell, doch seine Wirtschaftlichkeit verschlechterte sich, als das Team seinen tatsächlichen Coding-Traffic wiedergab.
Zum regulären On-Demand-Mietpreis kostete der Server ungefähr doppelt so viel wie derselbe Workload über DeepSeeks eigene API. Die Beratung kam außerdem zu dem Schluss, dass ihre bestehenden Claude-Code-Abonnements konkurrenzfähig blieben, sobald sie abgeschlossene Codeänderungen statt Token-Preise maß.
Diese Ergebnisse stammen aus dem Workload, der Konfiguration und den internen Messungen eines einzelnen Unternehmens. Sie sind kein allgemeingültiger Benchmark für eines der beiden Modelle. DeepSeek erhielt während des Tests nie die Erlaubnis, Produktionscode zu schreiben, was jeden direkten Vergleich abgeschlossener Arbeit einschränkt.
Dennoch ist das Experiment relevant, weil es Traffic von eingesetzten Coding-Agenten statt eines isolierten Benchmarks verwendete. Es maß wiederholten Kontext, Parallelität, Latenz, operativen Aufwand und die Sicherheitsgrenze rund um autonome Codeausführung.
Die zentrale Umkehrung ist einfach. DeepSeeks niedrige API-Tarife blieben attraktiv, während das Self-Hosting desselben Modells auf Premium-GPUs für diesen speziellen Workload eine schlechtere Wirtschaftlichkeit ergab.
Das Ergebnis setzt Käufer unter Druck, vor einem Anbieterwechsel zu definieren, was „günstiger“ bedeutet. Ein niedriger Output-Token-Preis kann relevant sein, sagt jedoch nichts über Durchsatz, Zuverlässigkeit, Engineering-Aufwand oder erfolgreiche Bereitstellung aus.
Der DeepSeek-H200-Test ersetzte eine Preisbehauptung durch einen Workload-Test
Die Beratung testete ein vollständiges Inferenzsystem, nicht nur die Zahl neben einer Million Tokens.
The Call Center Doctors baut und betreibt Callcenter-Umgebungen für andere Unternehmen. Das Unternehmen nutzt außerdem Coding-Agenten, um die Software zu warten, die diese Arbeit unterstützt.
Am 27. September mietete das Unternehmen einen Server mit vier Nvidia-H200-Beschleunigern. Es lud DeepSeek V4.1 Flash herunter und konfigurierte das Modell als Backend für Agenten, die normalerweise mit Claude Code verbunden sind.
Der Test zielte auf zwei verbreitete Behauptungen zu Modellen mit offenen Gewichten. Die erste besagt, dass niedrigere Token-Preise direkt zu geringeren Betriebskosten führen. Die zweite besagt, dass Unternehmen Anbieteraufschläge vermeiden können, indem sie GPUs mieten und das Modell selbst bereitstellen.
DeepSeek liefert Käufern Gründe, diese Behauptungen zu prüfen. Sein Modell-Launch beschreibt V4.1 Flash als Mixture-of-Experts-Modell, das für schnellere Inferenz und höheren Durchsatz ausgelegt ist.
Ein Mixture-of-Experts-Modell aktiviert für jeden Token nur einen Teil seines Netzwerks. Dieses Design kann den Rechenaufwand verringern, verglichen mit der Ausführung jedes Parameters für jede Anfrage.
DeepSeek erklärt, dass seine Architektur beim Verarbeiten von Ein- und Ausgaben weniger Parameter aktiviert. Zudem benötigt das Modell nach eigenen Angaben weniger High-Bandwidth-Memory für seinen Key-Value-Cache als die vorherige Generation.
Ein Key-Value-Cache speichert zwischengelagerte Attention-Daten früherer Tokens. Die Wiederverwendung dieser Daten macht wiederholten Kontext günstiger als die Verarbeitung der gesamten Sequenz als neue Eingabe.
Die Beratung wählte daher Hardware, die für speicherintensive Inferenz geeignet ist. Jede H200 enthält laut den H200-Spezifikationen von Nvidia 141 GB High-Bandwidth-Memory.
Über vier GPUs hinweg reichte diese Kapazität nach mehreren Konfigurationsänderungen aus, um das Modell zu laden und bereitzustellen. Einen stabilen Dienst zu erreichen, erforderte jedoch fünf Starts.
Jeder Neustart erforderte eine weitere Phase zum Laden des Modells. Eine Optimierung verbrauchte unerwartet Speicher, ein weiterer Durchlauf fror ein, und eine spätere Konfiguration scheiterte bei höherer Parallelität.
Der fünfte Versuch stabilisierte sich mit einer niedrigeren Obergrenze für Parallelität und weitgehend reserviertem verfügbarem Speicher. Diese operative Abfolge wurde Teil des wirtschaftlichen Ergebnisses.
Eine gehostete API verbirgt Modelldownloads, Speicherzuweisung, Serving-Software, Kapazitätsplanung und fehlgeschlagene Starts. Eine gemietete Maschine macht jede dieser Aufgaben für den Kunden sichtbar.
Nach der Stabilisierung lieferte der Server in isolierten einminütigen Tests gute Ergebnisse. Er verarbeitete insbesondere gecachte Eingaben schnell und erzeugte über die gesamte Maschine hinweg Tausende Tokens pro Sekunde.
Dieses Ergebnis stützte zunächst das Argument für Self-Hosting. Vier H200s boten einen erheblichen Rohdurchsatz, und DeepSeeks cacheorientiertes Design verhielt sich wie erwartet.
Das Problem zeigte sich, als das Team aufhörte, jeweils nur eine Token-Kategorie zu testen. Seine Coding-Agenten sendeten keine ausgewogene Abfolge aus neuen Eingaben, gecachten Eingaben und Ausgaben.
Sie lieferten wiederholt lange Konversationen, Tool-Ergebnisse, Dateikontext und frühere Überlegungen. Der Großteil jeder Anfrage bestand aus Text, den das Modell bereits gesehen hatte.
Dieser Workload verlagerte den Test weg von theoretischer Output-Geschwindigkeit. Er zwang die Maschine, fast ihre gesamte Zeit mit der Verarbeitung des Kontexts zu verbringen, der vor der Generierung der nächsten Antwort erforderlich war.
Das Ereignis war daher kein herkömmliches Modellrennen. Es war ein Test dafür, ob attraktive Inferenzraten dem realen Traffic eines Agentensystems standhalten.
Warum Agentenkontext die vier H200s auslastete
Coding-Agenten verwenden oft weitaus mehr Rechenleistung darauf, ihren Verlauf zu lesen, als darauf, den nächsten nützlichen Token zu schreiben.
Die September-Logs der Beratung enthielten 388,5 Milliarden gelesene und 393 Millionen geschriebene Tokens. Von den Eingaben waren 374,2 Milliarden Tokens erneut gelesener gecachter Kontext.
Das bedeutet, dass mehr als 96 Prozent der erfassten Eingaben früheren Kontext wiederholten. Auf jeden Output-Token lieferten die Agenten etwa 41,6 neue Input-Tokens und 1.042 gecachte Tokens.
Eine durchschnittliche Anfrage las ungefähr 196.000 Tokens erneut. Dieses Muster ist wichtig, weil gecachte Eingaben pro Token günstig, aber nie rechenfrei sind.
Der gemietete Server verarbeitete jeden gecachten Token schneller als jeden neuen Token. Die Agenten lieferten jedoch so viele gecachte Tokens, dass sich diese kleinen Kosten zum dominanten Workload summierten.
Das Unternehmen maß für einen gecachten Token ungefähr 1,9 Mikrosekunden Serverzeit. Ein neuer Input-Token benötigte etwa 60 Mikrosekunden, während ein Output-Token etwa 189 Mikrosekunden erforderte.
Die Anwendung dieser Messungen auf den Mix des Produktions-Traffics ergab eine kombinierte Obergrenze von etwa 213 Output-Tokens pro Sekunde. Dies war das aggregierte Ergebnis für alle Agenten, die sich sämtliche vier GPUs teilten.
Laut der Beratung stimmte die Formel bis auf drei Prozent mit dem Live-Test überein. Diese Übereinstimmung stärkte das Workload-Modell, auch wenn es noch nicht von einer unabhängigen Partei repliziert wurde.
Das Unternehmen schätzte, dass die Maschine bei diesem Mix täglich ungefähr 20 Milliarden Tokens verarbeiten könnte. Der geschäftigste Septembertag erreichte 51 Milliarden Tokens.
Die Kapazität wurde damit zu einer zweiten Einschränkung. Ein Server konnte den erfassten Spitzenwert nicht aufnehmen, selbst wenn seine reguläre Mietwirtschaftlichkeit günstig gewesen wäre.
Der Kontrast zwischen isolierten und gemischten Tests erklärt, warum Durchsatz-Schlagzeilen irreführend sein können. Die Maschine erzeugte mehr als 5.000 Tokens pro Sekunde, wenn nur Output gemessen wurde.
Reale Agenten können nicht allein mit Output arbeiten. Sie müssen fortlaufend Anweisungen, Code, Dateien, Logs, Tool-Antworten und frühere Nachrichten bereitstellen.
Lang laufende Agenten verstärken dieses Ungleichgewicht, weil Konversationen mit der Zeit wachsen. Jeder nachfolgende Aufruf kann einen großen Teil desselben Verlaufs plus eine kleine Menge neuer Informationen enthalten.
Cache-Rabatte senken die Kosten dieser wiederholten Tokens. Sie beseitigen weder Speicherbandbreite, Planungsverzögerungen noch die Opportunitätskosten der Belegung eines Servers.
Diese Unterscheidung erschwert auch Vergleiche zwischen Modellen. Ein leistungsfähigeres Modell könnte eine Aufgabe mit weniger Versuchen, kürzeren Prompts oder weniger Überprüfung abschließen.
Ein günstigeres Modell könnte dennoch gewinnen, wenn es ähnlichen Kontext nutzt und vergleichbare Ergebnisse erzielt. Es könnte verlieren, wenn es mehr Wiederholungen, längere Erklärungen oder die Verifizierung durch ein anderes Modell benötigt.
Der DeepSeek-H200-Test beantwortete diese Qualitätsfrage nicht vollständig, weil DeepSeek hauptsächlich als schreibgeschützter Prüfer diente. Er zeigte jedoch, warum Output-Token-Preise allein sie nicht beantworten können.
Welche Kennzahl zählt, hängt von der Aufgabe ab. Ein System zur Stapelzusammenfassung könnte den Gesamtdurchsatz priorisieren, während ein interaktiver Agent zusätzlich geringe Latenz und zuverlässige Tool-Nutzung benötigt.
Ein Coding-Betrieb interessiert sich für abgeschlossene Änderungen, Prüfungszeit, Regressionen, Sicherheit und Wartezeit für Entwickler. Token-Effizienz ist nur ein Einflussfaktor auf dieses Ergebnis.
Die Logs der Beratung boten anderen Käufern eine nützliche Warnung. Vor der Auswahl von Hardware müssen Teams das Verhältnis zwischen neuer Eingabe, gecachtem Kontext und generiertem Output analysieren.
Ohne dieses Verhältnis kann ein Benchmark den kleinsten Teil des Workloads optimieren. Ein schneller Generierungstest kann wenig über einen Agenten aussagen, der die meiste Zeit mit Lesen verbringt.
DeepSeek-Self-Hosting verlor gegen die DeepSeek-API
Das eindeutigste Ergebnis war nicht DeepSeek gegen Claude, sondern gemietete DeepSeek-Infrastruktur gegen DeepSeeks verwalteten Dienst.
Der reguläre On-Demand-Serverpreis führte zu täglichen Kosten, die ungefähr dem Zwei- bis 2,4-Fachen des Werts desselben Traffics über DeepSeeks API entsprachen. Diese Berechnung setzte eine kontinuierliche Auslastung voraus.
Die im Experiment verwendete Spot-Miete war deutlich günstiger. Zu diesem vorübergehenden Preis näherte sich der Server DeepSeeks verwaltetem Dienst nur bei Volllast der Kostengleichheit.
Spot-Kapazität ist mit einem Verfügbarkeitskompromiss verbunden. Anbieter können sie zurückfordern, wenn sich die Nachfrage ändert, was es schwierig macht, sie als verlässliche Produktionsinfrastruktur zu behandeln.
Das geschah nahezu unmittelbar nach dem Experiment. Der Anbieter nahm die Maschine innerhalb weniger Minuten nach dem abschließenden Test zurück.
Die On-Demand-Alternative vermied dieses Unterbrechungsrisiko, schwächte jedoch die Wirtschaftlichkeit. Sie verursachte zudem Kosten, während das Modell geladen oder neu gestartet wurde, auf Traffic wartete oder unterhalb der maximalen Auslastung blieb.
DeepSeeks verwaltete API verteilt diese Leerlaufzeiten auf viele Kunden. Der Anbieter kann Anfragen bündeln, Hardware poolen und seinen eigenen Serving-Stack in größerem Maßstab betreiben.
Seine API-Preisliste unterscheidet ebenfalls zwischen gecachter Eingabe, neuer Eingabe und Output. Traffic außerhalb der Spitzenzeiten erhält niedrigere Preise als Traffic zu Spitzenzeiten an Werktagen.
Dieser Tarif bietet Käufern einen weiteren Optimierungsweg. Flexible Batch-Workloads können von Spitzenzeiten weg verlagert werden, ohne dass eine dedizierte Maschine erforderlich ist.
Der gemietete Server hatte keine entsprechende Anpassung an die Nachfrage. Sein Stundenzähler lief weiter, unabhängig davon, ob die Agenten nützliche Arbeit produzierten.
Der Vergleich belegt nicht, dass Self-Hosting immer unwirtschaftlich ist. Unternehmen können abgeschriebene Hardware besitzen, niedrigere Kapazitätspreise aushandeln oder eine konstante Auslastung über mehrere Workloads hinweg aufrechterhalten.
Große Deployments können zudem Kernel, Quantisierung, Routing und Batch-Planung weiter optimieren, als dies ein kurzes Experiment erreichen konnte. DeepSeek selbst lädt Unternehmen, die sehr große Deployments planen, dazu ein, zusätzliche Optionen zu besprechen.
Datenschutz kann einen lokalen Betrieb rechtfertigen, selbst wenn gehostete Inferenz günstiger ist. Regulierte Workloads können Datenkontrollen erfordern, die direkte Rechenkosten überwiegen.
Auch vorhersehbare Kapazität kann wichtig sein. Ein Unternehmen mit dauerhaftem Bedarf könnte Infrastruktur bevorzugen, die es selbst kontrolliert, insbesondere wenn eine externe API Limits oder Verfügbarkeitsrisiken mit sich bringt.
Diese Vorteile erfordern jedoch eine stabile Maschine, erfahrene Betreiber, Monitoring, Failover und Sicherheitskontrollen. Nichts davon ist bei offenen Modellgewichten automatisch vorhanden.
Der Test zeigte außerdem eine Art Expertise-Steuer. Ingenieure mussten Speicherverbrauch, Startfehler, Parallelitätsgrenzen und Serving-Verhalten diagnostizieren, bevor sie die eigentliche Nutzlast ausführen konnten.
Diese Arbeit war im einfachen Maschinenvergleich nicht enthalten. Würde man sie einbeziehen, fiele das kurze Self-Hosting-Experiment weniger vorteilhaft aus.
Das ist die wichtigste Lehre für Unternehmen, die einen selbst gehosteten DeepSeek-Einsatz erwägen. Der relevante Vergleich stellt einen vollständigen Service einem anderen vollständigen Service gegenüber.
Modellgewichte sind nur eine Komponente. Hardwaremiete, ungenutzte Kapazität, Orchestrierung, Observability, Incident Response, Strom, Speicher und Arbeitszeit des Personals vervollständigen das System.
Die DeepSeek API profitiert von derselben architektonischen Effizienz wie das herunterladbare Modell. Sie profitiert zudem von einer Infrastruktur, die DeepSeek über viele Kunden hinweg betreiben kann.
Self-Hosting muss beide Vorteile überwinden. Das Vermeiden eines API-Aufschlags reicht nicht aus, wenn der API-Anbieter über bessere Auslastung und mehr Serving-Expertise verfügt.
Für diese Arbeitslast gelang das nicht. Die Open-Weight-Option schuf Kontrolle, aber DeepSeeks Cloud lieferte die günstigere DeepSeek-Erfahrung.
Die Behauptung „80-mal günstiger“ verglich unterschiedliche Beschaffungsmodelle
Der zentrale Vergleich wurde geschwächt, weil er öffentliche API-Preise neben intensiv genutzten Abonnementzugängen stellte.
Die Behauptung „80-mal günstiger“ vergleicht Tokenpreise unter bestimmten Annahmen. Sie beschreibt nicht automatisch, was jeder Claude-Code-Nutzer tatsächlich bezahlt.
Die Beratung nutzte Claude über Abonnements statt über die verbrauchsbasierte API von Anthropic. Anthropic bestätigt, dass berechtigte Tarife Abonnementzugang zu Claude Code bieten, vorbehaltlich gemeinsamer Nutzungslimits.
Ein Abonnement und eine API bedienen unterschiedliche Beschaffungsmuster. Das Abonnement bündelt den Zugriff innerhalb definierter Grenzen, während eine API nach gemessenem Verbrauch abrechnet.
Die Beratung erklärte, ihre Abonnementnutzung entspreche einem hohen Rabatt auf öffentliche API-Preise. Dieser Unterschied absorbierte den Großteil der theoretischen 80-fachen Differenz.
Anhand des September-Traffics berechnete das Unternehmen, dass DeepSeeks API von etwas günstiger bis teurer als seine Claude-Abonnements reichen könnte. Der Zeitpunkt bestimmte, ob die Nutzung zwischen Spitzen- und Nebenzeiten lag.
Die berichteten Ergebnisse schätzten außerdem, dass Claudes öffentliche API-Preise zu einer deutlich höheren Rechnung geführt hätten. Doch das war nicht das Produkt, das das Unternehmen gekauft hatte.
Diese Unterscheidung lässt sich leicht übersehen, wenn Vergleiche jedes Produkt auf einen nominalen Tokenpreis reduzieren. Dasselbe Modell kann über Abonnements, Unternehmensverträge, Cloud-Plattformen oder direkte APIs verkauft werden.
Jeder Kanal hat andere Grenzen und wirtschaftliche Anreize. Ein Abonnement kann regelmäßige individuelle Nutzung begünstigen, während eine API programmierbare Skalierung und detaillierte Verbrauchsabrechnung bietet.
Ein Unternehmensvertrag kann ausgehandelte Kapazität, Servicezusagen oder Kontrollen ergänzen. Self-Hosting ersetzt die Servicemarge des Anbieters durch Infrastruktur- und Betriebsverantwortung.
Kein einzelner Preis erfasst alle vier Modelle. Käufer sollten den Weg vergleichen, den sie tatsächlich beschaffen und betreiben können.
Die Beratung berechnete außerdem die Kosten einer gemergten Codeänderung. Ihre Claude-Agenten schlossen im gemessenen Zeitraum 5.610 gemergte Änderungen ab, von denen fünf später zurückgesetzt wurden.
Sie schätzte, dass DeepSeek zusätzliche Tokens, Wiederholungsversuche und Claude-basierte Prüfungen benötigen würde. Unter diesen Annahmen würde jede akzeptierte Änderung über DeepSeek mehr kosten.
Diese Schätzung verdient Vorsicht. DeepSeek führte nicht dieselbe schreibfähige Aufgabe aus, daher konnte die Studie weder seine tatsächliche Erfolgsrate noch seinen gesamten Tokenverbrauch beobachten.
Die Annahmen könnten zu hart sein, wenn besseres Prompting, Serving-Software oder Agentendesign DeepSeeks Ergebnisse verbessern. Sie könnten zu optimistisch sein, wenn die Prüfung weitere Mängel aufdeckt.
Dennoch sind die Kosten pro akzeptierter Änderung ein sinnvolleres Ziel als die Kosten pro Ausgabetoken. Sie verbinden Inference-Ausgaben mit Software, die die Prüfung übersteht.
Die beste Kennzahl hängt vom Workflow ab. Kundendienstteams könnten gelöste Fälle messen, während Forschende verifizierte Erkenntnisse messen könnten.
Ein niedriger Tokenpreis bleibt wertvoll, wenn Modelle ähnliche Arbeit benötigen, um diese Ergebnisse zu erzielen. Er wird weniger entscheidend, wenn sich Fähigkeiten, Latenz oder Prüfaufwand unterscheiden.
Die „80x“-Zahl beschreibt daher einen engen Vergleich, keine universelle Einsparung. The Call Center Doctors widerlegten DeepSeeks veröffentlichten Preis nicht.
Stattdessen zeigte die Untersuchung, dass Preislisten-Arithmetik zusammenbrechen kann, wenn sich Produkte, Arbeitslasten und Ergebnisqualität unterscheiden.
Sicherheit hielt DeepSeek davon ab, Produktionscode zu schreiben
Die größte Einschränkung des Experiments war zugleich seine wichtigste operative Warnung: DeepSeek erfüllte den vorgesehenen Programmierauftrag nie.
Das Unternehmen plante, DeepSeek für Code-schreibende Agenten einzusetzen. Seine Prüfer fanden dann mögliche Wege, über die generierter Code der vorgesehenen Sandbox entkommen könnte.
Eine Sandbox ist eine isolierte Ausführungsumgebung, die einschränkt, worauf nicht vertrauenswürdiger Code zugreifen kann. Sie sollte verhindern, dass ein Agent sensible Dateien, Zugangsdaten, Netzwerke oder administrative Berechtigungen erreicht.
Eine gemeldete Schwachstelle betraf eine Einstellungsdatei in einem gemeinsam genutzten temporären Verzeichnis. Das Unternehmen ging davon aus, dass manipulierte Inhalte dort möglicherweise erlauben könnten, generierten Code mit erweiterten Berechtigungen auszuführen.
Die Beratung hielt die Builder-Agenten deshalb offline. DeepSeek arbeitete ausschließlich über 48 bis 64 schreibgeschützte Prüfer-Agenten.
Diese Prüfer untersuchten 2.377 Codeordner und erstellten 32 Fehlerberichte. Diese Aktivität zeigte nützlichen Durchsatz, testete jedoch keine autonome Implementierung.
Das Sicherheitsproblem wurde nicht als Fehler in DeepSeeks Modellgewichten dargestellt. Es betraf die umgebende Agentenumgebung und die Ausführungskontrollen der Beratung.
Diese Unterscheidung ist wichtig. Jedes Modell, das Befehle erzeugen kann, kann Schwächen in einer schlecht isolierten Toolchain offenlegen.
Claude, DeepSeek oder ein anderes Modell können unsichere Aktionen erzeugen, wenn Agenten Zugriff auf Dateisystem und Shell erhalten. Die Sicherheitsgrenze muss davon ausgehen, dass Modellausgaben nicht vertrauenswürdig sind.
Der Test vermischte folglich zwei getrennte Fragen. Eine betraf die Wirtschaftlichkeit von DeepSeek-Inference. Die andere betraf die Frage, ob die Agenten-Sandbox des Unternehmens für schreibfähige Automatisierung bereit war.
Nur die erste Frage erhielt direkte Messungen der Arbeitslast. Die zweite stoppte den vorgesehenen direkten Coding-Vergleich.
Dies verhindert die starke Behauptung, dass Claude im selben Experiment besseren Code erzeugte. Claudes abgeschlossene September-Arbeit waren historische Produktionsdaten, während DeepSeeks Arbeit ein eingeschränkter Test war.
Es verhindert auch eine faire Messung von DeepSeeks Kosten pro gemergter Änderung. Das Modell erhielt nie die Gelegenheit, Änderungen zur Prüfung und Bereitstellung zu erzeugen.
Das Unternehmen verwies auf öffentliche Coding-Benchmarks, um zu argumentieren, dass Opus einen Fähigkeitsvorteil hatte. Benchmarks können Kontext liefern, ersetzen jedoch kein identisches internes Aufgabenset.
Ein rigoroser Folgetest würde beiden Modellen dieselben Repositories, Tools, Sicherheitsbeschränkungen, Prompts und Akzeptanztests geben. Die Prüfer blieben gegenüber der Modellidentität blind.
Die Studie würde erfolgreiche Änderungen, Regressionen, Wiederholungsversuche, Latenz, Tokenverbrauch, Zeit für menschliche Prüfung und Sicherheitsverletzungen erfassen. Erst dann könnten die gesamten Bereitstellungskosten direkt verglichen werden.
Trotz dieser Einschränkung enthält die abgebrochene Bereitstellung eine praktische Lehre. Infrastrukturkosten haben wenig Bedeutung, wenn die Ausführungsebene die vorgesehenen Tools des Modells nicht sicher bereitstellen kann.
Agentensysteme vergrößern die Angriffsfläche, weil sie probabilistische Modellausgaben mit deterministischen Aktionen verbinden. Ein einzelner unsicherer Pfad kann wichtiger sein als Tausende günstiger Tokens.
Unternehmen sollten daher die Abschottung testen, bevor sie Einsparungen durch autonome Arbeit berechnen. Schreibgeschützte Analyse und schreibfähige Agenten gehören zu sehr unterschiedlichen Risikokategorien.
Sicherheit beeinflusst auch die Wirtschaftlichkeit. Stärkere Isolierung kann wegwerfbare Umgebungen, eingeschränkte Zugangsdaten, Netzwerkkontrollen, Logging und Freigabepunkte erfordern.
Diese Kontrollen verbrauchen Engineering-Zeit und erhöhen die Latenz. Sie können außerdem die Parallelität reduzieren oder separate Infrastruktur erfordern.
Das Modell mit dem niedrigsten Inference-Preis liefert möglicherweise nicht die niedrigsten sicher bereitgestellten Kosten. Das relevante System umfasst jede Kontrolle, die nötig ist, um seinen Ergebnissen zu vertrauen.
Was der DeepSeek-H200-Test für KI-Käufer bedeutet
Der nächste Vergleich sollte sich auf akzeptierte Arbeit, nachhaltige Auslastung und sichere Ausführung konzentrieren, statt auf einen einzelnen Tokenpreis.
Das erste zu beobachtende Signal ist ein kontrollierter erneuter Test mit Schreibzugriff. DeepSeek benötigt dieselben Tools, Repositories, Prompts und Akzeptanzkriterien, die zuvor mit Claude verwendet wurden.
Wenn es vergleichbare Änderungen mit begrenzter Prüfung abschließt, würde die negative Schlussfolgerung der Beratung schwächer. Wenn Wiederholungsversuche und Korrekturen hoch bleiben, würde das ergebnisbasierte Kostenargument gestärkt.
Das zweite Signal ist eine nachhaltige Auslastung über mehrere Wochen. Ein selbst gehosteter Server wird attraktiver, wenn die nützliche Nachfrage den ganzen Tag über nahe an der Kapazität bleibt.
The Call Center Doctors maßen eine Spitze, die die Kapazität einer Maschine überstieg. Variabler Traffic kann jedoch außerhalb dieser Spitzen weiterhin teure Leerlaufzeiten verursachen.
Ein längerer Test sollte Auslastung nach Stunde, Warteschlangentiefe, Latenz bis zum ersten Token, Unterbrechungen und den Zeitanteil für Laden oder Wiederherstellung berichten.
Er sollte außerdem zwischengespeicherte Eingaben, neue Eingaben und Ausgaben trennen. Diese Kategorien interagieren unterschiedlich mit Speicherbandbreite und Batching.
Das dritte Signal ist DeepSeek V4.1-Pro. DeepSeek erklärt, dass sich seine aktuelle Flash-Architektur auf größere Modelle ausweiten wird, hat jedoch kein verbindliches Veröffentlichungsdatum genannt.
Ein stärkeres Modell könnte die Wirtschaftlichkeit verändern, wenn es mehr Aufgaben mit weniger Wiederholungsversuchen abschließt. Es könnte auch mehr Speicher benötigen oder geringeren Durchsatz liefern.
Käufer sollten sowohl Fähigkeiten als auch Serving-Anforderungen beobachten. Eine Benchmark-Verbesserung garantiert keine niedrigeren Produktionskosten.
DeepSeeks derzeitige Leistung bleibt bedeutend. Seine offiziellen Preise machen Experimente mit hohem Volumen zugänglich, und seine herunterladbaren Gewichte bieten Flexibilität bei der Bereitstellung.
Der Test hat diese Vorteile nicht beseitigt. Er hat die Bedingungen eingegrenzt, unter denen sie zu Einsparungen führen.
Bei intermittierender oder unsicherer Nachfrage erscheint DeepSeeks verwaltete API rationaler als die Miete eines dedizierten Servers mit vier GPUs. Sie bewahrt niedrige Tokenpreise, ohne Infrastrukturaufgaben auf den Kunden zu übertragen.
Bei sensiblen Daten, vorhersehbarer dauerhafter Nachfrage oder spezialisierter Optimierung kann Self-Hosting weiterhin eine Prüfung verdienen. Der Business Case muss Personal, Zuverlässigkeit, Sicherheit und ungenutzte Kapazität einbeziehen.
Claude Code stellt ein anderes Angebot dar. Es bündelt Modellzugang, eine Coding-Oberfläche und vom Anbieter betriebene Infrastruktur unter Abonnementlimits.
Diese Paketierung kann tokenbasierte Vergleiche bei intensiver individueller Nutzung übertreffen. Sie kann aber auch einschränkend werden, wenn Organisationen programmierbare Kapazität oder zentrale Kontrolle benötigen.
Der Druck liegt daher bei Beschaffungsteams und technischen Führungskräften. Sie müssen aufhören, „API“, „Abonnement“ und „selbst gehostet“ als austauschbare Beschaffungseinheiten zu behandeln.
Sie sollten mit Produktionsspuren statt mit Anbieterbeispielen beginnen. Die nützlichste Spur erfasst Kontextlänge, Cache-Treffer, Ausgaben, Latenz, Fehler und akzeptierte Ergebnisse.
Teams können dann repräsentative Arbeitslasten über konkurrierende Systeme erneut ausführen. Der Test sollte die operativen Bedingungen einbeziehen, die nach einer erfolgreichen Demo relevant sind.
Zu diesen Bedingungen gehören Parallelität, schwankendes Verkehrsaufkommen, Neustarts, Warteschlangen, Modellupdates, Monitoring und Wiederherstellung. Sicherheitstests müssen erfolgen, bevor Agents Schreibzugriff erhalten.
Ergebniskennzahlen sollten dem Ziel der Organisation entsprechen. Bei Coding-Agents zählen dazu zusammengeführte Änderungen, Defekte, Reverts, Review-Zeit und Zeit bis zum Abschluss.
Für Support-Agents sind gelöste Fälle, Eskalationen, Kundenzufriedenheit und Richtlinienverstöße nützliche Kennzahlen. Bei Research-Agents sind verifizierte Erkenntnisse wichtiger als erzeugte Seiten.
Der DeepSeek-H200-Test ist wertvoll, weil er sich diesem Standard angenähert hat. Er ersetzte einen abstrakten Ratenvergleich durch eine reale Kontextverteilung und reale Infrastruktur.
Seine Einschränkungen sind ebenso aufschlussreich. Die kurze Laufzeit, eine einzelne Organisation, unvollständige Sicherheitsarbeit und ungleicher Produktionszugang verhindern ein allgemeingültiges Urteil.
Die angemessene Schlussfolgerung ist enger gefasst. Vier gemietete H200 übertrafen DeepSeeks API bei diesem Agent-Workload nicht, und die API bot gegenüber Abonnements keinen offensichtlichen 80-fachen Vorteil.
Das reicht aus, um vereinfachte Behauptungen infrage zu stellen. Es reicht nicht aus, DeepSeek, Open Weights oder selbst gehostete Inferenz abzuschreiben.
Bevor Sie einen AI-Stack verändern, erfassen Sie eine Woche repräsentativen Datenverkehrs und berechnen Sie die Kosten pro akzeptiertem Ergebnis. Wiederholen Sie den Vergleich anschließend mit aktivierten Sicherheitskontrollen.
Fragen Sie, ob das Modell dieselbe Arbeit abschließt – nicht, ob sein günstigster Token beeindruckend wirkt. Der nächste DeepSeek-H200-Test sollte diese schwierigere Frage beantworten.
