Microsoft-Decision-1 kontra Intern-Decision-2B: o dziewięć milisekund szybszy i mierzalnie gorzej skalibrowany

W tabeli samego InternLM znajduje się liczba, której nie powinno tam być, i to właśnie ona sprawia, że to porównanie jest warte więcej niż karta katalogowa. Intern-Decision-2B — 2 213 241 664 parametrów, dostrojony z Qwen/Qwen3.5-2B, wgrany do Hugging Face 26 września 2026 o 05:36:19 UTC bez żadnej zapowiedzi — osiąga 33.28 ms średniego opóźnienia na zapytanie na pojedynczym RTX 4090, co jest nieznacznie szybciej niż jego własny krewniak z 852 milionami parametrów przy 33,98 ms. Osiąga też najgorszą kalibrację w swojej rodzinie: oczekiwany błąd kalibracji wynoszący 0.100 wobec 0.066 u modelu 0.8B, przy dopasowanej temperaturze 2.100509348278 wobec 2.747760550703 u modelu 0.8B. Tymczasem Microsoft-Decision-1, ogólnie dostępny w Microsoft Foundry od 8 października 2026, nie publikuje ani wskaźnika opóźnienia, ani błędu kalibracji — jedynie akapit metodologii opisujący, jak zmierzono oba. Zatem pytanie, które to starcie naprawdę stawia, nie brzmi, który z tych dwóch jest lepszy. Brzmi: co kupujesz, gdy kupujesz średni rozmiar czegokolwiek.

Oba modele to moduły oceny decyzji: stan na wejściu, ograniczony zestaw pytań na wejściu, skalibrowane prawdopodobieństwa na wyjściu, brak generowanego tekstu i brak tokenów do parsowania. To ten wspólny kontrakt sprawia, że różnice stają się czytelne. Microsoft-Decision-1 to hostowane API Foundry tylko do tekstu, oparte na bazie Qwen3.5-9B z oknem 32 768 tokenów, bez rozproszonych wag i bez ścieżki dostrajania. Intern-Decision-2B to checkpoint na licencji Apache-2.0 z zachowaną licencją upstream Qwen jako LICENSE-QWEN, około 4,46 GB repozytorium, niestandardowy kod wnioskowania i brak jakiegokolwiek hostowanego punktu końcowego.

Do czego właściwie służy średni rozmiar

InternLM wypuścił trzy checkpointy w ciągu czterdziestu sekund: 0.8B o 05:35:57, ten o 05:36:19, 4B o 05:36:37. Według własnej średniej dostawcy z siedmiu zestawów rodzina rośnie w kolejności, na jaką można mieć nadzieję — 79,38, 84,68, 90,02 — i to jest jedyne miejsce, w którym 2B wygląda na rozsądny zakup. Wszędzie indziej wygląda na rozmiar, którego nikt nie wybrałby celowo.

Przetwarzanie promptu dominuje w wywołaniu decyzyjnym i to jest mechaniczne wyjaśnienie odwrócenia latencji, a nie żadna tajemnica. Scorer wykonuje dokładnie jeden przebieg w przód po promptcie, którego długość wyznaczają stan, schemat i opisy opcji — nigdy przez cokolwiek, co zapisuje model, ponieważ model nic nie zapisuje. W tym reżimie liczba parametrów jest kosztem drugorzędnym, więc zwykły powód, by sięgać po najmniejszy checkpoint, nie ma zastosowania: nie oszczędzasz czasu, oszczędzasz pamięć. Całe repozytorium wersji 0.8B ma około 1,73 GB w porównaniu z 4,46 GB tego modelu i to jest uczciwy powód, by ją preferować. Jedynym prawdziwym atutem wersji 2B jest to, że akurat jest najszybszą z szybkich, a przewaga jest tak mała, że można ją uznać za szum.

W zestawieniu z Microsoft-Decision-1 to twierdzenie jest niemal nieistotne, ponieważ oba modele nie znajdują się w tym samym reżimie opóźnień. Szybkość hostowanego punktu końcowego zależy przede wszystkim od kształtu wdrożenia — bezserwerowe versus aprowizowana przepustowość na tym samym standardowym SKU — a dopiero potem od modelu, a Microsoft nie publikuje żadnej wartości na wywołanie do porównania. To, co Microsoft publikuje, to twarde ograniczenie operacyjne działające w przeciwnym kierunku: wnioskowanie wsadowe jest wyłączone. Nie ma kanału offline, przez który można by amortyzować masowy przebieg scoringu, więc potok Microsoft-Decision-1 ponosi koszt interaktywny każdej decyzji, podczas gdy samodzielnie hostowany checkpoint płaci w godzinach GPU niezależnie od tego, czy wykonuje scoring.

Kolumna kalibracyjna, w której środek przegrywa

