Routing oparty na rozumowaniu w bramie API AI: kontroluj tokeny myślenia, opóźnienia i koszty u różnych dostawców

Głębokość rozumowania nie jest już prostą opcją modelu. Niektórzy dostawcy udostępniają poziomy wysiłku w stylu wyliczeniowym. Inni eksponują symboliczne budżety, dynamiczne myślenie lub modelowe rodziny, w których myślenia nie można całkowicie wyłączyć. Widoczna odpowiedź może być krótka, podczas gdy ukryte rozumowanie zużywa płatne tokeny wyjściowe. Jeśli każdy zespół ds. aplikacji ustawi te kontrole bezpośrednio, koszty, opóźnienia i jakość staną się trudne do wyjaśnienia.

Praktycznym rozwiązaniem jest przeniesienie kontroli opartej na wnioskowaniu do bramy API. Brama powinna klasyfikować obciążenie, mapować je do kontroli wnioskowania specyficznej dla dostawcy, egzekwować budżety dzierżawy, rejestrować rzeczywiste wykorzystanie wnioskowania i sprawiać, że decyzje o przejściu na niższą wersję będą widoczne w analizach. Identyfikator modelu, poziom usług, maksymalna wydajność i głębokość rozumowania powinny być oddzielnymi wymiarami polityki.

Problem czytelnika: proste żądania opłacają się za głębokie rozumowanie

Zespoły przyjmujące modele zdolne do rozumowania zwykle zaczynają od rozsądnego celu: poprawy jakości trudnych zadań. Problem pojawia się później, gdy te same wartości domyślne są ponownie wykorzystywane do wyodrębniania, krótkich podsumowań, formatowania i klasyfikacji. Żądania te nie wymagają kosztownych obliczeń w czasie testowania, ale mogą je wywołać.

Powoduje to trzy błędy operacyjne:

• Przejrzystość kosztów: użytkownik widzi krótką odpowiedź, ale księga zawiera ukryte tokeny rozumowania lub odpowiedniki specyficzne dla dostawcy.
• Dryf opóźnienia: przepływ pracy, który wyglądał na interaktywny, staje się powolny, ponieważ w przypadku tego samego modelu wzmożony został wysiłek rozumowania alias.
• Fragmentacja zasad: każdy zespół ds. produktu uczy się różnych parametrów dostawców i stosuje różne ograniczenia.

Zasady rozumowania na poziomie bramy rozwiązują problem kontroli, zanim stanie się on problemem z rozliczeniami.

Fakty: Kontrole rozumowania dostawcy nie są równoważne

Poniżej znajdują się fakty dotyczące implementacji, a nie zalecenia.

• Interfejsy API obsługujące rozumowanie OpenAI ujawniają obiekt reasoning dla obsługiwanych modeli, w tym wartości wysiłku, takie jak none, minimal, low, medium, high i xhigh. Mniejszy wysiłek może zmniejszyć tokeny wnioskowania i poprawić szybkość reakcji.
• Dokumentacja OpenAI stwierdza, że ​​max_output_tokens może ograniczyć całkowitą liczbę wygenerowanych tokenów, w tym zarówno tokeny wnioskowania, jak i końcowe tokeny wyjściowe.
• Rozszerzone myślenie antropiczne można włączyć za pomocą wartości budget_tokens. Tokeny myślenia są rozliczane jako tokeny wyjściowe i wliczane do max_tokens obok widocznego tekstu odpowiedzi.
• Dokumentacja Anthropic zauważa również, że liczba naliczonych tokenów wyjściowych może nie odpowiadać liczbie widocznych tokenów odpowiedzi, ponieważ wewnętrzne tokeny myślenia mogą być rozliczane nawet wtedy, gdy nie są w pełni widoczne.
• Dokumentacja myślenia Gemini stwierdza, że wycena odpowiedzi może obejmować zarówno tokeny wyjściowe, jak i tokeny myślące, z polami użycia oddzielającymi tokeny myśli i dane wyjściowe tokeny.
• Kontrola w stylu Gemini 2.5 obejmuje thinkingBudget z dynamicznym myśleniem na obsługiwanych modelach i wyłączaniem zerowego budżetu w niektórych rodzinach modeli. Niektóre modele nie mogą wyłączyć myślenia.
• Nowe wytyczne Gemini zalecają wartości thinking_level, takie jak minimal, low, medium i high dla modeli w stylu Gemini 3.x zamiast surowych budżetów liczbowych.

