Optymalizowanie kosztów obciążeń sztucznej inteligencji na Azure

W tym artykule pokazano zespołom startupów na wczesnym etapie rozwoju, jak identyfikować i ograniczać koszty obciążeń AI na platformie Microsoft Azure. Jest przeznaczony dla założyciela, CTO lub pierwszego inżyniera, który jednocześnie odpowiada za koszty chmury i zestaw ewaluacyjny (eval set). Obejmuje tagowanie i dyscyplinę budżetową, cztery mechanizmy optymalizacji ścieżki obsługi żądań (buforowanie, przetwarzanie wsadowe, routing i dobór modelu), właściwe dopasowanie zasobów GPU do samodzielnie hostowanej inferencji, wzorce wyszukiwania w środowiskach wielodzierżawnych oraz bezpieczny cykl wprowadzania zmian, który można realizować bez dedykowanego zespołu platformowego. Każda sekcja jest oznaczona etapem z przewodnika po architekturze Azure dla startupów gdzie ma zastosowanie (Eksploruj, Rozwiń lub Wyodrębnij), aby uniknąć optymalizacji problemów, których jeszcze nie masz.

Z tego artykułu dowiesz się, jak wykonywać następujące działania:

  • Zidentyfikuj najważniejsze czynniki kosztów w obciążeniu sztucznej inteligencji w Azure.
  • Dopasuj dźwignie optymalizacji kosztów do etapu uruchamiania.
  • Zastosuj buforowanie promptów, buforowanie semantyczne, przetwarzanie wsadowe, trasowanie żądań do modeli i właściwy dobór rozmiaru.
  • Projektuj wielodostępne wzorce pobierania danych i wzorce bazodanowe, które skalują się liniowo wraz z przychodami, a nie wraz z poziomem użycia.
  • Obejmij zmiany kosztów bramką ewaluacyjną, alertami budżetowymi i limitami liczby żądań na dzierżawcę.
  • Rozpoznaj wczesne sygnały, że wyrosłeś już z podejścia typu „zrób to sam” do zarządzania kosztami.

Prerequisites

  • Subskrypcja platformy Azure z co najmniej jednym obciążeniem AI działającym w środowisku produkcyjnym, przedprodukcyjnym lub w formie działającego prototypu.
  • Uprawnienia właściciela lub współautora dotyczące zasobów, które chcesz zmierzyć.
  • Komfort otwierania portalu Azure. Nie jest wymagane wcześniejsze doświadczenie z usługą Cost Management lub Azure Monitor. Ten artykuł wskazuje odpowiednie strony.
  • Mały zestaw ewaluacyjny dla funkcji AI, zawierający od 10 do 50 reprezentatywnych promptów i oczekiwanych zachowań. Jeśli jeszcze go nie masz, zobacz sekcję Powiązane artykuły. Pierwszą wersję można utworzyć po południu.

Dlaczego ma to znaczenie dla startupów

W przypadku wczesnego uruchamiania koszt sztucznej inteligencji jest ryzykiem operacyjnym. Niższy koszt inferencji pozwala zaoszczędzić czas pracy inżynierów na kolejny eksperyment, a stabilny koszt przypadający na aktywnego użytkownika pozwala planować dalej niż do kolejnego etapu finansowania, zamiast tylko do terminu kolejnej faktury. Wzorce w tym artykule są celowo małe. Każdy z nich jest osiągalny przez inżyniera założyciela w weekend, bez wymaganej platformy ani zespołu FinOps.

Important

Nie potrzebujesz dedykowanego zespołu FinOps, aby rozpocząć. Pierwsze 80 procent oszczędności kosztowych wynika z oznaczania wszystkiego tagami od pierwszego dnia, wyznaczenia jednej osoby odpowiedzialnej za cotygodniowy przegląd zarządzania kosztami oraz stosowania mechanizmów opisanych w tym artykule zgodnie z kolejnością etapów. Wdrażaj formalne narzędzia i procesy FinOps dopiero wtedy, gdy wydatki przekroczą około 50 000 USD miesięcznie lub gdy obejmują więcej niż pięć odrębnych obciążeń roboczych.

