Optimalizace nákladů na úlohy AI na Azure

Tento článek ukazuje týmům startupů v rané fázi, jak identifikovat a snížit náklady na úlohy AI v Microsoft Azure. Je určen pro zakladatele, CTO nebo prvního technického zaměstnance, který má zároveň na starosti náklady na cloud a vyhodnocovací (eval) sadu. Zahrnuje tagování a rozpočtovou hygienu, čtyři oblasti optimalizace v cestě požadavku (ukládání do mezipaměti, dávkování, směrování a výběr modelu), správné nastavení velikosti GPU pro inferenci na vlastní infrastruktuře, vzory vyhledávání pro více nájemců a cyklus bezpečných změn, který můžete provozovat i bez specializovaného platformního týmu. Každý oddíl je označen fází z průvodce architekturou Azure pro startupy kde se používá (Prozkoumat, Rozbalit nebo Extrahovat), abyste se vyhnuli optimalizaci problémů, které ještě nemáte.

V tomto článku se dozvíte, jak:

  • Identifikujte hlavní nákladové faktory v úloze AI na Azure.
  • Spárujte nástroje pro optimalizaci nákladů s fází spuštění.
  • Použijte ukládání promptů do mezipaměti, sémantické ukládání do mezipaměti, dávkování, směrování modelů a volbu správné velikosti.
  • Návrh vzorů načítání a databází s více tenanty, které se škálují lineárně s výnosy, ne s využitím.
  • Zaveďte u změn nákladů schvalovací bránu, upozornění na překročení rozpočtu a limity počtu požadavků pro jednotlivé tenanty.
  • Rozpoznejte první signály, že vám svépomocný přístup k řízení nákladů už nestačí.

Předpoklady

  • Předplatné Azure s alespoň jednou úlohou AI spuštěnou v produkčním, přípravném nebo pracovním prototypu.
  • Oprávnění vlastníka nebo přispěvatele k prostředkům, které chcete měřit.
  • Pohodlí při otevření portálu Azure. Nevyžaduje se žádné předchozí zkušenosti se službou Cost Management nebo Azure Monitor. Tento článek vás odkazuje na příslušné stránky.
  • Malá hodnoticí sada pro vaši AI funkci s 10 až 50 reprezentativními výzvami a očekávanými reakcemi. Pokud ho ještě nemáte, přečtěte si část Související články. První verzi můžete sestavit odpoledne.

Proč je to důležité pro startupy

U počátečního spuštění jsou náklady na AI provozní riziko. Levnější inference uvolní čas vývojářů pro další experiment a stabilní náklady na jednoho aktivního uživatele vám umožní plánovat i za horizont příštího kola financování, místo abyste řešili jen další fakturu. Vzory v tomto článku jsou záměrně malé. Každý z nich je dosažitelný zakládajícím inženýrem o víkendu, který nevyžaduje žádnou platformu ani tým FinOps.

Important

Abyste mohli začít, nepotřebujete vyhrazený tým FinOps. Prvních 80 % úspor nákladů lze dosáhnout tím, že budete od prvního dne vše tagovat, pověříte jednu osobu týdenní kontrolou v rámci Cost Managementu a využijete opatření uvedená v tomto článku v pořadí podle fází. Formální nástroje a procesy FinOps zavádějte teprve poté, co výdaje přesáhnou přibližně 50 000 USD měsíčně nebo zahrnují více než pět samostatných úloh.

Proč se náklady na AI zobrazují jinak než náklady na tradiční cloud

U tradiční webové aplikace tvoří hlavní část vašeho měsíčního účtu virtuální počítače, databáze a odchozí přenos dat. Obvykle to můžete odhadnout s přesností na 10 %, když víte, kolika uživatelům poskytujete služby. Zátěže AI tuto intuici narušují. Stejný uživatel může v jednu chvíli stát 0,001 USD a vzápětí 0,40 USD v závislosti na délce kontextu, hloubce načítání a na tom, na který model byl požadavek směrován.

