Если вы сразу вспомнили про победы AMD EPYC или Ryzen в CINEBENCH и решили, что, мол, тут всё и так понятно, то не спешите — работа над CG-эффектами и анимацией в реальности не так проста и наличие множества ядер ещё ничего решает. При поддержке московского представительства AMD, дистрибьютора ASBIS и студии CGF мы подготовили материал о тонкостях работы студии и ее опыте пробной эксплуатации новых процессоров AMD EPYC серии 7002, которые студия тестировала, чтобы оценить возможность их дальнейшего использования в серверном парке.

На счету студии сотни работ — от спецэффектов для полнометражных фильмов до коротких рекламных роликов, а также полностью анимационные картины. Однако даже так называемые VFX breakdown, из которых зритель узнаёт, что на экране было настоящим, а что нет, не полностью отражают всю глубину и сложность создания даже нескольких захватывающих секунд видео, на которые в реальности могут уйти часы или даже дни. Обо всех тонкостях и нюансах рассказать не удастся, так как у студии есть свои секреты, но общее представление о процессах получить можно.

Рабочий процесс

Типичный сценарий работы студии над спецэффектами для кинофильма описать непросто, поскольку всё зависит от особенностей конкретного проекта. В общем случае задача состоит в обработке исходного съёмочного материала — добавлении отсутствующих в нём объектов, удалении лишних или корректировке снятых. Исходный видеоматериал со съёмок может составлять десятки терабайт данных. Как правило, такое видео хранится на множестве LTO-кассет. Наряду с ростом емкости ленточных накопителей растёт и качество видео, его разрешение и глубина цвета, поэтому на одну кассету LTO-5 размером 1,5 Тбайт помещается всего 5-10 минут записи (без компрессии).

В наиболее сложном случае всё начинается с оцифровки физических или же моделирования с нуля будущих «искусственных» объектов в кадре, а также симуляции, то есть физических расчётов поведения и взаимодействия таких объектов. Затем происходит рендеринг — отрисовка смоделированных объектов. И уже в самом конце происходит композитинг — совмещение просчитанных и отрисованных объектов с исходным видео. Конечно, за таким формально простым описанием скрываются десятки часов работы большого числа специалистов.

Для начального моделирования объектов используются графические станции, преимущественно с Autodesk Maya. За симуляцию, физические расчёты, рендер и так далее отвечает SideFX Houdini. Для композитинга студия применяет The Foundry Nuke. Для каждого ПО есть отдельные дополнительные плагины и модули. Кроме того, имеется и собственный локальный инструментарий. Каждый этап разбивается на отдельные задачи, единицы достаточно независимых друг от друга расчётов. Практически все эти задачи попадают на рендер-ферму.

«Проблема многих небольших по голливудским меркам студий заключается в ограниченности бюджетов на закупку новых серверных ферм и рабочих станций. И в случае CGF цикл обновления оборудования, всё же весьма недешёвого, может составлять от 4 до более чем 7 лет. Для экономической рентабельности, качества работ и скорости исполнения заказов, студии необходимо максимально эффективно использовать всё имеющееся оборудование»,— отмечает Кирилл Кочетков, CTO студии CGF, под руководством которого происходило тестирование новых платформ.

В результате рендер-ферма CGF не полностью унифицирована, она состоит из нескольких типов когда-то дорогостоящих блейд-лезвий и серверных систем. В свободное время в качестве дополнительных узлов фермы подключаются и индивидуальные графические станции сотрудников. А при выборе нового «железа» важно подбирать процессоры и платформы под конкретные нагрузки и соблюсти баланс, так как у задач, описанных выше, заметно различаются требования к ресурсам: одно- и многопоточности, IPC ядра, пропускной способности памяти и так далее.

Многие задачи симуляции очень ресурсоёмкие — время счёта одного кадра может составлять несколько часов. При этом встречаются как использующие все ресурсы процессоров (8-24 потока) сценарии, так и специфичные задачи, которые фактически используют только один поток и для которых на первый план выходит частота и IPC одного ядра. К таковым относятся некоторые физические расчёты, где каждое следующее состояние напрямую зависит от предыдущего — например, распад объекта на части с их последующим взаимодействием между собой и со средой, на которую они тоже оказывают влияние. Непосредственно рендер же в среднем достаточно хорошо распараллеливается.

