Согласно отчёту NETINT «2026 State of Video Encoding Report», в котором опрошены 286 специалистов по видеокодированию, выбор серверного оборудования для видеостриминга в 2026 году сводится к трём решениям: кодек, аппаратная платформа и бюджет. При этом 91% компаний уже используют видео в своих продуктах и коммуникациях, по данным Rocketium, «Video marketing statistics 2026». Именно поэтому требования к серверному оборудованию для видеостриминга перестали быть узкой задачей медиакомпаний. В этом материале команда COSMONOVA разбирает, какие параметры действительно определяют, сколько зрителей выдержит ваша инфраструктура и где чаще всего ошибаются при подборе конфигурации.
Обзор требований к серверному оборудованию для видеостриминга стоит начинать не с железа, а с нагрузки. Живой поток, видео по запросу и транскодирование в реальном времени предъявляют к серверу разные требования. Одна и та же конфигурация, идеальная для раздачи готового файла, провалится на перекодировании четырёх потоков 4K одновременно.
Процессор и вычислительная мощность
Процессор определяет, сколько одновременных сессий и транскодирований выдержит сервер без падения качества. Для простой раздачи контента через HTTP достаточно 8–16 ядер: узкое место смещается в сеть, а не в CPU. Для транскодирования в реальном времени счёт идёт на десятки ядер, и здесь CPU уступает специализированным ускорителям.
Ключевая метрика — не тактовая частота, а пропускная способность на ватт и на ядро. При планировании закладывайте запас 30–40%: пиковые нагрузки на прямых трансляциях приходят волнами.
Оперативная память и дисковая подсистема
Оперативная память влияет на число параллельных потоков, дисковая подсистема — на задержку старта и стоимость хранения. Практическое правило: 2–4 ГБ RAM на каждый активный поток транскодирования и 1–2 ГБ на раздачу.
Для дисковой подсистемы критичны два параметра: IOPS и пропускная способность. NVMe нужен для кэша сегментов и записи эфира, ёмкие HDD или объектное хранилище — для архива. Объём хранилища для видео быстро растёт: час 4K-контента занимает десятки гигабайт ещё до упаковки.
Сервер для транскодирования видео: GPU, VPU или CPU
Сервер для транскодирования видео в 2026 году почти всегда строится вокруг аппаратного ускорителя. Использование только CPU остаётся вариантом для небольших объёмов и нестандартных кодеков, где важнее гибкость, а не плотность потоков.
На практике используются три подхода:
-
Транскодирование на CPU. Максимальная совместимость, минимум зависимостей, но низкая плотность потоков и высокое энергопотребление на поток.
-
GPU. Гибкость в работе с кодеками и фильтрами, подходит для сложной обработки, но дороже в расчёте на поток и требует места в серверной стойке.
-
VPU (Video Processing Units). Специализированные чипы для кодирования: более высокая плотность потоков на ватт и меньшая стоимость на поток при массовом кодировании.
Аппаратное ускорение и выбор кодека
Аппаратное ускорение окупается только при правильном выборе кодека. H.264 остаётся универсальным стандартом совместимости, но HEVC и AV1 обеспечивают заметно меньший битрейт при том же качестве.
Компромисс прост: AV1 экономит трафик, но требует современных ускорителей и совместимых проигрывателей у аудитории. Если зрители используют мобильные устройства разных поколений, оставьте H.264 базовым профилем и добавьте HEVC или AV1 в качестве второго потока для совместимых устройств.
Совет профессионала
На практике выгоднее сразу кодировать видео в двух-трёх вариантах качества, чем гнаться за одним «идеальным» кодеком. Разные сети и устройства получают подходящий профиль, а вы не теряете зрителей со старыми телефонами.
Расчёт пропускной способности для видеостриминга
Расчёт пропускной способности для видеостриминга строится по формуле: битрейт потока × число одновременных зрителей × коэффициент запаса. Для 5 000 зрителей на потоке 4 Мбит/с это 20 Гбит/с исходящего трафика. Такой канал нужен постоянно, а не только в пиковые моменты.
Формула выглядит так:
Требуемая полоса = (битрейт × количество зрителей) × 1,3
Коэффициент 1,3 учитывает служебный трафик, повторные передачи и неравномерность нагрузки. Считать нужно исходящий трафик (egress), поскольку именно он формирует основную статью расходов, как отмечает Forasoft в материале «Video Streaming Server Cost: The 2026 Four-Line Model».
Сколько зрителей выдержит канал
Количество зрителей, которое выдержит канал, зависит от битрейта, а не от числа «слотов» на сервере. Канал 10 Гбит/с может обслуживать примерно 2 500 зрителей при 4 Мбит/с или 1 250 зрителей при 8 Мбит/с.
| Пропускная способность канала | Битрейт 2 Мбит/с | Битрейт 4 Мбит/с | Битрейт 8 Мбит/с |
|---|---|---|---|
| 1 Гбит/с | ~500 зрителей | ~250 зрителей | ~125 зрителей |
| 10 Гбит/с | ~5 000 зрителей | ~2 500 зрителей | ~1 250 зрителей |
| 40 Гбит/с | ~20 000 зрителей | ~10 000 зрителей | ~5 000 зрителей |
Цифры приведены без коэффициента запаса. При реальном планировании вычитайте 30% на служебный трафик и резерв.
Протоколы HLS и MPEG-DASH: что это значит для сервера
Протоколы HLS и MPEG-DASH определяют, как сервер нарезает видео на сегменты и передаёт их клиенту. HLS использует сегменты в контейнере TS или fMP4 и список воспроизведения m3u8, а MPEG-DASH работает с XML-манифестом и чаще применяется в браузерах через MSE.
Для серверной части разница практическая. HLS проще кэшировать на CDN, и он нативно поддерживается на мобильных устройствах Apple.
Что протокол требует от сервера на самом деле
Разница между HLS и DASH с точки зрения оборудования заключается не в кодеках, а в профиле запросов:
-
Длина сегмента. HLS с сегментами по 2–6 секунд генерирует больше мелких запросов в секунду, чем DASH с сегментами по 4–10 секунд. Это напрямую влияет на требования к IOPS и кэшу.
-
Манифест. В прямом эфире HLS обновляет m3u8 при каждом сегменте. Сервер должен отдавать его с минимальной задержкой, не полагаясь на кэширование на стороне клиента.
-
Контейнер. fMP4 в HLS и DASH позволяет повторно использовать одни и те же сегменты для обоих протоколов, экономя место и упрощая раздачу по нескольким протоколам.
Практический вывод: если вы поддерживаете оба протокола, храните один набор fMP4-сегментов и формируйте два манифеста. Это снижает нагрузку на хранилище и упрощает кэширование на CDN.
Метрики качества, которые определяют выбор оборудования
Выбор сервера нельзя оценивать без измеримых критериев. Вот параметры, которые напрямую зависят от конфигурации:
| Метрика | Что показывает | На что влияет в оборудовании |
|---|---|---|
| Время до первого кадра (TTFF) | Скорость начала воспроизведения | IOPS кэша, задержка сети, длина сегмента |
| Задержка эфира | Отставание от реального времени | Длина сегмента, скорость транскодирования, буферизация плеера |
| Потеря пакетов | Качество доставки | Пропускная способность канала, резервирование |
| Доступность (uptime) | Стабильность сервиса | Резервирование узлов, балансировка |
| Коэффициент повторной буферизации | Плавность воспроизведения | Запас полосы, адаптивная лестница качества |
Низкая задержка прямого эфира (2–5 секунд) требует коротких сегментов и, как следствие, более мощного узла транскодирования и более быстрого хранилища. Если задержка не критична (VOD, вебинары с допустимым отставанием), можно использовать длинные сегменты и сэкономить на оборудовании.
Начать сегодня →
Как протокол связан с выбором конфигурации
Сервер раздачи должен обрабатывать тысячи небольших запросов в секунду, а не выполнять тяжёлые вычисления. Ошибка новичков — покупать оборудование для транскодирования, когда нужна только раздача.
Обратная ошибка — использовать для транскодирования слабый CPU и надеяться на ускоритель. Ускоритель ускоряет кодирование, но подготовка кадров, нарезка сегментов и упаковка в контейнер ложатся на CPU. Если ядер не хватает, ускоритель простаивает.
Совет профессионала
Начинайте с метрик, а не с оборудования. Определите целевую задержку, допустимый TTFF и уровень доступности, а затем подбирайте сегментацию, протокол и конфигурацию сервера под эти показатели. Так вы не переплатите за мощность, которая не влияет на пользовательский опыт.
Сравнение серверных конфигураций для разных нагрузок
Ниже приведены три типовые конфигурации для разных сценариев. Это ориентир по составу, а не готовый прайс-лист: конкретные модели и стоимость зависят от площадки и объёма.
Изображение: инженер проверяет кабели и оборудование в серверной стойке; холодное освещение дата-центра, на заднем плане ряды серверов.
| Профиль нагрузки | Процессор | Память | Хранилище | Ускоритель |
|---|---|---|---|---|
| Раздача VOD до 1 000 зрителей | 8–16 ядер | 32 ГБ | NVMe-кэш + HDD-архив | Не требуется |
| Прямой эфир до 10 000 зрителей | 16–32 ядра | 64–128 ГБ | NVMe + объектное хранилище | 1–2 GPU или VPU |
| Транскодирование 4K, несколько платформ | 32+ ядра | 128–256 ГБ | Массив NVMe | Несколько VPU |
Для VOD главное — кэш и пропускная способность канала. Для прямого эфира — ускоритель и запас по сети. Для транскодирования на несколько платформ — плотность ускорителей на серверный юнит.
Масштабирование, отказоустойчивость и полная стоимость владения
Полная стоимость владения складывается из четырёх составляющих: исходящий трафик, хранение, вычисления и сопутствующие сервисы. Эта модель, описанная Forasoft, помогает не упустить скрытые расходы: резервные каналы, лицензии, поддержку и резервирование.
Три модели владения: что выбрать под свой профиль
| Модель | Капитальные затраты | Операционные расходы | Когда выгодна | Главный риск |
|---|---|---|---|---|
| Собственное оборудование в колокейшене | Высокие, разовые | Средние: канал, электричество, поддержка | Стабильная круглосуточная нагрузка, чувствительные данные | Простой оборудования и амортизация за 3–5 лет |
| Аренда выделенного сервера | Нет | Предсказуемые, фиксированные | Прямые эфиры с известным графиком | Ограниченная гибкость конфигурации |
| Облако | Нет | Переменные, зависят от трафика | Пиковые нагрузки, нерегулярные трансляции | Исходящий трафик может поглотить бюджет при росте аудитории |
Практическое правило: если исходящий трафик стабильно превышает 10 Гбит/с в сутки, собственная инфраструктура или выделенный сервер почти всегда дешевле облака на горизонте 12–24 месяцев. Если нагрузка волнообразная, облако выигрывает, потому что вы платите только за пиковое использование.
Вертикальное и горизонтальное масштабирование
Вертикальное масштабирование — добавление ядер, памяти и ускорителей в один узел — упирается в физические ограничения стойки и стоимость: топовый CPU с несколькими VPU обходится непропорционально дорого. Горизонтальное масштабирование — множество одинаковых узлов за балансировщиком — обеспечивает линейный рост и естественное резервирование, но требует, чтобы сегменты HLS/DASH были доступны всем узлам через общее хранилище или CDN.
Для раздачи VOD горизонтальное масштабирование — норма: добавляете узел, добавляете пропускную способность. Для транскодирования в реальном времени горизонтальное масштабирование сложнее: нужно распределять потоки между узлами и синхронизировать лестницы качества.
Поведение при отказе: что реально проверять
Отказоустойчивость строится на резервировании N+1 и географическом разнесении узлов. Для медиакомпаний это не роскошь: отказ одного узла во время прямого эфира может стоить репутации.
Проверяйте