U většiny produktů AI na Azure se rekurzují čtyři obrazce nákladů:

  • Výdaje na tokeny se škálují s délkou kontextu, nikoli počtem uživatelů. Jednoduchý prompt pro RAG může po jediné změně produktu narůst z 800 na 12 000 tokenů.
  • Prostoje GPU jsou největším skrytým nákladem při inferenci na vlastní infrastruktuře. A100 ponechaný běžet přes noc stojí víc než měsíční provoz malé databáze Postgres.
  • Rozvětvení načítání z databází pro vyhledávání a vektorových databází se kumuluje. Každý krok chatu může vydávat tři až osm skrytých dotazů, které v protokolech nikdy nevidíte.
  • Odchozí přenos dat a úložiště se nenápadně navyšují kvůli artefaktům modelu, embeddingům, auditním protokolům a indexům pro jednotlivé tenanty.

Každý faktor ovlivňující náklady má danou sadu nástrojů. Zbývající části je popisují v pořadí podle priority a uvádějí, pro kterou fázi startupu je dané opatření relevantní, aby týmy nevytvářely zbytečně složitá řešení pro problémy, které je ještě netrápí.

Tip

Využijte pokyny k optimalizaci nákladů z architektury Azure Well-Architected Framework ve vaší architektuře k udržení a zlepšení návratnosti investic (ROI).

Mapa fáze: které páky patří tam, kde

Průvodce architekturou Azure pro startupy popisuje tři fáze vývoje produktů: Prozkoumat, Rozbalit a Extrahovat. Nástroje pro optimalizaci nákladů v tomto článku odpovídají těmto fázím. Pomocí následující tabulky určete, které sekce se dnes vztahují na váš tým a které lze odložit.

Etapa Počet zaměstnanců Primární cíl nákladů Kroky, které se vyplatí
Prozkoumat 1–10 techniků Volitelnost a rychlost Štítkování, ukládání promptů do mezipaměti, levný výchozí model
Rozbalit 10–50 techniků Zastavte lineární růst nákladů spolu s růstem výnosů Sémantická mezipaměť, škálování na nulu, směrování, rozhraní API služby Batch
Extrahovat 50 a více techniků Margin, předvídatelnost, FinOps Rezervace, vyhrazené indexy, kvantování, ceny za tenanty

Určete své hlavní zdroje nákladů

Než začnete cokoli optimalizovat, udělejte si přehled o tom, kam peníze skutečně směřují. V Azure je nejrychlejší možností Cost Management, seskupený podle služeb a značek za posledních 30 dní.

Označte vše od prvního dne

Označování je nejúčinnějším postupem pro získání přehledu o nákladech. Bez konzistentních štítků nelze přiřadit náklady konkrétnímu tenantovi, funkci ani prostředí. Referenční architektura cílové zóny pro škálování startupů (SSLZ) vynucuje označování na úrovni zásad cílové zóny. Stejný přístup použijte pro prostředky AI.

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

Kam se podívat nejdříve

Nákladový faktor Kde ji najít Typický podíl na faktuře
Tokeny (LLM API) Metriky Azure OpenAI > Zpracované tokeny promptu/dokončení 30–60%
GPUs Hodiny uzlů VM/AKS podle SKU (řady ND, NC a NV) 20–50%
Vektorové vyhledávání Jednotky dotazů vyhledávání AI, RU/s služby Cosmos DB 5–20%
Storage Blob Storage, Azure Files a Azure Container Registry pro artefakty modelu 3–10%
Egress Šířka pásma mimo oblast, zejména volání mezi cloudy 2–15%

Denně exportujte data služby Cost Management do účtu úložiště a propojte je se svým stávajícím analytickým prostředím. Týdenní graf nákladů na aktivního uživatele je spolehlivý signál, že optimalizace měla zamýšlený účinek.

Páka 1: Ukládání do mezipaměti, dávkování, směrování a výběr modelu

Fázi: Prozkoumejte extrakci. Začněte s ukládáním do mezipaměti v Explore, v Expand přidejte směrování a dávkové zpracování a v Extract přidejte podrobný výběr modelu pro každého tenanta.