Для большинства задач используются преимущественно расчёты на CPU. В некоторых случаях GPU могут дать ускорение, но это не универсальное решение. При условии должного финансирования конкретного проекта некоторые студии собирают системы с ускорителями, под конкретное ПО. В случае CGF добавлять GPU в имеющуюся у студии ферму уже не имеет большого смысла, в связи с устареванием серверной части и наработанным инструментарием.

Второй важный ресурс — оперативная память. Её потребление зависит от конкретной задачи (и даже конкретного кадра), и при её недостатке возможны дисбаланс и замедление общей работы. В частности, задача может отъесть почти все ОЗУ узла, нагружая при этом лишь малую часть доступных ядер. Наконец, время счёта увеличивается в разы, когда свободная оперативная память узла закончилась и приходится использовать swap-файлы на дисках

Наконец, не стоит забывать и о дисковой подсистеме. Требования к ней тоже зависят от задач. Для одних требуется большой объём входных данных, а на выходе получается совсем немного. Для других всё ровно наоборот (обычно это симуляции физики), а у третьих результаты промежуточных расчётов занимают гигантское место, но вход и выход относительно невелики. Нюанс ещё и в том, что распространённые технологии кеширования в большинстве задач не эффективны, поскольку файлы обычно читаются только один раз. Часть расчётов на основе алгоритмов можно весьма эффективно запускать в облаке или на удалённом кластере, так как не требуется гонять десятки терабайт данных на накопителях и между узлами и СХД.

Для упрощения процесса распределения задач у каждой из них имеется определённый вес, который отражает требования к ресурсам. У каждого узла фермы, соответственно, есть определённая ёмкость. Если, к примеру, ёмкость узла составляет 1000 условных единиц (у. е.), то он сможет одновременно обработать десять задач по 100 у. е. каждая или две задачи по 350 у. е. и две по 150 у. е. А вот задачу на 2000 у. е. такой узел уже не осилит, и на него она не попадёт.

«Соблюдение баланса доступных и требуемых ресурсов позволяет CGF эффективно использовать имеющиеся аппаратные мощности. А если нагрузка не распределена по всей ферме, то это прямая потеря денег из-за простоя или недостаточно полного использования оборудования. В идеальном случае вся ферма должна быть всегда загружена на 100%, и на практике к этому показателю и стремятся», — говорит CTO студии CGF.

Рендер-ферма

Ферма CGF на основе блейд-систем (4U, 10 «лезвий») позволила плотнее размесить вычислительные ресурсы на имеющихся площадях студии. На текущий момент используется два варианта таких узлов на базе прошлых поколений Intel Xeon:

• двухпроцессорное «лезвие» попроще, в двух исполнениях (далее обозначены как Blades 1 и Blades 2), но с одинаковой конфигурацией: 2 × Intel Xeon E5645 (6C/12T, 2,4-2,67 ГГц, 80 Вт), 64 Гбайт RAM;
• «лезвие» помощнее, тоже двухпроцессорное (Blades 3): 2 × Intel Xeon E5-2670 (8C/16T, 2,6-3,3 ГГц, 115 Вт), 128 Гбайт RAM.

Но это не всё, в составе фермы задействуются все рабочие станции студии, когда они свободны от интерактивного использования сотрудниками. Их типовая конфигурация включает высокочастотный процессор на 8 или 12 потоков — Intel Core i7-6700K, i7-8700K или i7-9700K — и 64 Гбайт оперативной памяти. Общее число активных узлов в пике достигает 150.

На ферме запускаются задачи по симуляции и рендеру, расчёт моделей, а также задачи сборки финального изображения. Программное обеспечение рендер-фермы работает под управлением Linux-дистрибутива Debian 10. Распределением задач занимается менеджер CGRU, популярное открытое ПО для управления рендер-фермами. Из-за того, что задач много и все они относительно независимы друг от друга, ферма готова принять практически любое подходящее «железо», а уж чем нагрузить его, всегда найдётся.

Поэтому в эту рендер-ферму для оценки перспективности использования были добавлены тестовые серверы на базе современных процессоров AMD EPYC и Intel Xeon Scalable. В первую очередь было интересно выяснить, как задачи студии будут выполняться на наиболее продвинутом односокетном AMD-сервере с максимальным числом ядер и двух двухсокетных системах с процессорами AMD и Intel примерно с таким же суммарным количеством ядер на машину.

