Udostępniaj niestandardowe modele LLM za pomocą funkcji Custom Model Serving

Ważna

Ta funkcja jest dostępna w wersji beta. Administratorzy obszaru roboczego mogą kontrolować dostęp do tej funkcji ze strony Podglądy . Zobacz Zarządzanie wersjami zapoznawczami usługi Azure Databricks.

Ta strona pokazuje, jak wdrażać niestandardowe duże modele językowe (LLM) w Model Serving przy użyciu silnika vLLM. Użyj tego przepływu pracy do udostępniania modeli dostrojonych, wariantów PEFT, modeli multimodalnych oraz innych modeli bazowych, które nie są dostępne w interfejsach API modeli bazowych (FMAPI). Notatnik startowy znajdujący się na końcu tej strony zawiera cały kod gotowy do uruchomienia, potrzebny do wykonania poniższych kroków.

Kiedy używać niestandardowej usługi LLM

Azure Databricks zaleca użycie niestandardowej usługi LLM, jeśli masz jeden z następujących przypadków użycia:

  • Modele w pełni dostrojone z niestandardowymi wagami, które wytrenowano na platformie Azure Databricks.
  • Modele z Hugging Face, które nie są dostępne w FMAPI.
  • Niestandardowe przepisy PEFT, których interfejs FMAPI nie obsługuje.
  • Wyspecjalizowane modele poza wykazem FMAPI, takie jak MedGemma.
  • Modele wielomodalne (język przetwarzania obrazów), takie jak Qwen/Qwen2.5-VL-3B-Instruct.
  • Osadzanie modeli, które nie są dostępne w interfejsie FMAPI, takich jak nomic-ai/nomic-embed-text-v2-moe.
  • Każdy model, który pasuje do 1xH100 (80 GB pamięci procesora GPU).

Requirements

  • Niestandardowa obsługa LLM jest w wersji beta. Administratorzy obszaru roboczego mogą włączać lub wyłączać tę funkcję na stronie Podglądy . Zobacz Zarządzanie wersjami zapoznawczami usługi Azure Databricks.

  • Bezserwerowe obliczenia procesora GPU. Procesor GPU A10 jest zalecanym środowiskiem programistycznym dla mniejszych modeli, H100 dla większych modeli.

  • MLflow 3.12 lub nowszy i databricks-sdk>=0.102.0. Notatnik startowy przypisuje na stałe mlflow==3.12.0 i zgodną wersję zestawu SDK. Jeśli tworzysz własne środowisko, dopasuj je do tych wersji. We wcześniejszych wersjach zestawu SDK może dochodzić do przekroczenia limitu czasu podczas przesyłania artefaktów modelu w trakcie rejestracji. Zobacz Limit czasu przekazywania artefaktów podczas rejestracji.

Krok 1. Konfigurowanie środowiska

Utwórz notatnik w bezserwerowym środowisku obliczeniowym GPU z procesorem graficznym A10. Zainstaluj program vLLM i jego zależności. Początkowy notatnik określa przetestowaną wersję vLLM.

Można również określić zależności za pośrednictwem środowiska bezserwerowego , a nie za pomocą polecenia %pip install.

Ważna

Ustaw katalog roboczy na lokalny dysk twardy (na przykład przy użyciu polecenia tempfile.mkdtemp()). System /Workspace plików nie obsługuje dużych plików, takich jak wagi modelu.

Krok 2. Pobieranie modelu

Pobierz wagi modelu z Hugging Face przy użyciu snapshot_download. Notes początkowy używa Qwen/Qwen3-4B jako przykładu, ale możesz zastąpić go dowolnym modelem, który mieści się w limicie pamięci wybranego procesora GPU, w tym na przykład następującymi:

  • Modele wielomodalne, takie jak Qwen/Qwen2.5-VL-3B-Instruct, do zastosowań wizyjno-językowych.
  • Większe modele pasujące do 1xH100, takie jak openai/gpt-oss-120b.

Wybierz procesor GPU na podstawie potrzeb dotyczących pamięci i wydajności modelu.

procesor GPU Pamięć procesora GPU workload_type
T4 16 GB GPU_SMALL
A100 80 GB GPU_LARGE

Krok 3. Testowanie modelu lokalnie przy użyciu maszyny wirtualnej vLLM

Przed wdrożeniem przetestuj model bezpośrednio w notatniku z bezserwerowym GPU, uruchamiając lokalny serwer vLLM. Testowanie lokalne umożliwia zweryfikowanie modelu, eksperymentowanie z parametrami vLLM i rozwiązywanie problemów przed utworzeniem punktu końcowego obsługującego.