Przeczytaj trzy karty Intern-Decision razem, a rodzina przestaje zachowywać się przewidywalnie. Dokładność jest monotoniczna względem rozmiaru; kalibracja już nie. Model 2B ma ECE na poziomie 0,100 — najsłabszy z trzech — oraz dopasowaną temperaturę 2,100509348278, znacznie poniżej 2,747760550703 modelu 0.8B. Karta instruuje, aby użyć modułu wnioskowania dołączonego do pobranego rozmiaru, ponieważ domyślne kalibracje są przypisane do poszczególnych checkpointów; każdy, kto kopiuje wrapper z jednego modelu bliźniaczego do drugiego, po cichu stosuje niewłaściwą temperaturę.

Samo przekształcenie warto zrozumieć, zanim potraktujesz to 0,100 jako wyrok na wagi. To softmax po logitach kandydatów danego pola, a następnie drugi softmax po logarytmie tego rozkładu podzielonym przez temperaturę. Ponieważ działa po pierwszym softmaxie i zachowuje porządek, nie może w ogóle zmienić argmax. Przesuwa pewność, prawdopodobieństwo odpowiedzi „tak” oraz wartość oczekiwaną pytania punktowanego, a etykietę pozostawia identyczną. Jeśli twój pipeline czyta etykiety, temperatura jest bez znaczenia, a ECE to ciekawostka. Jeśli twój pipeline czyta prawdopodobieństwa — stosuje do nich progi, szereguje według nich, podaje je do obliczenia wartości oczekiwanej — to ECE równe 0,100 jest różnicą między progiem, który znaczy to, co napisałeś, a takim, który tego nie robi. Właściwą reakcją jest dopasowanie własnej temperatury na własnych oznaczonych przypadkach, a nie wyciąganie wniosku, że wagi są złe.

Microsoft-Decision-1 wymaga dokładnie tej samej pracy, mając mniej na starcie. Jego zakładka Benchmarks podaje, że dokładność, błąd kalibracji, wykrywalność bezpieczeństwa, wskaźniki fałszywie dodatnich i spójność w zakresie sprawiedliwości mierzono na publicznych i społecznościowych benchmarkach decyzyjnych oraz odłożonych wewnętrznych zbiorach testowych, że zmieniano kolejność opcji, że zastosowano sparowane testy statystyczne oraz że model „osiąga wyniki na równi z wiodącymi modelami decyzyjnymi i wyprzedza inne otwarte modele decyzyjne oceniane według tej samej metodologii”. Brak ECE. Brak Brier. Brak temperatury. Brak tabeli dokładności. Model, którego całą propozycję wartości stanowi wiarygodne prawdopodobieństwo, jest w tym porównaniu tym, który nie ma w ogóle opublikowanej liczby kalibracyjnej.

Granice kontraktu: cztery rzeczy, których hostowany model nie zrobi

Oba modele przyjmują coś, co wygląda na to samo wywołanie, a rozbieżności tkwią na jego krawędziach.

• Modalność — Microsoft-Decision-1 obsługuje wyłącznie tekst i nie przyjmuje obrazów, dźwięku ani wideo. Intern-Decision-2B przyjmuje do ośmiu obrazów wraz ze stanem, co czyni go kandydatem do segregacji zrzutów ekranu i kontroli układu, którym hostowane API nie jest w stanie sprostać przy żadnej dokładności.

• Górny limit danych wejściowych i tryb awarii — Microsoft-Decision-1 wykonuje pojedyncze wywołanie obejmujące do 32 768 tokenów. Intern-Decision-2B deklaruje DecisionEngine(max_length=8192) i odrzuca zbyt duże dane wejściowe, zamiast je obcinać, co jest poprawnym zachowaniem dla modułu oceniającego, a także twardą barierą, ponieważ stan, schemat i szkielet muszą wszystkie być obecne w jednym przebiegu; żadna strategia dzielenia na fragmenty nie zachowuje kontraktu.

• Kształt pytania — InternLM dokumentuje od jednego do szesnastu pytań na wywołanie, z maksymalnie 62 opcjami w każdym, w ramach trzech typów pól (choice, score, noul), gdzie noul to binarne tak/nie zwracające prawdopodobieństwo, a score zwraca ważoną prawdopodobieństwem wartość oczekiwaną w skali, którą podasz. Microsoft dokumentuje te formaty — tak/nie, wielokrotny wybór, ocena, klasyfikacja, rubryka — a także jawnie obsługiwaną opcję wstrzymania się, taką jak „nie można stwierdzić”, gdy dowody są niewystarczające, co jest najbardziej użyteczną informacją na tej stronie dla każdego, kto pisze logikę eskalacji.

• Cena — strona modelu Microsoft-Decision-1 nie podaje stawki; informacje o cenach prowadzą do strony cenowej Microsoft, więc koszt na decyzję odczytuje się z Azure albo z faktury, przy czym 0% tego kosztu można przypisać tokenom wyjściowym, ponieważ ich nie ma. Intern-Decision-2B nie kosztuje nic za wywołanie, a cały koszt stanowi czas GPU, i nie ma dostawcy hostującego. Jego rozmiar magazynowy to około 4,46 GB, na co składają się: 3,76 GB shardu językowego, 612,5 MB wieży wizyjnej i 50,3 MB projektora.