Tip

Ukládejte embeddingy do mezipaměti s klíčem odvozeným z hashe zdrojového obsahu a pro prvotní klasifikaci nebo extrakci použijte menší, levnější model, například GPT-4o mini nebo model s otevřenými vahami o velikosti 7B až 13B. Eskalovat na hraniční model pouze na požadavky, kde je malý model nejistý. Tento model sám často snižuje náklady na odvozování o 60 až 80 % bez měřitelné ztráty kvality u rutinních dotazů.

Caching

  • Ukládání promptů do mezipaměti: Azure OpenAI automaticky poskytuje slevu na opakované předpony u promptů o délce alespoň 1 024 tokenů; tato funkce je podporována v modelu GPT-4o a novějších modelech. Prvních 1 024 tokenů musí být identické pro přístup do mezipaměti, takže nechte systémové výzvy a definice nástrojů stabilní.
  • Sémantická mezipaměť: Ukládejte dvojice vektorových reprezentací a odpovědí do Azure Cache for Redis nebo Cosmos DB. Vrátí odpověď uloženou v mezipaměti, pokud má nový dotaz kosinus podobnosti nad přibližně 0,95.
  • Výstupní mezipaměť: U ne personalizovaných koncových bodů, jako jsou nejčastější dotazy a deterministické nástroje, snižuje mezipaměť TTL (Time to Live) provoz o 30 až 80 procent.

Batching

Embeddingové a klasifikační úlohy jsou nasnadě. Batch API služby Azure OpenAI nabízí o 50 % nižší cenu než zpracování v reálném čase u úloh, které mohou počkat až 24 hodin, jako jsou noční aktualizace indexů, běhy vyhodnocování a asynchronní sumarizace.

Routing

Většina produktů nepotřebuje při každém volání ten nejdražší model. Směrovač, založený na pravidlech nebo naučený, může posílat 60 až 80 procent provozu do levnějšího modelu bez měřitelného poklesu kvality.

Pattern Levná cesta Drahá cesta
Klasifikace záměru GPT-4o mini nebo Phi-4 GPT-4o pro nejednoznačné požadavky
Použití nástroje nebo volání funkcí Model střední vrstvy Nejvyšší model při opakovaném pokusu
Shrnutí dlouhého kontextu Posuvné okno s modelem střední vrstvy Model nejvyšší vrstvy s úplným kontextem
Generování kódu Model střední úrovně pro šablonový text Model nejvyšší úrovně pro refaktoringy

Výběr modelu

Přehodnotujte výběr modelu každé čtvrtiny. Ceny a kvalita se rychle pohybují. Model, který byl před šesti měsíci vaší jedinou možností, teď může být pětkrát dražší než novější SKU, které ve vašich evaluacích dosahuje výsledku jen o jeden až dva body horšího.

Páka 2: Optimalizace velikosti infrastruktury pomocí automatického škálování

Fázi: Rozbalit a extrahovat. V prozkoumávání používejte bezserverovou platformu nebo platformu jako službu (PaaS), jako je App Service, Container Apps consumption nebo Azure OpenAI Service a tuto páku přeskočte.

Pokud na Azure Kubernetes Service (AKS) nebo v Container Apps provozujete inferenci ve vlastní režii pomocí vLLM, Triton nebo Text Generation Inference (TGI), druhým nejdůležitějším faktorem je zajistit, aby GPU nezahálely.

Škálování na nulu u nečinných úloh

Nastavte minReplicas: 0 u kontejnerových aplikací s profilem zatížení GPU nebo v AKS použijte horizontální automatické škálování podů (HPA) či KEDA ke škálování fondů uzlů na nulu, pokud se právě nezpracovávají žádné požadavky. Studené starty obvykle trvají desítky sekund. Proveďte benchmark se svým modelem a během pracovní doby udržujte jednu zahřátou repliku, pokud je důležitá latence pro uživatele.

