Nasazujte vlastní LLM pomocí Custom Model Serving

Important

Tato funkce je v beta verzi. Správci pracovního prostoru můžou řídit přístup k této funkci ze stránky Previews . Viz Manage Azure Databricks preview.

Na této stránce se dozvíte, jak nasadit vlastní velké jazykové modely (LLM) na obsluhu modelů pomocí modulu vLLM . Tento pracovní postup použijte k poskytování jemně vyladěných modelů, variant PEFT, multimodálních modelů a dalších základních modelů, které nejsou k dispozici v rozhraních API pro základní modely (FMAPI). Úvodní poznámkový blok na konci této stránky obsahuje veškerý spustitelný kód pro následující kroky.

Kdy použít vlastní obsluhu LLM

Azure Databricks doporučuje vlastní obsluhu LLM, pokud máte jeden z následujících případů použití:

  • Plně doladěné modely s vlastními váhami, které jste natrénovali v Azure Databricks.
  • Modely z Hugging Face, které nejsou dostupné v FMAPI
  • Vlastní recepty PEFT, které FMAPI nepodporuje.
  • Specializované modely mimo katalog FMAPI, například MedGemma.
  • Multimodální modely (vizionální jazyk), například Qwen/Qwen2.5-VL-3B-Instruct.
  • Vložené modely, které nejsou k dispozici v FMAPI, například nomic-ai/nomic-embed-text-v2-moe.
  • Každý model, který se vejde na 1xH100 (80 GB paměti GPU).

Requirements

  • Vlastní obsluha LLM je v beta verzi. Správci pracovního prostoru můžou tuto funkci povolit nebo vypnout na stránce Previews . Viz Manage Azure Databricks preview.

  • Výpočetní prostředí GPU bez serveru. Gpu A10 je doporučené vývojové prostředí pro menší modely H100 pro větší modely.

  • MLflow 3.12 nebo vyšší a databricks-sdk>=0.102.0. Počáteční poznámkový blok určuje verzi mlflow==3.12.0 a kompatibilní verzi sady SDK. Pokud si vytváříte vlastní prostředí, použijte tyto verze. U starších verzí SDK může při registraci dojít k vypršení časového limitu během nahrávání artefaktů modelu. Podívejte se na časový limit nahrávání artefaktů během registrace.

Krok 1: Nastavení prostředí

Vytvořte notebook pro bezserverové výpočty na GPU s GPU A10. Nainstalujte vLLM a jeho závislosti. Výchozí notebook používá ověřenou verzi vLLM.

Můžete také zadat závislosti prostřednictvím bezserverového prostředí místo použití %pip install.

Important

Nastavte pracovní adresář na místní pevný disk (například pomocí tempfile.mkdtemp()). /Workspace Systém souborů nepodporuje velké soubory, jako jsou váhy modelu.

Krok 2: Stažení modelu

Stáhněte si váhy modelu z Hugging Face pomocí snapshot_download. V úvodním notebooku je jako příklad použit Qwen/Qwen3-4B, ale můžete jej nahradit libovolným modelem, který odpovídá paměťovému limitu vybraného GPU, včetně následujících:

  • Multimodální modely, jako je Qwen/Qwen2.5-VL-3B-Instruct, pro úlohy propojující obraz a jazyk.
  • Větší modely, které se vejdou na 1xH100, například openai/gpt-oss-120b.

Vyberte GPU na základě požadavků modelu na paměť a výkon.

GPU Paměť GPU workload_type
T4 16 GB GPU_SMALL
A100 80 GB GPU_LARGE

Krok 3: Místní testování modelu pomocí vLLM

Před nasazením otestujte model přímo v bezserverovém poznámkovém bloku GPU spuštěním místního serveru vLLM. Místní testování umožňuje ověřit model, experimentovat s parametry vLLM a řešit problémy před vytvořením koncového bodu obsluhy.

Důležité informace:

  • Výpočetní prostředí GPU bez serveru umožňuje pro místní testování jenom porty 3000–3999. Vyberte port v tomto rozsahu; počáteční notebook používá port 3080.
  • Server vLLM zveřejňuje rozhraní API kompatibilní s OpenAI na adrese /invocations.
  • Můžete testovat běžné i streamované požadavky.
  • Vylaďte parametry, například --dtype, --max-model-lena --gpu-memory-utilization pro model.
  • Přidejte --enforce-eager pro rychlejší spuštění za cenu nějakého výkonu odvozování.
  • U větších modelů použijte pro místní testování variantu GPU bez serveru H100.

Až budete s konfigurací spokojeni, před pokračováním zastavte místní server.

Krok 4: Protokolování modelu pomocí vlastního vstupního bodu