К сожалению, на момент тестирования не удалось получить наиболее похожие конфигурации с новыми Intel Xeon Gold 6248R, у которых в сравнении с 6248 больше ядер и выше частоты при меньшей цене (1ku RCP $2 700), и новыми же AMD EPYC 7F72 (1ku RCP $2 450) c тем же числом ядер, но более высокой частотой. В итоге были взяты конфигурации с чуть более простыми, но и более дешёвыми процессорами, что с точки зрения стоимости CPU (см. ниже) видится вполне приемлемым вариантом для тестирования.

Однопроцессорный сервер на базе AMD EPYC 7702 (далее обозначен как EPYC x1):

• платформа Gigabyte R162-Z11-00 (1U);
• 1 × AMD EPYC 7702 (64C/128T, 2,0-3,35 ГГц, 180 Вт);
• 512 Гбайт (8 × 64 Гбайт) DDR4-3200;
• SSD Seagate FireCuda 520 (M.2, NVMe, 500 Гбайт);
• сетевой контроллер 10GbE;
• 2 × БП 1200 Вт (80+ Platinum).

Двухпроцессорный сервер на базе AMD EPYC 7402 (далее обозначен как EPYC x2):

• платформа Gigabyte R282-Z91-00 (2U);
• 2 × AMD EPYC 7402 (24C/48T, 2,8-3,35 ГГц, 180 Вт);
• 1 Тбайт (16 × 64 Гбайт) DDR4-3200;
• SSD Seagate FireCuda 520 (M.2, NVMe, 500 Гбайт);
• сетевой контроллер 10GbE;
• 2 × БП 1600 Вт (80+ Platinum).

Двухпроцессорный сервер на базе Intel Xeon Gold 6248 (далее обозначен как Xeon x2):

• платформа Gigabyte R281-3C2 (2U);
• 2 × Intel Xeon Gold 6248 (20C/40T, 2,5-3,9 ГГц, 150 Вт);
• 768 Гбайт (12 × 64 Гбайт) DDR4-2933;
• 2 × SSD Samsung PM883 (SATA, 240 Гбайт; LSI RAID);
• сетевой контроллер 10GbE;
• 2 × БП 1200 Вт (80+ Platinum).

Все машины работали с профилем performance, а для AMD оставлен один NUMA-домен на сокет по умолчанию. На все машины был установлен тот же стек ПО, что используется в ферме; с ним никаких проблем не возникло. На локальных дисках фактически находился только софт, тогда как доступ к рабочим данным на внешней СХД с NFS осуществлялся по 10GbE-сети. Все машины получили конфигурацию памяти 1DPC с максимально возможной частотой для каждой платформы. Для текущих задач студии, обсчитывающихся на ферме, такой объём памяти чаще всего избыточен, но зато в тестах она точно не станет ограничивающим производительность фактором.

Тестирование

На одной машине каждого типа — EPYC x1, EPYC x2, Xeon x2, Blades 1, Blades 2 и Blades 3 — были запущены одинаковые тестовые сценарии, которые включают как исключительно синтетические нагрузки, которые на практике являются лишь частями более крупных задач, так и реальные расчёты тех проектов, над которыми трудилась студия во время тестового периода, продолжавшегося несколько недель.

Синтетические тесты

Для первичной оценки относительно производительности узлов использовались физические расчёты (симуляции) различных типов объектов и веществ в ПО SideFX Houdini:

• Cloth — ткань и одежда;
• FLIP — жидкость;
• Grain —сыпучие вещества;
• Pyro — газ;
• RBD — динамика твёрдых тел;
• Vellum Cloth и Vellum Hair —динамика мягких тел, основанная на явных связях между точками.

Такие расчёты происходят относительно быстро и имеют разные требования к числу и частоте ядер. Например, инструмент Cloth имеет однопоточную природу, поэтому только для него важна максимальная частота одного ядра. Прочие же инструменты умеют распараллеливать расчёты в той или иной степени. В данном тесте на каждый узел попадала ровно одна расчётная задача.

На графике выше приведено время, потребовавшееся узлам на расчёт каждой симуляции вышеперечисленных типов. Столь большая разница между старыми и новыми узлами объясняется в большей степени теми архитектурными улучшениями процессоров и платформ в целом, которые произошли за последнее десятилетие. Если же сравнивать между собой только современные платформы, приняв за базовый уровень результаты машины с Xeon, то разница уже не такая гигантская, хотя и очень существенная.