Konsekwencje architektury podstawowej są proste: nie eksponuj kontroli rozumowania natywnego dostawcy jako jedynej umowy. Nie są wystarczająco stabilne, wystarczająco przenośne ani wystarczająco porównywalne, aby można było zarządzać wieloma dostawcami.

Zalecenie: utwórz profile rozumowania neutralne dla dostawcy

Zdefiniuj małe wewnętrzne słownictwo, które zespoły produktowe będą mogły zrozumieć bez konieczności czytania dokumentacji API każdego dostawcy.W przypadku większości bram wystarczy pięć profili:

Profil to kontrakt skierowany do aplikacji. Parametry dostawcy stają się szczegółami adaptera. Dzięki temu kod klienta jest przenośny i pozwala właścicielom platform aktualizować mapowania w miarę zmiany interfejsów API dostawców.

Mapuj klasy obciążenia przed mapowaniem dostawców

Wysiłek wnioskowania należy wybierać na podstawie przeznaczenia obciążenia, a nie osobistych preferencji lub popularności modelu. Dodaj pole bramy, takie jak workload_class, dostarczone przez klienta lub wywnioskowane z zatwierdzonej konfiguracji trasy.

Przykładowa polityka obciążenia

{
  „polityka obciążenia_pracą”: {
    "pola_wyciągu_faktury": {
      "default_reasoning_profile": "brak",
      "max_reasoning_profile": "niski",
      „max_output_tokens”: 800
    },
    „classify_support_ticket”: {
      "default_reasoning_profile": "brak",
      "max_reasoning_profile": "niski",
      „max_output_tokens”: 300
    },
    "wersja robocza_odpowiedzi_klienta": {
      "default_reasoning_profile": "niski",
      "max_reasoning_profile": "standardowy",
      „max_output_tokens”: 1200
    },
    „code_review”: {
      "default_reasoning_profile": "standardowy",
      "max_reasoning_profile": "głęboki",
      „max_output_tokens”: 4000
    },
    „przegląd_bezpieczeństwa”: {
      "default_reasoning_profile": "głęboki",
      "max_reasoning_profile": "ograniczona głębokość",
      „max_output_tokens”: 6000
    },
    "plan_agenta": {
      "default_reasoning_profile": "standardowy",
      "max_reasoning_profile": "głęboki",
      „max_output_tokens”: 5000
    }
  }
}

Ta zasada spełnia dwie przydatne funkcje. Po pierwsze, zapobiega dziedziczeniu kosztownych ustawień domyślnych przez proste punkty końcowe. Po drugie, zapewnia administratorom konkretną powierzchnię do przeglądu: które przepływy pracy mogą żądać głębokiego uzasadnienia i przy jakich ograniczeniach?

Stwórz macierz zgodności

Adapter bramy powinien utrzymywać macierz dla każdego dostawcy i rodziny modeli. Zapisz co najmniej, czy model obsługuje wyłączanie wnioskowania, wysiłek wyliczeniowy, budżet numeryczny, myślenie dynamiczne, maksymalny obsługiwany budżet i pola użycia dla tokenów wnioskowania.

Przykładowy kształt macierzy

{
  "dostawcy": {
    "dostawca_a": {
      „rodzina_modeli_x”: {
        „supports_reasoning”: prawda,
        "typ_kontroli": "wyliczenie_wysiłku",
        „allowed_values”: [„brak”, „minimalny”, „niski”, „średni”, „wysoki”, „xwysoki”],
        „can_disable”: prawda,
        „reports_reasoning_tokens”: prawda
      }
    },
    "dostawca_b": {
      "model_rodzina_y": {
        „supports_reasoning”: prawda,
        "control_type": "budget_tokens",
        „min_budżet_tokens”: 1024,
        „max_budget_tokens”: 32000,
        „can_disable”: fałsz,
        „reports_reasoning_tokens”: prawda
      }
    },
    "dostawca_c": {
      "model_rodzina_z": {
        „supports_reasoning”: prawda,
        "control_type": "poziom myślenia",
        „allowed_values”: [„minimalne”, „niskie”, „średnie”, „wysokie”],
        „can_disable”: fałsz,
        „reports_reasoning_tokens”: prawda
      }
    }
  }
}

Macierz zgodności nie jest dokumentacją przeznaczona wyłącznie dla ludzi. Powinna to być polityka wykonywalna. Router żądań powinien go używać przed wysyłką, a księga rozliczeniowa powinna używać go podczas rozliczeń.

Przetłumacz profile wewnętrzne na parametry dostawcy

