Именно такого графика с e-2-e латенси нет, но вся эта информация есть на графиках в статье. В каждой модели в статье это третий и четвертый графики. По оси y третий график подписан как time to first token, это время до появления первого токена, когда пользователь уже может начинать читать ответ. Если вам полное латенси нужно, то тогда прибавьте туда с 4 графика размер decode разделенный на per user speed по оси y. На четвертом графике скорость в токенах в секунду на пользователя, так что делением получите время от первого токена ответа до последнего.
Посчитаю для обычного оригинального fp8 deepseek v3.2 из графиков. Если у вас одномоментно, в одну и ту же секунду, 256 пользователей захотели суммаризировать документ на 16000 токенов и получили ответ в 2000 токенов, то каждый будет ждать полного ответа примерно 2 минуты.
Правильно было бы посчитать среднюю и пиковую нагрузку для 10 вопросов в день, как вы упоминаете. Это будет никак не 20000 запросов одномоментно.
Предположим, у вас 20000 пользователей в основном работают 8 часов днем с 9 до 18 и все находятся в одном часовом поясе. Если они делают 10 запросов в этом промежутке, то это примерно 7 запросов в секунду в среднем. Если брать пример с суммаризацией выше, то одного B300 для такой нагрузки не хватит, он сможет прожевать примерно 2 запроса в секунду, именно такого профиля. Значит надо 4 машины минимум.
На деле конечно не все пользователи делают такие запросы и это теоретическая оценка.
Должен заметить, что если у вас все 20 тысяч пользователей вашей системы пришли одновременно, то это особый случай. Это для любой системы нестандартная ситуация и перегрузка. Но ок. Вдруг у вас сервис открывается ровно в 10 утра, а пользователям надо именно в 10 утра обязательно нажать кнопку send в чате с моделью и никак иначе.
Пробовали для моделей поменьше, результат ожидаемо оказался не очень. Для таких больших моделей как Deepseek это невыгодная конфигурация. Объем батчей, передаваемых через PCI становится слишком большой, поэтому большую параллельную нагрузку обработать не выйдет. Карты будут часть времени простаивать, в ожидании данных через PCI. Даже если это пайплайновый параллелизм, наиболее экономный по передаваемому объему. Без расчетов под рукой твердо обосновать не готов, но замечал простои карт с ожиданием данных на конфигурации: 4 карты, пайплайн, 48 гигабайт VRAM на карту в моделях типа Qwen3.
Это не на одного пользователя. Бенчмарки показывают число одновременно исполняемых запросов сервером. Сколько при этом пользователей - зависит от сервиса, который запросы отправляет. Допустим агентский сервис может и несколько сразу отправить. Нужны какие-то начальные допущения о том, что делает пользователь в вашем сервисе. Например, если у вас пользователь просто общается с чат ботом и делает, скажем, не более 10 вопросов в день, то тогда B300 сможет обслужить примерно 20 тысяч пользователей в сутки в среднем (DAU - daily average users). У вас какая нагрузка, под которую хотите посчитать B300?
На доступной мне машине есть еще 3 Tesla T4, в которых полностью умещается Coder-30B. Интересный возникает четвертый сценарий в дополнение к Вашему, толстая MoE только на CPU и драфтовая полегче на GPU.
Сервера в аренду с двумя процессорами AMD epyc и большим объемом памяти, чтобы запускать такие LLM. Точная конфигурация и ее стоимость приведены в статье в разделе "Как собрать Inference-сервер на CPU"->"Как собрать конфигурацию"
Выше также комментировали (не Вы, а SlavikF) некие 200 гигабайт и 30 гигабайт, не понимаю откуда числа. Но давайте просто проверим теоретические расчеты тестами, какая пропускная способность будет на Epyc 4 поколения:
Что получили - 700 гигабайт в секунду на оба сокета, 340 на один, 147 в одну сторону между numa 0-1 и 147 в другую между numa 1-0.
Итого: каждый процессор в numa interleaving может получать до 340 гигабайт в секунду в сумме (своя память + память соседа по numa), а оба примерно 700 гигабайт.
Именно такого графика с e-2-e латенси нет, но вся эта информация есть на графиках в статье. В каждой модели в статье это третий и четвертый графики. По оси y третий график подписан как time to first token, это время до появления первого токена, когда пользователь уже может начинать читать ответ. Если вам полное латенси нужно, то тогда прибавьте туда с 4 графика размер decode разделенный на per user speed по оси y. На четвертом графике скорость в токенах в секунду на пользователя, так что делением получите время от первого токена ответа до последнего.
Посчитаю для обычного оригинального fp8 deepseek v3.2 из графиков. Если у вас одномоментно, в одну и ту же секунду, 256 пользователей захотели суммаризировать документ на 16000 токенов и получили ответ в 2000 токенов, то каждый будет ждать полного ответа примерно 2 минуты.
Правильно было бы посчитать среднюю и пиковую нагрузку для 10 вопросов в день, как вы упоминаете. Это будет никак не 20000 запросов одномоментно.
Предположим, у вас 20000 пользователей в основном работают 8 часов днем с 9 до 18 и все находятся в одном часовом поясе.
Если они делают 10 запросов в этом промежутке, то это примерно 7 запросов в секунду в среднем. Если брать пример с суммаризацией выше, то одного B300 для такой нагрузки не хватит, он сможет прожевать примерно 2 запроса в секунду, именно такого профиля. Значит надо 4 машины минимум.
На деле конечно не все пользователи делают такие запросы и это теоретическая оценка.
Должен заметить, что если у вас все 20 тысяч пользователей вашей системы пришли одновременно, то это особый случай. Это для любой системы нестандартная ситуация и перегрузка. Но ок. Вдруг у вас сервис открывается ровно в 10 утра, а пользователям надо именно в 10 утра обязательно нажать кнопку send в чате с моделью и никак иначе.
Пока не тестили.
Пробовали для моделей поменьше, результат ожидаемо оказался не очень.
Для таких больших моделей как Deepseek это невыгодная конфигурация. Объем батчей, передаваемых через PCI становится слишком большой, поэтому большую параллельную нагрузку обработать не выйдет. Карты будут часть времени простаивать, в ожидании данных через PCI.
Даже если это пайплайновый параллелизм, наиболее экономный по передаваемому объему.
Без расчетов под рукой твердо обосновать не готов, но замечал простои карт с ожиданием данных на конфигурации: 4 карты, пайплайн, 48 гигабайт VRAM на карту в моделях типа Qwen3.
Это не на одного пользователя. Бенчмарки показывают число одновременно исполняемых запросов сервером. Сколько при этом пользователей - зависит от сервиса, который запросы отправляет. Допустим агентский сервис может и несколько сразу отправить.
Нужны какие-то начальные допущения о том, что делает пользователь в вашем сервисе.
Например, если у вас пользователь просто общается с чат ботом и делает, скажем, не более 10 вопросов в день, то тогда B300 сможет обслужить примерно 20 тысяч пользователей в сутки в среднем (DAU - daily average users).
У вас какая нагрузка, под которую хотите посчитать B300?
На доступной мне машине есть еще 3 Tesla T4, в которых полностью умещается Coder-30B. Интересный возникает четвертый сценарий в дополнение к Вашему, толстая MoE только на CPU и драфтовая полегче на GPU.
Сервера в аренду с двумя процессорами AMD epyc и большим объемом памяти, чтобы запускать такие LLM. Точная конфигурация и ее стоимость приведены в статье в разделе "Как собрать Inference-сервер на CPU"->"Как собрать конфигурацию"
Резонно. Вот результаты из которых сделаны графики https://gist.github.com/nsforth/e4457bd4749c98eb28f980c67a870618
model-draft не проверял, ранее в других тестах не получал заметную разницу, поэтому не включал в тесты в этот раз.
Машину я вернул с тестов, есть под рукой односокетная с AMD EPYC 9754 128-Core Processor, могу на ней попробовать с draft и без.
Каждый xGMI это 16 линий pcie 5.0, только с другим протоколом, но скорость та же.
Получается 64 линии по 32 гигабита, при стандартной конфигурации 4 линка xGMI.
Это теоретически до 2048 гигабит в каждую сторону (256 гигабайт/с), двусторонний линк 512 гигабайт/с. Об этом написано в вашей же ссылке ниже в разделе Theoretical value analysis https://lenovopress.lenovo.com/lp1852-configuring-amd-xgmi-links-on-thinksystem-sr665-v3#theoretical-value-analysis
Также рекомендую прочитать https://www.amd.com/content/dam/amd/en/documents/products/epyc/4th-gen-epyc-processor-architecture-white-paper.pdf
там архитектура Infinity Fabric более-менее понятно расписана и тоже приводятся теоретические показатели пропускной способности.
Выше также комментировали (не Вы, а SlavikF) некие 200 гигабайт и 30 гигабайт, не понимаю откуда числа. Но давайте просто проверим теоретические расчеты тестами, какая пропускная способность будет на Epyc 4 поколения:
https://gist.github.com/nsforth/50e87a9769dba93f897e194459857e24
Что получили - 700 гигабайт в секунду на оба сокета, 340 на один, 147 в одну сторону между numa 0-1 и 147 в другую между numa 1-0.
Итого: каждый процессор в numa interleaving может получать до 340 гигабайт в секунду в сумме (своя память + память соседа по numa), а оба примерно 700 гигабайт.