Dlaczego koszt sztucznej inteligencji różni się od tradycyjnego kosztu chmury

W tradycyjnej aplikacji internetowej miesięczne koszty są zdominowane przez maszyny wirtualne, bazy danych i transfer wychodzący. Zazwyczaj można przewidzieć ją w ciągu 10 procent, wiedząc, ilu użytkowników obsługujesz. Obciążenia sztucznej inteligencji przerywają te intuicje. Ten sam użytkownik może kosztować 0,001 USD w jednej chwili, a 0,40 USD w następnej, w zależności od długości kontekstu, zakresu pobierania i tego, do którego modelu skierowano żądanie.

Cztery kształty kosztów powtarzają się w większości produktów sztucznej inteligencji w Azure:

  • Wydatki na tokeny są skalowane z długością kontekstu, a nie z liczbą użytkowników. Naiwny prompt generowania wspomaganego wyszukiwaniem (RAG) może wzrosnąć z 800 do 12 000 tokenów po jednej zmianie w produkcie.
  • Czas bezczynności GPU to największy ukryty koszt inferencji hostowanej samodzielnie. Pozostawiony na noc A100 kosztuje więcej niż miesięczne utrzymanie małej bazy danych Postgres.
  • Fan-out pobierania z baz wyszukiwania i baz wektorowych narasta. Każda tura czatu może generować od trzech do ośmiu ukrytych zapytań, których nigdy nie zobaczysz w swoich logach.
  • Transfer danych na zewnątrz i przechowywanie danych stopniowo narastają za sprawą artefaktów modelu, embeddingów, dzienników audytu i indeksów przypisanych do poszczególnych dzierżawców.

Każdy czynnik kosztotwórczy ma określony zestaw dźwigni. Pozostałe sekcje opisują je w kolejności priorytetów, opatrując je informacją o etapie rozwoju startupu, na którym dana dźwignia ma zastosowanie, dzięki czemu zespoły nie tworzą zbyt złożonych rozwiązań dla problemów, których jeszcze nie mają.

Wskazówka

Skorzystaj ze wskazówek dotyczących optymalizacji kosztów z Azure Well-Architected Framework w architekturze, aby utrzymać i poprawić zwrot z inwestycji (ROI).

Mapa etapów: które dźwignie do czego należą

Przewodnik po architekturze Azure dla startupów opisuje trzy etapy opracowywania produktów: Eksplorowanie, Rozwijanie i Wyodrębnianie. Dźwignie optymalizacji kosztów w tym artykule są dostosowane do tych etapów. Skorzystaj z poniższej tabeli, aby określić, które sekcje dotyczą dziś Twojego zespołu, a które można odłożyć na później.

Etapie Liczba pracowników Podstawowy cel kosztowy Dźwignie, które się opłacają
Poznaj 1–10 inżynierów Opcjonalność i szybkość Tagowanie, buforowanie monitów, tani model domyślny
Rozwiń 10–50 inżynierów Powstrzymaj liniowy wzrost kosztów wraz ze wzrostem przychodów Semantyczna pamięć podręczna, skalowanie do zera, trasowanie, interfejs API Batch
Ekstrakt 50+ inżynierów Margines, przewidywalność, FinOps Rezerwacje, dedykowane indeksy, kwantyzacja, cennik dla poszczególnych dzierżaw

Identyfikowanie najważniejszych czynników kosztów

Zanim zaczniesz cokolwiek optymalizować, uzyskaj pełny obraz tego, na co faktycznie idą pieniądze. W Azure najszybszym sposobem jest użycie usługi Cost Management w podziale na usługę i tag z ostatnich 30 dni.

Oznaczaj wszystko od samego początku

Stosowanie tagów to praktyka o największym wpływie na przejrzystość kosztów. Bez spójnych tagów nie da się przypisać wydatków do dzierżawcy, funkcji ani środowiska. Architektura referencyjna Startup Scale Landing Zone (SSLZ) wymusza tagowanie na poziomie zasad strefy docelowej. Użyj tego samego podejścia dla zasobów sztucznej inteligencji.

