Sdílet prostřednictvím

Řešení potíží s nasazením a vyhodnocováním online koncového bodu

  • Článek

PLATÍ PRO:Rozšíření Azure CLI ml v2 (aktuální)Python SDK azure-ai-ml v2 (aktuální)

Tento článek popisuje, jak identifikovat a řešit běžné problémy s nasazením a vyhodnocováním online koncových bodů Azure Machine Learning.

Struktura dokumentu odráží způsob, jakým byste měli řešit potíže:

  1. Použijte místní nasazení a před nasazením do cloudu proveďte místní otestování a odladění vašich modelů.
  2. Použijte protokoly kontejnerů, které vám pomohou odladit případné potíže.
  3. Seznamte se s běžnými chybami nasazení, ke kterým může dojít, a zjistěte, jak je opravit.

Část stavových kódů HTTP vysvětluje, jak se chyby vyvolání a predikce mapují na stavové kódy HTTP při vyhodnocování koncových bodů pomocí požadavků REST.

Požadavky

Trasování požadavků

Jsou dvě podporované hlavičky trasování:

  • x-request-id je vyhrazen pro sledování serverů. Azure Machine Learning tuto hlavičku přepíše, aby se zajistilo, že se jedná o platný identifikátor GUID. Když vytvoříte lístek podpory pro neúspěšnou žádost, připojte ID neúspěšné žádosti, abyste urychlili šetření. Případně zadejte název oblasti a název koncového bodu.

  • x-ms-client-request-id je k dispozici pro scénáře sledování klientů. Toto záhlaví přijímá pouze alfanumerické znaky, pomlčky a podtržítka a zkracuje se na maximálně 40 znaků.

Místní nasazení

Místní nasazení znamená nasazení modelu do místního prostředí Dockeru. Místní nasazení podporuje vytváření, aktualizaci a odstraňování místního koncového bodu a umožňuje vyvolat a získat protokoly z koncového bodu. Místní nasazení je užitečné pro testování a ladění před nasazením do cloudu.

Tip

K ladění hodnoticího skriptu na místním počítači můžete také použít balíček Pythonu pro inference HTTP serveru služby Azure Machine Learning. Ladění pomocí serveru odvozování vám pomůže ladit bodovací skript před nasazením do místních koncových bodů, abyste mohli ladit bez ovlivnění konfigurací kontejneru nasazení.

Nasazení můžete provést místně pomocí Azure CLI nebo sady Python SDK. studio Azure Machine Learning nepodporuje místní nasazení ani místní koncové body.

Pokud chcete použít místní nasazení, přidejte --local do příslušného příkazu.

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

Během místního nasazení dochází k následujícím krokům:

  1. Docker buď sestaví novou image kontejneru, nebo stáhne existující image z místní mezipaměti Dockeru. Docker používá existující image, pokud se shoduje s prostředím v souboru specifikace.
  2. Docker spustí nový kontejner s připojenými místními artefakty, jako jsou soubory modelu a kódu.

Další informace najdete v tématu Místní nasazení a ladění pomocí místního koncového bodu.

Tip

Visual Studio Code můžete použít k místnímu testování a ladění koncových bodů. Další informace naleznete v tématu Ladění online koncových bodů na místním počítači v aplikaci Visual Studio Code.

Získání protokolů kontejneru

Nemůžete získat přímý přístup k virtuálnímu počítači, na kterém se model nasazuje, ale můžete získat protokoly z některých kontejnerů spuštěných na virtuálním počítači. Množství informací, které obdržíte, závisí na stavu poskytování nasazení. Pokud zadaný kontejner běží, zobrazí se výstup na jeho konzoli. Jinak dostanete zprávu, abyste to zkusili znovu později.

Protokoly můžete získat z následujících typů kontejnerů:

  • Protokol konzoly inferenčního serveru obsahuje výstup funkcí tisků a protokolování z bodovacího skriptu score.py.
  • Protokoly inicializátoru úložiště obsahují informace o tom, jestli se data kódu a modelu úspěšně stáhla do kontejneru. Kontejner se spustí před spuštěním kontejneru serveru pro odvození.

U online koncových bodů Kubernetes můžou správci přistupovat přímo ke clusteru, do kterého model nasazujete, a kontrolovat protokoly v Kubernetes. Příklad:

kubectl -n <compute-namespace> logs <container-name>

Poznámka:

Pokud používáte protokolování Pythonu, nezapomeňte použít správnou úroveň protokolování, například INFO, aby se zprávy publikovaly do protokolů.

Zobrazení výstupu protokolu z kontejnerů

Pokud chcete zobrazit výstup protokolu z kontejneru, použijte následující příkaz:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

Nebo

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

Ve výchozím nastavení se protokoly načítají z inferenčního serveru. Protokoly můžete předáním –-container storage-initializer získat z kontejneru inicializátoru úložiště.

Pokud jste tyto parametry ještě nenastavili, přidejte --resource-group a --workspace-name do příkazů pomocí az configure. Pokud chcete zobrazit informace o tom, jak tyto parametry nastavit, nebo pokud máte aktuálně nastavené hodnoty, spusťte následující příkaz:

az ml online-deployment get-logs -h

Pokud chcete zobrazit další informace, přidejte --help nebo --debug do příkazů.

Běžné chyby nasazení

Stav operace nasazení může hlásit následující běžné chyby nasazení:

Pokud vytváříte nebo aktualizujete online nasazení Kubernetes, podívejte se také na běžné chyby specifické pro nasazení Kubernetes.

CHYBA: Selhání sestavení obrazu

Tato chyba se vrátí při vytváření prostředí image Dockeru. Další informace o selhání najdete v protokolu sestavení. Protokol sestavení se nachází ve výchozím úložišti pro váš pracovní prostor Azure Machine Learning.

Přesné umístění může být vráceno jako součást chyby, například "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

Následující části popisují běžné scénáře selhání sestavení obrazu:

Selhání autorizace ve službě Azure Container Registry

Chybová zpráva se zobrazí "container registry authorization failure" , když nemůžete získat přístup k registru kontejneru s aktuálními přihlašovacími údaji. Desynchronizace klíčů zdrojů pracovního prostoru může způsobit tuto chybu, a trvá nějakou dobu, než dojde k automatické synchronizaci. Můžete ale ručně provést synchronizaci klíčů pomocí příkazu az ml workspace sync-keys, což může vyřešit selhání autorizace.

Registry kontejnerů, které jsou za virtuální sítí, se můžou také setkat s touto chybou, pokud jsou správně nastavené. Ověřte, že je virtuální síť správně nastavená.

Výpočet sestavení image není nastaven v privátním pracovním prostoru propojeném s virtuální sítí.

Pokud se chybová zpráva zmíní "failed to communicate with the workspace's container registry"a používáte virtuální síť a registr kontejneru pracovního prostoru je privátní a nakonfigurovaný s privátním koncovým bodem, musíte službě Container Registry povolit vytváření imagí ve virtuální síti.

Vypršel časový limit pro vytvoření obrazu

Příčiny časových limitů při sestavování obrazu často zahrnují příliš velký obraz, který nelze dokončit v rámci časového rámce pro vytvoření nasazení. Zkontrolujte protokoly sestavení obrazu na místě, které je uvedeno v chybě. Protokoly se přeruší v bodě, kdy vypršel časový limit pro sestavení obrazu.

