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 elementy sterujące bezpośrednio, koszty, opóźnienia i jakość staną się trudne do wyjaśnienia.

Praktyczną odpowiedzią jest przeniesienie kontroli wysiłku wnioskowania 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 testów, 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: a przepływ pracy, który wyglądał na interaktywny, staje się powolny, ponieważ w przypadku tego samego aliasu modelu wzrósł wysiłek w zakresie rozumowania.
• Fragmentacja zasad: każdy zespół ds. produktu uczy się parametrów innych dostawców i stosuje różne ograniczenia.

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

Fakty: Kontrola rozumowania dostawcy nie istnieje Odpowiednik

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

• OpenAI Interfejsy API umożliwiające wnioskowanie udostępniają 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.
• OpenAI Dokumentacja stwierdza, że ​​max_output_tokens może ograniczyć całkowitą liczbę wygenerowanych tokenów, w tym zarówno tokeny rozumowania, jak i końcowe tokeny wyjściowe.
• Anthropic rozszerzone myślenie 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.
• Anthropic W dokumentacji odnotowano 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.
• Gemini dokumentacja myślenia stwierdza, że wycena odpowiedzi może obejmować zarówno tokeny wyjściowe, jak i tokeny myślenia, z polami użycia oddzielającymi myśli tokeny i tokeny wyjściowe.
• Gemini Elementy sterujące w stylu 2.5 obejmują thinkingBudget z dynamicznym myśleniem o obsługiwanych modelach i wyłączeniem przy zerowym budżecie w niektórych rodzinach modeli.Niektóre modele nie mogą wyłączyć myślenia.
• Nowsze wytyczne Gemini zalecają wartości thinking_level, takie jak minimal, low, medium i high dla modeli Gemini w stylu 3.x zamiast surowych budżetów liczbowych.

Konsekwencje architektury podstawowej są proste: nie eksponuj kontroli rozumowania natywnej 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 uzasadniające neutralne dla dostawcy

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

Profil jest umową skierowaną 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 dostawcami mapowania

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 zasada obciążenia

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "none",
      "max_reasoning_profile": "low",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "none",
      "max_reasoning_profile": "low",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "low",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "deep",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "deep",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "deep",
      "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ą wymagać głębokiego uzasadnienia i pod jakimi ograniczeniami?

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

{
  "providers": {
    "provider_a": {
      "model_family_x": {
        "supports_reasoning": true,
        "control_type": "effort_enum",
        "allowed_values": ["none", "minimal", "low", "medium", "high", "xhigh"],
        "can_disable": true,
        "reports_reasoning_tokens": true
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": true,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": false,
        "reports_reasoning_tokens": true
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": true,
        "control_type": "thinking_level",
        "allowed_values": ["minimal", "low", "medium", "high"],
        "can_disable": false,
        "reports_reasoning_tokens": true
      }
    }
  }
}

Macierz zgodności nie jest dokumentacją 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": {
    "none": {
      "effort_enum": "none",
      "budget_tokens": 0,
      "thinking_level": "minimal"
    },
    "low": {
      "effort_enum": "low",
      "budget_tokens": 2048,
      "thinking_level": "low"
    },
    "standard": {
      "effort_enum": "medium",
      "budget_tokens": 8192,
      "thinking_level": "medium"
    },
    "deep": {
      "effort_enum": "high",
      "budget_tokens": 20000,
      "thinking_level": "high"
    },
    "capped-deep": {
      "effort_enum": "high",
      "budget_tokens": 12000,
      "thinking_level": "high"
    }
  }
}

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 awaryjne, gdy mapowanie jest niebezpieczne

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

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ą.
• Przejście na niższą wersję: żądany profil jest niezgodny z zasadami, więc bramka stosuje najwyższy zatwierdzony profil i rejestruje zmianę na niższą.
• Odrzuć: profil nie może być bezpiecznie reprezentowany, najemca wymaga rygorystycznego zachowania, w przeciwnym razie obniżenie wersji naruszyłoby oczekiwania produktu.

Przykładowy zapis decyzji

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "deep",
  "applied_reasoning_profile": "standard",
  "decision": "downgraded",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "effort": "medium"
  }
}

Ten zapis decyzji jest cenny podczas wsparcia technicznego, sporów dotyczących rachunków i dochodzeń dotyczących jakości. Zapobiega także niewidocznym spadkom 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 sufitów warstwowych:

• max_reasoning_profile na najemcę, klucz API i przepływ pracy.
• max_thinking_budget lub odpowiednik na parę dostawca/model.
• max_output_tokens dla łącznej liczby wygenerowanych tokenów, gdzie dostawca zlicza rozumowanie i widoczne wyniki razem.
• daily_deep_reasoning_spend na dzierżawcę 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ą. Etap rozliczeń 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 wnioskowaniu