costCenter = product | platform | research
tenant     = <customer-id> | shared
workload   = inference | embedding | training | eval
env        = prod | staging | dev
team       = <owning-team>

Gdzie najpierw szukać

Sterownik kosztów Gdzie go znaleźć Typowa część rachunku
Tokeny (interfejs API LLM) Metryki Azure OpenAI > Przetworzone tokeny promptu/uzupełnienia 30–60%
GPUs Liczba godzin węzłów VM/AKS według SKU (rodziny ND, NC i NV) 20–50%
Wektor/wyszukiwanie Jednostki zapytań wyszukiwania sztucznej inteligencji, ru/s usługi Cosmos DB 5–20%
Magazyn Blob Storage, Azure Files i Azure Container Registry dla artefaktów modelu 3–10%
Egress Przepustowość poza regionem, zwłaszcza wywołania między chmurami 2–15%

Codziennie eksportuj dane z Cost Management do konta magazynu danych i połącz je z istniejącym środowiskiem analitycznym. Cotygodniowy wykres kosztów za aktywne użytkownika jest niezawodnym sygnałem, że optymalizacja miała zamierzony efekt.

Dźwignia 1: buforowanie, przetwarzanie wsadowe, routing i wybór modelu

Etapie: Eksplorowanie za pomocą funkcji Wyodrębnij. Zacznij od buforowania w obszarze Eksploruj, dodaj routing i usługę Batch w obszarze Rozwiń, a następnie dodaj precyzyjny wybór modelu dla każdej dzierżawy w sekcji Wyodrębnij.

Wskazówka

Buforuj embeddingi przy użyciu klucza będącego haszem treści źródłowej i używaj mniejszego, tańszego modelu, takiego jak GPT-4o mini lub modelu o otwartych wagach 7B–13B, do wstępnej klasyfikacji lub ekstrakcji. Eskaluj do modelu granic tylko w przypadku żądań, w których mały model jest niepewny. Sam ten wzorzec często obniża koszt wnioskowania o 60–80 procent bez mierzalnej utraty jakości w typowych zapytaniach.

Caching

  • Buforowanie promptów: Azure OpenAI automatycznie stosuje zniżkę na powtarzające się prefiksy w przypadku promptów liczących co najmniej 1024 tokeny; funkcja jest obsługiwana przez modele GPT-4o i nowsze. Pierwsze 1 024 tokeny muszą być identyczne, aby trafić do pamięci podręcznej, więc zachowaj prompty systemowe i definicje narzędzi bez zmian.
  • Semantyczna pamięć podręczna: Przechowuj pary osadzania i odpowiedzi w usłudze Azure Cache for Redis lub Cosmos DB. Zwróć buforowaną odpowiedź, gdy nowe zapytanie ma podobieństwo cosinusowe przekraczające około 0,95.
  • Pamięć podręczna wyników: W przypadku niespersonalizowanych punktów końcowych, takich jak sekcje FAQ i narzędzia deterministyczne, prosta pamięć podręczna z czasem życia (TTL) zmniejsza ruch o 30–80%.

Batching

Zadania osadzania i klasyfikacji są oczywistym wyborem. Interfejs API Azure OpenAI Batch oferuje 50% zniżki w porównaniu z przetwarzaniem w czasie rzeczywistym w przypadku zadań, które mogą czekać do 24 godzin, takich jak nocne odświeżanie indeksów, przebiegi ewaluacji i asynchroniczne podsumowania.

Routing

Większość produktów nie wymaga najdroższego modelu przy każdym wywołaniu. Router, zarówno oparty na regułach, jak i wyuczony, może kierować od 60 do 80 procent ruchu do tańszego modelu bez mierzalnego spadku jakości.

Wzór Tania ścieżka Kosztowna ścieżka
Klasyfikacja intencji GPT-4o mini lub Phi-4 GPT-4o dla niejednoznacznych żądań
Używanie narzędzia lub wywoływanie funkcji Model warstwy średniej Model najwyższego poziomu ponawiania próby
Podsumowywanie długiego kontekstu Okno przesuwne z modelem średniej klasy Model najwyższej klasy z pełnym kontekstem
Generowanie kodu Model średniej klasy dla szablonowego tekstu Model najwyższej klasy do refaktoryzacji

