Мой блог
Как устроена инфраструктура LLM: анатомия серверного железа
Подробности изложены в материале первоисточника. Когда я проектирую запуск современных больших языковых моделей, то сразу отхожу от простых арифметических задач деления размера модели на объем видеопамяти одной карты. Запуск сервиса для единственного тестировщика сильно отличается от реальной эксплуатации, куда приходят пользователи с огромными документами и постоянным потоком запросов.
В своей практике я учитываю, что сама модель — лишь один из жильцов GPU. Рядом с ней функционирует объемный KV-кеш каждого диалога, задействованы высокоскоростные сети между серверами, центральные процессоры для распределения задач и емкие дисковые накопители. В этой статье я подробно разберу всю аппаратную анатомию современной AI-инфраструктуры, опираясь на свежие данные и технические стандарты индустрии. Больше деталей об архитектуре систем можно изучить в оригинальной публикации на Хабре.
Считаем память на пальцах
При формате BF16 каждый отдельный параметр нейросети требует ровно два байта. Соответственно, для модели на 70 миллиардов параметров нужны 140 гигабайт чистой памяти только под веса. На рынке уже представлены или готовятся к выходу мощные ускорители с разным объемом HBM-памяти: NVIDIA H100 предлагает 80 ГБ с пропускной способностью 3,35 ТБ/с, H200 дает 141 ГБ на 4,8 ТБ/с, а передовые решения вроде NVIDIA B200, B300, AMD MI355X и архитектуры Rubin оснащаются 288 ГБ памяти HBM3e или HBM4 со скоростью от 8 до 22 ТБ/с.
Подобный расчет дает лишь базовое представление, ведь движку инференса и системным буферам тоже требуются ресурсы. Однако реальная нагрузка возрастает с появлением пользователей. Для предотвращения постоянного пересчитывания диалога модель сохраняет ключи и значения для каждого обработанного токена. Такой KV-кеш рассчитывается исходя из архитектуры: у Llama 3.1 70B насчитывается 80 слоев, 8 голов для ключей и значений при размерности 128. На один токен уходит около 320 килобайт памяти.
Треть мегабайта кажется незначительной цифрой, но полноценный диалог на 128 тысяч токенов занимает порядка 43 ГБ. Десять пользователей с документами по 32 тысячи токенов задействуют около 107 ГБ — три четверти от объема самих весов. Если веса занимают фиксированное пространство, то кеш стремительно растет с каждым новым клиентом, полностью исчерпывая доступную емкость под нагрузкой.
Один ответ, две разные нагрузки
В процессе генерации ответов графический процессор функционирует в двух принципиально разных режимах. На этапе prefill модель единовременно обрабатывает весь входящий запрос и формирует стартовый KV-кеш. Здесь нагрузка на вычисления максимальна, но она отлично поддается параллелизации. Затем наступает фаза decode, когда токен за каждый шаг выдается последовательно. Каждый новый элемент опирается на предыдущие, поэтому объем вычислений падает, а узким местом становится чтение весов и накопленного кеша из памяти.
Из-за этого сервис может тормозить по-разному. Долгий вывод первого слова указывает на очередь и тяжелый prefill. Если же первая часть текста появляется мгновенно, но дальше строка ползет медленно, значит, система уперлась в ограничения decode и пропускную способность памяти. В тестах MLCommons эти задержки разделяют на TTFT и TPOT.
Режимы способны конфликтовать друг с другом. Поступление нового запроса с объемным файлом запускает prefill, который на мгновение замирает у всех остальных клиентов, ожидающих ответ. В передовых системах эти задачи стараются разносить по разным GPU, хотя это требует постоянной перегонки KV-кеша через сетевые интерфейсы.
Делим модель: внутри сервера и между серверами
Если веса превышают емкость одного ускорителя, применяется разделение. При tensor parallelism слои распределяются между картами, которые постоянно обмениваются промежуточными результатами матрицы. При pipeline parallelism выстраивается конвейер, где первая карта обрабатывает начальные слои, а следующая продолжает цепочку. Если же модель целиком помещается на один ускоритель, для масштабирования сервиса создают независимые копии на каждой карте под разные запросы.
Tensor parallelism предъявляет колоссальные требования к скорости сети из-за сотен синхронизаций на каждый токен. Внутри сервера чипы связываются через шину NVLink, обеспечивающую у H100 суммарные 900 ГБ/с. Между серверами обмен идет через сетевые адаптеры вроде InfiniBand на 400 Гбит/с, что дает около 50 ГБ/с в каждую сторону — разница достигает девятикратных значений.
На практике реальные показатели пропускной способности оказываются ниже спецификаций. В кластерах DeepSeek V3 на базе H800 зафиксированы показатели 160 ГБ/с по NVLink против 50 ГБ/с по InfiniBand. С новыми поколениями чипов разрыв сохраняется: архитектура Rubin через NVLink 6 выдает 3,6 ТБ/с на чип, а адаптеры ConnectX-9 обеспечивают 200 ГБ/с.
Чтобы обойти физические ограничения межсетевых соединений, компания NVIDIA внедрила концепцию масштабирования шины NVLink на всю стойку в системах вроде GB200 NVL72 и Vera Rubin NVL72. Семьдесят два ускорителя в таких стойках связаны между собой так же плотно, как и набор чипов в едином сервере, отодвигая узкие места медленной сетевой инфраструктуры.
MoE: память как у гиганта, вычисления как у середнячка
Многие современные открытые модели перешли на архитектуру Mixture of Experts. Внутри таких систем функционирует множество специализированных экспертных блоков, из которых для каждого токена активируется лишь малая доля. Например, DeepSeek-V3 насчитывает 671 миллиард параметров, но на один токен задействует только 37 миллиардов.
Для инфраструктуры это создает специфический дисбаланс: вычислительные мощности требуются как для небольшой модели, но хранить в памяти необходимо все 671 млрд параметров, так как заранее предсказать выбор эксперта невозможно. Эксперты распределяются по разным картам с помощью expert parallelism, из-за чего сеть начинает играть ключевую роль в постоянной пересылке токенов.
Для оценки таких моделей недостаточно одной цифры. Общий объем параметров определяет требования к видеопамяти, а количество активных параметров показывает реальную скорость генерации ответа. В продакшене для потоковой обработки запросов крупным сервисам требуются десятки узлов и сотни графических процессоров.
Зачем серверу с GPU процессор, RAM и NVMe
Анализируя архитектуру стандартных серверных комплексов вроде DGX H100, легко заметить мощную сопутствующую обвязку: два многоядерных процессора Xeon, два терабайта оперативной памяти и массив накопителей NVMe емкостью почти 31 терабайт. Системной памяти здесь в три с лишним раза больше, чем графической.
Центральный процессор берет на себя рутину: принимает внешние запросы, токенизирует текст, управляет очередями и своевременно подкармливает ускорители данными. Отставание CPU приводит к банальному простаиванию дорогостоящих GPU. Накопители NVMe задействуются не только для первоначальной быстрой загрузки весов, но и для разгрузки переполненного KV-кеша.
Когда пользователь возвращается к давнему диалогу или множество клиентов обращаются к одинаковому документу, поднимать кеш из системной RAM или локального NVMe-диска гораздо эффективнее, чем заново запускать ресурсоемкий этап prefill. Современные программные платформы и аппаратные решения активно развивают системы кэширования для оптимизации нагрузки на дата-центры.