Zvolte vhodnou variantu GPU podle velikosti modelu

Porovná třídu GPU s počtem parametrů. T4 nebo L4 stačí pro modely nižší než 13B parametrů. A100 nebo H100 se vyplatí pouze u modelů s více než přibližně 34 miliardami parametrů nebo při trvale vysokém počtu dotazů za sekundu (QPS). Bezserverové GPU Container Apps v současné době podporuje T4 a A100. L4 a H100 vyžadují AKS.

Nárazové trénování a dávkové úlohy pro instance Spot

Spouštějte noční vyhodnocování, obnovu embeddingů a offline shrnutí na poolech spotových uzlů, které jsou obvykle o 60 až 80 % levnější než uzly na vyžádání. Pro produkční inferenci používejte vyhrazenou kapacitu. Následující tabulka shrnuje strategie automatického škálování a jejich typické úspory.

Caution

Spotovou kapacitu lze odebrat s upozorněním pouhých 30 sekund předem. Spot instance používejte pouze pro úlohy, u kterých lze průběžně ukládat checkpointy nebo je lze bez problémů restartovat, například dávkové vyhodnocování, aktualizaci embeddingů, offline sumarizaci a doladění s častým ukládáním checkpointů. Nikdy neumisťujte odvozování nebo úlohy bez restartování logiky na místě.

Strategy Jak Typické úspory
Škálování na nulu minReplicas: 0 v kontejnerových aplikacích s profilem úloh GPU. Studené starty obvykle trvají desítky sekund. Proveďte srovnávací testy s vaším modelem. Až 90%
KEDA na základě hloubky fronty Škálujte podle zpráv ve službě Service Bus nebo ve frontě, nikoli podle CPU. 30–60%
Správně dimenzované SKU T4 nebo L4 pro modely s méně než 13B parametry. A100 nebo H100 pouze pro modely s více než 34B parametry nebo vysokou úrovní QPS. Bezserverové GPU služby Container Apps v současné době podporuje pouze T4 a A100. L4 a H100 vyžadují AKS. 40–70%
Spotová kapacita Fondy spotových uzlů pro dávkové úlohy a vyhodnocení Kapacita na vyžádání pro produkci. 40–80%
Kvantování 4bitová kvantizace AWQ nebo GPTQ pro spuštění větších modelů na menších GPU. Přizpůsobit 30B na 16 GB

Note

Škálování na nulu na chatovací ploše přidává viditelnou latenci studeného startu. Běžným vzorem je zachování jedné až dvou teplých replik během pracovní doby a škálování na nulu přes noc.

Využití 3: Vzory s více tenanty bez nárůstů nákladů na načítání

Fáze: Pozdní rozšíření a extrakce V Explore téměř jistě máte pouze jednoho tenanta: vy sami. Tuto část přeskočte, dokud nebudete mít aspoň tři skutečné zákazníky.

Produkty AI s více tenanty selžou ve velkém měřítku při výběru vzorů načítání a databází pro prototyp jednoho tenanta. Rekurzují se tři vzory.

Jeden index na tenanta vs. sdílený index s filtry

Vyhrazený index vyhledávání AI na tenanta poskytuje čistou izolaci, ale účtuje se za každý index i v případě nečinnosti. Sdílený index s filtrem tenanta je mnohem levnější v malém a středním měřítku. Přepněte na vyhrazenou variantu pouze pro podnikovou úroveň nebo když tenant překročí definovaný práh velikosti.

Volba vektorové databáze

Zvolte úložiště vektorů na základě stávající infrastruktury a škálování. Následující tabulka shrnuje, kdy se jednotlivé možnosti hodí.

Warning

Odstranění vektorového indexu nebo jeho podkladového úložiště je nevratné a opětovné vytvoření embeddingů pro rozsáhlý korpus může stát stovky až tisíce dolarů za volání modelu plus hodiny inženýrské práce. Před jakoukoli destruktivní změnou vektorového úložiště pořiďte snapshot zdrojových dokumentů a ověřte, že pipeline pro opětovné vytváření embeddingů funguje end-to-end na malé podmnožině dokumentů.