Najważniejsze kwestie do poznania:

  • Bezserwerowe obliczenia procesora GPU umożliwiają testowanie lokalne tylko na portach 3000–3999. Wybierz port z tego zakresu; notatnik startowy używa portu 3080.
  • Serwer vLLM uwidacznia interfejs API zgodny z interfejsem OpenAI pod adresem /invocations.
  • Możesz przetestować zarówno regularne, jak i przesyłane strumieniowo żądania.
  • Dostraj parametry, takie jak --dtype, --max-model-len i --gpu-memory-utilization, dla swojego modelu.
  • Dodaj --enforce-eager, aby przyspieszyć uruchamianie, kosztem części wydajności wnioskowania.
  • W przypadku większych modeli użyj wariantu bezserwerowego procesora GPU H100 do testowania lokalnego.

Gdy uznasz konfigurację za odpowiednią, zatrzymaj lokalny serwer przed kontynuowaniem.

Krok 4. Rejestrowanie modelu przy użyciu niestandardowego punktu wejścia

Ten krok łączy konfigurację lokalną z obsługą modelu i ma następujące wymagania dotyczące konfiguracji:

  • task musi być "llm/v1/chat" (modele czatu, w tym wielomodalne) lub "llm/v1/embeddings" (modele osadzające). Zobacz Obsługiwane zadania.
  • Punkt wejścia musi zostać otwarty na porcie 8080— oczekiwany jest port obsługujący model.
  • Polecenie punktu wejścia musi odzwierciedlać to, co przetestowano w kroku 3, przy użyciu portu 8080 zamiast portu lokalnego.
  • Punkt wejścia uruchamia się z folderu artefaktów modelu MLflow, więc ścieżki do modelu są względne względem tego folderu.

W przypadku modelu czatu:

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"
    ),
}

W przypadku modelu embeddingów ustaw task na "llm/v1/embeddings" i uruchom serwer w trybie embeddingów. W przypadku używanej tutaj wersji vLLM, czyli --runner pooling (starsze wersje vLLM używają --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"
    ),
}

Obsługiwane zadania

task Typ modelu Powierzchnia zapytań
llm/v1/chat Modele rozmów, w tym wielomodalne (język obrazów) chat.completions
llm/v1/embeddings Osadzanie modeli embeddings

To, co deklarujesz jako task, musi odpowiadać temu, co punkt wejścia rzeczywiście udostępnia: punkt wejścia musi udostępniać interfejs API zgodny z OpenAI dla tego zadania na porcie 8080. Powyższe przykłady używają maszyny wirtualnej vLLM, ale każdy serwer, który spełnia ten kontrakt, działa. Inne typy zadań, takie jak llm/v1/completions, nie są obsługiwane.

Krok 5: Zarejestrować model w usłudze Unity Catalog

Zarejestruj model w Unity Catalog za pomocą mlflow.register_model. Udostępnianie niestandardowych modeli LLM jest oparte na wdrożeniach Express, więc do rejestracji używa się parametru env_pack="databricks_model_serving", a także wymagane są mlflow>=3.12 i databricks-sdk>=0.102.0.

Dodaj na przykład następujący kod do notesu:


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

Krok 6. Tworzenie punktu końcowego obsługującego

Utwórz punkt końcowy z interfejsu użytkownika lub programowo za pomocą zestawu SDK Azure Databricks. Kluczowe decyzje dotyczą typu obliczeń, rozmiaru obciążenia i zachowania skalowania do zera.

Wybierz workload_type w zależności od modelu i chmury:

workload_type procesor GPU Notatki
GPU_SMALL 1x T4 (16 GB) Najmniejsza opcja.
GPU_LARGE 1x A100 (80 GB) Zalecane w przypadku dużych obciążeń LLM.

workload_size (Small, Medium lub Large) określa liczbę aprowizowanych replik dla punktu końcowego. Używaj Small do programowania i obciążeń o niewielkim natężeniu ruchu.

W poniższym przykładzie przedstawiono typową konfigurację:

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

Skalowanie do zera i planowanie wydajności

Niestandardowe udostępnianie modeli LLM w fazie beta udostępnia stałą liczbę replik dla punktu końcowego. Skalowanie automatyczne do więcej niż zera replik nie jest jeszcze obsługiwane, więc musisz dobrać odpowiedni rozmiar workload_type i workload_size pod kątem szczytowego natężenia ruchu. Punkt końcowy umieszcza w kolejce żądania przekraczające wydajność przydzielonych replik.

Ustaw scale_to_zero_enabled=True wartość , aby umożliwić skalowanie punktu końcowego w dół do zera replik w przypadku bezczynności. Zimne uruchomienia są powolne — ładowanie wag modelu i uruchamianie vLLM zwykle trwa od jednej do kilku minut.

W przypadku obciążeń wrażliwych na opóźnienia lub krytycznych dla produkcji ustaw scale_to_zero_enabled=False i dobierz rozmiar workload_size pod kątem szczytowego ruchu z wyprzedzeniem.

Ostrzeżenie

Możliwość zwiększenia skali nie jest gwarantowana. Za każdym razem, gdy usługa Azure Databricks musi przydzielić nowy procesor GPU dla punktu końcowego — podczas tworzenia, podczas zwiększania workload_size lub gdy punkt końcowy wybudza się ze stanu zerowego — żądanie może przestać odpowiadać, jeśli dostawca chmury nie dysponuje dostępnymi zasobami GPU w Twoim regionie. Dotyczy to wszystkich typów procesorów GPU. Databricks łagodzi ten problem dzięki ciepłym pulom i wcześniejszej rezerwacji, które utrzymują zasoby GPU w gotowości i dostępności.