Pokud chcete tento problém vyřešit, sestavte samostatně image tak, aby se během vytváření nasazení musela načíst pouze jednou. Zkontrolujte také výchozí nastavení sondy, pokud se potýkáte s vypršením časových limitů u ImageBuild.

Selhání sestavení obecného obrazu

Další informace o selhání najdete v protokolu sestavení. Pokud se v protokolu sestavení nenajde žádná zjevná chyba a poslední řádek je Installing pip dependencies: ...working..., chybu může způsobovat závislost. Tento problém můžete vyřešit připnutím závislostí verzí v souboru conda.

Zkuste modely otestovat a ladit místně před nasazením do cloudu.

CHYBA: Překročená kvóta

Při používání služeb Azure může dojít k vyčerpání kvóty následujících prostředků:

Pouze u online koncových bodů Kubernetes může také dojít k vyčerpání kvóty zdroje Kubernetes.

Kvóta procesoru

K nasazení modelu potřebujete dostatečnou kvótu výpočetních prostředků. Kvóta procesoru definuje, kolik virtuálních jader je dostupných na předplatné, na pracovní prostor, na skladovou položku a v jednotlivých oblastech. Každé nasazení odečte z dostupné kvóty a po odstranění ji přidá zpět, v závislosti na typu SKU.

Můžete zkontrolovat, jestli neexistují nepoužívané nasazení, která můžete odstranit, nebo můžete odeslat žádost o navýšení kvóty.

Kvóta clusteru

K OutOfQuota chybě dochází v případě, že nemáte dostatečnou kvótu výpočetního clusteru služby Azure Machine Learning. Kvóta definuje celkový počet clusterů na předplatné, které můžete použít současně k nasazení uzlů PROCESORu nebo GPU v cloudu Azure.

Kvóta disků

K OutOfQuota chybě dochází, když je velikost modelu větší než dostupné místo na disku a model nejde stáhnout. Zkuste použít skladovou položku s větším místem na disku nebo zmenšit velikost image a modelu.

Kvóta paměti

K OutOfQuota chybě dochází, když je využití paměti modelu větší než dostupná paměť. Zkuste SKU s větší pamětí.

Kvóta přiřazení rolí

Když vytvoříte spravovaný online koncový bod, vyžaduje se přiřazení role pro spravovanou identitu pro přístup k prostředkům pracovního prostoru. Pokud dosáhnete limitu přiřazení role, zkuste odstranit některá nepoužitá přiřazení rolí v tomto předplatném. Všechna přiřazení rolí můžete zkontrolovat tím, že v Azure portálu vyberete Řízení přístupu pro vaše předplatné Azure.

Kvóta koncových bodů

Zkuste odstranit některé nepoužívané koncové body v tomto předplatném. Pokud se aktivně používají všechny vaše koncové body, zkuste požádat o navýšení limitu koncového bodu. Další informace o limitu koncového bodu najdete v tématu Kvóta koncových bodů pomocí online koncových bodů služby Azure Machine Learning a dávkových koncových bodů.

Kvóta Kubernetes

K OutOfQuota chybě dochází v případě, že požadovaný procesor nebo paměť nelze poskytnout kvůli neplánovatelným uzlům pro toto nasazení. Například uzly mohou být izolovány nebo jinak nedostupné.

Chybová zpráva obvykle značí nedostatečnost prostředků v clusteru, například OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Tato zpráva znamená, že v clusteru je příliš mnoho podů a není dostatek prostředků k nasazení nového modelu na základě vaší žádosti.

Pokud chcete tento problém vyřešit, zkuste následující omezení rizik:

  • Operátoři IT, kteří udržují cluster Kubernetes, se můžou pokusit přidat další uzly nebo vymazat některé nepoužívané pody v clusteru a uvolnit některé prostředky.

  • Technici strojového učení, kteří nasazují modely, se mohou pokusit snížit požadavek na prostředky nasazení.

    • Pokud přímo definujete požadavek na prostředek v konfiguraci nasazení prostřednictvím oddílu prostředků, zkuste snížit požadavek na prostředek.
    • Pokud používáte instance_type k definování prostředku pro nasazení modelu, obraťte se na it operátora a upravte konfiguraci prostředku typu instance. Další informace najdete v tématu Vytváření a správa typů instancí.

Kapacita virtuálního počítače na úrovni celé oblasti

Kvůli nedostatku kapacity služby Azure Machine Learning v oblasti se službě nepodařilo zřídit zadanou velikost virtuálního počítače. Zkuste to znovu později nebo zkuste nasazení do jiné oblasti.

Jiná kvóta

Pokud chcete spustit soubor score.py , který zadáte jako součást nasazení, Azure vytvoří kontejner, který obsahuje všechny prostředky, které score.py potřebuje. Azure Machine Learning pak v tomto kontejneru spustí bodovací skript. Pokud se váš kontejner nedá spustit, bodování se nestane. Kontejner může vyžadovat více prostředků, než instance_type může podporovat. Zvažte aktualizaci nasazení online instance_type.

Pokud chcete získat přesný důvod chyby, proveďte následující akci.

Spusťte následující příkaz:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

CHYBA: ŠpatnýArgument

K této chybě může dojít při použití spravovaných online koncových bodů nebo online koncových bodů Kubernetes z následujících důvodů:

Tato chyba se může zobrazit také při používání online koncových bodů Kubernetes, a to z následujících důvodů:

Předplatné neexistuje.

Odkazované předplatné Azure musí být existující a aktivní. K této chybě dochází, když Azure nemůže najít ID předplatného, které jste zadali. Příčinou chyby může být překlep v ID předplatného. Pečlivě zkontrolujte, jestli se ID předplatného správně zadalo a je aktuálně aktivní.

Chyba autorizace

Po zřízení výpočetního prostředku při vytváření nasazení Azure stáhne image kontejneru uživatele z registru kontejnerů pracovního prostoru a připojí uživatelský model a artefakty kódu do kontejneru uživatele z účtu úložiště pracovního prostoru. Azure používá spravované identity pro přístup k účtu úložiště a registru kontejneru.

Pokud vytvoříte přidružený koncový bod s identitou přiřazenou uživatelem, musí mít spravovaná identita uživatele oprávnění ke čtení dat objektů blob úložiště k účtu úložiště pracovního prostoru a oprávnění AcrPull v registru kontejneru pracovního prostoru. Ujistěte se, že vaše identita přiřazená uživatelem má správná oprávnění.

Pokud je povolena funkce MDC, spravovaná identita uživatele musí mít oprávnění Přispěvatel dat úložiště blob v účtu úložiště pracovního prostoru. Další informace najdete v tématu Chyba autorizace úložiště blobů, je-li povolen MDC.

Pokud vytvoříte přidružený koncový bod s identitou přiřazenou systémem, automaticky se udělí oprávnění řízení přístupu na základě role (RBAC) Azure a žádná další oprávnění se nepotřebují. Další informace najdete v tématu Chyba autorizace registru kontejneru.

Neplatná specifikace funkce šablony

K této chybě dochází, když byla nesprávně zadána funkce šablony. Opravte zásadu nebo zrušte přiřazení zásady pro odblokování. Chybová zpráva může obsahovat název přiřazení zásady a definici zásady, aby vám pomohla při odstraňování této chyby. Tipy , jak se vyhnout chybám šablon, najdete v tématu Struktura definic zásad Azure.

