--- title: "Сколько зрителей выдержит сервер на 10 Гбит/с? Расчёт" description: "Около 1 000 зрителей при 1080p, 470 — в 4K или 62 500 — только аудио при загрузке порта 10 Гбит/с на 80%: формула, месячный трафик, стоимость CDN и схема с edge-узлами." url: "https://powerdedi.com/blog/streaming-server-viewers-per-10gbps" last_updated: "2026-10-15" publisher: "PowerDedi (https://powerdedi.com)" --- # Сколько зрителей выдержит стриминговый сервер с портом 10 Гбит/с? Зрители = полезная пропускная способность ÷ битрейт. Число зрителей от 4K до аудио на порту 10 Гбит/с, месячный трафик и цены CDN, пресеты x264 против NVENC, Owncast, MediaMTX, SRS и nginx-rtmp, HLS и LL-HLS, а также схема «источник + edge-серверы». Инженеры PowerDedi · 15 октября 2026 г. · 10 мин чтения **Поделиться статьёй** Сервер на 10 Гбит/с при безопасной загрузке 80%, то есть 8 Гбит/с, может одновременно обслуживать около 1 000 зрителей потока 1080p с битрейтом 7,8 Мбит/с, 1 700 — при 720p, 470 — в 4K и 62 500 слушателей только аудио. Формула: зрители = полезная пропускная способность ÷ битрейт на зрителя, поэтому выбранный битрейт важнее, чем оборудование. ## Коротко: сколько зрителей на 8 Гбит/с Восемьдесят процентов порта 10 Гбит/с; каждый зритель получает один вариант видеопотока плюс стереозвук AAC 128 кбит/с: | Поток | Битрейт видео | Источник битрейта | На зрителя, с аудио | Зрителей одновременно | | --- | --- | --- | --- | --- | | 4K (2160p), 30 кадр/с, HEVC | 16,8 Мбит/с | Лестница битрейтов HLS от Apple, верхний уровень 4K | 16,93 Мбит/с | 472 | | 1080p60, H.264, ретрансляция без транскодирования | 17 Мбит/с | Битрейт входящего потока, рекомендуемый YouTube | 17,13 Мбит/с | 467 | | 1080p, H.264 | 7,8 Мбит/с | Apple, верхний уровень 1080p | 7,93 Мбит/с | 1 009 | | 1080p, H.264 | 6,0 Мбит/с | Apple, нижний уровень 1080p | 6,13 Мбит/с | 1 305 | | 720p, H.264 | 4,5 Мбит/с | Apple, верхний уровень 720p | 4,63 Мбит/с | 1 728 | | Класс 480p (768 × 432), H.264 | 1,1 Мбит/с | Apple | 1,23 Мбит/с | 6 514 | | Только аудио, стерео AAC | — | Рекомендация YouTube для стереозвука | 0,128 Мбит/с | 62 500 | Цифры Apple — это средние битрейты из её спецификации по подготовке HLS-контента. На уровнях H.264 начиная с 540p сохраняется исходная частота кадров, поэтому трансляция с частотой 60 кадр/с остаётся на 60 кадр/с; цифры для HEVC приведены для 30 кадр/с. Цифры YouTube — это то, что он просит отправлять ему энкодеры, а не то, что он отдаёт зрителям: они показывают, что происходит, когда сервер ретранслирует поток энкодера без изменений. Если пропускать поток 1080p60 как есть, с битрейтом 17 Мбит/с, аудитория сокращается более чем вдвое по сравнению с транскодированием в 7,8 Мбит/с. ## Сколько зрителей выдержит сервер на 10 Гбит/с? Зрители = полезная пропускная способность ÷ битрейт на зрителя. Ответ определяют три параметра: - **Полезная пропускная способность.** Рассчитывайте примерно на 80% порта. Энкодеры превышают заданный битрейт: спецификация Apple допускает, что измеренный пиковый битрейт прямой трансляции достигает 125% от заявленного, а среднее значение за час — 110% от заявленного среднего. Сверх этого добавляются накладные расходы TCP/IP и HTTP. - **Битрейт на зрителя.** Видео плюс аудио. YouTube рекомендует 128 кбит/с для стереозвука; у Apple диапазон для стерео AAC — от 32 до 160 кбит/с. - **Какой вариант потока смотрят зрители.** При адаптивном битрейте телефоны и медленные подключения выбирают нижние уровни, поэтому реальное среднее значение ниже верхнего уровня. Расчёт по верхнему уровню — безопасное допущение. Порт — это лишь половина пути. Каждому зрителю этот битрейт нужен на всём пути до экрана, а в любой сети аплинки за портом сервера общие. Перед крупной трансляцией проверьте реальные маршруты с помощью нашего [руководства по тестированию скорости сети](https://powerdedi.com/ru/docs/network-speed-test). ## Пропускная способность для 1 000 зрителей Умножьте битрейт на зрителя на 1 000: около 17 Гбит/с в 4K, 7,9 Гбит/с при 1080p с видео 7,8 Мбит/с, 4,6 Гбит/с при 720p, 1,2 Гбит/с при качестве класса 480p и 0,13 Гбит/с только для аудио. Тысяча зрителей 1080p загружает один порт 10 Гбит/с до отметки 80%; той же аудитории в 4K нужны три сервера. ## Месячный трафик и сколько за него возьмёт CDN Один зритель, который в течение часа смотрит поток 1 Мбит/с, потребляет 0,45 ГБ трафика: 1 Мбит/с × 3 600 с ÷ 8 бит в байте. Следовательно, месячный трафик = одновременные зрители × Мбит/с на зрителя × часы в день × 30 × 0,45 ГБ. Для 1 000 зрителей потока 7,93 Мбит/с по четыре часа в день: 1 000 × 7,93 × 4 × 30 × 0,45 = 428 000 ГБ, около 428 ТБ. | Аудитория | Пик | За 30-дневный месяц | Amazon CloudFront | bunny.net Standard, Европа и Северная Америка | bunny.net Volume | | --- | --- | --- | --- | --- | --- | | 200 зрителей, 720p (4,63 Мбит/с), 3 ч в день | 0,9 Гбит/с | 37,5 ТБ | около $3 050 | около $375 | около $190 | | 1 000 зрителей, 1080p (7,93 Мбит/с), 4 ч в день | 7,9 Гбит/с | 428 ТБ | около $21 300 | около $4 280 | около $2 140 | | 3 000 зрителей, 720p (4,63 Мбит/с), 4 ч в день | 13,9 Гбит/с | 750 ТБ | около $31 800 | около $7 500 | около $3 500 | | 1 000 зрителей, 1080p (6,13 Мбит/с), 24 ч в день | 6,1 Гбит/с | 1 986 ТБ | около $64 100 | около $19 900 | около $6 470 | | 5 000 слушателей, аудио (128 кбит/с), 24 ч в день | 0,6 Гбит/с | 207 ТБ | около $12 400 | около $2 070 | около $1 040 | Цены по прайс-листу на октябрь 2026 г., без налогов и платы за запросы, из расчёта 1 ТБ = 1 000 ГБ. Amazon CloudFront берёт $0,085 за ГБ за первые 10 ТБ в месяц в США и Европе, далее цена по ступеням снижается до $0,04 в диапазоне от 150 до 500 ТБ и до $0,02 — свыше 5 ПБ. bunny.net в сети Standard берёт $0,01 за ГБ в Европе и Северной Америке ($0,03 — в Азии и Океании), а в сети Volume с 10 точками присутствия — $0,005 за ГБ за первые 500 ТБ, $0,004 — до 1 ПБ и $0,002 — до 2 ПБ. ## Origin-сервер и edge-узлы в нескольких городах При собственной доставке работа распределяется между серверами. Один **origin-сервер** принимает поток от энкодера по SRT или RTMP, транскодирует его в лестницу битрейтов и упаковывает в HLS. **Edge-узлы** в городах, где находятся ваши зрители, забирают каждый сегмент один раз и отдают его много раз. В документации SRS приведён расчёт: поток 1 Мбит/с для 1 000 зрителей, раздаваемый через edge-узлы NGINX, даёт 1 Гбит/с нагрузки на edge-узлы и лишь 1 Мбит/с на origin-сервер, а десяти edge-узлов по 10 Гбит/с каждый хватает для 100 000 зрителей при таком битрейте. Наши серверы работают в Амстердаме, Франкфурте, Лондоне, Париже, Цюрихе, Нью-Йорке, Майами, Лос-Анджелесе, Сингапуре и Токио, и у каждого — собственный порт 10 Гбит/с без учёта трафика, поэтому edge-узел стоит одинаково, передаёт ли он 5 ТБ или 2 ПБ в месяц. При загрузке 80% один edge-узел обслуживает около 1 000 зрителей при 7,9 Мбит/с. В приведённом выше примере с 1 000 зрителями по четыре часа в день даже по тарифу сети Volume у bunny.net одна только доставка обходится примерно в $2 140 в месяц, тогда как origin-сервер за $159 и два edge-узла по $55 каждый стоят лишь малую долю этой суммы. Наш [обзор цен на 10 Гбит/с без учёта трафика](https://powerdedi.com/ru/blog/unmetered-bandwidth-survey-2026) и руководство о том, [как тарифицируется канал](https://powerdedi.com/ru/blog/unmetered-vs-95th-percentile-bandwidth-billing), объясняют, почему фиксированная плата за порт меняет расчёт. В некоторых случаях CDN всё же выигрывает: - **Аудитория, рассеянная по всему миру.** Одна только сеть Standard у bunny.net насчитывает 119 точек присутствия — против наших десяти городов. - **Непредсказуемые всплески,** намного превышающие вашу обычную аудиторию. CDN их поглощает, а ваши собственные edge-узлы упираются в свои порты. - **Некому обслуживать серверы.** Edge-узлы — это простые кэши, но кто-то должен устанавливать на них обновления, следить за ними и добавлять новые. Можно и совмещать оба подхода: собственные edge-узлы — для постоянной аудитории, CDN — для пиковых излишков. ## Транскодирование: пресеты x264 и x265 или NVENC Транскодирование превращает один поток с высоким битрейтом в лестницу битрейтов, которая действительно нужна зрителям. На CPU энкодеры x264 и x265 позволяют выбирать баланс между скоростью и степенью сжатия с помощью пресетов — от самого быстрого к самому медленному: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow и placebo. Заголовочный файл самого x264 предупреждает, что «скорость этих пресетов различается кардинально»: ultrafast быстрее placebo в целых 100 раз. Кодирование прямой трансляции должно успевать за реальным временем на каждой ступени лестницы, поэтому для него используют быстрые пресеты; в собственном примере перекодирования от MediaMTX используется `-preset ultrafast`. Режим tune `zerolatency` в x265 идёт ещё дальше: он отключает B-кадры, lookahead и параллельную обработку кадров, чтобы сократить задержку энкодера. Сколько ступеней выдержит 16-ядерный CPU, зависит от пресета, разрешения и частоты кадров, поэтому перед трансляцией проверьте свою лестницу битрейтов на целевом сервере. GPU переносит эту работу на специализированные энкодеры. У RTX PRO 4000 Blackwell два энкодера NVENC девятого поколения, два декодера NVDEC шестого поколения и 24 ГБ памяти GDDR7 с ECC при энергопотреблении не более 145 Вт. В матрице поддержки NVIDIA указаны кодирование в H.264, HEVC и AV1 и «неограниченное» (Unrestricted) число одновременных сессий, тогда как для GPU, не входящих в квалифицированный список NVIDIA, действует лимит в 8 сессий на систему. В документе NVENC Application Note NVIDIA приводит производительность Blackwell в расчёте на один энкодер при 1080p с настройкой на низкую задержку и постоянным битрейтом: | Пресет | H.264 | HEVC | AV1 | Потоки 1080p60 H.264 на двух NVENC | | --- | --- | --- | --- | --- | | P1 (самый быстрый) | 977 кадр/с | 1 134 кадр/с | 1 076 кадр/с | около 32 | | P3 | 718 кадр/с | 529 кадр/с | 798 кадр/с | около 23 | | P5 | 323 кадр/с | 506 кадр/с | 624 кадр/с | около 10 | | P7 (самый медленный) | 264 кадр/с | 464 кадр/с | 395 кадр/с | около 8 | NVIDIA получила эти значения с Video Codec SDK 13.0 и указывает, что драйвер распределяет сессии между энкодерами чипа, поэтому с двумя NVENC эти цифры примерно удваиваются; это результаты бенчмарков NVIDIA, а не замеры на наших серверах. Лестнице нужна не только верхняя ступень: 720p, 540p, 432p и 234p вместе добавляют около 90% к числу пикселей кадра 1080p, поэтому закладывайте примерно два кодирования 1080p на канал, если считать, что производительность пропорциональна числу пикселей. По такой оценке одна карта выдерживает около пяти каналов с 60 кадр/с на пресете P5 и больше — на более быстрых пресетах. ## Owncast, MediaMTX, SRS и nginx-rtmp | Стек | Лицензия и последний выпуск | Что делает | Горизонтальное масштабирование | | --- | --- | --- | --- | | Owncast | MIT; v0.3.0, 3 сентября 2026 г. | «Однопользовательский сервер для прямых видеотрансляций и чата»; транскодирует через FFmpeg на CPU или с помощью NVENC, VA-API или Quick Sync либо пропускает видео без изменений | Может записывать сегменты HLS в S3-совместимое объектное хранилище, «чтобы разгрузить канал» | | MediaMTX | MIT; v1.21.2, 8 октября 2026 г. | Медиамаршрутизатор: SRT, WebRTC, RTSP, RTMP и LL-HLS на входе и на выходе; перекодирование через FFmpeg | Реплики для чтения за балансировщиком нагрузки, с привязкой сессий (sticky sessions) для HLS | | SRS | MIT; v6.0-r2, 24 сентября 2026 г. | Origin- и edge-сервер для RTMP, HLS и HTTP-FLV | Кэширующие edge-узлы на NGINX для HLS | | nginx-rtmp-module | BSD-2-Clause; последний коммит — в декабре 2024 г. | RTMP в HLS или DASH внутри NGINX; транскодирование путём запуска FFmpeg через `exec` | Передача RTMP между серверами в режимах push и pull | Аппаратному кодированию в Owncast нужен прямой доступ к GPU, что, согласно документации, исключено на общем VPS; выделенный GPU-сервер этому условию отвечает. Бакет объектного хранилища должен быть публичным, и в нём всегда хранятся только последние несколько минут трансляции. В документации MediaMTX отмечается, что без перекодирования — а именно так MediaMTX и работает — узким местом почти всегда оказывается пропускная способность между сервером и зрителями. Приведённые ниже примеры конфигурации взяты из документации соответствующих проектов. В README nginx-rtmp RTMP-приложение превращается в HLS тремя директивами: ```nginx rtmp { server { listen 1935; application hls { live on; hls on; hls_path /tmp/hls; } } } ``` MediaMTX по умолчанию отдаёт LL-HLS. Ниже — соответствующие строки из его стандартного `mediamtx.yml`; в комментариях к ним отмечено, что для корректной работы LL-HLS на устройствах Apple требуется HTTPS: ```yaml hls: true hlsAddress: :8888 hlsVariant: lowLatency hlsSegmentCount: 7 hlsSegmentDuration: 1s hlsPartDuration: 200ms ``` Реплика MediaMTX для чтения в другом городе по запросу забирает с origin-сервера каждый путь (path): ```yaml paths: "~^(.+)$": source: rtsp://dns-of-origin:8554/$G1 sourceOnDemand: yes ``` Для стандартного HLS руководство SRS по кластерам использует NGINX в качестве кэширующего edge-узла, который хранит плейлисты 10 секунд, а сегменты — 60 минут. На edge-узле в другом городе направьте `proxy_pass` на ваш origin-сервер вместо 127.0.0.1: ```nginx proxy_cache_path /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m; proxy_temp_path /tmp/nginx-cache/tmp; server { listen 80; server_name your.domain.com; proxy_cache_valid 404 10s; proxy_cache_lock on; proxy_cache_lock_age 300s; proxy_cache_lock_timeout 300s; proxy_cache_min_uses 1; location ~ /.+/.*\.(m3u8)$ { proxy_pass http://127.0.0.1:8080$request_uri; proxy_cache srs_cache; proxy_cache_key $scheme$proxy_host$uri$args; proxy_cache_valid 200 302 10s; } location ~ /.+/.*\.(ts)$ { proxy_pass http://127.0.0.1:8080$request_uri; proxy_cache srs_cache; proxy_cache_key $scheme$proxy_host$uri; proxy_cache_valid 200 302 60m; } } ``` ## HLS и LL-HLS вкратце HLS разбивает поток на короткие медиасегменты, перечисленные в плейлистах, и всё это загружается по обычному HTTP — поэтому такой поток могут отдавать обычные веб-кэши. Спецификация Apple по подготовке контента требует ключевой кадр каждые две секунды, целевую длительность сегмента 6 с и вариант по умолчанию на 2 000 кбит/с; YouTube тоже рекомендует интервал между ключевыми кадрами 2 с и не более 4 с. Как отмечено в конфигурации MediaMTX, плееры обычно буферизуют около трёх сегментов перед началом воспроизведения, поэтому при 6-секундных сегментах зрители заметно отстают от прямого эфира. Low-Latency HLS добавляет частичные сегменты (в примере Apple — длительностью 200 мс), дельта-обновления плейлистов, блокирующую перезагрузку плейлистов, подсказки предзагрузки (preload hints) и отчёты о вариантах (rendition reports). По словам Apple, это снижает задержку в публичных сетях «до уровня обычного телевизионного вещания». Загвоздка — в цепочке доставки: каждый промежуточный узел должен удерживать блокирующие запросы плейлистов и отвечать на них по мере появления новых частей, а кэш, который хранит плейлисты 10 секунд, как в примере с NGINX выше, сводит весь смысл на нет. Пропускайте стандартный HLS через простые кэши, а LL-HLS на всём пути доставки обслуживайте ПО, которое его реализует, например MediaMTX. ## Масштабируемая схема: origin-сервер, edge-узлы и GPU - **Origin-сервер и упаковщик:** [Ryzen 9 9950X](https://powerdedi.com/ru/dedicated-servers/amd-ryzen/ryzen-9-9950x) за $159 в месяц с 16 ядрами Zen 5, 128 ГБ DDR5 и двумя NVMe-накопителями по 1,92 ТБ — для приёма потока, упаковки в HLS и работы лестницы битрейтов на CPU, производительность которой вы измерили. Выдаётся примерно за 15 минут в Амстердаме, Франкфурте, Лондоне, Нью-Йорке, Майами, Лос-Анджелесе, Сингапуре и Токио. - **Edge-узлы:** [Ryzen 5 7600](https://powerdedi.com/ru/dedicated-servers/amd-ryzen/ryzen-5-7600) за $55 в месяц с 6 ядрами, 32 ГБ памяти и двумя NVMe-накопителями по 512 ГБ. Кэш, который не перекодирует видео, упирается в порт, а не в процессор. Этот сервер доступен в восьми из десяти наших городов; в Токио используйте Ryzen 9 9950X, а в Цюрихе — Xeon E-2488 за $95. - **Транскодирование:** [сервер с RTX PRO 4000 Blackwell](https://powerdedi.com/ru/dedicated-servers/gpu/rtx-pro-4000-blackwell) за $169 в месяц, который собирается в течение 24 часов в Амстердаме, Франкфурте или Нью-Йорке, — когда у вас несколько каналов, 4K, HEVC или AV1. В каждый сервер входят [порт 10 Гбит/с без учёта трафика](https://powerdedi.com/ru/network/10gbps-unmetered) и постоянно включённая защита от DDoS, поэтому счёт за edge-узел не меняется вместе с аудиторией. Другие схемы для прямых трансляций и видео по запросу — на нашей [странице о стриминге и CDN](https://powerdedi.com/ru/solutions/streaming-cdn). Это руководство предполагает, что вы транслируете собственный контент или мероприятия, на трансляцию которых у вас есть права. ## Источники - [Выбор настроек энкодера, битрейта и разрешения для трансляций](https://support.google.com/youtube/answer/2853702?hl=en) — Справка YouTube - [Спецификация по подготовке HTTP Live Streaming (HLS) для устройств Apple](https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices) — Apple Developer - [Включение Low-Latency HTTP Live Streaming (HLS)](https://developer.apple.com/documentation/http-live-streaming/enabling-low-latency-http-live-streaming-hls) — Apple Developer - [Прайс-лист AWS: Amazon CloudFront](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonCloudFront/current/index.json) — Amazon Web Services, опубликован 3 октября 2026 г. - [Цены на CDN](https://bunny.net/pricing/cdn/) — bunny.net, проверено в октябре 2026 г. - [RTX PRO 4000 Blackwell](https://www.nvidia.com/en-us/products/workstations/professional-desktop-gpus/rtx-pro-4000/) — NVIDIA; [Матрица поддержки кодирования и декодирования видео](https://developer.nvidia.com/video-encode-decode-support-matrix) — NVIDIA Developer - [NVENC Application Note](https://docs.nvidia.com/video-technologies/video-codec-sdk/13.0/nvenc-application-note/index.html) — NVIDIA Video Codec SDK 13.0 - [x264.h](https://code.videolan.org/videolan/x264/-/blob/master/x264.h) — VideoLAN x264; [Параметры пресетов](https://x265.readthedocs.io/en/master/presets.html) — документация x265 - [owncast/owncast](https://github.com/owncast/owncast), [Аппаратное ускорение кодирования и кодеки](https://owncast.online/docs/codecs/), [Выбор правильных настроек качества видео](https://owncast.online/docs/video/) и [Использование объектного хранилища для экономии трафика](https://owncast.online/docs/storage/) — Owncast - [bluenviron/mediamtx](https://github.com/bluenviron/mediamtx), [mediamtx.yml](https://github.com/bluenviron/mediamtx/blob/main/mediamtx.yml), [Масштабируемость](https://github.com/bluenviron/mediamtx/blob/main/docs/2-features/19-scalability.md) и [Перекодирование](https://github.com/bluenviron/mediamtx/blob/main/docs/2-features/07-remuxing-reencoding-compression.md) — MediaMTX - [Кластер HLS](https://ossrs.io/lts/en-us/docs/v6/doc/nginx-for-hls) — документация SRS; [ossrs/srs](https://github.com/ossrs/srs) — GitHub - [arut/nginx-rtmp-module](https://github.com/arut/nginx-rtmp-module) — GitHub **Поделиться статьёй** Инженерная команда PowerDedi Команда, которая собирает, устанавливает в стойки и обслуживает каждый сервер PowerDedi. Мы пишем о железе, сетях и затратах, с которыми работаем каждый день, и указываем источники. **Выделенные серверы** от $55/мес Примерно на 40% ниже рынка, безлимитный порт 10 Гбит/с на каждом сервере. Оплата криптовалютой. [Все серверы](https://powerdedi.com/ru/dedicated-servers) **Ещё в блоге** - [Руководства](https://powerdedi.com/ru/blog/ton-node-requirements) 21 октября 2026 г. **Требования к ноде TON в 2026 году: полная нода, лайт-сервер, валидатор** - [Сравнения](https://powerdedi.com/ru/blog/crypto-dedicated-server-providers-compared) 15 октября 2026 г. **Выделенные серверы за криптовалюту: сравнение 14 провайдеров (октябрь 2026 г.)** - [Сравнения](https://powerdedi.com/ru/blog/hetzner-alternatives-2026) 15 октября 2026 г. **Альтернативы Hetzner в 2026 году: оплата криптовалютой, 10 Гбит/с, без платы за подключение** - [Сравнения](https://powerdedi.com/ru/blog/ovhcloud-alternatives-2026) 15 октября 2026 г. **Принимает ли OVHcloud криптовалюту? Альтернативы OVHcloud в 2026 году** ## Похожие статьи [Все статьи](https://powerdedi.com/ru/blog) [Руководства](https://powerdedi.com/ru/blog/category/guides) 15 октября 2026 г. ### [Альтернативы MinIO в 2026 году: собственный S3 после архивации репозитория](https://powerdedi.com/ru/blog/minio-alternatives-self-hosted-s3) Репозиторий minio/minio доступен только для чтения с 25 апреля 2026 года. Сравниваем форк Silo, Garage, SeaweedFS, RustFS и Ceph RGW по лицензии, избыточности и поддержке S3, рассчитываем их на одном сервере хранения, считаем стоимость облачных альтернатив и переносим данные с помощью rclone. 12 мин чтения [Руководства](https://powerdedi.com/ru/blog/category/guides) 15 октября 2026 г. ### [Порт без учёта трафика, 95-й перцентиль или оплата за ТБ: как тарифицируется канал сервера](https://powerdedi.com/ru/blog/unmetered-vs-95th-percentile-bandwidth-billing) Порты без учёта трафика, тарификация по 95-му перцентилю, квоты с оплатой за каждый терабайт сверх них и плата за исходящий трафик в облаке: как каждая модель учитывает ваш трафик, сколько она стоит при 50 ТБ, 200 ТБ и 1 ПБ в месяц и какие вопросы задать до подписания договора. 6 мин чтения [Рынок](https://powerdedi.com/ru/blog/category/market) 22 сентября 2026 г. ### [Сколько на самом деле стоит порт 10 Гбит/с без учёта трафика в 2026 году](https://powerdedi.com/ru/blog/unmetered-bandwidth-survey-2026) У 19 провайдеров, которые его продают, порт 10 Гбит/с без учёта трафика добавляет к цене около $630 в месяц (медиана). Что вы за это получаете, как тарифицируются альтернативы, сколько стоит исходящий трафик в облаке и как проверить порт. 6 мин чтения ## До вашего следующего сервера — 15 минут. От $55/мес: 10 Гбит/с без учёта трафика, без платы за подключение и без договора. [Все серверы](https://powerdedi.com/ru/dedicated-servers) [Все статьи](https://powerdedi.com/ru/blog) Запуск за ~15 мин · Отмена в любой момент · BTC, ETH, XMR, USDT или SOL --- PowerDedi — Dedicated servers with 10 Gbps unmetered, paid in crypto. Page: https://powerdedi.com/blog/streaming-server-viewers-per-10gbps. Index of the site for AI assistants: https://powerdedi.com/llms.txt