Тест, свързан с ръководство · Среден Ниво

LLM Inference Routing и тест за балансиране на натоварването

Проверява маршрутизирането на реплика и модел, афинитета на кеша, телеметрията на живо, променливата цена на токена и добър път, съобразен с латентността, за LLM извод.

Въпрос 1 на 8

Защо обикновеният кръгов режим често е лоша стратегия за балансиране на натоварването за LLM извод?

Визуализирайте всеки въпрос8 въпроси

Отговорите и обясненията се появяват, докато отговаряте на теста.

  1. Защо обикновеният кръгов режим често е лоша стратегия за балансиране на натоварването за LLM извод?
    • Заявките варират значително по цена и репликите държат лепкави KV кешове
    • Това е незаконно в повечето страни
    • Round-robin работи само за бази данни
    • Изисква графичен процесор, за да работи
  2. Какво се опитва да постигне маршрутизирането с афинитет на префикс-кеш?
    • Изпращане на всяка заявка до произволен GPU
    • Маршрутизиране на заявка към репликата, която вече е кеширала своя префикс за подкана
    • Шифроване на подканата преди изпращане
    • Компресиране на тежестите на модела
  3. При маршрутизиране на модел, базиран на трудност, какво обикновено се случва с лесна заявка?
    • Отхвърля се
    • Изпраща се до най-големия наличен модел
    • Изпраща се на малък по-евтин модел
    • Стои на опашка за 24 часа
  4. Кой сигнал на живо е най-полезен за LLM-aware load balancer?
    • Дължина на името на хоста на сървъра
    • Цветът на стелажа
    • Часовата зона само на потребителя
    • Дълбочина на опашката и заетост на KV-кеша на всяка реплика
  5. Какво предоставя инструмент като LiteLLM при настройка с множество доставчици?
    • Единичен прокси, който балансира и преодолява много доставчици на модели
    • Нова трансформаторна архитектура
    • Система за охлаждане на GPU
    • Заместител на токенизатора
  6. Защо една дълга заявка за изход може да надвиши много кратки за балансиране?
    • Дългите резултати не използват ресурси
    • Всеки изходен токен струва пълно предаване напред, така че общото натоварване на токена има повече значение от броя на заявките
    • Кратките заявки винаги са по-бавни
    • Рутерът изобщо не може да види изходната дължина
  7. A serving system reports goodput rather than raw request count. What does goodput usually emphasize?
    • Общият брой параметри на модела
    • Only the number of HTTP connections opened
    • Requests served while meeting the specified latency or service-level targets
    • The fraction of requests that use the largest model
  8. A gateway first chooses a small or large model, then chooses a replica of that model. What are these two decisions?
    • Tokenization followed by decoding
    • Training followed by fine-tuning
    • Prefill followed by prompt construction
    • Model routing followed by replica load balancing