Nejde stáhnout image kontejneru uživatele

Kontejner uživatele pravděpodobně nebyl nalezen. Další podrobnosti najdete v protokolech kontejneru.

Ujistěte se, že je image kontejneru dostupná v registru kontejneru pracovního prostoru. Pokud je například obrázek testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, můžete pomocí následujícího příkazu zkontrolovat úložiště:

az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table`

Nejde stáhnout uživatelský model

Uživatelský model pravděpodobně nebyl nalezen. Další podrobnosti najdete v protokolech kontejneru. Ujistěte se, že jste model zaregistrovali do stejného pracovního prostoru jako pro nasazení.

Pokud chcete zobrazit podrobnosti modelu v pracovním prostoru, proveďte následující akci. Abyste získali informace o modelu, musíte zadat buď verzi, nebo popisek.

Spusťte následující příkaz:

az ml model show --name <model-name> --version <version>

Zkontrolujte také, jestli jsou bloby v úložišti v účtu pracovního prostoru. Pokud je například https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl objekt blob, můžete pomocí následujícího příkazu zkontrolovat, jestli objekt blob existuje.

az storage blob exists --account-name <storage-account-name> --container-name <container-name> --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>

Pokud je objekt blob k dispozici, můžete pomocí následujícího příkazu získat protokoly z inicializátoru úložiště:

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

Formát modelu MLflow s privátní sítí není podporován.

Pokud používáte starší metodu izolace sítě pro spravované online koncové body, nemůžete použít funkci privátní sítě s formátem modelu MLflow. Pokud potřebujete nasadit model MLflow s přístupem bez kódu, zkuste použít virtuální síť spravovanou pracovním prostorem.

Požadavky na prostředky větší než limity

Požadavky na prostředky musí být menší nebo rovny limitům. Pokud nenastavíte limity, Azure Machine Learning při připojení výpočetních prostředků k pracovnímu prostoru nastaví výchozí hodnoty. Limity můžete zkontrolovat na webu Azure Portal nebo pomocí az ml compute show příkazu.

Azureml-fe není připravený

Front-endová azureml-fe komponenta, která směruje příchozí dotazy pro odvození na nasazené služby, se nainstaluje během instalace k8s-rozšíření a automaticky se škáluje podle potřeby. Tato komponenta by měla mít v clusteru alespoň jednu repliku, která je v pořádku.

Tato chyba se zobrazí, pokud není komponenta dostupná, když spustíte online endpoint Kubernetes nebo provedete žádost o vytvoření nebo aktualizaci nasazení. Pokud chcete tento problém vyřešit, zkontrolujte stav podu a protokoly. Můžete se také pokusit aktualizovat rozšíření k8s nainstalované v clusteru.

CHYBA: Prostředek není připraven

Pokud chcete spustit soubor score.py , který zadáte jako součást nasazení, Azure vytvoří kontejner, který obsahuje všechny prostředky, které score.py potřebuje, a spustí v daném kontejneru bodovací skript. Chyba v tomto scénáři spočívá v tom, že tento kontejner při spuštění narazí, takže není možné bodovat. K této chybě může dojít za jedné z následujících podmínek:

  • V score.py došlo k chybě. Slouží get-logs k diagnostice běžných problémů, například:

    • Balíček, který se score.py pokouší importovat, ale není součástí prostředí conda
    • Chyba syntaxe
    • Selhání v init() metodě

    Pokud get-logs nevytvářejí žádné protokoly, obvykle to znamená, že se kontejner nepodařilo spustit. Pokud chcete tento problém odstraňovat, zkuste ho nasadit lokálně.

  • Testy připravenosti nebo životnosti nejsou správně nastavené.

  • Inicializace kontejneru trvá příliš dlouho, takže test připravenosti nebo aktivity selže nad prahovou hodnotu selhání. V tomto případě upravte nastavení sondy tak, aby bylo umožněno delší čas na inicializaci kontejneru. Nebo zkuste větší podporovaný VM SKU, který zrychluje inicializaci.

  • V nastavení prostředí kontejneru došlo k chybě, například chybějící závislost.

    Pokud se zobrazí chyba TypeError: register() takes 3 positional arguments but 4 were given, zkontrolujte kompatibilitu mezi flask verze 2 a azureml-inference-server-http. Další informace najdete v tématu Řešení potíží se serverem HTTP.

CHYBA: Prostředek Nenalezen

K této chybě může dojít při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes z následujících důvodů:

Resource Manager nemůže najít prostředek

K této chybě dochází, když Azure Resource Manager nemůže najít požadovaný prostředek. Tato chyba se může zobrazit například v případě, že se v zadané cestě nepodařilo najít účet úložiště. Pečlivě zkontrolujte cestu nebo specifikace názvu pro přesnost a pravopis. Další informace naleznete v tématu Řešení chyb pro Prostředek Nenalezen.

Chyba autorizace registru kontejneru

K této chybě dochází v případě, že je pro nasazení zadána image patřící do privátního nebo jinak nepřístupného registru kontejneru. Rozhraní API služby Azure Machine Learning nemůžou přijímat přihlašovací údaje privátního registru.

Pokud chcete tuto chybu zmírnit, ujistěte se, že registr kontejneru není soukromý, nebo proveďte následující kroky:

  1. Udělte roli acrPull vašeho privátního registru systémové identitě vašeho online koncového bodu.
  2. V definici prostředí zadejte adresu vaší soukromé image a dejte pokyn, aby image neupravoval ani nevytvořil.

Pokud toto zmírnění proběhne úspěšně, obrázek nevyžaduje sestavení a konečná adresa obrázku je daná adresa obrázku. V době nasazení stáhne identita systému vašeho online koncového bodu obraz z privátního registru.

Další diagnostické informace najdete v tématu Použití diagnostiky pracovního prostoru.

CHYBA: Workspace Spravovaná Síť Není Připravená

K této chybě dochází v případě, že se pokusíte vytvořit online nasazení, které umožňuje virtuální síť spravovanou pracovním prostorem, ale spravovaná virtuální síť ještě není zřízená. Před vytvořením online nasazení zřiďte virtuální síť spravovanou pracovním prostorem.

Pokud chcete ručně zřídit spravovanou virtuální síť pracovního prostoru, postupujte podle pokynů v části Ruční zřízení spravované virtuální sítě. Následně můžete začít vytvářet nasazení online. Další informace najdete v tématu Izolace sítě se spravovaným online koncovým bodem a zabezpečení spravovaných online koncových bodů pomocí izolace sítě.

CHYBA: Operace zrušena

K této chybě může dojít při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes z následujících důvodů:

Operace zrušená jinou operací s vyšší prioritou

Operace Azure mají určitou úroveň priority a provádějí se od nejvyšších po nejnižší. K této chybě dochází, když jiná operace s vyšší prioritou přepíše vaši operaci. Opětovné spuštění operace může umožnit pokračování bez zrušení.

Operace byla zrušena při čekání na potvrzení zámku.

Operace Azure mají po odeslání krátkou čekací dobu, během které získají zámek, aby zajistily, že nenarazí na souběžné podmínky. K této chybě dochází, když je operace, kterou jste odeslali, stejná jako jiná operace. Druhá operace aktuálně čeká na potvrzení, že obdržela zámek před tím, než bude pokračovat.

Možná jste po počátečním požadavku odeslali podobný požadavek příliš brzy. Opakování operace po čekání až minutu může umožnit, aby se operace prováděla bez zrušení.

CHYBA: Chyba při vkládání tajemství

Načítání tajných kódů a injektáž během vytváření online nasazení používá identitu přidruženou k online koncovému bodu k načtení tajných kódů z připojení pracovního prostoru nebo trezorů klíčů. K této chybě dochází z jednoho z následujících důvodů:

  • Identita koncového bodu nemá oprávnění Azure RBAC ke čtení tajných kódů z připojení pracovního prostoru nebo trezorů klíčů, i když definice nasazení zadala tajné kódy jako odkazy namapované na proměnné prostředí. Předtím, než se změny při přiřazování rolí projeví, může to chvíli trvat.

  • Formát odkazů na tajné kódy je neplatný nebo zadané tajné kódy neexistují v připojeních pracovního prostoru nebo trezorech klíčů.

Další informace najdete v tématu Injektáž tajných kódů v online koncových bodech (Preview) a Přístup k tajným kódům z online nasazení pomocí injektáže tajných kódů (Preview).

CHYBA: Interní chyba serveru

Tato chyba znamená, že ve službě Azure Machine Learning je něco špatně, co je potřeba opravit. Odešlete požadavek zákaznické podpory se všemi potřebnými informacemi k vyřešení problému.

Běžné chyby specifické pro nasazení Kubernetes

Chyby identit a ověřování:

Chyby CrashLoopBackOff:

Chyby hodnoticího skriptu:

Jiné chyby:

CHYBA: ACRSecretError

Při vytváření nebo aktualizaci nasazení Kubernetes online se mohou zobrazit tyto chyby z jednoho z následujících důvodů:

  • Přiřazení role není dokončeno. Počkejte několik sekund a zkuste to znovu.

  • Cluster Kubernetes s podporou Služby Azure Arc nebo rozšíření AKS Azure Machine Learning není správně nainstalovaný nebo nakonfigurovaný. Zkontrolujte konfiguraci a stav rozšíření Azure Arc-enabled Kubernetes nebo Azure Machine Learning.

  • Cluster Kubernetes má nesprávnou konfiguraci sítě. Zkontrolujte proxy server, zásady sítě nebo certifikát.

  • Váš privátní cluster AKS nemá správné koncové body. Nezapomeňte nastavit privátní koncové body pro Container Registry, účet úložiště a pracovní prostor ve virtuální síti AKS.

  • Vaše verze rozšíření Azure Machine Learning je v1.1.25 nebo nižší. Ujistěte se, že je vaše verze rozšíření větší než verze 1.1.25.

CHYBA: Obnovení tokenu se nezdařilo

K této chybě dochází, protože identita clusteru Kubernetes není správně nastavená, takže rozšíření nemůže získat hlavní přihlašovací údaje z Azure. Přeinstalujte rozšíření Azure Machine Learning a zkuste to znovu.

CHYBA: GetAADTokenFailed

K této chybě dochází, protože došlo k selhání nebo vypršení časového limitu požadavku clusteru Kubernetes na token Microsoft Entra ID. Zkontrolujte síťový přístup a zkuste to znovu.

  • Podle pokynů v části Use Kubernetes compute zkontrolujte odchozí proxy a ujistěte se, že se cluster může připojit k pracovnímu prostoru. Adresu URL koncového bodu pracovního prostoru najdete v definici vlastního prostředku (CRD) online v clusteru.

  • Zkontrolujte, jestli pracovní prostor umožňuje veřejný přístup. Bez ohledu na to, jestli je samotný cluster AKS veřejný nebo soukromý, může cluster Kubernetes komunikovat s tímto pracovním prostorem pouze prostřednictvím privátního propojení. Další informace najdete v tématu Co je zabezpečené prostředí pro odvozování AKS.

CHYBA: Selhání výzvy ACR ověřování

K této chybě dochází, protože cluster Kubernetes se nemůže spojit se službou Container Registry pracovního prostoru a provést ověřovací výzvu. Zkontrolujte síť, zejména přístup k veřejné síti služby Container Registry, a zkuste to znovu. Při kontrole sítě můžete postupovat podle kroků pro řešení potíží v getAADTokenFailed .

CHYBA: Selhání výměny tokenu ACR

K této chybě dochází, protože token Microsoft Entra ID ještě není autorizovaný, takže token pro výměnný registr kontejnerů v clusteru Kubernetes selže. Přiřazení role nějakou dobu trvá, proto chvíli počkejte a zkuste to znovu.

Příčinou tohoto selhání může být také příliš mnoho souběžných požadavků na službu Container Registry. Tato chyba by měla být přechodná a můžete to zkusit později.

CHYBA: KubernetesNepřístupný

Při nasazení modelu Kubernetes se může zobrazit následující chyba:

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Pokud chcete tuto chybu zmírnit, můžete certifikát AKS pro cluster otočit. Nový certifikát by se měl aktualizovat po 5 hodinách, takže můžete počkat na 5 hodin a znovu ho nasadit. Další informace najdete v tématu Obměny certifikátů ve službě Azure Kubernetes Service (AKS).

CHYBA: ImagePullLoopBackOff

Můžete narazit na tuto chybu při vytváření nebo aktualizaci online nasazení Kubernetes, protože nemůžete stáhnout obrazy z registru kontejneru, což vede k chybě při stahování obrazů. Zkontrolujte zásady sítě clusteru a registr kontejneru pracovního prostoru a zjistěte, jestli cluster dokáže načíst image z registru kontejneru.

CHYBA: Deployment CrashLoopBackOff

Tato chyba se může zobrazit, když vytváříte nebo aktualizujete online nasazení v Kubernetes, protože kontejner uživatele havaroval při inicializaci. K této chybě existují dva možné důvody:

  • Uživatelský skript score.py má chybu syntaxe nebo chybu importu, která vyvolává výjimky při inicializaci.
  • Pod nasazení potřebuje více paměti, než je jeho limit.

Pokud chcete tuto chybu zmírnit, nejprve zkontrolujte, jestli protokoly nasazení neobsahují výjimky ve skriptech uživatelů. Pokud chyba přetrvává, zkuste rozšířit limit paměti typu prostředku nebo instance.

CHYBA: KubernetesCrashLoopBackOff (error opakovaného selhání Kubernetes)

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů nebo nasazení Kubernetes z jednoho z následujících důvodů:

  • Jeden nebo více podů uvízlo ve stavu CrashLoopBackoff. Zkontrolujte, jestli protokol nasazení existuje, a v protokolu jsou chybové zprávy.
  • V score.py došlo k chybě a při inicializaci vašeho kódu skóre kontejner havaroval. Postupujte podle pokynů v části CHYBA: ResourceNotReady.
  • Proces vyhodnocování potřebuje více paměti, než je limit konfigurace nasazení. Můžete zkusit aktualizovat nasazení s větším limitem paměti.

CHYBA: Namespace nebyl nalezen

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů Kubernetes, protože obor názvů použitý vaším výpočetním prostředkem Kubernetes není dostupný ve vašem clusteru. Zkontrolujte výpočet v Kubernetes na vašem portálu pracovního prostoru a zkontrolujte obor názvů ve vašem Kubernetes clusteru. Pokud obor názvů není dostupný, odpojte starší výpočetní prostředí a znovu se připojte k vytvoření nového, při čemž zadejte obor názvů, který už v clusteru existuje.

CHYBA: Nezdařila se inicializace uživatelského skriptu (UserScriptInitFailed)

K této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, protože funkce init ve vašem souboru nahraném score.py vyvolala výjimku. Podrobné informace o výjimce najdete v protokolech nasazení a opravte výjimku.

CHYBA: UserScriptImportError

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože score.py soubor, který jste nahráli, importuje nedostupné balíčky. Podrobné informace o výjimce najdete v protokolech nasazení a opravte výjimku.

CHYBA: Funkce skriptu nenalezena

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože score.py soubor, který jste nahráli, nemá funkci s názvem init() nebo run(). Zkontrolujte kód a přidejte funkci.

CHYBA: Nenalezen Konečný Bod

Tato chyba se může zobrazit při vytváření nebo aktualizaci nasazení Kubernetes online, protože systém nemůže najít prostředek koncového bodu pro nasazení v clusteru. Vytvořte nasazení v existujícím koncovém bodu nebo nejprve vytvořte koncový bod v clusteru.

CHYBA: Koncový bod již existuje

Tato chyba se může zobrazit při vytváření online koncového bodu Kubernetes, protože koncový bod už ve vašem clusteru existuje. Název koncového bodu by měl být jedinečný pro každý pracovní prostor a pro cluster, takže vytvořte koncový bod s jiným názvem.

CHYBA: Nezdravé bodováníFe

K této chybě může dojít při vytváření nebo aktualizaci online koncového bodu nebo nasazení Kubernetes, protože služba systému azureml-fe , která běží v clusteru, nebyla nalezena nebo není v pořádku. Pokud chcete tento problém zmírnit, přeinstalujte nebo aktualizujte rozšíření Azure Machine Learning ve vašem clusteru.

CHYBA: Nepodařilo se ověřit skórování

K této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, protože ověření URL pro žádost o hodnocení selhalo při zpracování modelu. Zkontrolujte adresu URL koncového bodu, a pak zkuste znovu nasadit.

CHYBA: Neplatná specifikace nasazení

K této chybě může dojít, když vytváříte nebo aktualizujete nasazení Kubernetes do online prostředí, protože specifikace nasazení je neplatná. Zkontrolujte chybovou zprávu a ujistěte se, že instance count je platná. Pokud jste povolili automatické škálování, ujistěte se, že minimum instance count a maximum instance count jsou obě platné.

CHYBA: PodUnschedulable

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů nebo nasazení Kubernetes z jednoho z následujících důvodů:

  • Systém nemůže naplánovat pod na uzly kvůli nedostatečným prostředkům v clusteru.
  • Žádný uzel neodpovídá selektoru spřažení uzlů.

Pokud chcete tuto chybu zmírnit, postupujte takto:

  1. Zkontrolujte definici node selector, kterou jste použili pro instance_type, a konfiguraci uzlů vašeho clusteru node label.
  2. Zkontrolujte instance_type a velikost SKU uzlu pro cluster AKS nebo prostředek uzlu pro cluster Kubernetes s podporou Azure Arc.
  3. Pokud je cluster nedostatečně vybaven, snižte požadavky na prostředky pro typ instance nebo použijte jiný typ instance s menšími požadavky na prostředky.
  4. Pokud cluster nemá další prostředky, které by splňovaly požadavek nasazení, odstraňte některá nasazení, aby uvolnila prostředky.

CHYBA: PodOutOfMemory

K této chybě může dojít při vytváření nebo aktualizaci online nasazení, protože limit paměti, který jste zadali pro nasazení, není dostatečná. Pokud chcete tuto chybu zmírnit, můžete nastavit limit paměti na větší hodnotu nebo použít větší typ instance.

CHYBA: Volání klienta pro inferenci selhalo

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů nebo nasazení Kubernetes, protože rozšíření k8s v clusteru Kubernetes nelze připojit. V takovém případě odpojte a znovu připojte výpočetní prostředky.

Pokud chcete vyřešit chyby opětovným připojením, nezapomeňte se znovu připojit se stejnou konfigurací jako odpojené výpočetní prostředky, jako je název výpočetních prostředků a obor názvů, abyste se vyhnuli dalším chybám. Pokud to stále nefunguje, požádejte správce, který má přístup ke clusteru kubectl get po -n azureml , aby zkontroloval, jestli jsou pody přenosového serveru spuštěné.

Problémy se spotřebou modelů

Mezi běžné chyby spotřeby modelu vyplývající ze stavu operace koncového bodu invoke patří problémy s omezením šířky pásma, zásady CORS a různé stavové kódy HTTP.

Problémy s limitem šířky pásma

Spravované online koncové body mají pro každý koncový bod omezení šířky pásma. Konfiguraci limitu najdete v limitech pro online koncové body. Pokud využití šířky pásma překročí limit, vaše žádost se zpozdí.

Pokud chcete monitorovat zpoždění šířky pásma, použijte metriku bajtů sítě k pochopení aktuálního využití šířky pásma. Další informace najdete v tématu Monitorování spravovaných online koncových bodů.

Pokud je vynucen limit šířky pásma, vrátí se dvě následné odpovědi:

  • ms-azureml-bandwidth-request-delay-ms je doba zpoždění v milisekundách, kterou trvalo pro přenos datového proudu požadavku.
  • ms-azureml-bandwidth-response-delay-msje doba zpoždění v milisekundách, která trvala pro přenos datového proudu odpovědi.

Blokované zásadami CORS

Online endpointy V2 nepodporují nativně Cross-Origin Resource Sharing (CORS), sdílení zdrojů mezi doménami. Pokud se vaše webová aplikace pokusí vyvolat koncový bod bez správného zpracování předběžných požadavků CORS, zobrazí se následující chybová zpráva:

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

Azure Functions, Azure Application Gateway nebo jinou službu můžete použít jako dočasnou vrstvu pro zpracování předběžných požadavků CORS.

Stavové kódy HTTP

Při přístupu k online koncovým bodům pomocí požadavků REST splňují vrácené stavové kódy standardy stavových kódů HTTP. Následující části obsahují podrobnosti o tom, jak se chyby volání koncového bodu a predikce přiřazují ke stavovým kódům HTTP.

Běžné kódy chyb pro spravované online koncové body

Následující tabulka obsahuje běžné kódy chyb, když požadavky REST spotřebovávají spravované online koncové body:

Stavový kód Důvod Popis
200 OK Model se úspěšně spustil v mezích latence.
401 Neautorizováno Nemáte oprávnění k provedení požadované akce, například ohodnocení, nebo váš token vypršel či má nesprávný formát. Další informace najdete v tématu Ověřování spravovaných online koncových bodů a ověřování klientů pro online koncové body.
404 Nenalezeno Koncový bod nemá žádné platné nasazení s kladnou hmotností.
408 Časový limit požadavku vypršel Provádění modelu trvalo déle než časový limit zadaný v request_timeout_ms rámci request_settings konfigurace nasazení modelu.
424 Chyba modelu Pokud kontejner modelu vrátí odpověď, která není 200, Azure vrátí hodnotu 424. Zkontrolujte dimenzi Model Status Code pod metrikou Requests Per Minute v Průzkumníku metrik Azure Monitor vašeho koncového bodu. Nebo zkontrolujte hlavičky odpovědí ms-azureml-model-error-statuscode a ms-azureml-model-error-reason, abyste získali další informace. Pokud se 424 dodává se selháním liveness či readiness sondy, zvažte úpravu ProbeSettings, abyste umožnili delší dobu pro testování živosti nebo připravenosti kontejneru.
429 Příliš mnoho čekajících požadavků Váš model momentálně dostává více požadavků, než dokáže zpracovat. Aby bylo zaručeno bezproblémové fungování, Azure Machine Learning umožňuje provádět maximálně 2 * max_concurrent_requests_per_instance * instance_count requests zpracování paralelně v libovolném okamžiku. Žádosti, které překračují toto maximum, jsou odmítnuty.

Konfiguraci nasazení modelu můžete zkontrolovat a v části request_settings a scale_settings ověřit a upravit tato nastavení. Také se ujistěte, že je proměnná prostředí WORKER_COUNT správně předána, jak je uvedeno v RequestSettings.

Pokud se vám při použití automatického škálování zobrazí tato chyba, váš model dostává požadavky rychleji, než může vertikálně navýšit kapacitu systému. Zvažte opětovné odeslání požadavků s exponenciálním zpoždováním , abyste systému poskytli čas na úpravu. Počet instancí můžete také zvýšit pomocí kódu k výpočtu počtu instancí. Zkombinujte tyto kroky s nastavením automatického škálování, abyste měli jistotu, že je váš model připravený ke zpracování nárůstu požadavků.
429 Omezení rychlosti Počet žádostí za sekundu dosáhl limitů spravovaných online koncových bodů.
500 Vnitřní chyba serveru Infrastruktura zřízená službou Azure Machine Learning selhává.

Běžné kódy chyb pro online koncové body Kubernetes

Následující tabulka obsahuje běžné kódy chyb, když požadavky REST spotřebovávají online koncové body Kubernetes:

Stavový kód Chyba Popis
409 Chyba konfliktu Pokud už operace probíhá, všechny nové operace na stejném online koncovém bodu reagují chybou 409 konfliktu. Pokud například probíhá operace vytvoření nebo aktualizace online koncového bodu, vyvolá se při aktivaci nové operace odstranění chyba.
502 Výjimka nebo chybové ukončení v metodě souboru run() Pokud dojde k chybě v score.py, například importovaný balíček, který v prostředí conda neexistuje, chyba syntaxe nebo selhání v init() metodě, podívejte se na CHYBA: ResourceNotReady pro ladění souboru.
503 Velké špičky požadavků za sekundu Autoscaler je navržen tak, aby zpracovával postupné změny zatížení. Pokud dostáváte velké špičky požadavků za sekundu, klienti můžou obdržet stavový kód HTTP 503. I když automatické škálování rychle reaguje, trvá AKS značné množství času, než vytvoří více kontejnerů. Podívejte se, jak zabránit chybám stavových kódů 503.
504 Časový limit žádosti vypršel Stavový kód 504 označuje, že vypršel časový limit požadavku. Výchozí nastavení časového limitu je 5 sekund. Časový limit můžete zvýšit nebo zkusit urychlit koncový bod úpravou score.py , aby se odebraly nepotřebná volání. Pokud tyto akce problém neopraví, může být kód v nereagujícím stavu nebo nekonečné smyčce. Postupujte podle CHYBY: ResourceNotReady pro ladění souboru score.py.
500 Vnitřní chyba serveru Infrastruktura zřízená službou Azure Machine Learning selhává.

Jak zabránit chybám stavových kódů 503

Online nasazení Kubernetes podporují automatické škálování, což umožňuje přidání replik pro podporu dodatečného zatížení. Další informace najdete v tématu Směrovač odvozování ve službě Azure Machine Learning. Rozhodnutí o navýšení nebo snížení rozsahu závisí na využití aktuálních replik kontejneru.

Dvě akce můžou pomoct zabránit chybám stavového kódu 503: Změna úrovně využití pro vytváření nových replik nebo změna minimálního počtu replik. Tyto přístupy můžete použít jednotlivě nebo v kombinaci.

  • Změňte cíl využití, při kterém automatické škálování vytváří nové repliky nastavením autoscale_target_utilization na nižší hodnotu. Tato změna nezpůsobí rychlejší vytváření replik, ale s nižší prahovou hodnotou využití. Změna hodnoty na 30 % například způsobí, že se repliky vytvoří při 30% využití, aniž by bylo potřeba čekat, až bude služba využita na 70 %.

  • Změňte minimální počet replik, aby bylo k dispozici větší množství, které dokáže zvládnout příchozí špičky.

Jak vypočítat počet instancí

Pokud chcete zvýšit počet instancí, můžete vypočítat požadované repliky následujícím způsobem:

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

Poznámka:

Pokud obdržíte špičky požadavků, které překročí kapacitu nových minimálních replik, můžete znovu obdržet chybu 503. Například s rostoucím provozem na vašem koncovém bodu možná budete muset zvýšit minimální počet replik.

Pokud online koncový bod Kubernetes už používá aktuální maximální počet replik a stále získáte stavové kódy 503, zvyšte hodnotu, abyste zvýšili autoscale_max_replicas maximální počet replik.

Problémy s izolací sítě

Tato část obsahuje informace o běžných problémech s izolací sítě.

Vytvoření online koncového bodu selže se zprávou o režimu kompatibility verze v1.

Spravované online koncové body jsou funkcí platformy rozhraní API služby Azure Machine Learning v2. Pokud je váš pracovní prostor Azure Machine Learning nakonfigurovaný pro starší režim verze 1, spravované online koncové body nefungují. Konkrétně platí, že pokud v1_legacy_mode je nastavení pracovního prostoru nastavené na true, je zapnutý starší režim verze 1 a pro rozhraní API v2 neexistuje žádná podpora.

Pokud chcete zjistit, jak vypnout starší verzi režimu v1, přečtěte si téma Změna izolace sítě pomocí nové platformy rozhraní API v Azure Resource Manageru.

Důležité

Obraťte se na svůj tým zabezpečení sítě, než nastavíte v1_legacy_mode na false, protože starší režim verze 1 může být zapnutý z nějakého důvodu.

Vytvoření online koncového bodu s ověřováním na základě klíčů selže

Pomocí následujícího příkazu vypíšete pravidla sítě trezoru klíčů Azure pro váš pracovní prostor. Nahraďte <key-vault-name> názvem trezoru klíčů.

az keyvault network-rule list -n <key-vault-name>

Odpověď pro tento příkaz se podobá následujícímu kódu JSON:

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

bypass Pokud hodnota neníAzureServices, použijte pokyny v tématu Konfigurace nastavení sítě služby Azure Key Vault a nastavte ho na AzureServices.

Selhání online nasazení kvůli chybě při stahování obrazu

Poznámka:

Tento problém se týká použití starší metody izolace sítě pro spravované online koncové body. V této metodě Azure Machine Learning vytvoří spravovanou virtuální síť pro každé nasazení v rámci koncového bodu.

  1. Zkontrolujte, zda má příznak egress-public-network-access hodnotu disabled pro nasazení. Pokud je tento příznak povolený a viditelnost registru kontejneru je soukromá, očekává se toto selhání.

  2. Pomocí následujícího příkazu zkontrolujte stav připojení privátního koncového bodu. Nahraďte <registry-name> názvem služby Azure Container Registry pro váš pracovní prostor:

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{ID:id, status:privateLinkServiceConnectionState.status}"

    V kódu odpovědi ověřte, že status je pole nastavené na Approved. Pokud hodnota není Approved, použijte následující příkaz ke schválení připojení. Nahraďte ID, které vrací předchozí příkaz, za <private-endpoint-connection-ID>.

    az network private-endpoint-connection approve --id <private-endpoint-connection-ID> --description "Approved"

Bodovací koncový bod nelze vyřešit

  1. Ověřte, že klient, který vydává žádost o hodnocení, je virtuální síť, která má přístup k pracovnímu prostoru Azure Machine Learning.

  2. Pomocí příkazu nslookup na názvu hostitele koncového bodu načtěte informace o IP adrese:

    nslookup <endpoint-name>.<endpoint-region>.inference.ml.azure.com

    Například příkaz může vypadat nějak takto:

    nslookup endpointname.westcentralus.inference.ml.azure.com

    Odpověď obsahuje adresu, která by měla být v rozsahu poskytovaném virtuální sítí.

    Poznámka:

    • V případě online koncového bodu Kubernetes by měl být název hostitele koncového bodu CName (název domény), který je zadaný v clusteru Kubernetes.
    • Pokud koncový bod používá protokol HTTP, IP adresa se nachází v identifikátoru URI koncového bodu, který můžete získat z uživatelského rozhraní studia.
    • Další způsoby získání IP adresy koncového bodu najdete v tématu Aktualizace DNS pomocí plně kvalifikovaného názvu domény.

  3. Pokud příkaz nslookup nepřeloží název hostitele, proveďte akce v jedné z následujících částí.

Spravované online koncové body

  1. Pomocí následujícího příkazu zkontrolujte, jestli záznam A existuje v zóně DNS (Private Domain Name System) pro virtuální síť.

    az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

    Výsledky by měly obsahovat položku podobnou *.<GUID>.inference.<region>.

  2. Pokud se nevrátí žádná hodnota odvozování, odstraňte privátní koncový bod pracovního prostoru a pak ho znovu vytvořte. Další informace najdete v tématu Konfigurace privátního koncového bodu.

  3. Pokud pracovní prostor s privátním koncovým bodem používá vlastní server DNS, spusťte následující příkaz k ověření, že rozlišení z tohoto serveru funguje správně:

    dig <endpoint-name>.<endpoint-region>.inference.ml.azure.com

Online koncové body Kubernetes

  1. Zkontrolujte konfiguraci DNS v clusteru Kubernetes.

  2. Zkontrolujte, azureml-fejestli směrovač odvozovací služby Azure Machine Learning funguje podle očekávání. Pokud chcete provést tuto kontrolu, proveďte následující kroky:

    1. V podu azureml-fe spusťte následující příkaz:

      kubectl exec -it deploy/azureml-fe -- /bin/bash

    2. Spusťte jeden z následujících příkazů:

      curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

      V případě protokolu HTTP použijte následující příkaz:

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

  3. Pokud příkaz HTTPS curl selže nebo vyprší časový limit, ale příkaz HTTP funguje, zkontrolujte, jestli je certifikát platný.

  4. Pokud se předchozí proces nepodaří přeložit na záznam A, pomocí následujícího příkazu ověřte, jestli překlad funguje z virtuální veřejné IP adresy Azure DNS 168.63.129.16:

    dig @168.63.129.16 <endpoint-name>.<endpoint-region>.inference.ml.azure.com

  5. Pokud předchozí příkaz proběhne úspěšně, vyřešte potíže s podmíněným předáváním pro Azure Private Link ve vlastním DNS.

Nelze stanovit skóre pro online nasazení.

  1. Spuštěním následujícího příkazu zobrazte stav nasazení, které nelze ohodnotit.

    az ml online-deployment show -e <endpoint-name> -n <deployment-name> --query '{name:name,state:provisioning_state}'

    Hodnota Succeeded pole state označuje úspěšné nasazení.

  2. V případě úspěšného nasazení pomocí následujícího příkazu zkontrolujte, jestli je k nasazení přiřazený provoz:

    az ml online-endpoint show -n <endpoint-name>  --query traffic

    Odpověď na tento příkaz by měla obsahovat procentuální podíl provozu přiřazený každému nasazení.

    Tip

    Tento krok není nutný, pokud k cílení na toto nasazení použijete hlavičku azureml-model-deployment v požadavku.

  3. Pokud jsou přiřazení provozu nebo hlavička nasazení správně nastavená, pomocí následujícího příkazu získejte protokoly pro koncový bod:

    az ml online-deployment get-logs  -e <endpoint-name> -n <deployment-name>

  4. Zkontrolujte protokoly a zjistěte, jestli při odeslání požadavku do nasazení došlo k potížím se spuštěním kódu bodování.

Problémy se serverem odvození

Tato část obsahuje základní tipy pro řešení potíží pro server HTTP odvozování služby Azure Machine Learning.

Kontrola nainstalovaných balíčků

Při řešení problémů s nainstalovanými balíčky postupujte takto:

  1. Shromážděte informace o nainstalovaných balíčcích a verzích pro vaše prostředí Pythonu.

  2. V souboru prostředí zkontrolujte verzi zadaného azureml-inference-server-http balíčku Pythonu. V protokolech spouštění serveru HTTP odvozování služby Azure Machine Learning zkontrolujte verzi zobrazeného serveru odvozování. Ověřte, že se obě verze shodují.

    V některých případech pip řešič závislostí nainstaluje neočekávané verze balíčků. Možná budete muset spustit pip , abyste opravovali nainstalované balíčky a verze.

  3. Pokud ve vašem prostředí určíte Flask nebo jeho závislosti, odeberte tyto položky.

    • Závislé balíčky zahrnují flask, , jinja2itsdangerous, werkzeug, markupsafe, a click.
    • Balíček flask je uveden jako závislost v balíčku inferenčního serveru. Nejlepším přístupem je umožnit serveru nainstalovat balíček flask.
    • Pokud je server odvozování nakonfigurovaný tak, aby podporoval nové verze Flasku, server odvozování automaticky obdrží aktualizace balíčku, jakmile budou k dispozici.

Kontrola verze serveru odvození

Balíček azureml-inference-server-http serveru se publikuje do PyPI. Stránka PyPI obsahuje protokol změn a všechny verze balíčku.

Pokud používáte dřívější verzi balíčku, aktualizujte konfiguraci na nejnovější verzi. Následující tabulka shrnuje stabilní verze, běžné problémy a doporučené úpravy:

Verze balíčku Popis Problém Rozlišení
0.4.x Zabalené ve výcvikových obrázcích datovaných k 20220601 nebo dříve a verzích balíčků azureml-defaults od 0.1.34 do 1.43. Nejnovější stabilní verze je 0.4.13. U serverových verzí starších než 0.4.11 může docházet k problémům se závislostmi Flasku, například can't import name Markup from jinja2. Pokud je to možné, upgradujte na verzi 0.4.13 nebo 1.4.x.
0.6.x Předinstalováno při odvozování imagí datovaných 20220516 a dřívějších verzí. Nejnovější stabilní verze je 0.6.1. není k dispozici není k dispozici
0.7.x Podporuje Flask 2. Nejnovější stabilní verze je 0.7.7. není k dispozici není k dispozici
0.8.x Používá aktualizovaný formát protokolu. Končí podpora pythonu 3.6. není k dispozici není k dispozici
1.0.x Končí podpora Pythonu 3.7. není k dispozici není k dispozici
1.1.x Migruje na pydantic verzi 2.0. není k dispozici není k dispozici
1.2.x Přidává podporu pro Python 3.11. Aktualizace gunicorn na verzi 22.0.0. Aktualizace werkzeug pro verzi 3.0.3 a novější. není k dispozici není k dispozici
1.3.x Přidává podporu pro Python 3.12. Upgraduje certifi na verzi 2024.7.4. Upgraduje flask-cors na verzi 5.0.0. Aktualizuje balíčky gunicorn a pydantic. není k dispozici není k dispozici
1.4.x Upgraduje waitress na verzi 3.0.1. Končí podpora pythonu 3.8. Odebere vrstvu kompatibility, která brání upgradu Flasku 2.0 v narušení kódu objektu požadavku. Pokud závisíte na vrstvě kompatibility, nemusí kód objektu požadavku fungovat. Migrujte svůj skript skóre do Flasku 2.

Kontrola závislostí balíčků

Mezi nejdůležitější závislé balíčky pro azureml-inference-server-http balíček serveru patří:

  • flask
  • opencensus-ext-azure
  • inference-schema

Pokud v prostředí Pythonu azureml-defaults zadáte balíček, azureml-inference-server-http je balíček závislým balíčkem. Závislost se nainstaluje automaticky.

Tip

Pokud používáte sadu Azure Machine Learning SDK pro Python v1 a explicitně nezadáte azureml-defaults balíček ve vašem prostředí Pythonu, může sada SDK balíček automaticky přidat. Verze balíčku je však uzamčena vzhledem k verzi sady SDK. Pokud je například verze sady SDK 1.38.0, položka azureml-defaults==1.38.0 je přidána do požadavkům pip prostředí.

TypeError během spouštění serveru odvozování

Při spuštění serveru pro inference můžete narazit na následující TypeError:

TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

K této chybě dochází v případě, že máte ve svém prostředí Pythonu nainstalovaný Flask 2, ale azureml-inference-server-http verze balíčku flask 2 nepodporuje. Podpora flask 2 je k dispozici v azureml-inference-server-http balíčku 0.7.0 a novějších verzích a azureml-defaults v balíčku 1.44 a novějších verzích.

  • Pokud balíček Flask 2 nepoužíváte v imagi Dockeru služby Azure Machine Learning, použijte nejnovější verzi azureml-inference-server-http balíčku nebo azureml-defaults balíčku.

  • Pokud použijete balíček Flask 2 v Dockerovém obrazu služby Azure Machine Learning, ověřte, že verze sestavení obrazu je July 2022 nebo novější.

    Verzi image najdete v protokolech kontejneru. Podívejte se například na následující příkazy protokolu:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    Datum sestavení obrázku se zobrazí po zápisu Materialization Build . V předchozím příkladu je verze image 20220708, tedy 8. července 2022. Obrázek v tomto příkladu je kompatibilní s Flaskem 2.

    Pokud v protokolu kontejneru nevidíte podobnou zprávu, váš obraz je zastaralý a měl by se aktualizovat. Pokud používáte image CUDA (Compute Unified Device Architecture) a nemůžete najít novější image, zkontrolujte v úložišti AzureML-Containers , jestli je vaše image zastaralá. Určené náhrady za zastaralé obrazy najdete.

    Pokud používáte server odvozování s online koncovým bodem, můžete protokoly najít také v nástroji Azure Machine Learning Studio. Na stránce vašeho koncového bodu vyberte kartu Protokoly .

Pokud nasadíte pomocí sady SDK v1 a explicitně nezadáte image v konfiguraci nasazení, server odvozování použije openmpi4.1.0-ubuntu20.04 balíček s verzí, která odpovídá vaší místní sadě nástrojů sady SDK. Nainstalovaná verze ale nemusí být nejnovější dostupnou verzí image.

Pro SDK verze 1.43 nainstaluje inferenční server ve výchozím nastavení verzi balíčku openmpi4.1.0-ubuntu20.04:20220616, ale tato verze balíčku není s SDK 1.43 kompatibilní. Ujistěte se, že pro nasazení používáte nejnovější sadu SDK.

Pokud nemůžete aktualizovat obraz, můžete se dočasně vyhnout tomuto problému tím, že připnete položky azureml-defaults==1.43 nebo azureml-inference-server-http~=0.4.13 ve vašem souboru prostředí. Tyto položky nasměrují server odvození tak, aby nainstaloval starší verzi s flask 1.0.x.

ImportError nebo ModuleNotFoundError během spouštění inferenčního serveru

Během spouštění serveru pro odvozování můžete narazit na ImportError nebo ModuleNotFoundError u specifických modulů, jako jsou opencensus, jinja2, markupsafe nebo click. Následující příklad ukazuje chybovou zprávu:

ImportError: cannot import name 'Markup' from 'jinja2'

K chybám importu a modulu dochází při použití verze 0.4.10 nebo starších verzí serveru odvozování, které nepřipnou závislost Flask na kompatibilní verzi. Pokud chcete tomuto problému zabránit, nainstalujte novější verzi odvozování serveru.

Další běžné problémy

Další běžné problémy s online koncovými body souvisí s instalací a automatickým škálováním conda.

Problémy s instalací Conda

Problémy s nasazením MLflow obvykle vyplývají z problémů s instalací uživatelského prostředí zadaného v souboru conda.yml .

Pokud chcete odstraňovat problémy s instalací conda, vyzkoušejte následující kroky:

  1. Zkontrolujte protokoly instalace conda. Pokud došlo k chybovému ukončení kontejneru nebo pokud spuštění trvalo příliš dlouho, je pravděpodobně problém v tom, že aktualizace prostředí conda se nepodařila správně vyřešit.
  2. Nainstalujte soubor conda mlflow místně pomocí příkazu conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Pokud dojde k chybám místně, zkuste před opětovným nasazením vyřešit prostředí Conda a vytvořit funkční prostředí.
  4. Pokud kontejner spadne, i když se vyřeší na místním počítači, může být velikost SKU použitá pro nasazování příliš malá.
    • Instalace balíčku Conda probíhá za běhu, takže pokud je velikost skladové položky příliš malá, aby vyhovovala všem balíčkům v souboru prostředí conda.yml , může dojít k chybovému ukončení kontejneru.
    • Virtuální počítač Standard_F4s_v2 je dobrým výchozím rozměrem konfigurace VM, ale v závislosti na závislostech určených souborem conda možná budete potřebovat větší virtuální počítače.
    • V případě online koncových bodů Kubernetes musí mít cluster Kubernetes minimálně čtyři jádra vCPU a 8 GB paměti.

Problémy s automatickým škálováním

Pokud máte potíže s automatickým škálováním, přečtěte si téma Řešení potíží s automatickým škálováním služby Azure Monitor.

U online koncových bodů Kubernetes je směrovač odvozování služby Azure Machine Learning front-end komponentou, která zpracovává automatické škálování pro všechna nasazení modelu v clusteru Kubernetes. Další informace naleznete v automatickém škálování inference v Kubernetes.

Související obsah