В среднем преимущество системы на базе одного процессора AMD EPYC составляет порядка 20%, а системы на базе двух процессоров AMD EPYC — 30%. Решения с процессорами AMD опережают конкурента во всех тестах, кроме первого, который, как уже говорилось выше, отличается тем, что математические расчеты в нем работают в однопоточном режиме. Напомним, что процессор Intel Xeon Gold 6248 имеет турбочастоту 3,9 ГГц, тогда как решения AMD — только 3,35 ГГц. Вероятно, этим и объясняется отставание на 10% в данном тесте.

Практические тесты: симуляция и рендер

Тестируемые системы работали в составе рендер-фермы студии несколько недель, так что удалось собрать достаточно обширную статистику по задачам, которых за это время было обработано несколько сотен. Поскольку в общем случае распределение задач по вычислительным узлам осуществлялось в автоматическом режиме, то для итогового отчёта были выбраны наиболее репрезентативные задачи: с большим числом кадров и с временем счёта одного кадра на самой быстрой машине не менее одной минуты.

В подавляющем большинстве случаев серверы на базе EPYC оказались быстрее машины с Xeon, причём односокетная EPYC-система оказалась в среднем даже чуть быстрее. В среднем преимущество систем на базе AMD в сравнении с Intel-сервером составило 20-21%. Но так как это реальные задачи, включающие разные типы нагрузок, прирост не везде равномерный. Например, в одном случае два процессора AMD оказались втрое быстрее двух CPU Intel, в другом — почти в два раза медленнее. Такой разброс является прямым следствием того, что не всегда одиночные задачи эффективно масштабируются на большое число ядер.

В этом случае более выгодным может оказаться распределение не из расчёта «одна задача на один узел», как в предыдущих тестах, а «несколько задач на один узел». Для оценки обоих подходов на каждую тестовую систему был отправлен набор из 10 кадров для рендеринга. В последовательном варианте каждый кадр отправлялся на серверы один за одним, а в параллельном — все сразу. Результатом является общее время вычислений. Тестирование показало, что двухпроцессорные серверы с AMD и Intel в этой задаче оказываются примерно на треть быстрее в случае одновременного запуска кадров на рендер, а однопроцессорный AMD-сервер — примерно на 20%. По общей скорости системы с AMD лидируют.

В следующем специальном тесте для более точного изучения эффективности распараллеливания была использована еще одна, отличная от прошлых, задача рендера, состоящая из восьми кадров. При этом время счёта каждого на узлах студийной фермы (Blades) составляло обычно 10-20 минут в зависимости от их производительности. Данная задача запускалась на сервере с одним процессором AMD (EPYC x1) с настройками системы управления задачами для счёта на сервере одновременно одного, двух, четырех и восьми кадров. Таким образом, первый вариант будет последовательным, а все остальные — параллельными.

Здесь стоит обратить внимание на работу программного обеспечения рендера. Одним из вариантов автоматического универсального распараллеливания его задач является разбиение целевого поля изображения на несколько блоков и вычисление каждого отдельным потоком рендера. В общем случае пользователь может сам выбрать для своей задачи, на сколько блоков её можно или нужно разделить. В данном случае рендер каждого кадра не знает, что на узле считается ещё что-то, и ориентируется на число вычислительных ядер для выбора числа запускаемых потоков для счёта блоков.

В результате получается, что одновременный расчёт восьми кадров уже активно использует средства процессоров и операционной системы для обработки числа потоков существенно большего, чем число ядер. Из таблицы с результатами видно, что в этом случае можно получить неплохой выигрыш — общее время получения результата примерно на треть меньше, чем если бы все кадры считались последовательно, хотя формально в обоих вариантах активно используются все ядра процессора.

Виртуализация

Как уже отмечалось выше, для некоторых вычислительных сценариев использование одного мощного сервера с большим числом ядер и большим объёмом оперативной памяти может быть не очень эффективно из-за сложности управления разнородными задачами на нём. В частности, это связано с отличиями таких ресурсов, как ядра и оперативная память. Первые непосредственно влияют только на скорость проведения расчётов, а вот прогнозировать потребление оперативной памяти разнородными задачами и управлять им может быть просто невозможно.