Možnost Nejlepší pro Tvar nákladů
Azure AI Vyhledávač (vektorový) Hybridní vyhledávání a fazety Předvídatelné pro každou repliku
Cosmos DB (vektor) Týmy už používají Cosmos DB pro data aplikací RU/s, škáluje se pomocí QPS
pgvector on Postgres Malé nebo střední korpusy, jednoduché operace Za virtuální počítač, velmi levně
Vyhrazená vektorová databáze více než 100 milionů vektorů, požadavek na vysokou míru záchytu Na uzel, nákladný

Vyhněte se skrytému načítání N+1

Každý krok agenta, který volá search , je fakturovatelný dotaz. Zaznamenávejte počet volání načítání na jeden tah uživatele a upozorněte, když medián překročí váš rozpočet. Dobrým výchozím cílem jsou dvě nebo méně vyhledání na jedno kolo. U modulů pro změnu pořadí a přepisování snadno nechtěně zdvojíte provoz.

Zásady správného řízení: Zachování bezpečných změn nákladů

Fázi: Všechny fáze. Odlehčená verze, která zahrnuje rozpočet, jednořádkovou vyhodnocovací kontrolu před nasazením a jediný limit počtu požadavků, patří od začátku do sekce Explore. Robustnější varianta s vyhodnocovacími branami blokujícími CI a limity rychlosti pro jednotlivé tenanty ve službě API Management patří do fáze Expand a vyšších.

Optimalizace, která přeruší kvalitu, není optimalizace. Je to výpadek. Každou změnu nákladů ohraničte třemi mantinely. Každou mantinelu může jeden inženýr nastavit za hodinu.

  1. Kontrola zkušebního intervalu: Před nasazením jakékoli výzvy, modelu nebo změny směrování spusťte zkušební sadu. V rané fázi může být tato kontrola skriptem, který spustíte ručně. Zablokujte nasazení nebo se vraťte, pokud skóre klesne více než vaše tolerance, například jeden bod ve škále 100 bodů.
  2. Rozpočtová upozornění: Nastavte rozpočty Správa nákladů v Azure pro každou skupinu prostředků s upozorněními při 50, 80 a 100 %. Směřujte je do stejného kanálu ve Slacku nebo Teamsu, kam vám chodí upozornění na chyby, aby byly náklady i incidenty na jednom místě.
  3. Limit rychlosti požadavků: I jediný limit na IP adresu nebo API klíč v API Managementu, NGINXu nebo vaší bráně zabrání tomu, aby jediný klient, který se vymkne kontrole, přes noc vyčerpal váš kreditní zůstatek. Limity pro jednotlivé tenanty přidejte později, až budete mít platící zákazníky.

Buďte opatrní při sdružování několika optimalizací nákladů do jedné verze. Když se sada změn seskupí, přisuzování se stává obtížné a jakákoli regrese je náročná na bisect.

Experiment se dvěma páky: jak porovnat před a po

Když se rozhodujete, kde začít, zvolte dvě možnosti z předchozích částí, nasaďte je pod feature flagem a měřte po dobu 7 až 14 dní. K detekci smysluplné pohyby stačí dvě páky. Více než dvě činí přisuzování nespolehlivým.

Navrhované první párování podle fáze

Etapa Páka A Páka B
Před spuštěním (<100 DAU) Ukládání promptů do mezipaměti Směrování modelů s levným výchozím modelem
Počáteční růst (100–10k DAU) Sémantická mezipaměť Škálování na nulu při inferenci
Měřítko (10 tisíc+ DAU) Batch API pro asynchronní úlohy Strategie indexu pro jednotlivé tenanty
Úroveň Enterprise Vyhrazené indexy pro hlavní účty Kvantované modely na L4 nebo 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 tento článek popisuje a co ne

Tento článek je záměrně vymezený. Následující části obsahují seznam témat, která jsou v oboru, témata, která jsou mimo rozsah, a signály, které označují, kdy je přidat.

