Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Importante
Este recurso está no Public Preview. Os administradores do espaço de trabalho podem controlar o acesso a esse recurso na página Visualizações . Ver Gerir as pré-visualizações de Azure Databricks.
Esta página mostra como servir o seu próprio LLM num endpoint GPU Model Serving. Qualquer modelo que o vLLM execute torna-se um endpoint de produção com uma API compatível com OpenAI. É assim que funciona:
- Executas o servidor de inferência, como o vLLM, e escolhes a sua versão e definições.
- Testas o servidor num notebook com GPU serverless. Uma flag errada ou um erro de falta de memória aparece em segundos em vez de após uma implementação.
- Fazes o deployment do mesmo comando e ambiente que construíste e sabes que funciona para um endpoint de serviço de produção.
Início Rápido
Importa o seguinte notebook para o teu espaço de trabalho e clica em Executar tudo no AI Runtime com uma GPU A10. Em cerca de 15 minutos, tens um endpoint Qwen3.5-4B que responde a pedidos de chat compatíveis com OpenAI.
Servir Qwen3.5-4B com vLLM
Quando usar serviço personalizado para LLM
Utilize o serviço de LLM personalizado nos seguintes casos:
- Afinaste um LLM em AI Runtime e queres disponibilizá-lo. Veja a secção abaixo para um exemplo.
- Queres servir um modelo aberto que as APIs do Foundation Model (FMAPI) não suportam, como um novo LLM, um modelo de voz para texto ou um modelo de embedding.
- Queres mudar o runtime ou a arquitetura de um LLM e precisas de controlar o runtime e o ambiente.
Não utilize serving de LLM personalizado nos seguintes casos:
- A FMAPI fornece o modelo de que precisas, inalterado. O FMAPI é mais simples de usar e altamente otimizado.
- O modelo não cabe numa única GPU com cerca de 80 GB de memória. Por exemplo, Qwen3.8-27B e gpt-oss-120b encaixam, mas Kimi K3 e GLM 5.3 não.
- Precisas de throughput ou preço por token de ponta sem fazer tuning. O desempenho iguala o do vLLM open source na mesma GPU.
Requirements
O serviço de LLM personalizado tem os seguintes requisitos:
- O seu espaço de trabalho deve ter computação GPU serverless.
- Tens de registar o modelo a partir de um notebook com GPU serverless. Um modelo registado a partir de um ambiente de CPU empacota as dependências da CPU, e o endpoint da GPU falha em arrancar.
- Deve ter permissão para criar modelos num esquema do Unity Catalog.
- Deve registar o modelo com
env_pack="databricks_model_serving". O serviço personalizado de LLM é construído sobre implementações Express, que integram o ambiente do notebook com o modelo. - Deve usar MLflow 3.12 ou superior e
databricks-sdk0.102.0 ou superior. O ambiente da IA v6 inclui ambos os elementos.
notebooks de exemplo
Cada notebook leva um modelo do Hugging Face para um endpoint alvo da consulta, como o quickstart. Execute uma tal como está, ou comece a partir de uma para implementar o seu próprio modelo.
| Modelo | Tarefa | Meio Ambiente | GPU de portátil | Endpoint GPU |
|---|---|---|---|---|
| Qwen3.5-4B | Chat | AI v6 ou Standard v6 | A10 | A10G (AWS), A100 (Azure) |
| Qwen3.8-27B | Conversar com chamadas de ferramentas | AI v6 | H100 | H100 (AWS), A100 (Azure) |
| Gemma 4 26B-A4B | Conversa com chamadas de ferramentas | AI v6 | H100 | H100 (AWS), A100 (Azure) |
| Muse Glimmer 30B | Chat | Standard v6 | H100 | H100 (AWS), A100 (Azure) |
| Whisper large-v3-turbo | Conversão de voz para texto | AI v6 | A10 | A10G (AWS), A100 (Azure) |
| Qwen3-Embedding-0.6B | Embeddings | AI v6 | A10 | A10G (AWS), A100 (Azure) |
AI v6 e Standard v6 são ambientes de IA Runtime. A IA v6 vem com vLLM, PyTorch, Transformers e outros pacotes comuns de aprendizagem automática pré-instalados e prontos a usar. Veja a lista de pacotes do AI v6. Um notebook Standard v6 instala o próprio vLLM, por isso escolhes a sua versão. Use um notebook Standard v6 quando o seu modelo precisar de um vLLM ou transformers mais recentes do que o AI v6 inclui, como acontece com o Muse Glimmer.
Disponibilize o seu próprio modelo
Para servir outro modelo, escolhe o notebook inicial com a mesma tarefa e a GPU de que o teu modelo precisa. Altere MODEL_REPO_ID e as flags em vllm_command, depois execute o notebook. Cada notebook executa os seguintes passos:
- Descarregue os pesos modelo do Hugging Face, ou obtenha-os num ponto de controlo de treino.
- Começa o vLLM no notebook e faz uma consulta.
- Regista o modelo com o comando vLLM como ponto de entrada e regista-o no Unity Catalog como um deployment expresso.
- Cria um endpoint de serviço, que inicia o mesmo comando.
- Consulte o endpoint com o cliente OpenAI, o SDK Databricks ou SQL
ai_query.
No exemplo seguinte, o metadata modelo mantém a tarefa e o ponto de entrada:
import mlflow
from mlflow.pyfunc.model import ChatCompletionResponse, ChatModel
# The endpoint runs the entrypoint and never calls predict, but MLflow needs a model class to log.
class Placeholder(ChatModel):
def predict(self, context, messages, params):
return ChatCompletionResponse.from_dict({"choices": []})
model_info = mlflow.pyfunc.log_model(
name="my-model",
python_model=Placeholder(),
artifacts={"model_dir": "my-model"}, # the weights folder, which --model names
metadata={
"task": "llm/v1/chat",
"entrypoint": (
"python -u -m vllm.entrypoints.openai.api_server "
"--model my-model --served-model-name my-model "
"--host 0.0.0.0 --port 8080 --max-model-len 16384"
),
},
)
mlflow.register_model(model_info.model_uri, "<catalog>.<schema>.my_model", env_pack="databricks_model_serving")
Disponibilizar um modelo ajustado
Afina um modelo no AI Runtime e serve-o a partir do mesmo notebook. Para um exemplo, veja Ajuste fino supervisionado (Completo) e implementação de Qwen3.5-0.8B. O tutorial afina o Qwen3.5-0.8B num único H100, compara respostas antes e depois do treino, e disponibiliza o modelo afinado.
Tarefas suportadas
O task nos metadados do modelo define a API que o endpoint serve. O seu servidor deve expor a API compatível com OpenAI para essa tarefa. Outras tarefas, como llm/v1/completions, não são suportadas. A tabela seguinte lista as tarefas suportadas.
task |
Tipo de modelo | Consultar com |
|---|---|---|
llm/v1/chat |
Modelos de chat, incluindo modelos de visão e linguagem | chat.completions |
llm/v1/embeddings |
Incorporação de modelos | embeddings |
llm/v1/audio/transcriptions |
Modelos de voz para texto | audio.transcriptions |
llm/v1/audio/translations |
Modelos de tradução de fala para inglês | audio.translations |
Escolha uma GPU
O Azure Databricks recomenda desenvolver na mesma GPU em que serves, por isso as definições que testas são as que implementas. A tabela seguinte lista as GPUs para serviço personalizado de LLMs.
workload_type |
GPU | Notes |
|---|---|---|
GPU_SMALL |
1x T4 (16 GB) | Modelos até cerca de 5B de parâmetros. |
GPU_LARGE |
1x A100 (80 GB) | Modelos grandes. Disponível de forma geral |
GPU_LARGE_RTX |
1x RTX PRO 6000 (96 GB) | Mais memória e velocidade do que o A100. Disponível em southeastasia e westus2. |
Problemas comuns
Os seguintes problemas são os mais comuns quando se troca um portátil:
- O download falha em
/Workspace, que não aceita ficheiros de vários GB. Descarregue os pesos para o disco local, tal como fazem os notebooks iniciais. - O servidor local não arranca. Notebooks com GPU serverless só permitem as portas 3000 a 3999, por isso experimenta numa dessas portas. Só o entrypoint usa a porta 8080, e caso contrário tem de corresponder ao comando que testou.
- O endpoint não consegue encontrar os pesos. O ponto de entrada fica na pasta de artefactos do modelo, por isso
--modeldeve nomear a pasta de pesos que guardou. - Um modelo de embedding não serve embeddings. Inicie o vLLM com
--runner pooling. -
O registo falha com
TimeoutError('Timed out after 0:05:00')ao carregarmodel_version.taroumodel_environment.tar. Atualize paradatabricks-sdk0.102.0 ou superior e volte a registar o modelo.
Criar um ponto final
Crie o endpoint a partir da IU de Serving ou com o SDK Databricks, como fazem os notebooks iniciais.
workload_type escolhe a GPU, e workload_size (Small, Medium, ou Large) define o número de réplicas.
ServedEntityInput(
entity_name="<catalog>.<schema>.<model>",
entity_version="<version>",
workload_type=ServingModelWorkloadType.GPU_MEDIUM,
workload_size="Small",
scale_to_zero_enabled=False,
)
Dimensionamento até zero e capacidade
Atualmente, endpoints LLM personalizados não escalam dinamicamente, por isso dimensiona workload_size para o teu pico de tráfego.
Com scale-to-zero, um endpoint inativo pára todas as réplicas. O pedido seguinte demora de um a vários minutos enquanto o vLLM carrega novamente o modelo e todas as réplicas arrancam. O Azure Databricks recomenda desligar o scale-to-zero para tráfego de produção.
Advertência
A capacidade de ampliação não é garantida. Sempre que o Azure Databricks precisa de adquirir uma nova GPU para o seu endpoint, como na criação, num workload_size aumento ou quando um endpoint desperta de zero, o pedido pode ficar sem resposta se o fornecedor de cloud não tiver capacidade de GPU na sua região. Isto aplica-se a todos os tipos de GPUs. O Databricks mitiga isto com pools quentes e pré-reserva, que mantêm a capacidade da GPU disponível e pronta.
Consultar o seu ponto de extremidade
Um endpoint de chat pronto aparece no AI Playground. Os exemplos seguintes consultam um endpoint com o Databricks SDK, o cliente OpenAI e o REST.
Databricks SDK
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import ChatMessage, ChatMessageRole
w = WorkspaceClient()
w.serving_endpoints.query(
name="<endpoint-name>",
messages=[ChatMessage(role=ChatMessageRole.USER, content="Hello")],
)
Cliente OpenAI
from openai import OpenAI
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"}])
client.embeddings.create(model="<endpoint-name>", input=["The quick brown fox jumps over the lazy dog."])
with open("speech.flac", "rb") as audio:
client.audio.transcriptions.create(model="<endpoint-name>", file=audio)
REST: conversa
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
REST: embeddings
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
Alguns modelos de embedding esperam um prefixo em cada entrada, como search_query: ou search_document:. Verifica a ficha do modelo.
Monitorize o seu endpoint
O separador de Logs do endpoint mostra os stdout do seu servidor e stderr em direto. A API dos logs devolve a mesma saída.
O Azure Databricks encaminha as métricas do seu servidor vLLM e grafica-as no separador Métricas do endpoint:
- Latência: tempo até ao primeiro token, tempo por token de saída, latência de pedido e tempo de fila.
- Carga: solicitações em execução e à espera.
- Cache KV: utilização e taxa de acerto.
- Throughput: prompt e tokens de geração por segundo.
A API de métricas de exportação devolve as mesmas métricas em formato Prometheus, por isso pode recolhê-las para o Prometheus ou o Datadog.
Com a telemetria ativada, o Azure Databricks também guarda os registos do servidor e as métricas Prometheus do vLLM em tabelas do Unity Catalog, para que possas consultá-las durante períodos mais longos. Veja Persistir modelo personalizado que serve dados para o Catálogo Unity.
Pricing
Paga-se por hora de instância da GPU, o mesmo que para outros serviços de serving de modelos personalizados com GPU. Veja preços do Model Serving.
Limitações e disponibilidade da região
Registas um LLM personalizado a partir do AI Runtime, por isso o serviço de LLM personalizado está disponível nas mesmas regiões que o processamento de GPU serverless. São regiões dos EUA na AWS e Azure. O GCP não é suportado.
As seguintes funcionalidades estão a chegar em breve:
- Adaptadores LoRA.
- Disponibilização entre regiões.
- Registar modelos fora do AI Runtime, por exemplo do Databricks Runtime ou de CPU serverless.
Os seguintes recursos não são suportados:
- Encaminhamento com reconhecimento da cache KV.
- Otimização de rotas.