В этом случае можно рассмотреть вариант «нарезки» одного «большого» сервера на несколько виртуальных с заданным распределением ресурсов. Этот подход также позволит корректировать на лету распределение ресурсов, подбирая оптимальный вариант для текущих задач. Для проверки такого подхода на сервер с одним процессором AMD (EPYC x1) была установлена открытая система управления виртуальными машинами Proxmox.

Для машины EPYC x1 — 64 ядра/128 потоков и 512 Гбайт оперативной памяти — использовались виртуальные машины (ВМ) с конфигурациями от 16 ядер и 64 000 Мбайт оперативной памяти в количестве восьми штук до одной ВМ с 128 ядрами и 512 000 Мбайт оперативной памяти. В отличие от ранее проведенных тестов с реальными серверами, этот сценарий может иметь определённые ограничения производительности из-за размещения дисков виртуальных машин на внешней СХД, подключенной по протоколу NFS через 10-Гбит/с сетевое подключение.

Прежде всего стоит отметить, что лучший по скорости результат очень мало отличается от лучшего результата, полученного на реальной системе без применения виртуализации. Это говорит о том, что многоядерные процессоры AMD EPYC хорошо подойдут для подобных сценариев и смогут справиться с высокой нагрузкой. При этом в виртуализации лучше всего выступила схема «8 виртуальных машин, считающих каждая свой кадр». В общем случае можно сказать, что решения с AMD EPYC наиболее эффективны с точки зрения скорости именно в «перегруженных» сценариях, когда используется большое число одновременных ресурсоемких задач или потоков.

Энергопотребление и плотность

Энергопотребление и энергоэффективность являются не менее важными параметрами при оценке систем, чем их производительность. Старые блейд-системы имеют свою специфику: 4U-шасси на десять лезвий потребляет порядка 3 кВт (примерно 260-300 Вт на узел) и при этом требует отдельные кабели на каждый из четырех блоков питания. Тестовые системы, напротив, намного менее требовательны — им нужно всего по два кабеля на узел 1U или 2U. Сравнение плотности и потребления современных систем и старых блейд-серверов приведено в пересчёте на 4U-объём стоечного пространства — именно столько места требует каждая имеющаяся в распоряжении студии блейд-система.

Во время проведения тестирования на всех трех серверах был настроен удаленный мониторинг потребления с использованием встроенных в платформу сенсоров. На графике выше приведены максимальные и минимальные показатели энергопотребления. Первые — это самые высокие зафиксированные устойчивые значения под нагрузкой, а вторые были получены при отсутствии нагрузки на серверах. Более высокая эффективность AMD-решений, вероятно, частично обусловлена более тонким техпроцессом.

Однопроцессорная 1U-система c AMD EPYC 7702 представляет наибольший интерес в плане плотности размещения ресурсов. Четыре таких системы предлагают 256 ядер при суммарном потреблении около 1,3 кВт. Тогда как старая блейд-система (Blades 3) в 4U-шасси имеет 160 ядер и, как и было сказано выше, потребление на уровне 3 кВт. То есть современное решение AMD имеет в 1,6 раза больше ядер при более чем двукратной разнице в потреблении.

Две двухпроцессорные 2U-системы с AMD EPYC 7402 оказываются чуть менее плотными: 96 ядер при потреблении 950 Вт, то есть в 1,66 раза меньше ядер и в три с лишним раза меньшее потребление в сравнении с 4U-блейдом (Blades 3). Наконец, для тестовой системы с Intel Xeon Gold 6248 при тех же условиях сравнения получаем вдвое меньшее количество ядер и чуть менее чем трёхкратную разницу в энергопотреблении.

Кроме того, тестовые 1U/2U-серверы менее требовательны к охлаждению в сравнении с блейдами и позволяют при желании дооснастить их GPU (при условии, что платформа поддерживает данную возможность), которые могут ускорить некоторые расчёты или использоваться для организации VDI. Если же такая универсальность не нужна, а нужно ещё большее повышение плотности, то можно использовать узлы 2U4N.

Стоимость

Стоит сразу сделать оговорку, что расчёт стоимости тестовых платформ является приблизительным, так как обычно такого рода закупки носят гораздо более комплексный характер и учитывается весь проект целиком, а не отдельные машины. Компания ASBIS, которая предоставила серверы для тестирования, также привела цены на каждую из базовых платформ (CPU + память + шасси) в случае единичной закупки. Естественно, при покупке большего числа машин стоимость будет отличаться.

