Test DeepSeek H200 podważa twierdzenie o „80x niższych kosztach”
DeepSeek stanął przed praktycznym testem kosztów po tym, jak The Call Center Doctors wynajęło cztery procesory GPU Nvidia H200, aby sprawdzić twierdzenie modelu o „80x niższych kosztach”.
Firma konsultingowa spróbowała obsługiwać DeepSeek V4.1 Flash dla swoich agentów kodujących zamiast korzystać z Claude Opus 5.5 przez Claude Code. Jej pierwotny test wykazał, że niedrogie wagi modelu nie przekładają się na niedrogi działający system.
Test DeepSeek H200 ujawnił lukę między cenami tokenów a kosztem realizacji rzeczywistej pracy programistycznej. Wynajęty serwer szybko obsługiwał syntetyczne obciążenia, jednak jego ekonomika pogorszyła się, gdy zespół odtworzył rzeczywisty ruch swoich agentów kodujących.
Przy standardowej stawce wynajmu na żądanie serwer kosztował około dwa razy więcej niż wysłanie tego samego obciążenia do własnego API DeepSeek. Firma konsultingowa uznała również, że jej obecne subskrypcje Claude Code pozostają konkurencyjne, gdy mierzy się ukończone zmiany w kodzie zamiast cen tokenów.
Wnioski te pochodzą z obciążenia, konfiguracji i wewnętrznych pomiarów jednej firmy. Nie są uniwersalnym benchmarkiem żadnego z modeli. DeepSeek nigdy nie otrzymał podczas testu uprawnienia do pisania kodu produkcyjnego, co ogranicza wszelkie bezpośrednie porównania ukończonej pracy.
Mimo to eksperyment ma znaczenie, ponieważ wykorzystywał ruch z wdrożonych agentów kodujących, a nie odizolowany benchmark. Mierzył powtarzający się kontekst, współbieżność, opóźnienia, pracę operacyjną oraz granicę bezpieczeństwa wokół autonomicznego wykonywania kodu.
Główne odwrócenie sytuacji jest proste. Niskie stawki API DeepSeek pozostały atrakcyjne, podczas gdy samodzielne hostowanie tego samego modelu na wysokiej klasy GPU dało gorszą ekonomikę dla tego konkretnego obciążenia.
Wynik skłania kupujących do zdefiniowania, co oznacza „taniej”, przed zmianą dostawcy. Niska stawka za token wyjściowy może mieć znaczenie, ale nie opisuje przepustowości, niezawodności, nakładu pracy inżynierskiej ani skutecznego dostarczania.
Test DeepSeek H200 zastąpił twierdzenie cenowe testem obciążenia
Firma konsultingowa testowała kompletny system inferencyjny, a nie tylko liczbę wydrukowaną obok miliona tokenów.
The Call Center Doctors tworzy i obsługuje środowiska call center dla innych firm. Korzysta również z agentów kodujących, aby utrzymywać oprogramowanie wspierające tę działalność.
27 września firma wynajęła serwer zawierający cztery akceleratory Nvidia H200. Pobrała DeepSeek V4.1 Flash i skonfigurowała model jako backend dla agentów zwykle połączonych z Claude Code.
Test był ukierunkowany na dwa częste twierdzenia dotyczące modeli o otwartych wagach. Pierwsze głosi, że niższe stawki tokenowe bezpośrednio przekładają się na niższe koszty operacyjne. Drugie mówi, że organizacje mogą uniknąć marż dostawców, wynajmując GPU i samodzielnie obsługując model.
DeepSeek daje kupującym powody, by zbadać te twierdzenia. Jego premiera modelu opisuje V4.1 Flash jako model mixture-of-experts zaprojektowany pod kątem szybszej inferencji i wyższej przepustowości.
Model mixture-of-experts aktywuje tylko część swojej sieci dla każdego tokenu. Taka konstrukcja może zmniejszyć obliczenia w porównaniu z uruchamianiem wszystkich parametrów dla każdego żądania.
DeepSeek twierdzi, że jego architektura aktywuje mniej parametrów podczas przetwarzania wejścia i wyjścia. Podaje również, że model potrzebuje mniej pamięci o wysokiej przepustowości dla swojego cache klucz-wartość niż poprzednia generacja.
Cache klucz-wartość przechowuje pośrednie dane uwagi z wcześniejszych tokenów. Ponowne wykorzystanie tych danych sprawia, że powtarzający się kontekst jest tańszy niż przetwarzanie całej sekwencji jako nowego wejścia.
Firma konsultingowa wybrała więc sprzęt odpowiedni do inferencji intensywnie wykorzystującej pamięć. Każdy H200 obejmuje 141 GB pamięci o wysokiej przepustowości, zgodnie ze specyfikacją H200 firmy Nvidia.
Na czterech GPU pojemność ta wystarczyła do załadowania i obsługi modelu po kilku zmianach konfiguracji. Jednak osiągnięcie stabilnej usługi wymagało pięciu uruchomień.
Każdy restart wymagał kolejnego okresu ładowania modelu. Jedna optymalizacja zużyła nieoczekiwanie dużo pamięci, kolejne uruchomienie się zawiesiło, a późniejsza konfiguracja zawiodła przy wyższej współbieżności.
Piąta próba ustabilizowała się przy niższym limicie współbieżności i z wykorzystaniem większości dostępnej pamięci. Ta sekwencja operacyjna stała się częścią wyniku ekonomicznego.
Hostowane API ukrywa pobieranie modeli, alokację pamięci, oprogramowanie obsługujące, planowanie pojemności i nieudane uruchomienia. Wynajęta maszyna ujawnia klientowi każde z tych zadań.
Po ustabilizowaniu serwer osiągał dobre wyniki podczas odizolowanych, jednominutowych testów. Szczególnie szybko przetwarzał wejście z cache i generował tysiące tokenów na sekundę w skali całej maszyny.
Wynik ten początkowo wspierał argument za samodzielnym hostowaniem. Cztery H200 zapewniały znaczną surową przepustowość, a zorientowana na cache konstrukcja DeepSeek działała zgodnie z oczekiwaniami.
Problem pojawił się, gdy zespół przestał testować po jednej kategorii tokenów naraz. Jego agenci kodujący nie wysyłali zrównoważonej sekwencji nowego wejścia, wejścia z cache i wyjścia.
Wielokrotnie dostarczali długie rozmowy, wyniki narzędzi, kontekst plików i wcześniejsze rozumowanie. Większość każdego żądania składała się z tekstu, który model już wcześniej widział.
To obciążenie przesunęło test z teoretycznej szybkości wyjścia. Zmusiło maszynę do spędzania niemal całego czasu na przetwarzaniu kontekstu potrzebnego przed wygenerowaniem kolejnej odpowiedzi.
Wydarzenie nie było zatem konwencjonalnym wyścigiem modeli. Był to test tego, czy atrakcyjne stawki inferencyjne przetrwają kontakt z rzeczywistym ruchem systemu agentowego.
Dlaczego kontekst agentów pochłonął cztery H200
Agenci kodujący często zużywają znacznie więcej mocy obliczeniowej na czytanie historii niż na napisanie kolejnego użytecznego tokenu.
Wrześniowe logi firmy konsultingowej zawierały 388,5 miliarda odczytanych tokenów i 393 miliony zapisanych tokenów. Z wejścia 374,2 miliarda tokenów stanowiły ponowne odczyty z cache.
Oznacza to, że ponad 96 procent zarejestrowanego wejścia powtarzało wcześniejszy kontekst. Na każdy token wyjściowy agenci dostarczali około 41,6 nowego tokenu wejściowego i 1 042 tokeny z cache.
Przeciętne żądanie ponownie odczytywało około 196 000 tokenów. Ten wzorzec ma znaczenie, ponieważ wejście z cache jest niedrogie na token, ale nigdy nie jest obliczeniowo darmowe.
Wynajęty serwer przetwarzał każdy token z cache szybciej niż każdy nowy token. Agenci dostarczali jednak tak wiele tokenów z cache, że te niewielkie koszty skumulowały się w dominujące obciążenie.
Firma zmierzyła około 1,9 mikrosekundy czasu serwera dla tokenu z cache. Nowy token wejściowy wymagał około 60 mikrosekund, podczas gdy token wyjściowy wymagał około 189 mikrosekund.
Zastosowanie tych pomiarów do proporcji ruchu produkcyjnego dało łączny limit bliski 213 tokenom wyjściowym na sekundę. Był to zagregowany wynik dla wszystkich agentów współdzielących cztery GPU.
Według firmy konsultingowej formuła odpowiadała testowi na żywo z dokładnością do trzech procent. Ta zgodność wzmocniła model obciążenia, choć niezależna strona go nie powtórzyła.
Firma oszacowała, że maszyna mogłaby przetwarzać około 20 miliardów wszystkich tokenów dziennie przy takiej proporcji. Jej najbardziej intensywny dzień we wrześniu osiągnął 51 miliardów tokenów.
Pojemność stała się więc drugim ograniczeniem. Jeden serwer nie mógł obsłużyć zarejestrowanego szczytu, nawet gdyby jego standardowa ekonomika wynajmu była korzystna.
Kontrast między testami odizolowanymi a mieszanymi wyjaśnia, dlaczego nagłówkowa przepustowość może wprowadzać w błąd. Maszyna generowała ponad 5 000 tokenów na sekundę, gdy mierzone było wyłącznie wyjście.
Rzeczywiści agenci nie mogą działać wyłącznie na wyjściu. Muszą stale dostarczać instrukcje, kod, pliki, logi, odpowiedzi narzędzi i wcześniejsze wiadomości.
Długotrwale działający agenci wzmacniają tę nierównowagę, ponieważ rozmowy rosną z czasem. Każde kolejne wywołanie może zawierać znaczną część tej samej historii oraz niewielką ilość nowych informacji.
Zniżki za cache obniżają opłatę za te powtarzane tokeny. Nie eliminują przepustowości pamięci, opóźnień planowania ani kosztu alternatywnego zajmowania serwera.
To rozróżnienie komplikuje także porównania między modelami. Bardziej kompetentny model może ukończyć zadanie przy mniejszej liczbie prób, krótszych promptach lub mniejszej potrzebie przeglądu.
Tańszy model może mimo to wygrać, jeśli wykorzystuje podobny kontekst i osiąga porównywalne wyniki. Może przegrać, jeśli wymaga większej liczby ponowień, dłuższych wyjaśnień lub weryfikacji przez inny model.
Test DeepSeek H200 nie odpowiedział w pełni na pytanie o jakość, ponieważ DeepSeek służył głównie jako recenzent tylko do odczytu. Pokazał jednak, dlaczego same stawki za tokeny wyjściowe nie mogą na nie odpowiedzieć.
Metryka, która ma znaczenie, zależy od zadania. System wsadowego streszczania może priorytetowo traktować całkowitą przepustowość, podczas gdy interaktywny agent potrzebuje również niskich opóźnień i niezawodnego użycia narzędzi.
Dział programowania dba o ukończone zmiany, czas przeglądu, regresje, bezpieczeństwo i czas oczekiwania deweloperów. Wydajność tokenowa jest tylko jednym elementem tego wyniku.
Logi firmy konsultingowej stanowiły użyteczne ostrzeżenie dla innych kupujących. Przed wyborem sprzętu zespoły muszą określić proporcję między nowym wejściem, kontekstem z cache i generowanym wyjściem.
Bez tej proporcji benchmark może optymalizować najmniejszą część obciążenia. Test szybkiego generowania może niewiele mówić o agencie, który większość czasu spędza na czytaniu.
Samodzielne hostowanie DeepSeek przegrało z API DeepSeek
Najbardziej jednoznacznym wynikiem nie było porównanie DeepSeek z Claude, lecz wynajętej infrastruktury DeepSeek z zarządzaną usługą DeepSeek.
Standardowa stawka serwera na żądanie dawała dzienny koszt około 2–2,4 razy wyższy niż wartość tego samego ruchu przez API DeepSeek. Obliczenie to zakładało ciągłe wykorzystanie.
Wynajem spot wykorzystany podczas eksperymentu był znacznie tańszy. Przy tej tymczasowej stawce serwer jedynie zbliżył się do parytetu z zarządzaną usługą DeepSeek, działając przy pełnym obciążeniu.
Pojemność spot wiąże się z kompromisem dotyczącym dostępności. Dostawcy mogą ją odzyskać, gdy zmienia się popyt, co utrudnia traktowanie jej jako niezawodnej infrastruktury produkcyjnej.
Stało się to niemal natychmiast po eksperymencie. Dostawca odzyskał maszynę w ciągu kilku minut od ostatniego testu.
Alternatywa na żądanie eliminowała ryzyko takiej przerwy, ale pogarszała ekonomikę. Naliczano również opłaty, gdy model się ładował, restartował, czekał na ruch lub działał poniżej maksymalnego wykorzystania.
Zarządzane API DeepSeek rozkłada te okresy bezczynności między wielu klientów. Dostawca może grupować żądania, współdzielić sprzęt i obsługiwać własny stos serwujący na większą skalę.
Jego cennik API rozróżnia także wejście z cache, nowe wejście i wyjście. Ruch poza szczytem otrzymuje niższe stawki niż ruch w szczycie w dni robocze.
Ten harmonogram daje kupującym kolejną ścieżkę optymalizacji. Elastyczne obciążenia wsadowe mogą zostać przeniesione poza okresy szczytowe bez konieczności posiadania dedykowanej maszyny.
Wynajęty serwer nie miał odpowiadającego mu dostosowania do popytu. Jego licznik godzinowy działał niezależnie od tego, czy agenci wykonywali użyteczną pracę.
Porównanie nie dowodzi, że samodzielne hostowanie jest zawsze nieekonomiczne. Organizacje mogą posiadać zamortyzowany sprzęt, negocjować niższe stawki za pojemność lub utrzymywać stałe wykorzystanie w kilku obciążeniach.
Duże wdrożenia mogą również optymalizować kernele, kwantyzację, routing i planowanie wsadów bardziej niż udało się w krótkim eksperymencie. Sam DeepSeek zachęca organizacje planujące bardzo duże wdrożenia do omówienia dodatkowych opcji.
Prywatność może uzasadniać działanie lokalne nawet wtedy, gdy hostowana inferencja jest tańsza. Regulowane obciążenia mogą wymagać kontroli danych, które przeważają nad bezpośrednimi kosztami obliczeń.
Znaczenie może mieć również przewidywalna pojemność. Firma o utrzymującym się popycie może preferować infrastrukturę, którą kontroluje, zwłaszcza gdy zewnętrzne API nakłada limity lub wiąże się z ryzykiem dostępności.
Jednak te korzyści wymagają stabilnej maszyny, doświadczonych operatorów, monitorowania, mechanizmów przełączania awaryjnego i kontroli bezpieczeństwa. Żadna z nich nie wynika automatycznie z otwartych wag.
Test ujawnił również koszt kompetencji. Inżynierowie musieli zdiagnozować zużycie pamięci, błędy uruchamiania, limity współbieżności i zachowanie systemu serwującego model, zanim mogli uruchomić użyteczne obciążenie.
Nakład tej pracy nie został uwzględniony w prostym porównaniu maszyn. Jego wliczenie sprawiłoby, że krótkotrwały eksperyment z self-hostingiem wypadłby mniej korzystnie.
To główna lekcja dla przedsiębiorstw rozważających samodzielne wdrożenie DeepSeek. Właściwym porównaniem jest kompletna usługa z inną kompletną usługą.
Wagi modelu są tylko jednym elementem. System dopełniają wynajem sprzętu, niewykorzystana pojemność, orkiestracja, obserwowalność, reagowanie na incydenty, energia, pamięć masowa i czas pracy zespołu.
API DeepSeek korzysta z tej samej wydajności architektury co model dostępny do pobrania. Korzysta także z infrastruktury, którą DeepSeek może obsługiwać dla wielu klientów.
Self-hosting musi przezwyciężyć obie te przewagi. Uniknięcie marży API nie wystarcza, gdy dostawca API osiąga lepsze wykorzystanie zasobów i ma większe doświadczenie w obsłudze modeli.
W przypadku tego obciążenia nie udało się ich przezwyciężyć. Opcja z otwartymi wagami zapewniła kontrolę, ale chmura DeepSeek dostarczyła tańsze doświadczenie korzystania z DeepSeek.
Twierdzenie o „80-krotnie niższych kosztach” porównywało różne modele zakupu
Nagłówkowe porównanie osłabło, ponieważ zestawiało publiczne stawki API z intensywnie wykorzystywanym dostępem abonamentowym.
Twierdzenie o „80-krotnie niższych kosztach” porównuje stawki za tokeny przy określonych założeniach. Nie opisuje automatycznie kwoty płaconej przez każdego użytkownika Claude Code.
Firma konsultingowa korzystała z Claude poprzez subskrypcje, a nie rozliczane według użycia API Anthropic. Anthropic potwierdza, że kwalifikujące się plany zapewniają dostęp abonamentowy do Claude Code, z zastrzeżeniem wspólnych limitów użytkowania.
Subskrypcja i API służą różnym wzorcom zakupowym. Subskrypcja łączy dostęp w ramach określonych limitów, podczas gdy API nalicza opłaty według zmierzonego zużycia.
Firma konsultingowa stwierdziła, że jej użycie subskrypcji było równoważne otrzymaniu dużego rabatu względem publicznych stawek API. Ta różnica pochłonęła większość teoretycznej 80-krotnej luki.
Na podstawie ruchu z września firma obliczyła, że API DeepSeek mogłoby kosztować od nieco mniej do więcej niż jej subskrypcje Claude. O tym, gdzie wykorzystanie plasowało się między stawkami szczytowymi i pozaszczytowymi, decydował moment użycia.
Opublikowane wyniki oszacowały również, że publiczna stawka API Claude wygenerowałaby znacznie wyższy rachunek. Nie był to jednak produkt zakupiony przez firmę.
Łatwo przeoczyć to rozróżnienie, gdy porównania sprowadzają każdy produkt do nominalnej stawki za token. Ten sam model może być sprzedawany przez subskrypcje, kontrakty korporacyjne, platformy chmurowe lub bezpośrednie API.
Każdy kanał ma inne limity i zachęty ekonomiczne. Subskrypcja może sprzyjać regularnemu indywidualnemu użyciu, podczas gdy API oferuje programowalną skalę i szczegółowe rozliczanie użycia.
Kontrakt korporacyjny może zapewniać wynegocjowaną przepustowość, zobowiązania usługowe lub mechanizmy kontroli. Self-hosting zastępuje marżę usługową dostawcy infrastrukturą i odpowiedzialnością operacyjną.
Żadna pojedyncza stawka nie oddaje wszystkich czterech modeli. Nabywcy powinni porównywać wariant, który mogą faktycznie kupić i obsługiwać.
Firma konsultingowa obliczyła także koszt jednej scalonej zmiany w kodzie. Jej agenci Claude zrealizowali w badanym okresie 5 610 scalonych zmian, z których pięć później cofnięto.
Oszacowano, że DeepSeek wymagałby dodatkowych tokenów, ponownych prób i weryfikacji opartej na Claude. Przy tych założeniach każda zaakceptowana zmiana kosztowałaby więcej w przypadku DeepSeek.
Szacunek ten wymaga ostrożności. DeepSeek nie wykonywał tego samego zadania z możliwością zapisu, więc badanie nie mogło zaobserwować jego rzeczywistego wskaźnika sukcesu ani całkowitego zużycia tokenów.
Założenia mogą być zbyt surowe, jeśli lepsze prompty, oprogramowanie serwujące lub projekt agentów poprawiłyby wyniki DeepSeek. Mogą też być zbyt optymistyczne, jeśli przegląd wykryłby więcej defektów.
Mimo to koszt na zaakceptowaną zmianę jest bardziej użytecznym wskaźnikiem niż koszt tokena wyjściowego. Łączy wydatki na inferencję z oprogramowaniem, które przechodzi przegląd.
Najlepsza jednostka zależy od przepływu pracy. Zespoły obsługi klienta mogą mierzyć rozwiązane sprawy, a badacze — zweryfikowane ustalenia.
Niska stawka za token pozostaje cenna, gdy modele potrzebują podobnego nakładu pracy, aby osiągnąć te wyniki. Staje się mniej decydująca, gdy różnią się możliwości, opóźnienia lub obciążenie związane z przeglądem.
Wartość „80x” opisuje zatem wąskie porównanie, a nie uniwersalną oszczędność. The Call Center Doctors nie podważyli opublikowanej stawki DeepSeek.
Zamiast tego pokazali, że arytmetyka cenników może się załamać, gdy różnią się produkty, obciążenia i jakość wyników.
Bezpieczeństwo uniemożliwiło DeepSeek pisanie kodu produkcyjnego
Najpoważniejsze ograniczenie eksperymentu było zarazem jego najważniejszym ostrzeżeniem operacyjnym: DeepSeek nigdy nie wykonał planowanego zadania programistycznego.
Firma planowała wykorzystać DeepSeek do agentów piszących kod. Jej recenzenci znaleźli jednak możliwe ścieżki, którymi wygenerowany kod mógłby wydostać się z zamierzonego sandboxa.
Sandbox to odizolowane środowisko wykonawcze, które ogranicza dostęp niezaufanego kodu. Powinien uniemożliwiać agentowi dostęp do wrażliwych plików, poświadczeń, sieci lub uprawnień administracyjnych.
Jedna ze zgłoszonych słabości dotyczyła pliku ustawień we współdzielonym katalogu tymczasowym. Firma uznała, że zmanipulowana zawartość w tym miejscu mogłaby pozwolić wygenerowanemu kodowi działać z podwyższonymi uprawnieniami.
Firma konsultingowa pozostawiła więc agentów wykonujących zadania programistyczne offline. DeepSeek działał wyłącznie za pośrednictwem 48–64 agentów recenzujących w trybie tylko do odczytu.
Recenzenci przeanalizowali 2 377 folderów z kodem i sporządzili 32 raporty błędów. Działanie to wykazało użyteczną przepustowość, ale nie przetestowało autonomicznego wdrażania zmian.
Kwestii bezpieczeństwa nie przedstawiono jako wady wag modelu DeepSeek. Dotyczyła ona otoczenia agentowego firmy konsultingowej i kontroli wykonywania.
To rozróżnienie ma znaczenie. Każdy model zdolny do generowania poleceń może ujawniać słabości źle odizolowanego łańcucha narzędzi.
Claude, DeepSeek lub inny model mogą generować niebezpieczne działania, gdy agenci otrzymują dostęp do systemu plików i powłoki. Granica bezpieczeństwa musi zakładać, że wynik modelu jest niezaufany.
Test połączył więc dwa odrębne pytania. Jedno dotyczyło ekonomiki inferencji DeepSeek. Drugie — tego, czy sandbox agentowy firmy był gotowy na automatyzację z możliwością zapisu.
Bezpośrednie pomiary obciążenia uzyskano tylko dla pierwszego pytania. Drugie zatrzymało planowaną bezpośrednią próbę porównawczą zadań programistycznych.
Uniemożliwia to stanowcze twierdzenie, że Claude tworzył lepszy kod w tym samym eksperymencie. Ukończona przez Claude praca z września była historycznymi danymi produkcyjnymi, podczas gdy praca DeepSeek była ograniczonym testem.
Uniemożliwia to również uczciwy pomiar kosztu DeepSeek na scaloną zmianę. Model nigdy nie otrzymał możliwości wygenerowania zmian do przeglądu i wdrożenia.
Firma odwołała się do publicznych benchmarków programistycznych, aby argumentować, że Opus miał przewagę pod względem możliwości. Benchmarki mogą dostarczać kontekstu, ale nie zastępują identycznego wewnętrznego zestawu zadań.
Rygorystyczne badanie uzupełniające udostępniłoby obu modelom te same repozytoria, narzędzia, ograniczenia bezpieczeństwa, prompty i testy akceptacyjne. Recenzenci pozostaliby nieświadomi tożsamości modelu.
Badanie rejestrowałoby udane zmiany, regresje, ponowne próby, opóźnienia, zużycie tokenów, czas przeglądu przez ludzi i naruszenia bezpieczeństwa. Dopiero wtedy można byłoby bezpośrednio porównać całkowite koszty dostarczania efektów.
Pomimo tego ograniczenia przerwane wdrożenie niesie praktyczną lekcję. Koszt infrastruktury niewiele znaczy, gdy warstwa wykonawcza nie może bezpiecznie udostępnić modelowi zamierzonych narzędzi.
Systemy agentowe rozszerzają powierzchnię ataku, ponieważ łączą probabilistyczny wynik modelu z deterministycznymi działaniami. Jedna niebezpieczna ścieżka może mieć większe znaczenie niż tysiące tanich tokenów.
Przedsiębiorstwa powinny zatem testować mechanizmy izolacji przed obliczaniem oszczędności wynikających z autonomicznej pracy. Analiza tylko do odczytu i agenci z możliwością zapisu należą do bardzo różnych kategorii ryzyka.
Bezpieczeństwo wpływa także na ekonomikę. Silniejsza izolacja może wymagać jednorazowych środowisk, ograniczonych poświadczeń, kontroli sieci, logowania i punktów zatwierdzania.
Te mechanizmy pochłaniają czas inżynierów i zwiększają opóźnienia. Mogą również ograniczać współbieżność lub wymagać odrębnej infrastruktury.
Model o najniższej stawce inferencji może nie zapewnić najniższego kosztu bezpiecznego dostarczenia. Właściwy system obejmuje każdą kontrolę niezbędną, by zaufać jego wynikom.
Co test DeepSeek H200 oznacza dla nabywców AI
Kolejne porównanie powinno skupiać się na zaakceptowanej pracy, trwałym wykorzystaniu zasobów i bezpiecznym wykonaniu, a nie na pojedynczej cenie tokena.
Pierwszym sygnałem, na który należy zwrócić uwagę, jest kontrolowane ponowne uruchomienie z możliwością zapisu. DeepSeek potrzebuje tych samych narzędzi, repozytoriów, promptów i kryteriów akceptacji, które wcześniej stosowano z Claude.
Jeśli wykona porównywalne zmiany przy ograniczonym przeglądzie, negatywny wniosek firmy konsultingowej osłabnie. Jeśli liczba ponownych prób i poprawek pozostanie wysoka, argument dotyczący kosztów opartych na wynikach się wzmocni.
Drugim sygnałem jest trwałe wykorzystanie zasobów przez kilka tygodni. Serwer hostowany samodzielnie staje się bardziej atrakcyjny, gdy użyteczny popyt pozostaje przez cały dzień blisko jego przepustowości.
The Call Center Doctors zmierzyli szczyt przekraczający przepustowość jednej maszyny. Zmienny ruch może jednak nadal pozostawiać kosztowne okresy bezczynności poza tymi szczytami.
Dłuższy test powinien raportować wykorzystanie według godzin, głębokość kolejki, opóźnienie do pierwszego tokena, przerwania oraz udział czasu poświęcanego na ładowanie lub odzyskiwanie sprawności.
Powinien także rozdzielać dane wejściowe z pamięci podręcznej, nowe dane wejściowe i dane wyjściowe. Kategorie te w różny sposób oddziałują z przepustowością pamięci i grupowaniem żądań.
Trzecim sygnałem jest DeepSeek V4.1-Pro. DeepSeek twierdzi, że jego obecna architektura Flash zostanie rozszerzona na większe modele, lecz nie podał konkretnej daty premiery.
Silniejszy model mógłby zmienić ekonomikę, jeśli realizowałby więcej zadań przy mniejszej liczbie ponownych prób. Mógłby też wymagać więcej pamięci albo zapewniać niższą przepustowość.
Nabywcy powinni obserwować zarówno możliwości, jak i wymagania dotyczące obsługi modelu. Poprawa w benchmarkach nie gwarantuje niższego kosztu produkcyjnego.
Obeczne osiągnięcie DeepSeek pozostaje znaczące. Jego oficjalne stawki czynią eksperymenty na dużą skalę bardziej dostępne, a dostępne do pobrania wagi zapewniają elastyczność wdrożenia.
Test nie wymazał tych korzyści. Zawęził warunki, w których przekładają się one na oszczędności.
W przypadku przerywanego lub niepewnego popytu zarządzane API DeepSeek wydaje się bardziej racjonalne niż wynajęcie dedykowanego serwera z czterema GPU. Utrzymuje niskie stawki za tokeny, nie przenosząc operacji infrastrukturalnych na klienta.
W przypadku wrażliwych danych, przewidywalnego stałego popytu lub specjalistycznej optymalizacji self-hosting nadal może zasługiwać na ocenę. Uzasadnienie biznesowe musi uwzględniać personel, niezawodność, bezpieczeństwo i niewykorzystaną pojemność.
Claude Code przedstawia inną propozycję. Łączy dostęp do modelu, interfejs programistyczny i infrastrukturę obsługiwaną przez dostawcę w ramach limitów subskrypcji.
Taki pakiet może przewyższać porównania oparte na tokenach przy intensywnym indywidualnym użyciu. Może też stać się ograniczający, gdy organizacje potrzebują programowalnej przepustowości lub scentralizowanej kontroli.
Presja spada więc na zespoły zakupowe i liderów inżynierii. Muszą przestać traktować „API”, „subskrypcję” i „self-hosted” jako wymienne jednostki zakupu.
Powinni zaczynać od śladów produkcyjnych, a nie przykładów dostawców. Najbardziej użyteczny ślad rejestruje długość kontekstu, trafienia pamięci podręcznej, wyniki, opóźnienia, błędy i zaakceptowane rezultaty.
Zespoły mogą następnie odtwarzać reprezentatywne obciążenia w konkurujących systemach. Test powinien uwzględniać warunki operacyjne istotne po udanej demonstracji.
Warunki te obejmują współbieżność, zmienność ruchu, restarty, kolejkowanie, aktualizacje modeli, monitorowanie i odzyskiwanie sprawności. Testy bezpieczeństwa muszą zostać przeprowadzone, zanim agenci otrzymają dostęp do zapisu.
Metryki wyników powinny odpowiadać celowi organizacji. W przypadku agentów programistycznych obejmują one scalone zmiany, defekty, cofnięcia zmian, czas przeglądu oraz czas realizacji.
Dla agentów wsparcia przydatne wskaźniki obejmują rozwiązane zgłoszenia, eskalacje, satysfakcję klientów i naruszenia zasad. W przypadku agentów badawczych zweryfikowane ustalenia są ważniejsze niż liczba wygenerowanych stron.
Test DeepSeek H200 jest wartościowy, ponieważ przybliżył się do tego standardu. Zastąpił abstrakcyjne porównanie stawek rzeczywistym rozkładem kontekstu i realną infrastrukturą.
Jego ograniczenia są równie pouczające. Krótki czas działania, pojedyncza organizacja, niedokończone prace nad bezpieczeństwem i nierówny dostęp do środowiska produkcyjnego uniemożliwiają wydanie uniwersalnego werdyktu.
Właściwy wniosek jest węższy. Cztery wynajęte H200 nie pokonały API DeepSeek w tym obciążeniu agentowym, a API nie zapewniło oczywistej 80-krotnej przewagi nad subskrypcjami.
To wystarczy, by podważyć uproszczone twierdzenia. Nie wystarczy jednak, by odrzucić DeepSeek, otwarte wagi modeli ani samodzielnie hostowane wnioskowanie.
Przed zmianą stosu AI zbierz dane z tygodnia reprezentatywnego ruchu i oblicz koszt na zaakceptowany wynik. Następnie powtórz porównanie z włączonymi kontrolami bezpieczeństwa.
Zapytaj, czy model wykonuje tę samą pracę do końca, a nie czy jego najtańszy token wygląda imponująco. Kolejny test DeepSeek H200 powinien odpowiedzieć na to trudniejsze pytanie.
