Omówienie kosztów i użycia tokenów optymalizatora agenta

Optymalizator agenta w usłudze Agent platformy Foundry udostępnia modelowane oszacowanie kosztów przed przesłaniem zadania optymalizacji. Po zakończeniu zadania jego wynik może obejmować mierzone użycie tokenu. Użyj oszacowania dla planowania i mierzonego użycia, aby zrozumieć aktywność modelu, która wystąpiła podczas przebiegu.

Szacunkowe zużycie tokenów przed wykonaniem i rzeczywiste zużycie tokenów po wykonaniu służą różnym celom. Żadna wartość nie jest limitem wydatków ani zastąpieniem faktury Azure.

Szacowanie kosztów przed uruchomieniem dla agentów monitów

Przed utworzeniem zadania optymalizacji agenta promptów w portalu Foundry w kroku Przegląd wyświetlane jest oszacowanie kosztów dla wybranych ustawień. Przepływy optymalizacji hostowanego agenta obecnie nie wyświetlają tego oszacowania sprzed uruchomienia.

Oszacowanie szacuje liczbę wywołań modelu i koszty tokenów. Żądanie oszacowania nie powoduje utworzenia zadania optymalizacji ani wywołania modeli. Liczby wywołań są obliczane na podstawie danych wejściowych zadania. Wartości waluty są modelowane przez zastosowanie założeń tokenu statycznego i cen modelu referencyjnego do tych liczb wywołań.

W portalu są wyświetlane trzy modelowane wartości waluty:

Podsumowanie identyfikuje liczbę kandydatów, liczbę wierszy zestawu danych, liczbę ewaluatorów i datę ceny referencyjnej. Rozwiń Zestawienie kosztów (szacunkowe), aby wyświetlić szczegóły każdej fazy.

Dane wejściowe do oszacowania

Optymalizator oblicza zakresy liczby wywołań na podstawie wynikowej konfiguracji zadania. W obliczeniach są używane następujące dane wejściowe:

W przypadku przywoływanego zestawu danych usługa rozwiązuje liczbę wierszy, zanim zwróci oszacowanie. Jeśli nie można ustalić niezerowej liczby wierszy, nie tworzy oszacowania na podstawie przyjętego rozmiaru zbioru danych.

W przypadku przebiegów wyboru modelu oszacowanie nie wywołuje oddzielnie agenta cen dla każdego modelu w przestrzeni wyszukiwania. Używa skonfigurowanego bazowego modelu agenta, gdy jest dostępny. Jeśli nie można ustalić tego modelu, używana jest cena modelu ewaluacyjnego dla warstwy agenta.

Założenia dotyczące tokenu statycznego

Oszacowanie oddziela aktywność modelu na warstwy, aby zobaczyć, która część przebiegu przyczynia się do sumy. Używa on następujących założeń statycznych TokensPerCall :

Te założenia zarządzane przez usługę mogą ulec zmianie w miarę skalibrowania narzędzia do szacowania. Dla każdej warstwy optymalizator mnoży zakres liczby wywołań przez założenia dotyczące tokenu monitu statycznego i tokenu ukończenia. Następnie stosuje referencyjne ceny obowiązujące na dzień na każdy milion tokenów:

modeled layer cost = calls × ((prompt tokens × input price) + (completion tokens × output price)) / 1,000,000

Suma jest sumą warstw, które można wycenić. Jeśli dla warstwy nie jest dostępna cena modelu ani założenie dotyczące liczby tokenów, oszacowanie identyfikuje niewycenioną warstwę i nie uwzględnia jej w sumie całkowitej.

Co się dzieje podczas uruchamiania optymalizacji

Aby zrozumieć warstwy kosztów, warto wiedzieć, jak optymalizator używa każdego modelu w tle. Proces optymalizacji przebiega według tej pętli zarówno dla agentów promptów, jak i agentów hostowanych:

1. Oceń punkt odniesienia (agent + oceniający). Optymalizator wywołuje Twojego agenta dla każdego wiersza zbioru danych, aby zebrać odpowiedzi. Następnie model oceny ocenia każdą odpowiedź względem każdego ewaluatora w celu ustalenia punktów odniesienia.
2. Wygeneruj kandydata (refleksja). Model optymalizacji otrzymuje wyniki punktu odniesienia, analizuje słabe strony i tworzy ulepszoną konfigurację agenta. W zależności od typu agenta konfiguracja może obejmować przepisane instrukcje, wyrafinowane umiejętności, lepsze opisy narzędzi lub inny model.
3. Oceń kandydata (agent + sędzia). Optymalizator uruchamia agenta z konfiguracją kandydata w tych samych wierszach zestawu danych i ocenia odpowiedzi.
4. Powtórz. Kroki 2–3 powtórzą się dla każdego dodatkowego kandydata. Każdy cykl dodaje kolejną rundę wywołań związanych z refleksją i oceną.

Trzy warstwy kosztów odpowiadają bezpośrednio tej pętli:

• Uruchamianie agenta — za każdym razem, gdy agent jest wywoływany względem wiersza zestawu danych (punkt odniesienia i każdy kandydat).
• Ocenianie odpowiedzi — za każdym razem, gdy model ewaluacyjny ocenia odpowiedź względem ewaluatora.
• Generowanie ulepszeń — za każdym razem, gdy model optymalizacji odzwierciedla wyniki i generuje nowego kandydata.

Przykład praktyczny: przebieg dla 2 maksymalnych kandydatów

W poniższym przykładzie pokazano, jak formuła ma zastosowanie do konfiguracji konkretnego zadania. Wszystkie ceny mają charakter wyłącznie poglądowy.

Ustawienia zadania:

Szacowane liczby wywołań:

Optymalizator pobiera liczbę wywołań z konfiguracji zadania:

Zastosuj formułę do każdej warstwy:

Optymalizator wyszukuje referencyjne ceny wejściowe i wyjściowe z określoną datą dla każdego modelu i stosuje odpowiedni wzór. Na przykład obliczenie warstwy agenta to:

60 × ((2,000 × <input price>) + (400 × <output price>)) / 1,000,000

Ten sam schemat ma zastosowanie do warstw oceny i refleksji, z których każda korzysta z przyjętych założeń dotyczących tokenów i cen referencyjnych dla swojego modelu. Następnie portal sumuje wszystkie warstwy, aby utworzyć wartości Minimum, Szacowane i Maksymalne wyświetlane w kroku Przegląd .

W typowym uruchomieniu z 2 kandydatami warstwa refleksji (model optymalizacji) odpowiada za największą część szacowanego kosztu, ponieważ wykorzystuje bardziej zaawansowany model z wyższymi stawkami za token. Warstwa oceniająca jest zwykle najtańsza, ponieważ wykorzystuje mniejszy model ewaluacyjny i zakłada niewielką liczbę tokenów na wywołanie.

Założenia i ograniczenia dotyczące szacowania

Oszacowanie jest wartością planowania, a nie ostateczną opłatą, ponieważ łączy algorytmiczny budżet wywołań z modelowym użyciem tokenu.

• Założenia dotyczące tokenów są średnie dla każdej warstwy kosztów. Rzeczywiste liczby monitów, odpowiedzi, rozumowania i buforowanych tokenów różnią się w zależności od modelu i żądania.
• Zadanie optymalizacyjne może zakończyć się wcześniej, gdy nie znajduje już dalszej poprawy. Wczesne zatrzymywanie może zmniejszyć rzeczywiste użycie poniżej wartości szacowanej lub maksymalnej .
• Użycie agenta różni się w zależności od instrukcji, kolei konwersacji, długości odpowiedzi, wywołań narzędzi i danych wyjściowych narzędzia.
• Ceny modelu referencyjnego są datowane i mogą się różnić od cen subskrypcji, regionu, typu wdrożenia lub umowy.
• Szacunek nie obejmuje opłat za zewnętrzne interfejsy API, bazy danych, usługi wyszukiwania ani inne narzędzia, z których korzysta agent.
• Wartość Maksymalna nie jest limitem wydatków.

Po uruchomieniu mierzone użycie tokenu

Po zakończeniu zadania optymalizacji jego wynik może obejmować mierzone użycie tokenu dla każdej fazy przebiegu. Widok Użycie tokenów może być dostępny zarówno dla uruchomień agenta promptowego, jak i agenta hostowanego.

W przypadku hostowanych agentów dane o użyciu dla Uruchamianie agenta są dostępne tylko wtedy, gdy próbka oceny agenta lub ślad zawiera informacje o użyciu tokenów. Jeśli agent hostowany nie raportuje użycia, portal pomija fazę agenta, zamiast raportować tę fazę jako zero. Portal rejestruje oddzielnie dane o użyciu dla funkcji Ocenianie odpowiedzi i Generowanie ulepszeń, gdy wywołania tego modelu raportują użycie.

Widok może zawierać wiele wierszy dla opcji Uruchamianie agenta, gdy optymalizator ocenia wiele modeli agenta.

Portal oblicza szacowany koszt na podstawie mierzonego użycia tokenu i cen modelu referencyjnego. Wybierz pozycję Wyświetl cennik , aby przejrzeć źródło cen. Szacowanie nie jest ostateczną kwotą rozliczonego rachunku.

Brak fazy lub wartości tokenu oznacza, że użycie nie zostało zmierzone. Nie oznacza to, że faza używała tokenów zerowych ani nie ponosiła żadnych opłat. Niektórzy agenci hostowani i starsze zadania optymalizacji mogą nie udostępniać informacji o użyciu agenta.

Wynik bazowego zadania może zawierać więcej szczegółowych informacji o tokenach z pamięci podręcznej i tokenach rozumowania. Tokeny z pamięci podręcznej stanowią podzbiór tokenów wejściowych, a tokeny wnioskowania stanowią podzbiór tokenów wyjściowych. Nie dodawaj tych wartości podzestawu do sum wejściowych lub wyjściowych.

Obliczanie kosztów modelu na podstawie mierzonego użycia

Mierzone użycie tokenu jest bardziej reprezentatywne niż założenia przed uruchomieniem, ale zgłasza liczbę tokenów, a nie ostateczną kwotę rozliczoną. Zastosuj ceny dla każdego wiersza modelu, aby uzyskać przybliżony koszt modelu:

approximate model cost = ((input tokens × input price) + (output tokens × output price)) / 1,000,000

Jeśli szczegółowe dane o użyciu zawierają liczbę buforowanych tokenów, a model ma oddzielną stawkę dla danych wejściowych z pamięci podręcznej, odejmij liczbę buforowanych tokenów od łącznej liczby tokenów wejściowych i oblicz koszt części buforowanej oraz niebuforowanej osobno.

Oblicz oddzielnie każdą fazę i wiersz modelu, a następnie dodaj wyniki. Jeśli wiersz nie identyfikuje modelu, nie można niezawodnie zastosować ceny specyficznej dla wdrożenia do tego użycia.

Użyj stawek, które mają zastosowanie do subskrypcji, regionu, typu wdrożenia i umowy rozliczeniowej. W przypadku opublikowanych stawek zobacz cennik Azure OpenAI Service. Wynik nadal wyklucza opłaty z zewnętrznych narzędzi i usług.

Treści powiązane

• Omówienie optymalizatora agentów
• Szybki start: optymalizowanie agenta monitu
• Szybki start: optymalizowanie hostowanego agenta