Wybór modelu

Przeszacuj wybór modelu co kwartał. Ceny i jakość szybko się zmieniają. Model, który sześć miesięcy temu był jedyną opcją, może dziś kosztować pięć razy więcej niż nowsze SKU, które w Twoich ewaluacjach uzyskuje wynik gorszy zaledwie o jeden do dwóch punktów.

Obszar 2: Dostosowanie infrastruktury do potrzeb dzięki automatycznemu skalowaniu

Etap: Rozszerz i wyodrębnij. W sekcji Eksploruj użyj modelu bezserwerowego lub platformy jako usługi (PaaS), takiej jak App Service, Container Apps w planie consumption lub Azure OpenAI Service, i pomiń tę opcję.

Jeśli samodzielnie uruchamiasz inferencję za pomocą vLLM, Triton lub Text Generation Inference (TGI) w usłudze Azure Kubernetes Service (AKS) lub Container Apps, drugim najważniejszym czynnikiem jest zadbanie o to, aby procesory GPU nie pozostawały bezczynne.

Skaluj do zera w przypadku nieaktywnych obciążeń

Ustaw minReplicas: 0 w usłudze Container Apps z profilem obciążenia GPU lub użyj mechanizmu Horizontal Pod Autoscaling (HPA) albo KEDA w usłudze AKS, aby skalować pule węzłów do zera, gdy nie ma żadnych żądań w trakcie przetwarzania. Zimne starty to zazwyczaj dziesiątki sekund. Przeprowadź testy porównawcze dla swojego modelu i utrzymuj jedną rozgrzaną replikę w godzinach biznesowych, jeśli istotne są opóźnienia odczuwane przez użytkowników.

Dobierz odpowiedni wariant SKU procesora graficznego do rozmiaru modelu

Dopasuj klasę procesora GPU do liczby parametrów. T4 lub L4 jest wystarczająca dla modeli poniżej około 13B parametrów. A100 lub H100 są opłacalne tylko w przypadku modeli powyżej około 34 mld parametrów lub przy utrzymującej się wysokiej liczbie zapytań na sekundę (QPS). Bezserwerowy procesor GPU usługi Container Apps obecnie obsługuje procesory T4 i A100. L4 i H100 wymagają usługi AKS.

Trenowanie seryjne i zadania wsadowe do wykrywania

Uruchamiaj nocne ewaluacje, odświeżanie osadzeń i podsumowania offline na pulach węzłów spot, które są zazwyczaj o 60–80% tańsze niż pule na żądanie. Utrzymuj inferencję produkcyjną w dedykowanej infrastrukturze. W poniższej tabeli przedstawiono podsumowanie strategii skalowania automatycznego i ich typowych oszczędności.

Caution

Zasoby Spot mogą zostać odebrane z zaledwie 30-sekundowym wyprzedzeniem. Używaj instancji spot wyłącznie do zadań, dla których można zapisywać punkty kontrolne lub które można bezproblemowo uruchomić ponownie, takich jak wsadowe ewaluacje, odświeżanie embeddingów, sumaryzacja offline oraz dostrajanie z częstym zapisem punktów kontrolnych. Nigdy nie uruchamiaj obciążeń inferencyjnych ani zadań widocznych dla użytkowników na instancjach Spot bez mechanizmu restartu.