Tento krok připojí místní nastavení ke službě Model Serving a má následující požadavky na konfiguraci:

  • Musí task být "llm/v1/chat" (modely chatu, včetně multimodálních) nebo "llm/v1/embeddings" (vkládání modelů). Viz Podporované úkoly.
  • Vstupní bod se musí otevřít na portu 8080, který očekává služba Model Serving.
  • Příkaz entrypoint musí odpovídat tomu, co jste otestovali v kroku 3, jen s portem 8080 místo vašeho místního portu.
  • Vstupní bod se spustí ze složky artefaktů modelu MLflow, takže cesty modelu jsou relativní k této složce.

Pro model chatu:

metadata = {
    "task": "llm/v1/chat",
    "entrypoint": (
        "python -u -m vllm.entrypoints.openai.api_server "
        "--model qwen3 --served-model-name qwen "
        "--host 0.0.0.0 --port 8080 "
        "--dtype float16 --max-model-len 16384 "
        "--gpu-memory-utilization 0.85"
    ),
}

U modelu vkládání nastavte task"llm/v1/embeddings" a spusťte server v režimu vkládání. S verzí vLLM použitou zde, to znamená --runner pooling (starší verze vLLM používají --task embed):

metadata = {
    "task": "llm/v1/embeddings",
    "entrypoint": (
        "python -u -m vllm.entrypoints.openai.api_server "
        "--model nomic-embed --served-model-name nomic-embed "
        "--runner pooling "
        "--host 0.0.0.0 --port 8080 "
        "--gpu-memory-utilization 0.85"
    ),
}

Podporované úlohy

task Typ modelu Plocha dotazu
llm/v1/chat Modely chatu, včetně multimodálních (vizionálních jazyků) chat.completions
llm/v1/embeddings Vkládání modelů embeddings

Deklarace task musí odpovídat tomu, co váš vstupní bod skutečně slouží: vstupní bod musí zpřístupnit rozhraní API kompatibilní s OpenAI pro danou úlohu na portu 8080. Výše uvedené příklady používají vLLM, ale všechny servery, které splňují tento kontrakt, fungují. Jiné typy úkolů, například llm/v1/completions, nejsou podporovány.

Krok 5: Registrace modelu do katalogu Unity

Zaregistrujte model do katalogu Unity pomocí mlflow.register_model. Vlastní obsluha LLM závisí na expresních nasazeních. Pomocí parametru ho env_pack="databricks_model_serving" povolte.

Přidejte například do poznámkového bloku následující:


model_version = mlflow.register_model(model_info.model_uri, UC_MODEL_NAME, env_pack="databricks_model_serving")

Krok 6: Vytvoření koncového bodu obsluhy

Vytvořit koncový bod z uživatelského rozhraní nebo programově pomocí sady Azure Databricks SDK. Klíčová rozhodnutí jsou typ výpočetní instance, velikost pracovní zátěže a chování při škálování na nulu.

Vyberte workload_type podle modelu a cloudového prostředí:

workload_type GPU Poznámky
GPU_SMALL 1x T4 (16 GB) Nejmenší možnost.
GPU_LARGE 1x A100 (80 GB) Doporučeno pro velké úlohy LLM.

workload_size (Small, Mediumnebo Large) řídí počet zřízených replik za koncovým bodem. Použijte Small pro vývoj a úlohy s nízkým provozem.

Následující příklad ukazuje typickou konfiguraci:

ServedEntityInput(
    entity_name="main.<catalog>.<model_name>",
    entity_version="<version>",
    workload_type=ServingModelWorkloadType.GPU_MEDIUM,
    workload_size="Small",
    scale_to_zero_enabled=True,
)

Škálování na nulu a plánování kapacity

Vlastní obsluha LLM ve verzi beta zřídí pevný počet replik za vaším endpointem. Automatické škálování na více než nulu replik zatím není podporováno, takže musíte workload_type a workload_size nastavit pro špičkový provoz. Koncový bod zařadí do fronty požadavky, které překračují kapacitu zřízených replik.

Nastavte scale_to_zero_enabled=True, aby se koncový bod při nečinnosti mohl škálovat až na nula replik. Studené starty jsou pomalé – načítání hmotností modelu a spouštění vLLM obvykle trvá jednu až několik minut.

Pro úlohy citlivé na latenci nebo kritické pro produkční prostředí nastavte scale_to_zero_enabled=False a velikost workload_size provozu ve špičce předem.

Výstraha

Navýšení kapacity není zaručeno. Kdykoli Azure Databricks potřebuje získat novou GPU pro váš koncový bod – při vytvoření, při navýšení workload_size nebo když se koncový bod probudí z nulového stavu – může požadavek přestat odpovídat, pokud poskytovatel cloudu nemá ve vaší oblasti k dispozici kapacitu GPU. To platí pro všechny typy GPU. Databricks to zmírňuje pomocí warm poolů a předrezervace, které udržují kapacitu GPU dostupnou a připravenou.

Krok 7: Dotazování koncového bodu

Jakmile je koncový bod připravený, zobrazí se automaticky na stránce koncového bodu v AI Playground . Můžete ho také dotazovat programově pomocí sady Databricks SDK, sady OpenAI SDK nebo curl.

Modely chatu (llm/v1/chat):

Databricks SDK