Krok 7: Wykonaj zapytanie do swojego punktu końcowego

Gdy punkt końcowy będzie gotowy, pojawi się automatycznie w AI Playground na stronie punktu końcowego. Możesz również wykonać zapytanie programowe przy użyciu zestawu SDK usługi Databricks, zestawu OpenAI SDK lub narzędzia curl.

Modele rozmów (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

Osadzanie modeli (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

Niektóre modele osadzania oczekują prefiksu zależnego od zadania dla każdego elementu wejściowego (na przykład nomic-embed-text-v2-moe używa search_query: i search_document:). Sprawdź kartę modelu pod kątem konwencji wejściowych.

Monitoruj swój punkt końcowy

Niestandardowe udostępnianie modeli LLM korzysta z tej samej infrastruktury obserwowalności co standardowe punkty końcowe udostępniania modeli niestandardowych, ale zawiera kilka dodatkowych funkcji specyficznych dla vLLM, opisanych w poniższych sekcjach.

Dzienniki na żywo

Zakładka Dzienniki na stronie punktu końcowego w interfejsie Serving UI pokazuje w czasie rzeczywistym elementy stdout i stderr z procesu vLLM. Możesz również otworzyć te dane wyjściowe za pomocą interfejsu API dzienników.

Utrwalone dzienniki i metryki

Po włączeniu telemetrii zarówno dzienniki, jak i metryki są zapisywane w tabelach Delta w Unity Catalog w celu długoterminowego przechowywania danych, wykonywania zapytań SQL i zapewnienia zgodności. Pełne instrukcje konfiguracji, wymagania i schematy tabel można znaleźć tutaj: Utrwalanie niestandardowych danych udostępniania modeli w Unity Catalog.

W przypadku niestandardowych usług LLM obsługujących specjalnie:

  • Dzienniki: stdout i stderr z procesu vLLM są przechwytywane automatycznie. Nie jest wymagany kod rejestrowania po stronie aplikacji.
  • Metrics: Azure Databricks automatycznie pobiera metryki z punktu końcowego Prometheus serwera vLLM /metrics i zapisuje je wraz z dziennikami. Domyślnie otrzymujesz opóźnienie dla każdego żądania, przepustowość, liczbę tokenów, głębokość kolejki i wykorzystanie pamięci podręcznej KV.

Wykonywanie zapytań dotyczących danych telemetrycznych

W wersji beta nie ma interfejsu użytkownika do wizualizacji dzienników lub metryk. Wysyłaj zapytania do zapisanych danych bezpośrednio w Unity Catalog za pomocą języka SQL lub notatnika. Zapoznaj się ze schematami metryk i logów opisanymi w artykule Trwałe zapisywanie niestandardowych danych obsługi modelu w katalogu Unity Catalog.

W poniższym notatniku pokazano, jak parsować i wizualizować zapisane metryki vLLM:

Niestandardowy notatnik metryk obsługi LLM

Pobierz laptopa

Przykładowy notatnik

Opracuj i przetestuj model w notatniku z bezserwerowym procesorem GPU, a następnie zaloguj i wdróż tę samą konfigurację jako punkt końcowy udostępniania. Poniższy notatnik zawiera kompletny przepływ, który można uruchomić, opisany w tym przewodniku.

Niestandardowy notes początkowy obsługujący usługę LLM

Pobierz laptopa

Ograniczenia

Następujące ograniczenia dotyczą wersji beta.

  • Brak skalowania automatycznego między replikami. Skalowanie do zera jest obsługiwane.
  • Obsługiwane są tylko zadania czatu (llm/v1/chatw tym wielomodalne) i osadzania (llm/v1/embeddings). Zobacz Obsługiwane zadania.
  • Brak optymalizacji tras.
  • Brak interfejsu użytkownika do wizualizacji dzienników lub metryk. Wysyłaj zapytania do danych telemetrycznych bezpośrednio w Unity Catalog.

Skontaktuj się z zespołem ds. kont Azure Databricks, aby uzyskać opinię lub pytania.

Upłynął limit czasu przekazywania artefaktu podczas rejestracji

Podczas rejestrowania modelu za pomocą env_pack usługa Azure Databricks przesyła spakowane wagi modelu i środowisko jako artefakty (model_version.tar i model_environment.tar). W przypadku wersji databricks-sdk wcześniejszych niż 0.102.0 przesyłanie dużych artefaktów LLM może zakończyć się przekroczeniem limitu czasu po pięciu minutach, a rejestracja może zakończyć się niepowodzeniem z błędem podobnym do poniższego:

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')"
}

Aby rozwiązać ten problem, uaktualnij model do databricks-sdk>=0.102.0 i zarejestruj go ponownie:

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