Как да планирате натоварването на частен AI: едновременни заявки и време за отговор
Измерете капацитета на частен AI с представителни задачи, едновременност, опашка и време за отговор. Протокол за тест, без недоказани хардуерни обещания.
Как се измерва капацитетът на частен AI?
Капацитетът се установява с представителни задачи върху конкретен модел и инфраструктура. Измерват се успешно приключени заявки, време за отговор, опашка, грешки и качество при различно натоварване. Общият брой служители или паметта на видеокартата сами по себе си не определят колко работа ще поеме системата.
Това ръководство предоставя протокол за собствен тест. Не представя лабораторни резултати за конкретен хардуер и не обещава брой потребители. Числовите сметки по-долу са учебни; приемането на реална среда изисква измерване и технически преглед.
Опишете задачата преди инфраструктурата.
Разделете типовете работа: кратки вътрешни въпроси, обобщение на дълги документи, извличане на полета или пакетна обработка. Те имат различни входове, дължина на изхода и зависимост от търсене, OCR или други услуги. Използвайте реалистично разпределение на задачите в теста.
Запишете размерите на входа и изхода в токени с токенизатора на избрания модел. Броят страници не е надежден заместител: две страници могат да съдържат много различен обем текст. При мултимодален модел добавете настройките за изображенията или другия вход.
Фиксирайте модела и ревизията, serving софтуера, броя и типа ускорители, паметта, квантизацията, контекстния лимит и настройките за batch обработка. Включете мрежовия път и зависимите услуги. Без тази информация резултатът трудно се възпроизвежда.
Потребители, заявки и едновременност.
Сто регистрирани потребители не означават сто едновременни заявки. За планиране измерете честотата на постъпване и продължителността на обработката. Разграничете заявки, които пристигат, заявки в опашката и заявки, които се изпълняват.
Учебна сметка: при устойчиво средно постъпване от 0,5 заявки в секунда и средно общо време в системата 8 секунди, средният брой незавършени заявки е приблизително 0,5 × 8 = 4. Това е връзката L = λW за устойчив режим. Тя не предсказва пиковете, нужната GPU памет или максималната безопасна едновременност.
За сутрешни пикове и пакетни задачи използвайте отделни сценарии. Ако средата е претоварена и опашката расте, устойчивата сметка не е достатъчна. Увеличаването на разрешените едновременни заявки може да влоши времето и да създаде повече откази.
Попълваем протокол за натоварване.
Първо договорете допустимо време и качество за всеки тип задача. След това попълнете таблицата с реални измервания. Празните полета не са benchmark резултат.
| Сценарий | Натоварване | Какво се записва |
|---|---|---|
| Базов | Една заявка; различни входове | Качество, време, използвана памет |
| Обичаен | [Измерена нормална честота] | Успешни заявки/секунда; p50/p95; грешки |
| Пиков | [Очакван пик и продължителност] | Опашка, време на изчакване, откази |
| Смесен | Кратки и дълги задачи в реалистичен дял | Показатели по тип задача |
| Възстановяване | След пика или контролиран отказ | Време до нормален режим; обработка на чакащите задачи |
За всяко изпълнение запазете дата, среда, версия на входния набор, продължителност, общ и успешен брой заявки, timeout и настройките. Отделете студен старт от загрята система. Отбележете кеширането, защото повторени еднакви входове могат да дадат прекалено оптимистичен резултат.
Кои времена трябва да различавате?
Времето до първия токен показва кога започва потокът на отговора. Времето до пълния резултат показва кога задачата е готова. Ако CRM записът се изпълнява след генерирането, измерете и него. Бързото начало на текст не означава бързо приключила бизнес задача.
Използвайте медиана и p95 за достатъчно голяма извадка, а не само средна стойност. p95 е границата, под която попадат приблизително 95% от наблюдаваните времена. Записвайте неуспешните заявки отделно, за да не изглежда системата по-бърза само защото бавните случаи са отпаднали.
Официалната документация на vLLM Benchmark CLI описва метрики за latency, честота на заявки и ограничение на едновременността. Проверете опциите за инсталираната версия и включвайте клиентското изчакване в общото измерване. Самият инструмент не определя приемливите бизнес прагове.
Какво се прави при претоварване?
Задайте ограничена опашка, срок за изчакване и видим статус. При изчерпан капацитет системата трябва да покаже контролирано съобщение или да насочи към разрешен резервен процес. Безкрайните повторни опити могат да засилят претоварването.
Резервният вариант се съгласува с ограниченията за данните. Ако задачата е предназначена за частна среда, не я прехвърляйте автоматично към външна услуга без необходимото разрешение. Възможни са отложена обработка, по-малък проверен модел или човешко изпълнение.
Приемете капацитета само ако средата покрива качеството и времето при очакваното натоварване и се възстановява контролирано. Запазете измерения резерв като конкретен резултат от теста, вместо да обещавате универсален процент свободен ресурс.
Често задавани въпроси.
Може ли да изберем хардуер само по броя служители?
Не надеждно. Нужни са типове задачи, размер на входа, честота, едновременност и допустимо време. Изборът се потвърждава с измерване на конкретната конфигурация.
Защо повече едновременни заявки понякога забавят AI?
Те споделят ограничени изчислителни и паметови ресурси. При достигане на границите могат да увеличат изчакването или отказите. Оптималният лимит се установява с тест.
Учебната сметка доказва ли капацитет от четири заявки?
Не. Тя показва среден брой незавършени заявки при зададени условия. Не доказва производителност на модел или хардуер и не замества натоварващ тест.
Подгответе техническа оценка.
Съберете типовете задачи, входните размери и очакваните пикове. В частния AI можем да обсъдим границите на средата и протокола за измерване. Заяви безплатен AI одит.