Entendendo o ML Distribuído Moderno: De Agendadores HPC a Mecanismos de Servir LLM
Engenheiros de aprendizado de máquina hoje em dia lidam com um conjunto diversificado de ferramentas e conceitos para treinar e implantar modelos em escala. Este artigo fornece uma visão detalhada de vários tópicos importantes: executar trabalhos com Deep Learning Containers (DLC), usar agendadores de lote HPC como Volcano (VOLC) e SLURM, servir LLM de forma eficiente com vLLM e SGLang, estruturas e parâmetros de treinamento típicos, modos operacionais (treinamento versus inferência), estratégias de paralelismo (DPTPPP – dados, pipeline, paralelismo de tensor), o papel de roteadores e controladores em sistemas distribuídos e estratégias de carregamento de dados para alto rendimento. Explicaremos cada conceito, forneceremos exemplos (com amostras de código e configuração) e ofereceremos insights práticos de maneira técnica e precisa. Vamos mergulhar.
Deep Learning Containers (DLC) e Execução de Trabalhos de ML
Deep Learning Containers (DLC) referem-se a imagens de contêiner Docker pré-construídas que vêm com estruturas de aprendizado profundo populares e dependências otimizadas e prontas para serem executadas. Por exemplo, a AWS fornece DLCs para TensorFlow, PyTorch, MXNet, etc., que incluem construções otimizadas (muitas vezes com suporte a GPU, bibliotecas como CUDA/cuDNN instaladas e até mesmo otimizações de rede como EFA para treinamento multi-nó). Esses contêineres garantem um ambiente consistente para que os pesquisadores não precisem instalar manualmente as estruturas em cada máquina. De acordo com a AWS, os DLCs estão disponíveis como imagens Docker no Amazon ECR (Elastic Container Registry), e cada imagem é adaptada para uma versão e tarefa específica da estrutura (treinamento ou inferência) (Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog). Isso significa que você pode escolher um contêiner que corresponda à estrutura desejada (digamos PyTorch 2.0 com CUDA 11) e ter certeza de que ele tem todas as bibliotecas certas.
Como ele opera: Na prática, usar um DLC envolve puxar a imagem do contêiner e executar seu treinamento ou inferência dentro dele. Isso pode ser feito em uma VM na nuvem ou em um servidor local com o Docker instalado. Por exemplo, depois de iniciar uma instância GPU EC2, pode-se fazer:
# Passo 1: Faça login no AWS ECR público (se necessário) e puxe a imagem do DLC
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <aws_account>.dkr.ecr.us-west-2.amazonaws.com
docker pull <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2
# Passo 2: Execute o contêiner com um script de treinamento
docker run --gpus all -v /data:/data -it <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2 \
python /data/train.py --epochs 5 --batch-size 32
No exemplo acima, puxamos um DLC de treinamento AWS PyTorch 2.0 e, em seguida, executamos um script de treinamento (train.py) dentro dele. A flag --gpus all dá ao contêiner acesso às GPUs NVIDIA no host, e -v /data:/data monta um diretório de dados do host no contêiner. Essa abordagem garante que o ambiente dentro do contêiner tenha a versão correta do PyTorch, CUDA, etc., o que simplifica a execução do trabalho. Também é portátil – o mesmo contêiner pode ser executado em qualquer máquina com o Docker, de modo que os experimentos são reproduzíveis.
Quando usar DLCs: Os DLCs são especialmente úteis em plataformas de nuvem e serviços gerenciados. Por exemplo, os trabalhos de treinamento do Amazon SageMaker usam imagens DLC nos bastidores para que você possa apenas especificar a imagem e seu código de treinamento, e a plataforma cuida do resto. Mesmo em clusters HPC, as equipes às vezes usam Singularity ou Docker para executar trabalhos em um ambiente de contêiner para consistência. Em resumo, os DLCs simplificam o problema “funciona na minha máquina” fornecendo um tempo de execução consistente para tarefas de aprendizado profundo. Eles vêm com bibliotecas testadas e otimizadas (o que pode render aumentos de desempenho – por exemplo, a AWS relatou até 42% de aceleração usando seu DLC PyTorch 2.0 otimizado em certas instâncias (Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog)).
Volcano (VOLC) – Agendamento de Lote Kubernetes para Trabalhos de IA
Volcano (VOLC) é um sistema de agendamento de lote construído no Kubernetes, projetado para executar computação de alto desempenho (HPC) e cargas de trabalho de IA em um ambiente nativo da nuvem. Embora o agendador padrão do Kubernetes seja ótimo para microsserviços, ele carece de algumas capacidades necessárias para trabalhos de aprendizado profundo (como agendamento de gangues, gerenciamento de filas e agendamento de prioridades). O Volcano aborda isso fornecendo um agendador personalizado e CRDs de gerenciamento de trabalho (Custom Resource Definitions) em cima do Kubernetes (Volcano: Collision between containers and batch computing | CNCF). Em essência, o Volcano permite que o Kubernetes se comporte mais como um agendador de cluster HPC para trabalhos em lote.
O que é: O Volcano foi introduzido para unir contêineres e computação em lote. Ele suporta estruturas como TensorFlow, PyTorch, Spark e MPI, permitindo que os usuários enviem trabalhos que exigem vários recursos (por exemplo, um trabalho que precisa de 8 GPUs em 2 nós) e garantindo que esses recursos sejam alocados juntos antes que o trabalho comece (Volcano: Collision between containers and batch computing | CNCF). Esse “agendamento de gangue” garante que os trabalhos de treinamento distribuído (que podem gerar muitos pods) não comecem até que todos os pods necessários possam começar, evitando uma situação em que metade do trabalho está em execução e a outra metade está esperando (o que desperdiçaria recursos). O Volcano também fornece políticas de justiça, filas de prioridade e a capacidade de co-agendar cargas de trabalho mistas.
Como ele opera: O Volcano se integra ao Kubernetes como um plugin de agendamento. Os usuários normalmente definem um YAML de Job do Volcano, que especifica tarefas e suas contagens de réplicas, necessidades de recursos, etc. Por exemplo, um YAML pode declarar um trabalho com 4 réplicas, cada uma precisando de 1 GPU, e um minAvailable: 4 (o que significa agendar este trabalho somente quando 4 pods puderem ser colocados). Quando enviado, o agendador do Volcano encontrará espaço no cluster para todos os 4 pods e os iniciará simultaneamente. Se apenas 3 GPUs estiverem livres, ele esperará até que uma quarta esteja livre (em vez de iniciar 3 agora e 1 depois). Isso é crucial para estruturas de treinamento distribuído como Horovod ou PyTorch DDP, que esperam que todos os ranks estejam ativos ao mesmo tempo para sincronização.
A arquitetura do Volcano inclui um controlador central e plugins de agendamento. Ele considera algoritmos de agendamento como compartilhamento justo, prioridade, etc., por meio de um mecanismo de plugin. Por exemplo, ele pode impor políticas de filas (para que certos trabalhos não prejudiquem outros) e agendamento com reconhecimento de topologia (espalhando trabalhos por nós ou racks para desempenho). Da perspectiva do usuário, usar o Volcano parece usar o Kubernetes, mas com uma API diferente para trabalhos e a garantia de que seu trabalho de ML será agendado holisticamente. Em resumo, VOLC transforma o Kubernetes em um agendador com reconhecimento de HPC (Volcano: Collision between containers and batch computing | CNCF), unindo a conveniência dos contêineres com o poder da orquestração de trabalhos em lote.
Caso de uso de exemplo: Suponha que você tenha um cluster Kubernetes com nós GPU e queira executar um trabalho de treinamento distribuído baseado em MPI. Com o Volcano, você pode enviar um MPI Job (o Volcano se integra ao MPI Operator) solicitando (digamos) 2 pods cada um com 4 GPUs. O Volcano garantirá que ambos os pods comecem juntos em dois nós e tenham 4 GPUs cada. Ele também lidará se um pod falhar, reagendando todo o trabalho, se necessário, para manter a semântica da gangue. Dessa forma, seu comando MPI mpirun dentro dos pods pode ser lançado de forma confiável em ambos os pods. Sem o Volcano, o agendador padrão pode iniciar um pod e, em seguida, atrasar o segundo até que os recursos se liberem, o que faria com que o processo MPI do primeiro pod travasse ou expirasse.
SLURM: Agendamento de Trabalho HPC Clássico (Visão Detalhada)
SLURM (Simple Linux Utility for Resource Management) é um agendador de trabalhos de código aberto amplamente utilizado para clusters HPC. Ele funciona como o “sistema operacional” de um cluster, alocando recursos (núcleos de CPU, GPUs, memória, nós) para trabalhos, enfileirando trabalhos até que os recursos estejam disponíveis e iniciando e monitorando esses trabalhos. O Slurm é altamente escalável e é usado em muitos supercomputadores de ponta. Ele fornece uma ferramenta de gerenciamento de cluster e agendamento de trabalhos que se concentra em combinar trabalhos de forma eficiente com os recursos disponíveis (Choosing the Right Orchestration Tool for ML Workloads: Slurm vs. Kubernetes | Nscale).
Como o SLURM funciona: Um cluster Slurm consiste em um controlador central (slurmctld) que gerencia a fila e o agendamento, e daemons de agente (slurmd) em execução em cada nó de computação para iniciar e supervisionar tarefas. Os usuários interagem com o Slurm por meio de comandos como sbatch (para enviar um script de trabalho em lote), salloc (para solicitar uma alocação interativa) ou srun (para iniciar tarefas paralelas). O Slurm mantém uma lista de partições (pense nelas como filas ou grupos de nós nomeados), cada uma com certos limites ou características de hardware, e ele agenda trabalhos em nós nessas partições de acordo com as políticas configuradas (prioridade, justiça, agendamento de preenchimento, etc.).
Exemplo de envio de trabalho: Abaixo está um exemplo de script de trabalho em lote Slurm (train.sbatch), que solicita recursos e executa um programa de treinamento:
#!/bin/bash
#SBATCH --job-name=train_model # Nome do trabalho
#SBATCH --nodes=1 # Executar em um único nó
#SBATCH --ntasks=4 # Total de tarefas (processos) = 4
#SBATCH --gres=gpu:4 # Solicitar 4 GPUs (em um nó)
#SBATCH --cpus-per-task=4 # 4 núcleos de CPU por tarefa (16 núcleos no total)
#SBATCH --mem=64G # 64 GB de memória para o trabalho
#SBATCH --time=02:00:00 # Limite de tempo hh:mm:ss
#SBATCH --partition=ml_gpu # Nome da partição (fila)
module load anaconda/2023a # Carregar quaisquer módulos necessários (por exemplo, Anaconda)
source activate myenv # Ativar o ambiente virtual, se necessário
echo "Executando em $SLURM_NNODES nó(s) com $SLURM_NTASKS tarefas..."
srun python train.py --epochs 10 --batch-size 128
Neste script, as linhas #SBATCH são diretivas para o Slurm. Solicitamos 1 nó com 4 GPUs e definimos o trabalho para executar python train.py via srun. Quando executamos sbatch train.sbatch, o Slurm enfileirará o trabalho. Uma vez que um nó na partição ml_gpu com 4 GPUs livres e 16 núcleos de CPU livres esteja disponível, o Slurm alocará esse nó para o trabalho, iniciará o trabalho e srun lançará 4 tarefas (já que --ntasks=4). Se este fosse um cenário de treinamento distribuído usando MPI ou PyTorch distribuído, essas 4 tarefas poderiam corresponder a 4 workers (cada um atribuído a uma GPU). O Slurm cuida de lançá-los com as variáveis de ambiente adequadas para MPI ou para torch.distributed (se configurado para fazê-lo).
Usando o Slurm de forma eficaz: O Slurm fornece muitos recursos, como matrizes de trabalho (para enviar muitos trabalhos semelhantes facilmente), cadeias de dependência (iniciar o trabalho B após o término do trabalho A) e criação de perfil de recursos. Para ML, um padrão comum é solicitar --gres=gpu:N para obter N GPUs e usar srun ou MPI para gerar N processos. O Slurm garante que todos esses processos sejam executados nos nós alocados e possam se comunicar (muitas vezes ele configura nomes de host em SLURM_HOSTNAMES e o MPI pode usá-los). O Slurm também permite políticas de agendamento; por exemplo, os trabalhos podem ser preemptados ou preenchidos. O agendamento de preenchimento é útil em HPC para maximizar a utilização: um trabalho curto pode pular para frente na fila se puder caber em uma lacuna entre trabalhos grandes. Como engenheiro, quando você tem grandes trabalhos de treinamento, você pode solicitar um tempo de parede mais longo; mas se você puder dividir o trabalho em pedaços menores ou checkpoint e reiniciar, você pode utilizar o preenchimento para fazê-los executar mais cedo em pedaços.
Em resumo, o Slurm é uma ferramenta poderosa para executar trabalhos de ML em lote em clusters. É de nível inferior ao Kubernetes ou serviços de nuvem – você normalmente SSH em um nó de login e usa sbatch para enviar – mas ele oferece controle granular. Muitos pesquisadores executam PyTorch ou TensorFlow em clusters Slurm simplesmente escrevendo scripts Slurm que lançam seu código de treinamento, beneficiando-se do agendamento de recursos GPU do cluster.
vLLM: Mecanismo de Inferência LLM de Alto Rendimento
À medida que os grandes modelos de linguagem (LLMs) passaram da pesquisa para a produção, servi-los de forma eficiente tornou-se um desafio. vLLM é uma biblioteca e mecanismo de código aberto projetado para inferência LLM rápida e econômica. Desenvolvido no Sky Computing Lab da UC Berkeley, o vLLM introduz uma nova técnica de gerenciamento de memória chamada PagedAttention para otimizar como o cache de chave-valor de atenção do modelo é armazenado e acessado (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). O resultado é um rendimento significativamente maior (requisições por segundo) em comparação com as implementações tradicionais. De fato, o vLLM alcança até 24× maior rendimento do que a biblioteca Hugging Face Transformers de linha de base no serviço de modelo estilo GPT (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog), tudo sem exigir alterações na arquitetura do modelo.
Como o vLLM funciona: Na geração auto-regressiva (a maneira típica como os LLMs geram texto token por token), um cache de chaves e valores de atenção passados é mantido para cada sequência. Este cache KV cresce com o comprimento da sequência e pode consumir muita memória da GPU (por exemplo, ~1.7 GB para uma única sequência longa no LLaMA-13B (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)). A maioria das estruturas aloca um bloco contíguo para o comprimento máximo possível, levando a muito espaço não utilizado (fragmentação). O PagedAttention do vLLM, em vez disso, trata o cache KV como páginas de memória virtual, alocando-o em blocos e permitindo armazenamento não contíguo (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Dessa forma, a memória pode ser gerenciada de forma flexível: as sequências que terminam de gerar liberam suas páginas, que podem ser reutilizadas para novas sequências. Ele reduz drasticamente o desperdício de memória (em 60–80% em casos típicos) e permite que o vLLM lide com mais sequências simultâneas do que outros sistemas.
Além disso, o vLLM implementa lote contínuo: ele pode adicionar novas solicitações de entrada no lote em tempo real, mesmo enquanto outras solicitações estão no meio da geração. Os sistemas tradicionais geralmente processam um lote fixo de solicitações do início ao fim para cada etapa de geração; o agendador do vLLM, em vez disso, é ajustado para mesclar solicitações sempre que possível, mantendo as GPUs ocupadas. Ele também usa gráficos CUDA otimizados para evitar sobrecarga de Python no loop de serviço, suporta GPUs NVIDIA e AMD e se integra ao Hugging Face Transformers (para que você possa carregar modelos por nome e servi-los).
Exemplo de uso: Usar o vLLM é semelhante a usar um servidor de inferência de alto nível. Você pode usá-lo programaticamente ou por meio de um servidor de API. Por exemplo, programaticamente:
from vllm import LLM, SamplingParams
# Carregar um modelo 7B (assumindo que os pesos estejam disponíveis localmente ou via HuggingFace Hub)
llm = LLM(model="facebook/opt-6.7b", tensor_parallel_size=1) # tensor_parallel_size pode >1 para dividir o modelo em GPUs
prompts = [
"User: Hello, how are you?\nAssistant:",
"User: What is the capital of France?\nAssistant:"
]
# Gerar com certos parâmetros de decodificação
outputs = llm.generate(prompts, sampling_params=SamplingParams(top_p=0.95, max_tokens=100))
for out in outputs:
print("Prompt:\n", out.prompt)
print("Completion:\n", out.outputs[0].text)
Este código cria uma instância LLM e gera respostas para dois prompts em um lote. Nos bastidores, o vLLM usará PagedAttention para gerenciar o cache KV para esses prompts e pode até mesmo agrupá-los se possível. Os outputs conterão as conclusões para cada prompt. Também se poderia lançar o vLLM como um servidor (que fornece uma API REST compatível com OpenAI) usando um comando como python -m vllm.entrypoints.openai.api_server --model your_model_name. Isso facilita a integração do vLLM com aplicativos que esperam uma API OpenAI (basta apontá-los para este servidor).
Por que isso importa: O vLLM essencialmente empurra os limites de rendimento do serviço LLM. Se você tem um orçamento fixo de GPU, servir mais solicitações por segundo significa menor custo por solicitação. A melhoria de 24× relatada é em cenários onde muitas solicitações simultâneas são geradas com saídas relativamente longas (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Mesmo em casos menos extremos, o vLLM geralmente produz múltiplas acelerações em relação às implementações ingênuas, e cerca de 3× em relação ao servidor TGI do Hugging Face em muitas configurações (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Ele também suporta algoritmos de decodificação avançados (como busca de feixe, amostragem paralela) de forma eficiente (vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium). Para um engenheiro, adotar o vLLM pode ser tão simples quanto trocar seu código de inferência para usar a API do vLLM (ou executar seu servidor). O benefício é lidar com mais usuários ou reduzir a latência sem comprar mais GPUs.
SGLang: Linguagem de Geração Estruturada e Estrutura de Serviço
Enquanto o vLLM se concentra no rendimento bruto da conclusão de prompt de etapa única, o SGLang aborda o problema de orquestrar interações complexas e estruturadas com LLMs de forma eficiente. SGLang (abreviação de Structured Generation Language) é um sistema que combina uma DSL (Domain-Specific Language) de frontend para descrever programas LLM multi-etapas com um tempo de execução de backend altamente otimizado para executá-los ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs) (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community). É como se o SGLang fosse uma linguagem de programação para prompting (com recursos como loops, condicionais e chamadas paralelas) e um mecanismo de serviço que garante que esses programas sejam executados rapidamente.
O que é: A ideia central por trás do SGLang é que muitas aplicações reais exigem múltiplas chamadas para um LLM e saídas estruturadas. Por exemplo, um agente de IA pode planejar etapas e chamar o LLM para cada etapa, ou você pode exigir que o LLM produza JSON com um esquema específico. Fazer isso ingenuamente pode ser lento: múltiplas chamadas incorrem em sobrecarga e o LLM pode repetir o processamento das mesmas partes do prompt, etc. O frontend do SGLang permite que você escreva um único “script” que pode incluir múltiplas chamadas de geração, lógica de ramificação e integração de ferramentas externas. O compilador/tempo de execução do SGLang executará isso de forma eficiente. O tempo de execução introduz otimizações como RadixAttention (um algoritmo para reutilizar o cache KV em prefixos de prompt, semelhante em espírito à paginação do vLLM, mas voltado para partes de prompt compartilhadas) e uma máquina de estado finito comprimida para gramática de saída (para lidar com saídas estruturadas mais rapidamente) ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). Em termos simples, RadixAttention significa que se você tem muitas solicitações compartilhando um prefixo comum (por exemplo, sistema ou prompt de poucos disparos), o SGLang calculará essa parte uma vez e a reutilizará, tornando coisas como chatbots ou geração aumentada de recuperação muito mais rápidas, evitando trabalho redundante (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). O FSM de saída estruturada significa que se você espera, digamos, um JSON com chaves fixas, o SGLang pode pular a geração da pontuação/chaves fixas token por token e pular para frente, já que sabe que essas partes são determinísticas (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). Isso dá um aumento de velocidade de 3×+ para gerar saídas JSON ou XML longas (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium).
Como ele opera: SGLang consiste em duas partes – uma DSL baseada em Python e um tempo de execução. A DSL permite que os usuários escrevam algo como:
from sglang import sg # interface hipotética
# Pseudocódigo: definir um fluxo de geração estruturado
with sg.session(model="Llama-2-13b-chat") as sess:
# Um programa simples com duas chamadas LLM sequenciais e uma saída estruturada
user_input = "Translate the following English text to French and give sentiment: I love this product."
sg.prompt(f"User asks: {user_input}\nYou are a translator and sentiment analyzer.")
translation = sg.generate("First, translate to French:")
sentiment = sg.generate("Now, analyze the sentiment of the original text:")
sg.return_json({"translation": translation, "sentiment": sentiment})
(Nota: O código acima é um pseudocódigo ilustrativo. A sintaxe real do SGLang pode ser diferente, mas conceitualmente permite geração sequencial e paralela e retorno de dados estruturados.)
Quando este "programa" SGLang é executado, o tempo de execução assume o controle: ele pode executar a primeira chamada de geração para traduzir, depois a segunda para o sentimento e, finalmente, montar um JSON. Nos bastidores, ele usa um ou mais backends de inferência LLM (com otimizações semelhantes ao vLLM). Como os dois prompts compartilham o contexto de instrução inicial, o SGLang pode reutilizar a computação desse prefixo para a segunda chamada. E ao retornar JSON, se as chaves e o formato JSON forem predeterminados por sg.return_json, ele pode garantir que esses sejam produzidos sem gastar vários tokens em chaves/vírgulas.
Recursos principais: Os autores do SGLang destacam recursos incluindo agendamento de sobrecarga zero (seu agendador para orquestrar múltiplas chamadas não adiciona virtualmente nenhuma latência extra), balanceamento de carga consciente do cache (ele pode rotear solicitações para workers de forma que maximize os acertos de cache) e suporte multi-modal (ele pode lidar com modelos de visão-linguagem também, por exemplo, LLaVA para imagens) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.). Ele também suporta truques de eficiência comuns: quantização (int8/4-bit etc.), decodificação especulativa (gerando múltiplos tokens com antecedência para então verificar, o que pode acelerar gerações longas) e orquestração multi-modelo (por exemplo, usando um modelo para uma parte do programa e outro modelo para uma parte diferente). Essencialmente, é uma estrutura completa para escrever aplicativos alimentados por LLM e executá-los com alto desempenho.
Desempenho e casos de uso: O SGLang mostrou até 6.4× melhorias de rendimento em relação aos sistemas de ponta em tarefas complexas ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). Considere um pipeline de geração aumentada de recuperação (RAG): normalmente, você pode pesquisar vetorialmente por contexto, então anexá-lo a um prompt, então gerar uma resposta. Com o SGLang, você poderia expressar toda essa sequência (resultado de busca vetorial alimentando um modelo de prompt, então geração) como um único programa. O tempo de execução poderia paralelizar algumas etapas, se possível, e reutilizar componentes em cache. Da mesma forma, para chatbots que têm um histórico de conversa, o SGLang pode reutilizar as partes invariantes do prompt entre as voltas (em vez de reprocessar a conversa inteira a cada vez). Para saídas estruturadas, como garantir que a resposta do modelo siga um esquema JSON, a abordagem de máquina de estado finito do SGLang pode impedir que o modelo se desvie do formato e fazê-lo mais rapidamente injetando a sintaxe fixa. Do ponto de vista da engenharia, o SGLang oferece um aumento de produtividade (via DSL) e um aumento de desempenho (via execução otimizada) para construir fluxos de trabalho LLM complexos.
Quem está por trás disso: SGLang é um projeto de código aberto (apoiado por uma comunidade incluindo pesquisadores de Stanford/Berkeley, e empresas como LinkedIn, etc., conforme seus agradecimentos). Tem sido usado em produção por empresas como ByteDance e xAI (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community). É relativamente novo (o artigo arXiv veio no final de 2023), mas está ganhando força para aplicações LLM avançadas. Se seu caso de uso vai além de pares de conclusão de prompt único – digamos que você precisa de um agente que chama o modelo várias vezes ou você precisa de respostas estruturadas ultra-rápidas – explorar SGLang pode valer a pena. Ele tem mais partes móveis do que um servidor simples, mas pode automatizar muita da otimização que você teria que construir você mesmo.
Estruturas de Treinamento e Parâmetros de Treinamento Típicos
Quando falamos sobre estruturas de treinamento, nos referimos às bibliotecas e ferramentas usadas para implementar o treinamento de modelos. Os principais são PyTorch, TensorFlow, JAX e interfaces de nível superior como PyTorch Lightning ou Hugging Face Transformers Trainer, bem como estruturas de treinamento distribuído como Horovod, DeepSpeed ou ColossalAI que ficam em cima destes. Independentemente da estrutura, há um conjunto comum de parâmetros de treinamento (hiperparâmetros) que os profissionais devem gerenciar. Estes são os botões que definem a configuração