Стоимость всех трёх платформ имеет один и тот же порядок. Обе AMD-системы в тестах на реальных нагрузках оказались практически идентичными по производительности и заметно быстрее сервера с Xeon. Однако с учётом более высоких плотности и энергоэффективности именно односокетная система AMD является наиболее выгодной.

Если же сравнить реально протестированные системы с теоретически более подходящими (Xeon Gold 6248R, EPYC 7702P и 7F72), то картина становится ещё более интересной. Ценовая политика AMD в отношении P-серий процессоров, которые подходят только для односокетных систем, направлена на вытеснение двухсокетных конфигураций Intel — при меньшей стоимости CPU можно получить более высокую плотность и/или количество ядер. И это касается даже более «простых» моделей, без повышенной частоты и огромного кеша как в 7Fx2.

При этом AMD сознательно не сегментирует процессоры по всем остальным параметрам: любой EPYC 7002 имеет 8 каналов памяти DDR4-3200 и 128 линий PCIe 4.0 в отличие от 6 каналов DDR4-2666/2933 и 48 линий PCIe 3.0 у Intel. А двухпроцессорные системы AMD могут понадобиться уже для обеспечения более высокой базовой частоты на количество ядер, при потребности в объёмах памяти более 4 Тбайт, при определённых требованиях к объему и пропускной способности памяти на ядро, а также для HPC/AI-систем.

Заключение

Один из главных выводов, которые сделала для себя студия по итогам тестирования, касается скорее не «железа», а ПО. Точнее говоря, его полной совместимости с платформами AMD. Все используемые CGF программные пакеты заработали без каких-либо проблем или дополнительной тонкой настройки. В том числе и в более сложных сценариях блочного и виртуализированного рендеринга. Не было проблем и с совместимостью при установке дополнительных сетевых адаптеров или накопителей.

С аппаратной частью стратегия AMD по продвижению односокетных систем в случае студии попала точно в цель. Тестовые платформы имеют один порядок стоимости и при этом намного быстрее старых блейд-систем, но двухсокетная система AMD всё же несколько дороже остальных. При этом обе AMD-платформы в реальных задачах студии по симуляции и рендеру в среднем на 20-21% быстрее системы на базе Xeon. Если учесть, что использование P-версии процессора в односокетном AMD-сервере позволит ещё больше снизить стоимость, то становится очевидно, что именно эта платформа среди всех протестированных является наиболее привлекательной по соотношению цены и производительности.

Кроме того, она же относительно других тестовых платформ и старых блейд-систем является более энергоэффективной и более плотной с точки зрения числа ядер. Упрощение кабельного хозяйства и снижение счетов за электричество — без сомнения, очень важные аспекты для студии. Совокупность всех этих факторов привела к тому, что, ещё до завершения всех тестов в составе рендер-фермы, студия самостоятельно закупила ещё один односокетный сервер на базе AMD EPYC 7002 для изучения его возможностей в других сценариях IT-задач компании.

По итогам тестирования студия рассматривает возможность частичного обновления рендер-фермы, пока что без окончательного отказа от блейд-систем, за счёт использования однопроцессорных AMD-платформ высотой 1U, но в иной, нежели тестовая система, конфигурации. Основным фактором всё равно остаются финансы, так как экономика студии во многом завязана на требования выполняемых заказов — чем больше и сложнее в техническом отношении проекты, тем выше требования к «железу».

В текущей ситуации существует потребность в небольшом, относительно недорогом, но достаточно быстром и универсальном кластере для повседневных нужд студии. В том числе для отработки новых техник и возможностей. Единичные сверхтяжёлые задачи проектов по совокупности многих факторов чаще всего экономически выгоднее «выгружать» на внешние площадки — крупные кластеры или облака.

«Сколько вешать в ядрах? Наиболее оптимальными для нас сейчас видятся 1U-системы c 32-ядерными процессорами AMD EPYC 7502P (2,5-3,35 ГГц, L3-кеш 128 Мбайт, TDP 180 Вт). Они позволяют соблюсти баланс между стоимостью, в том числе шасси и памяти, плотностью размещения, энергопотреблением, производительностью и универсальностью для обеспечения эффективной работы студии в текущих условиях», — заключает технический директор CGF.