Mapowania dostawców powinny być jawne i wersjonowane. Nie polegaj na niejasnych sformułowaniach, takich jak „stosuj mądrzejsze rozumowanie”. Brama powinna dokładnie wiedzieć, który parametr dostawcy został wysłany.

Przykładowe mapowanie

{
  "reasoning_profile_mappings": {
    „brak”: {
      "effort_enum": "brak",
      "budżet_tokens": 0,
      "thinking_level": "minimalny"
    },
    „niski”: {
      "effort_enum": "niski",
      „budżet_tokens”: 2048,
      „thinking_level”: „niski”
    },
    „standardowy”: {
      "wysiłek_enum": "średni",
      „budżet_tokens”: 8192,„poziom myślenia”: „średni”
    },
    „głęboko”: {
      "effort_enum": "wysoki",
      "budżet_tokens": 20000,
      „thinking_level”: „wysoki”
    },
    „ograniczona głębokość”: {
      "effort_enum": "wysoki",
      „budżet_tokens”: 12000,
      „thinking_level”: „wysoki”
    }
  }
}

Te liczby są przykładami, a nie uniwersalnymi wartościami domyślnymi. Właściwe budżety zależą od rodziny modeli, cen, wymagań dotyczących opóźnień i wyników oceny. Ważnym szczegółem implementacji jest to, że brama jest właścicielem mapowania i rejestruje rozpoznany parametr dostawcy dla każdego żądania.

Zamykanie błędu, gdy mapowanie jest niebezpieczne

Nieobsługiwane mechanizmy wnioskowania nie powinny po cichu stać się domyślnymi ustawieniami dostawcy. Wartości domyślne mogą być kosztowne i mogą zmieniać się z biegiem czasu.

Jeśli nie można bezpiecznie zmapować żądanego profilu, użyj jednego z trzech wyników:

• Zezwól: dostawca/model obsługuje żądany profil i zasady najemcy na to pozwalają.
• Obniżenie wersji: żądany profil jest powyżej zasad, więc brama stosuje najwyższy zatwierdzony profil i rejestruje przejście na niższą wersję.
• Odrzuć: profil nie można bezpiecznie reprezentować, najemca wymaga rygorystycznego zachowania lub obniżenie wersji naruszyłoby oczekiwania produktu.

Przykładowy zapis decyzji

{
  "request_id": "req_123",
  "ident_dzierżawcy": "dzierżawca_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "głęboki",
  "applied_reasoning_profile": "standardowy",
  „decyzja”: „obniżona ocena”,
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "dostawca_a",
  "served_model": "model_rodzina_x",
  "provider_reasoning_param": {
    „wysiłek”: „średni”
  }
}

Ten zapis decyzji jest cenny podczas wsparcia, sporów dotyczących rozliczeń i dochodzeń dotyczących jakości. Zapobiega także niewidocznym regresjom jakości podczas presji budżetowej.

Kontrola budżetu wymaga więcej niż maksymalna liczba tokenów wyjściowych

Maksymalny limit tokenów wyjściowych jest konieczny, ale nie wystarczający. W przypadku modeli zdolnych do wnioskowania model może poświęcić dużą część rozumowania granicznego i pozostawić zbyt mało miejsca na ostateczną odpowiedź. Użytkownik może następnie zapłacić za bezużyteczną, skróconą odpowiedź.

Użyj warstwowych pułapów:

• max_reasoning_profile na dzierżawcę, klucz API i przepływ pracy.
• max_thinking_budget lub odpowiednik na parę dostawca/model.
• max_output_tokens dla wszystkich wygenerowanych tokenów, w których dostawca zlicza rozumowanie i widoczne dane wyjściowe razem.
• daily_deep_reasoning_spend na każdego najemcę lub klienta-sprzedawcę.
• deep_reasoning_requests_per_hour w przypadku punktów końcowych o dużym natężeniu ruchu.
• reasoning_token_ratio_threshold w przypadku alertów o anomaliach.

Kontrola budżetu powinna nastąpić przed wysyłką. Krok rozliczeniowy powinien następnie uzgodnić rzeczywiste wykorzystanie po nadejściu odpowiedzi dostawcy. Jeśli dostawca zgłasza, że ​​myśli o tokenach osobno, przechowuj je osobno. Jeśli raportuje tylko łączne tokeny wyjściowe, przechowuj najlepsze dostępne znormalizowane pola i zaznacz poziom ufności.

Pola księgi do wykorzystania w rozumowaniu

Analityka musi pokazywać różnicę między widoczną długością odpowiedzi a płatnym wysiłkiem rozumowania. Przydatny wiersz księgi powinien zawierać:

• tenant_id, api_key_id, end_user_id i workflow.
• requested_model, served_model, dostawcę i alias modelu.
• requested_reasoning_profile i applied_reasoning_profile.
• provider_reasoning_param, przechowywany jako ustrukturyzowany JSON.
• input_tokens, visible_output_tokens, reasoning_tokens_or_equivalent, cached_tokens i total_billable_tokens.
• max_output_tokens i dowolny budżet dostosowany do dostawcy.
• latency_to_first_token_ms, total_latency_ms i stan ukończenia strumienia.
• estimated_cost_before_dispatch, reserved_budget, settled_cost i reconciliation_status.
• policy_decision, na przykład dozwolone, obniżone, odrzucone lub awaryjne.

Domyślnie nie rejestruj nieprzetworzonego łańcucha przemyśleń. W przypadku większości prac związanych z zarządzaniem i FinOps wystarczą liczenia i decyzje polityczne. Przechowywanie wrażliwego tekstu uzasadnienia może powodować możliwe do uniknięcia problemy związane z prywatnością, zgodnością i przechowywaniem.

Przebieg wdrażania

Brama produkcyjna może wdrożyć routing wysiłku wnioskowania jako deterministyczny potok żądań.

1. Uwierzytelnij żądanie. Rozwiąż dzierżawę, klucz API, użytkownika, zespół i przepływ pracy.
2. Sklasyfikuj obciążenie. Jeśli to możliwe, użyj jawnego pola klienta.W przypadku znanych punktów końcowych powiąż klasę obciążenia podczas konfiguracji trasy.
3. Wczytaj zasady. Scal ograniczenia globalne, dzierżawy, klucza i przepływu pracy.
4. Wybierz kandydatów na modele. Użyj istniejącego aliasu modelu lub zasad wyboru modelu przed rozstrzygnięciem kontroli rozumowania.
5. Rozwiąż profil rozumowania. Zacznij od żądanego profilu, a następnie zastosuj domyślne ustawienia przepływu pracy i maksymalne.
6. Sprawdź zgodność. Potwierdź, że para dostawca/model bezpiecznie obsługuje wybrany profil.
7. Oszacuj koszt i budżet rezerwowy. Uwzględnij prawdopodobne użycie rozumowania, a nie tylko widoczne dane wyjściowe.
8. Wysyłaj z parametrami natywnymi dostawcy. Wyślij wysiłek wyliczeniowy, tokeny budżetowe, poziom myślenia lub brak kontroli rozumowania w zależności od adaptera.
9. Normamalizuj użycie włączone odpowiedź. Oddziel dane wejściowe, widoczne dane wyjściowe, wnioskowanie, buforowane, narzędzia i tokeny sumy, jeśli to możliwe.
10. Rozliczanie i ostrzeganie. Uzgadnianie kosztów zarezerwowanych i rzeczywistych, aktualizowanie przydziałów i emitowanie sygnałów o anomaliach.

Ten potok pozwala na kontrolę kontroli rozumowania. Daje także zespołom zajmującym się platformami jedno miejsce do zmiany ustawień domyślnych w miarę ewolucji interfejsów API dostawców.

Ocena przed zmianą ustawień domyślnych

Nie promuj większego wysiłku w rozumowaniu w oparciu tylko o kilka imponujących przykładów. Przeprowadź oceny przed zmianą ustawień domyślnych dla klasy obciążenia.

Zmierz co najmniej cztery wyniki:

• Jakość zadania: dokładność, akceptacja recenzenta, ważność schematu lub powodzenie wywołania narzędzia.
• Opóźnienie: czas do pierwszego tokena i całkowity czas ukończenia.
• Koszt: koszt żądania i koszt zaakceptowanej odpowiedzi.
• Niepowodzenie tryby: obcięcie, odmowa, zniekształcone dane wyjściowe, nadmierne wywołania narzędzi lub przekroczenie limitu czasu.

Kluczowym wskaźnikiem nie jest „tokeny na żądanie”. Odpowiedź z niższym tokenem, która nie przejdzie weryfikacji, może być droższa po ponownych próbach. Odpowiedź z wyższym uzasadnieniem może być uzasadniona do przeglądu bezpieczeństwa, ale jest marnotrawstwem w przypadku oznaczania biletów. Oceniaj na podstawie przepływu pracy.

Kompromisy

Rozsądne zarządzanie zwiększa kontrolę, ale nie jest darmowe.