Analytics 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, przechowywane w formie uporządkowanej 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 konkretnego 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 surowego łańcucha myślowego. W przypadku większości prac związanych z zarządzaniem i FinOps wystarczą liczenia i decyzje polityczne. Przechowywanie poufnego tekstu uzasadnienia może powodować możliwe do uniknięcia problemy związane z prywatnością, zgodnością i przechowywaniem.

Przebieg implementacji

Brama produkcyjna może zaimplementować routing na potrzeby 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żawcy, 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 i maksymalne wartości przepływu pracy.
6. Sprawdź zgodność. Potwierdź, że para dostawca/model bezpiecznie obsługuje wybrany profil.
7. Oszacuj koszt i budżet rezerwowy. Uwzględnij prawdopodobne wykorzystanie rozumowania, a nie tylko widoczne wyniki.
8. Wyślij za pomocą parametry natywne dostawcy. Wysyłaj wysiłek wyliczeniowy, tokeny budżetowe, poziom myślenia lub brak kontroli rozumowania zgodnie z adapterem.
9. Normalizuj użycie w odpowiedzi. Oddziel dane wejściowe, widoczne dane wyjściowe, rozumowanie, pamięć podręczną, narzędzia i tokeny sumy, jeśli to możliwe.
10. Skonfiguruj i ostrzegaj. Uzgadniaj zarezerwowane i rzeczywiste kosztów, aktualizować przydziały i emitować sygnały 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łkowitego ukończenia czas.
• Koszt: koszt żądania i koszt zaakceptowanej odpowiedzi.
• Tryby awarii: obcięcie, odmowa, zniekształcone dane wyjściowe, nadmierne wywołania narzędzi lub przekroczenie limitu czasu.

Kluczowym wskaźnikiem nie są „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. Oceń na podstawie przepływu pracy.

Kompromis

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ć zatwierdzonego luku ratunkowego do kontroli specyficznej dla dostawcy.
• Budżet pewność kontra jakość: twarde ograniczenia chronią najemców przed niekontrolowanymi wydatkami, ale zbyt wąskie ograniczenia mogą obciąć przydatne odpowiedzi po zużyciu tokenów wnioskowania.
• Dynamiczne myślenie a przewidywalność: dynamiczna kontrola dostawców może poprawić wygodę, ale osłabia szacunki kosztów przed wysyłką, chyba że brama rejestruje rzeczywiste wykorzystanie i wymusza rozliczenie limity.
• 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 rozumowania są przydatne, ale nieprzetworzone ślady rozumowania nie powinny być przechowywane, chyba że istnieje celowe, zatwierdzone przechowywanie policy.

Przewidywanie: zasady wnioskowania staną się standardową kontrolą bramy

To jest prognoza, a nie zweryfikowany fakt: wnioskowanie stanie się normalną kontrolą produkcji obok routingu modeli, 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żawcą, 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 z możliwością zastosowania

• Zdefiniuj profile wewnętrzne: none, low, standard, deep i capped-deep.
• 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.
• Zamknięcie kończy się niepowodzeniem, gdy żądanego profilu nie można bezpiecznie zmapować.
• Zarezerwuj budżet przed wysłaniem, korzystając z szacunków uwzględniających rozumowanie.
• Zarejestruj żądany profil, zastosowany profil, dostawcę parametr, użycie wnioskowania, widoczny wynik, opóźnienie i koszt.
• Dodaj alerty o anomaliach dla wysokich współczynników wnioskowania-tokenów i głębokiego wnioskowania w prostych przepływach pracy o dużej objętości.
• Przeprowadzaj oceny na poziomie przepływu pracy przed zmianą domyślnego wysiłku.
• Domyślnie unikaj rejestrowania surowego tekstu rozumowania; zamiast tego przechowuje liczniki i podejmuje decyzje dotyczące zasad.

Wniosek

Modele zdolne do wnioskowania są przydatne, ponieważ pozwalają przeznaczyć więcej mocy obliczeniowej na trudne problemy. 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 zamienia rozumowanie z ukrytej zmiennej kosztowej w wyraźną powierzchnię kontrolną dla kontroli kosztów AI API.

Powiązane lektury

• księga rozliczeniowa, która rezerwuje i rozlicza każde wywołanie modelu
• aliasy i możliwości modeli wewnętrznych kontrakty
• rozliczanie tokenu przesyłania strumieniowego pod kątem końcowego wykorzystania i odpowiedzi częściowych