O que significam os intervalos dos tokens por segundo na taxa de transferência provisionada?

Este artigo descreve como e por que razão o Databricks mede o número de tokens por segundo em cargas de trabalho com taxa de transferência provisionada para as APIs do Modelo de Fundação .

O desempenho de modelos de linguagem grandes (LLMs) é frequentemente medido em termos de tokens por segundo. Ao configurar o modelo de produção servindo pontos de extremidade, é importante considerar o número de solicitações que seu aplicativo envia para o ponto de extremidade. Isso ajuda você a perceber se o seu endpoint deve ser configurado para ser dimensionado a fim de não afetar a latência.

Ao configurar os intervalos de expansão para pontos de extremidade implantados com taxa de transferência provisionada, o Databricks achou mais fácil raciocinar sobre as entradas que entram em seu sistema usando tokens.

O que são tokens?

Os LLMs leem e generate texto em termos do que é chamado de token . Os tokens podem ser palavras ou subpalavras, e as regras exatas para dividir o texto em tokens variam de modelo para modelo. Por exemplo, você pode usar ferramentas on-line para ver como tokenizador da Lama converte palavras em tokens.

O diagrama a seguir mostra um exemplo de como o tokenizador Llama divide o texto:

Por que medir o desempenho do LLM em termos de tokens por segundo?

Tradicionalmente, os pontos de extremidade de serviço são configurados com base no número de solicitações simultâneas por segundo (RPS). No entanto, uma solicitação de inferência LLM leva uma quantidade diferente de tempo dependendo de quantos tokens são passados e de quantos são gerados, o que pode resultar em desequilíbrio entre as várias solicitações. Portanto, decidir quanto dimensionamento o seu endpoint exige efetivamente a medição da escala do endpoint em função do conteúdo dos seus pedidos - tokens.

Diferentes casos de uso apresentam diferentes proporções de token de entrada e saída:

• Comprimentos variáveis de contextos de entrada: Enquanto algumas solicitações podem envolver apenas alguns tokens de entrada, por exemplo, uma pergunta curta, outras podem envolver centenas ou até milhares de tokens, como um documento longo para resumo. Essa variabilidade torna desafiadora a configuração de um ponto de extremidade de serviço baseado apenas no RPS, uma vez que não leva em conta as diferentes demandas de processamento das diferentes solicitações.
• Comprimentos variáveis de saída dependendo do caso de uso: Casos de uso diferentes para LLMs podem levar a comprimentos de token de saída muito diferentes. A geração de tokens de saída é a parte mais demorada da inferência LLM, portanto, isso pode afetar drasticamente a taxa de transferência. Por exemplo, a sumarização envolve respostas mais curtas e picantes, mas a geração de texto, como escrever artigos ou descrições de produtos, pode generate respostas muito mais longas.

Como faço para select o intervalo de tokens por segundo para meu endpoint?

Os pontos de extremidade de serviço com taxa de transferência aprovisionada são configurados em termos de um intervalo de fichas por segundo que se pode enviar para o ponto de extremidade. O endpoint escalona para lidar com a carga do seu aplicativo de produção, aumentando ou diminuindo conforme necessário. Você é cobrado por hora com base no intervalo de tokens por segundo para o qual seu endpoint é dimensionado.

A melhor maneira de saber qual o intervalo de tokens por segundo funciona no endpoint do serviço de throughput provisionado para o seu caso de uso é realizar um teste de carga com um conjunto de dados que seja representativo. Consulte Conduza seu próprio benchmarking de ponto final LLM.

Há dois fatores importantes a considerar:

• Como o Databricks mede o desempenho do LLM em tokens por segundo.
• Como funciona o dimensionamento automático.

Como o Databricks mede o desempenho em tokens por segundo do LLM

O Databricks compara pontos de extremidade em relação a uma carga de trabalho que representa tarefas de sumarização que são comuns para casos de uso de geração aumentada por recuperação. Especificamente, a carga de trabalho consiste em:

• 2048 tokens de entrada
• 256 tokens de saída