Strategy Jak Typowe oszczędności
Skalowanie do zera minReplicas: 0 w usłudze Container Apps z profilem obciążenia procesora GPU. Zimne starty to zazwyczaj dziesiątki sekund. Przeprowadź test porównawczy z modelem. Nawet 90%
KEDA w zależności od głębokości kolejki Skaluj na podstawie komunikatów w usłudze Service Bus lub w kolejce, a nie na podstawie użycia procesora. 30–60%
Jednostka SKU o odpowiednim rozmiarze T4 lub L4 dla modeli mających mniej niż 13B parametrów. A100 lub H100 tylko dla modeli z więcej niż 34B parametrów lub wysokich QPS. Bezserwerowy procesor GPU usługi Container Apps obecnie obsługuje tylko T4 i A100. L4 i H100 wymagają usługi AKS. 40–70%
Pojemność typu spot Pule węzłów spot do zadań wsadowych i ewaluacji. Pojemność na żądanie dla środowiska produkcyjnego. 40–80%
Kwantyzacji 4-bitowa kwantyzacja AWQ lub GPTQ pozwalająca uruchamiać większe modele na mniejszych kartach graficznych. Dopasuj 30B na 16 GB

Note

Skalowanie do zera w interfejsie czatu powoduje widoczne opóźnienie przy zimnym starcie. Typowym wzorcem jest utrzymywanie jednej do dwóch ciepłych replik w godzinach pracy i skalowanie do zera z dnia na dzień.

Dźwignia 3: Wzorce wielodostępne bez skoków kosztów pobierania

Etap: Późne rozszerzanie i wyodrębnianie. W sekcji Explore prawie na pewno masz tylko jednego tenanta: siebie. Pomiń tę sekcję do czasu posiadania co najmniej trzech rzeczywistych klientów.

Produkty AI w modelu wielodzierżawnym zawodzą przy skalowaniu, jeśli wzorce dostępu do danych i projekt bazy danych dobrano pod kątem prototypu jednodzierżawnego. Trzy wzorce się powtarzają.

Jeden indeks dla każdego dzierżawcy kontra współdzielony indeks z filtrami

Dedykowany indeks AI Search dla każdej dzierżawy zapewnia pełną izolację, ale naliczane są opłaty za każdy indeks, nawet gdy pozostaje bezczynny. Współdzielony indeks z filtrem dzierżawcy jest znacznie tańszy przy małej i średniej skali. Przełączaj na środowisko dedykowane tylko w przypadku planu dla przedsiębiorstw lub gdy tenant przekroczy określony próg wielkości.

Wybór wektorowej bazy danych

Wybierz magazyn wektorów na podstawie istniejącej infrastruktury i skali. W poniższej tabeli podsumowano, kiedy każda opcja pasuje.

Warning

Usunięcie indeksu wektora lub jego magazynu bazowego jest nieodwracalne, a ponowne osadzanie dużego korpusu może kosztować setki do tysięcy dolarów w wywołaniach modelu oraz godziny czasu inżynieryjnego. Przed wprowadzeniem jakichkolwiek zmian destrukcyjnych w magazynie wektorowym wykonaj migawkę dokumentów źródłowych i sprawdź, czy potok ponownego osadzania działa od początku do końca na niewielkim podzbiorze.

Option Najlepsze dla Kształt kosztów
Wyszukiwanie AI platformy Azure (wektor) Wyszukiwanie hybrydowe i aspekty Na replikę, przewidywalną
Cosmos DB (wektor) Zespoły już korzystające z usługi Cosmos DB dla danych aplikacji RU/s, skaluje się wraz z QPS
pgvector w usłudze Postgres Małe lub średnie corpora, proste operacje Za maszynę wirtualną, bardzo tanie
Dedykowana baza danych wektorów ponad 100 mln wektorów, wysokie wymagania co do recall Kosztowna dla węzła

Unikaj ukrytych pobrań N+1

Każdy krok agenta, który wywołuje search, jest płatnym zapytaniem. Rejestruj liczbę wywołań pobierania logów na turę użytkownika i generuj alert, gdy mediana przekroczy założony budżet. Dobrym punktem wyjścia jest nie więcej niż dwa pobrania na turę. Moduły ponownego rankingowania i przepisywania to obszary, w których łatwo niechcący podwoić ruch.

Ład: zachowaj bezpieczeństwo zmian kosztów

Etapie: Wszystkie etapy. Lekka wersja, która obejmuje budżet, jednowierszowy test ewaluacyjny przed wdrożeniem oraz pojedynczy limit żądań, powinna od pierwszego dnia znaleźć się w sekcji Eksploruj. Bardziej rozbudowany wariant, z bramkami oceny blokującymi CI i limitami szybkości na dzierżawcę w usłudze API Management, należy do etapu Expand i kolejnych.

