Тест, свързан с ръководство · Среден Ниво
LLM Inference Routing и тест за балансиране на натоварването
Проверява маршрутизирането на реплика и модел, афинитета на кеша, телеметрията на живо, променливата цена на токена и добър път, съобразен с латентността, за LLM извод.
Въпрос 1 на 8
Защо обикновеният кръгов режим често е лоша стратегия за балансиране на натоварването за LLM извод?
Визуализирайте всеки въпрос8 въпроси
Отговорите и обясненията се появяват, докато отговаряте на теста.
- Защо обикновеният кръгов режим често е лоша стратегия за балансиране на натоварването за LLM извод?
- Заявките варират значително по цена и репликите държат лепкави KV кешове
- Това е незаконно в повечето страни
- Round-robin работи само за бази данни
- Изисква графичен процесор, за да работи
- Какво се опитва да постигне маршрутизирането с афинитет на префикс-кеш?
- Изпращане на всяка заявка до произволен GPU
- Маршрутизиране на заявка към репликата, която вече е кеширала своя префикс за подкана
- Шифроване на подканата преди изпращане
- Компресиране на тежестите на модела
- При маршрутизиране на модел, базиран на трудност, какво обикновено се случва с лесна заявка?
- Отхвърля се
- Изпраща се до най-големия наличен модел
- Изпраща се на малък по-евтин модел
- Стои на опашка за 24 часа
- Кой сигнал на живо е най-полезен за LLM-aware load balancer?
- Дължина на името на хоста на сървъра
- Цветът на стелажа
- Часовата зона само на потребителя
- Дълбочина на опашката и заетост на KV-кеша на всяка реплика
- Какво предоставя инструмент като LiteLLM при настройка с множество доставчици?
- Единичен прокси, който балансира и преодолява много доставчици на модели
- Нова трансформаторна архитектура
- Система за охлаждане на GPU
- Заместител на токенизатора
- Защо една дълга заявка за изход може да надвиши много кратки за балансиране?
- Дългите резултати не използват ресурси
- Всеки изходен токен струва пълно предаване напред, така че общото натоварване на токена има повече значение от броя на заявките
- Кратките заявки винаги са по-бавни
- Рутерът изобщо не може да види изходната дължина
- 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
- 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