• Przenośność w porównaniu z funkcjami dostawcy: profile wewnętrzne zapewniają przenośność kodu aplikacji, ale zaawansowane zespoły mogą potrzebować zatwierdzonej luki ratunkowej do kontroli specyficznej dla dostawcy.
• Pewność budżetu kontra jakość: twarde limity chronią najemców przed niekontrolowanymi wydatkami, ale zbyt wąskie ograniczenia mogą zostać obcięte przydatne odpowiedzi po zużyciu tokenów wnioskowania.
• Dynamiczne myślenie a przewidywalność: dynamiczna kontrola dostawcy może poprawić wygodę, ale osłabia szacunki kosztów przed wysyłką, chyba że brama rejestruje rzeczywiste wykorzystanie i wymusza limity rozliczeniowe.
• Obniżenie dostępności a spójność: obniżenie poziomu rozumowania podczas presji budżetowej pozwala zachować dostępność, ale odpowiedź powinna być oznaczona w telemetrii i uwzględniona w ocenie jakości.
• Analiza a prywatność: metryki oparte na tokenach wnioskowania są przydatne, ale surowe ślady wnioskowania nie powinny być przechowywane, chyba że istnieje przemyślana, zatwierdzona polityka przechowywania.

Przewidywanie: polityka wnioskowania stanie się standardową kontrolą bramy

To jest przewidywanie, a nie zweryfikowany fakt: wysiłek wnioskowania stanie się normalną kontrolą produkcji obok routingu modelu, limitów stawek, poziomów usług i budżetów tokenów. W miarę jak dostawcy będą w dalszym ciągu ujawniać różne kontrole myślenia, zespoły aplikacyjne będą miały mniejszy apetyt na zakodowanie na stałe tych różnic w kodzie produktu.

Bramy, które traktują rozumowanie jako kontrolowany wymiar czasu wykonania, będą miały jaśniejsze rozliczenia z dzierżawcami, czystszą przenośność i lepszą kontrolę nad opóźnieniami.Bramy, które traktują to jako przypadkowy parametr modelu, będą miały trudności z wyjaśnieniem, dlaczego krótkie odpowiedzi czasami kosztują więcej niż długie.

Lista kontrolna, którą można zastosować

• Zdefiniuj profile wewnętrzne: brak, niski, standard, głęboki i ograniczony zakres.
• Przypisz profile domyślne i maksymalne do każdego obciążenia class.
• Utwórz macierz zgodności dostawcy/modelu na potrzeby kontroli wnioskowania.
• Przetłumacz profile na parametry natywne dostawcy w warstwie adaptera.
• Zamykanie awaryjne, gdy nie można bezpiecznie zmapować żądanego profilu.
• Zarezerwuj budżet przed wysłaniem, korzystając z szacunków uwzględniających rozumowanie.
• Zarejestruj żądany profil, zastosowany profil, parametr dostawcy, wykorzystanie wnioskowania, widoczne dane wyjściowe, opóźnienie i koszt.
• Dodaj anomalię alerty dotyczące wysokiego współczynnika tokenów rozumowania i głębokiego rozumowania w prostych przepływach pracy o dużej objętości.
• Przeprowadź oceny na poziomie przepływu pracy przed zmianą domyślnego wysiłku.
• Domyślnie unikaj rejestrowania nieprzetworzonego tekstu uzasadnienia; zamiast tego zliczanie sklepów i decyzje dotyczące zasad.

Wnioski

Modele zdolne do wnioskowania są przydatne, ponieważ pozwalają przeznaczyć więcej mocy obliczeniowej na rozwiązywanie trudnych problemów. Ta sama funkcja staje się kosztowna, jeśli jest stosowana bezkrytycznie. Bramka powinna decydować, kiedy dozwolone jest głębsze rozumowanie, w jaki sposób przypisuje się do każdego dostawcy, ile może wykorzystać budżet i w jaki sposób mierzony jest wynik.

Trwały wzorzec polega na oddzieleniu wysiłku wnioskowania od identyfikatora modelu. Kieruj według obciążenia, ograniczaj według zasad dzierżawy, dostosowuj według dostawcy i rozliczaj rzeczywiste wykorzystanie w księdze. To zmienia rozumowanie z ukrytej zmiennej kosztowej w wyraźną powierzchnię kontrolną do kontroli kosztów interfejsu API AI.

Powiązana lektura

• księga rozliczeniowa, która rezerwuje i rozlicza każde wywołanie modelu
• aliasy modeli wewnętrznych i kontrakty dotyczące możliwości
• rozliczanie tokenów strumieniowych pod kątem końcowego wykorzystania i częściowego odpowiedzi