Optymalizacja, która przerywa jakość, nie jest optymalizacją. Jest to awaria. Każdą zmianę kosztów obejmij trzema zabezpieczeniami. Każda blokada może być skonfigurowana w ciągu niedużych godzin przez jednego inżyniera.

  1. Sprawdzanie oceny: Uruchom zestaw eval przed wdrożeniem dowolnego monitu, modelu lub zmiany routingu. Na wczesnym etapie to sprawdzenie może być skryptem uruchamianym ręcznie. Zablokuj wdrożenie lub wycofaj zmiany, jeśli wynik spadnie o więcej, niż wynosi dopuszczalna tolerancja, na przykład o jeden punkt w 100-punktowej skali.
  2. Alerty budżetowe: Ustaw budżety usługi Azure Cost Management dla każdej grupy zasobów z alertami przy 50%, 80% i 100%. Skieruj je do tego samego kanału na Slacku lub w Teams, do którego trafiają powiadomienia o błędach, aby wydatki i incydenty trafiały w to samo miejsce.
  3. Limit liczby żądań: Nawet pojedynczy limit na adres IP lub klucz API w API Management, NGINX lub bramie API zapobiega temu, by klient, który wymknął się spod kontroli, wyczerpał saldo środków w ciągu jednej nocy. Dodaj limity dla poszczególnych tenantów później, gdy będziesz mieć płacących klientów.

Należy zachować ostrożność w przypadku łączenia kilku optymalizacji kosztów w jednej wersji. Gdy zestaw zmian trafia jako całość, ustalenie, która zmiana za co odpowiada, staje się trudne, a wyizolowanie każdej regresji metodą bisekcji jest kosztowne.

Eksperyment z dwoma dźwigniami: porównanie przed i po

Gdy decydujesz, od czego zacząć, wybierz dwa obszary z poprzednich sekcji, wdroż je z użyciem flagi funkcji i mierz wyniki przez 7–14 dni. Dwie dźwignie są wystarczające do wykrywania znaczącego ruchu. Więcej niż dwa elementy sprawia, że przypisanie autorstwa staje się niewiarygodne.

Sugerowana pierwsza para według etapu

Etapie Dźwignia A Dźwignia B
Przed uruchomieniem (<100 DAU) Buforowanie monitów Routing modeli z użyciem taniego modelu domyślnego
Wczesna trakcja (100-10k DAU) Pamięć podręczna semantyczna Skalowanie do zera w wnioskowaniu
Skala (10 tys.+ DAU) Batch API do zadań asynchronicznych Strategia indeksowania na dzierżawcę
Poziom Enterprise Dedykowane indeksy dla najważniejszych kont Modele kwantyzowane na L4 lub H100 
Baseline window:   2026-04-15 to 2026-04-28 (14 days)
Treatment window:  2026-05-01 to 2026-05-14 (14 days)
Levers shipped:    1) semantic cache on /chat
                   2) scale-to-zero on vLLM

Metrics:
  cost_per_active_user   (target: down 30%)
  p95_latency_ms         (guardrail: +<= 150 ms)
  eval_score_delta       (guardrail: >= -1.0)

Decision rule: Keep both if all guardrails hold. Otherwise, revert and ship one at a time.

Co ten artykuł obejmuje i czego nie zawiera

Ten artykuł ma celowo ograniczony zakres. W poniższych sekcjach wymieniono tematy, które znajdują się w zakresie, tematy, które są poza zakresem, oraz sygnały wskazujące, kiedy je dodać.

W zakresie

  • Tagowanie, budżety i praktyki zarządzania kosztami odpowiednie dla każdego startupu.
  • Cztery dźwignie ścieżki żądania: buforowanie, przetwarzanie wsadowe, routing i wybór modelu.
  • Właściwy dobór zasobów GPU i skalowanie do zera dla samodzielnie hostowanego wnioskowania.
  • Wzorce pobierania danych w środowisku wielodostępnym dla produktów mających od trzech do 100 płacących klientów.
  • Pętla zarządzania bezpiecznymi zmianami: bramka oceny, alerty budżetowe i limity liczby żądań dla każdego tenanta.