w.serving_endpoints.query(
    name="<endpoint-name>",
    messages=[ChatMessage(role=ChatMessageRole.USER, content="Hello")],
)

OpenAI SDK

client = OpenAI(
    api_key=DATABRICKS_TOKEN,
    base_url=f"{DATABRICKS_HOST}/serving-endpoints",
)
client.chat.completions.create(
    model="<endpoint-name>",
    messages=[{"role": "user", "content": "Hello"}],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Hello"}]}' \
  https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations

Vložené modely (llm/v1/embeddings):

OpenAI SDK

client = OpenAI(
    api_key=DATABRICKS_TOKEN,
    base_url=f"{DATABRICKS_HOST}/serving-endpoints",
)
client.embeddings.create(
    model="<endpoint-name>",
    input=["The quick brown fox jumps over the lazy dog."],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"input":["The quick brown fox jumps over the lazy dog."]}' \
  https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations

Některé modely pro embeddingy očekávají u každého vstupu předponu specifickou pro daný úkol (například nomic-embed-text-v2-moe používá search_query: a search_document:). Zkontrolujte kartu svého modelu, kde najdete jeho vstupní konvence.

Monitorování koncového bodu

Obsluha vlastních modelů LLM používá stejnou infrastrukturu pro monitorování jako standardní endpointy obsluhy vlastních modelů, ale obsahuje několik doplňků specifických pro vLLM, které jsou popsány v následujících částech.

Živé logy

Na záložce Protokoly na stránce koncového bodu v uživatelském rozhraní Serving se v reálném čase zobrazují stdout a stderr z vašeho procesu vLLM. Tento výstup můžete otevřít také prostřednictvím rozhraní API protokolů.

Trvalé protokoly a metriky

Pokud je povolená telemetrie, protokoly i metriky se uchovávají v tabulkách Unity Catalog Delta pro dlouhodobé uchovávání, dotazování SQL a dodržování předpisů. Úplné pokyny k nastavení, požadavky a schémata tabulek najdete v tématu Uložení dat vlastního model servingu do Unity Catalogu.

Konkrétně pro vlastní provoz LLM:

  • Protokoly: stdout a stderr z procesu vLLM se zaznamenávají automaticky. Nevyžaduje se žádný kód protokolování na straně aplikace.
  • Metriky: Azure Databricks automaticky stahuje data z koncového bodu Prometheus serveru vLLM /metrics a ukládá metriky společně s logy. Ve výchozím nastavení získáte latenci na požadavek, propustnost, počet tokenů, délku fronty a využití mezipaměti KV.

Dotazování telemetrických dat

Během beta verze neexistuje žádné uživatelské rozhraní pro vizualizaci protokolů nebo metrik. Dotazujte se na trvalá data přímo v katalogu Unity pomocí SQL nebo poznámkového bloku. Viz schémata metrik a protokolů zdokumentovaná v části Uložení vlastních dat obsluhy modelu do katalogu Unity.

Následující poznámkový blok ukazuje, jak analyzovat a vizualizovat trvalé metriky vLLM:

Vlastní poznámkový blok metrik obsluhy LLM

Pořiďte si notebook

Příklad notebooku

Vytvořte a otestujte model v poznámkovém bloku s bezserverovým GPU, potom zaznamenejte a nasaďte stejnou konfiguraci jako koncový bod pro obsluhu. Následující notebook obsahuje kompletní spustitelný postup z tohoto průvodce.

Úvodní notebook pro nasazení vlastního LLM

Pořiďte si notebook

Omezení

Během beta verze platí následující omezení.

  • Mezi replikami není automatické škálování. Podporuje se škálování na nulu.
  • Podporují se jenom úlohy chatu (llm/v1/chatvčetně multimodálních) a vkládání (llm/v1/embeddings). Viz Podporované úkoly.
  • Žádná optimalizace trasy.
  • Žádné uživatelské rozhraní pro vizualizaci protokolů nebo metrik. Dotazování telemetrie přímo v katalogu Unity

S připomínkami nebo dotazy se obraťte na tým pro váš účet Azure Databricks.

Časový limit nahrávání artefaktů během registrace vypršel.

Když zaregistrujete model pomocí env_pack, Azure Databricks nahraje váhy zabaleného modelu a prostředí jako artefakty (model_version.tar a model_environment.tar). U verzí databricks-sdk starších než 0.102.0 může po pěti minutách při nahrávání velkých artefaktů LLM vypršet časový limit a registrace může selhat s chybou podobnou následující:

MlflowException: The following failures occurred while uploading one or more artifacts to
/Models/<catalog>/<schema>/<model>/<version>: {
  '.../model_environment.tar': "TimeoutError('Timed out after 0:05:00')",
  '.../model_version.tar': "TimeoutError('Timed out after 0:05:00')"
}

Pokud chcete tento problém vyřešit, upgradujte na databricks-sdk>=0.102.0 model a znovu ho zaregistrujte:

%pip install databricks-sdk>=0.102.0
  • Last updated on