Os intervalos de token exibidos combinam taxa de transferência de token de entrada e saída e, por padrão, optimize para equilibrar taxa de transferência e latência.

A Databricks realiza testes de desempenho que permitem aos utilizadores enviar um determinado número de tokens por segundo de forma concorrente ao endpoint, em um tamanho de lote de 1 por cada pedido. Isso simula várias solicitações atingindo o ponto de extremidade ao mesmo tempo, o que representa com mais precisão como você realmente usaria o ponto de extremidade na produção.

• Por exemplo, se um endpoint de serviço com taxa de transferência provisionada tiver uma taxa de set de 2304 tokens por segundo (2048 + 256), espera-se que uma única solicitação com uma entrada de 2048 tokens e uma saída esperada de 256 tokens leve cerca de um segundo para ser concluída.
• Da mesma forma, se a taxa de processamento for set a 5600, pode-se esperar que uma única solicitação, com as contagens de tokens de entrada e saída acima, leve cerca de 0,5 segundos para ser executada – ou seja, o endpoint pode processar duas solicitações semelhantes em cerca de um segundo.

Se sua carga de trabalho variar das anteriores, você pode esperar que a latência varie em relação à taxa de transferência provisionada listada. Como dito anteriormente, gerar mais tokens de saída é mais demorado do que incluir mais tokens de entrada. Se você estiver executando a inferência em lote e quiser estimar a quantidade de tempo que levará para ser concluída, poderá calcular o número médio de tokens de entrada e saída e comparar com a carga de trabalho de referência do Databricks acima.

• Por exemplo, se você tiver 1000 linhas, com uma contagem média de tokens de entrada de 3000 e uma contagem média de tokens de saída de 500, e uma taxa de transferência provisionada de 3500 tokens por segundo, pode levar mais de 1000 segundos no total (um segundo por linha) devido às contagens médias de tokens serem maiores do que o benchmark Databricks.
• Da mesma forma, se você tiver 1000 linhas, uma entrada média de 1500 tokens, uma saída média de 100 tokens e uma taxa de transferência provisionada de 1600 tokens por segundo, pode levar menos do que 1000 segundos no total (um segundo por linha) devido à sua contagem média de tokens ser menos do que o benchmark Databricks.

Para estimar a taxa de transferência provisionada ideal necessária para concluir sua carga de trabalho de inferência em lote, você pode usar o bloco de anotações no Executar inferência LLM em lote usando ai_query

Como funciona o dimensionamento automático

O Model Serving apresenta um sistema de dimensionamento automático rápido que dimensiona a computação subjacente para atender à demanda de tokens por segundo do seu aplicativo. O Databricks aumenta a taxa de transferência provisionada em blocos de tokens por segundo, assim o utilizador é cobrado por unidades adicionais de taxa de transferência provisionada somente quando estiver a utilizá-las.

O gráfico de relação entre taxa de transferência e latência a seguir mostra um ponto de extremidade de taxa de transferência provisionada que foi testado com um número crescente de pedidos paralelos. O primeiro ponto representa 1 solicitação, o segundo, 2 solicitações paralelas, a terceira, 4 solicitações paralelas, e assim por diante. À medida que o número de solicitações aumenta, e consequentemente a demanda por tokens por segundo, nota-se que a taxa de transferência provisionada também aumenta. Esse aumento indica que o dimensionamento automático aumenta a computação disponível. No entanto, poderá começar a ver que a taxa de transferência começa a estabilizar-se, atingindo uma limit de ~8000 tokens por segundo conforme mais solicitações paralelas são feitas. A latência total aumenta à medida que mais solicitações precisam aguardar na fila antes de serem processadas porque a computação alocada está sendo usada simultaneamente.

Observação

Você pode manter o throughput consistente desativando a funcionalidade de escalar para zero e configurando um throughput mínimo no endpoint de serviço. Isso evita a necessidade de esperar que o endpoint escale.

Você também pode ver no modelo que serve o ponto de extremidade como os recursos são girados para cima ou para baixo, dependendo da demanda:

Figura de Uso da GPU no Modelo