Poza zakresem

Temat Kiedy go dodać
Rezerwacje i plany oszczędności dotyczące obliczeń sztucznej inteligencji Opłata za inferencję pozostaje na stałym poziomie przez 90 dni, zwykle do połowy okresu mid-Expand.
Dedykowane narzędzia FinOps, takie jak Apptio Cloudability, Vantage i podobne narzędzia Wydatki na chmurę przekraczają około 50 000 USD miesięcznie lub obsługujesz wiele chmur. Większość startów na wczesnym etapie nie potrzebuje tego.
Niestandardowe rozliczanie oparte na tokenach dla każdego klienta końcowego Stosujesz model cenowy oparty na użyciu lub jeden dzierżawca przekracza 25 procent wartości faktury.
Optymalizacja kosztów trenowania, takich jak DeepSpeed i dostrajanie FSDP Trenujesz modele w firmie. Produkty typu inference-first nie wymagają tego.
Arbitraż kosztów między regionami lub w środowisku wielochmurowym Jesteś na etapie Extract, ze sprawdzoną opłacalnością w jednym regionie.

Gdy takie podejście nie jest już wystarczające

Rozwiązania opisane w tym artykule są przeznaczone dla małych zespołów działających w chmurze. W pewnym momencie twoja firma przerasta je. Następujące sygnały nie są błędami. To jest wzrost. Jeśli mają zastosowanie co najmniej dwa z nich, zaplanuj wdrożenie dedykowanych narzędzi lub wyznaczenie właściciela platformy na część etatu.

  • Miesięczne wydatki na platformę Azure przekraczają około 50 000 USD, a na sztuczną inteligencję przypada ponad 30 procent tej kwoty.
  • Ponad 10 inżynierów może wdrażać zmiany, które zmieniają koszty o co najmniej 5%.
  • Co najmniej jeden klient ma użycie powyżej 10 000 USD miesięcznie i płaci Ci stałą opłatę.
  • Inwestorzy lub partner finansowy zaczęli prosić o prognozę miesięcznych kosztów.
  • Produkt działa w więcej niż jednym regionie lub chmurze Azure.

Do tego czasu lekki proces opisany w tym artykule, obejmujący tagi, budżety, bramkę oceny i comiesięczny przegląd, to właściwe rozwiązanie. Oprzeć się pokusie wczesnego wdrażania narzędzi FinOps przedsiębiorstwa. Dodaje obciążenie procesów, zanim doda wartość.

Lista kontrolna odniesienia

Użyj poniższych elementów jako listy kontrolnej do comiesięcznego przeglądu. Każdy element odpowiada sekcji w tym artykule.

  • Wszystkie zasoby sztucznej inteligencji są oznaczone tagiem costCenter, , tenantworkloadi env.
  • Istnieje pulpit nawigacyjny usługi Cost Management, jest grupowany według tagu i jest przeglądany co tydzień.
  • Prompty systemowe są wystarczająco stabilne, aby uzyskiwać trafienia w pamięci podręcznej promptów.
  • Praca asynchroniczna, taka jak osadzenia, ewaluacje i podsumowania, jest wykonywana za pomocą interfejsu Batch API.
  • Router wysyła co najmniej 60 procent ruchu do tańszego modelu bez pogorszenia wyników ewaluacji.
  • Obciążenia procesora GPU są skalowane do zera poza godzinami pracy lub używają typu spot dla partii.
  • Mediana liczby pobrań na turę wynosi dwa lub mniej.
  • Strategia wielodostępności jest wybierana jawnie: współdzielona z filtrem lub dedykowana.
  • Budżety i limity szybkości dla dzierżawy są wymuszane.
  • Każda zmiana promptu, modelu lub trasowania przechodzi przez bramkę ewaluacyjną przed scaleniem.
  • Last updated on