V rozsahu

  • Označování, rozpočty a postupy správy nákladů v Cost Managementu vhodné pro jakýkoli startup.
  • Čtyři páky na cestě požadavku: ukládání do mezipaměti, dávkování, směrování a výběr modelu.
  • Nastavení správné velikosti GPU a škálování na nulu pro odvozování v místním prostředí
  • Vzory načítání dat ve víceklientské architektuře pro produkty se třemi až 100 platícími klienty
  • Cyklus správy bezpečných změn: vyhodnocovací brána, rozpočtová upozornění a limity rychlosti pro jednotlivé tenanty.

Mimo rozsah

Téma Kdy ji přidat
Plány rezervací a úspor pro výpočetní prostředí AI Náklady na inferenci zůstávají po dobu 90 dní stejné, obvykle do poloviny období Expand.
Vyhrazené nástroje FinOps, jako jsou Apptio Cloudability, Vantage a podobné nástroje Útrata za cloud překračuje přibližně 50 000 USD za měsíc nebo pracujete s více cloudy. Většina startupů v rané fázi to nepotřebuje.
Fakturace na základě tokenů pro každého koncového zákazníka Prodáváte ceny založené na využití nebo jeden tenant překračuje 25 procent faktury.
Optimalizace nákladů na trénink, například ladění DeepSpeedu a FSDP Modely trénujete interně. Produkty zaměřené primárně na inferenci tohle nepotřebují.
Nákladová arbitráž mezi regiony nebo ve více cloudových prostředích Jste ve fázi Extrakce s prověřenou ekonomikou v jedné oblasti.

Pokud tento přístup už nestačí

Postupy v tomto článku jsou určené pro malé týmy, které používají vlastní cloud. V určitém okamžiku je vaše firma přeroste. Následující signály nejsou selhání. Jsou růstem. Pokud platí dvě nebo více z uvedených možností, naplánujte nasazení specializovaných nástrojů nebo zajištění správce platformy na částečný úvazek.

  • Měsíční Azure útraty překračují přibližně 50 000 USD a AI je vyšší než 30 procent.
  • Více než 10 inženýrů může nasazovat změny, které změní náklady o 5 % nebo více.
  • Alespoň jeden zákazník má měsíční spotřebu přes 10 000 USD a platí vám paušální poplatek.
  • Vaši investoři nebo finanční partner začali žádat o měsíční prognózu nákladů.
  • Produkt běží ve více Azure oblastech nebo cloudu.

Do té doby je tím správným nástrojem odlehčený proces popsaný v tomto článku, který zahrnuje štítky, rozpočty, vyhodnocovací bránu a měsíční revizi. Odolejte pokušení přijmout podnikové nástroje FinOps brzy. Zvyšuje režii procesu před tím, než přidá hodnotu.

Kontrolní seznam odkazů

Jako kontrolní seznam pro měsíční kontrolu použijte následující položky. Každá položka odpovídá sekci v tomto článku.

  • Všechny prostředky AI jsou označené značkou costCenter, tenant, workloada env.
  • Existuje řídicí panel Cost Management, je seskupený podle značky a kontroluje se každý týden.
  • Systémové prompty jsou dostatečně stabilní na to, aby docházelo k zásahům v mezipaměti promptů.
  • Asynchronní práce, jako jsou vkládání, hodnocení a souhrny, se spouští v rozhraní API služby Batch.
  • Směrovač odesílá alespoň 60 % provozu do levnějšího modelu bez regrese hodnocení.
  • GPU úlohy se mimo pracovní dobu škálují na nulu nebo pro dávkové úlohy využívají spot instance.
  • Medián počtu načtení na jeden tah je dva nebo nižší.
  • Strategie s více tenanty je zvolena explicitně: sdílena s filtrem nebo vyhrazenou.
  • Vynucují se rozpočty a limity sazeb pro jednotlivé tenanty.
  • Každý prompt, model nebo změna routování před sloučením spustí eval gate.
  • Poslední aktualizace v