Co zostało potwierdzone, a co to tylko słowa dostawcy?

Cała dyscyplina w przypadku tej rodziny polega na rozdzielaniu tych dwóch kategorii. Potwierdzone przez listing plików lub odpowiedź HTTP: liczba parametrów, mapa shardów, para licencji, model bazowy, architektura leżąca u podstaw — Qwen3_5ForConditionalGeneration z 24 warstwami, rozmiarem ukrytym 2 048, 8 głowicami zapytań wobec 2 głowic klucz-wartość, wymiarem głowicy 256, powtarzającym się wzorcem trzech warstw uwagi liniowej na jedną warstwę pełnej uwagi, jedną zachowaną warstwą przewidywania wielu tokenów i pułapem osadzania wynoszącym 262 144 pozycje, który pułap silnika wynoszący 8 192 tokeny czyni praktycznie nieistotnym.

Raportowane przez dostawcę i nieodtworzone: każda liczba dotycząca dokładności, każda wartość opóźnienia i temperatura. Nie ma publikacji, wpisu na arXiv, wpisu o premierze, dziennika zmian ani niezależnej ewaluacji. Demo Space zwraca 401, co oznacza, że nie jest publiczne, a nie że jest zepsute. Repozytorium GitHub, które pojawiło się po modelu — trzy commity, kod treningowy, dwa backendy wnioskowania, pakiet ewaluacyjny z 10 751 wierszami testowymi, benchmark kalibracyjny obejmujący 96 przypadków i przewodnik reprodukcji — to więcej dokumentacji, niż otrzymuje większość cichych wydań, a nie dostarcza żadnych wag, danych treningowych ani licencji na kod. Microsoft jest w innej, ale pokrewnej sytuacji: jego metodologia jest prawdziwa, a jego twierdzenie ma charakter jakościowy, i obecnie żadna z tych firm nie jest w stanie sprawić, by jej kluczowa liczba została zweryfikowana przez kogokolwiek innego niż ty.

Gdzie w takim potoku znajduje się OrcaRouter

Żaden z tych modeli nie znajduje się w naszym katalogu i nic tutaj nie powinno być odczytywane jako twierdzenie o dostępności. Model, który zwraca prawdopodobieństwa zamiast tekstu, nie jest czymś, do czego kieruje się uzupełnienia czatu, i dotyczy to obu tych przypadków. To, co rzeczywiście mamy, to generatywna połowa pętli, której te scorery mają służyć: ponad 200 modeli za jednym kluczem zgodnym z OpenAI, które piszą rubrykę, tworzą szkice odpowiedzi-kandydatów i emitują wywołanie narzędzia, które scorer ocenia, zanim zostanie ono wykonane. Cena katalogowa dostawcy jest przekazywana z marżą 0%, więc obniżka ceny dostawcy po stronie generującej obowiązuje u nas tego samego dnia, a jeśli wolisz nie stawiać swojego progu na jednym sędzim, DSL routingu składa kilka modeli w jedno wywołanie, a fuzja modeli raportuje ich zgodność jako pole, które możesz ocenić. Automatyczne przełączanie awaryjne utrzymuje tę stronę przy życiu, gdy pojedynczy dostawca zawodzi, co ma większe znaczenie w pętli, która ocenia wszystko, co widzi, niż w takiej, która odpowiada użytkownikowi od czasu do czasu.

Konkluzja

Microsoft-Decision-1 jest ogólnie dostępny w Microsoft Foundry od 8 października 2026 r.: hostowany, wyłącznie tekstowy, 32 768 tokenów, bazowy model Qwen3.5-9B dotrenowany przez Microsoft, brak udostępnianych wag oraz sekcja benchmarków, która dokumentuje jego metodologię, nie podając żadnej liczby — w tym żadnego opóźnienia, przy wyłączonym wnioskowaniu wsadowym. Intern-Decision-2B to checkpoint na licencji Apache-2.0 o 2 213 241 664 parametrach z 26 września 2026 r., który jest najszybszy z trzech modeli siostrzanych — 33,28 ms na 4090 — i najgorzej skalibrowany, z ECE 0,100, z dopasowaną temperaturą 2,100509348278, która nie może zmienić etykiety, ale zmieni każdą pewność, względem której ustawiasz próg. Jeśli chcesz rozmiar pośredni, uczciwe uzasadnienie dla niego jest słabe: zapłać dodatkowe 2,7 GB za dokładność 4B albo zaakceptuj ślad 0,8B, a w obu przypadkach dopasuj własną kalibrację, zanim jakikolwiek próg zbliży się do produkcji.

To, co rzeczywiście dostarczamy, to generatywna połowa pętli, której służyć mają te systemy oceniające: ponad 200 modeli za jednym kluczem zgodnym z OpenAI, które piszą rubrykę, szkicują odpowiedzi kandydatów i emitują wywołanie narzędzia, które oceniający następnie ocenia, zanim zostanie wykonane.