Игровая нагрузка неравномерная: пики чередуются с провалами, кадр готовится за миллисекунды, часть ядер простаивает. Расчётная нагрузка ровная и длительная: все ядра или всё видеоядро заняты часами подряд без пауз. Из этого различия вытекают почти все решения по подбору компонентов — от системы охлаждения до объёма памяти.
Устойчивый режим вместо пикового
Короткий пик процессор проходит на повышенных частотах, пока тепловая инерция радиатора позволяет. При многочасовой нагрузке этот резерв заканчивается через десятки секунд, частоты опускаются до уровня, который система способна поддерживать непрерывно, и дальше всё определяется этим устойчивым уровнем. Конфигурация с высоким пиком, но слабым отводом тепла, в расчётах проигрывает более скромной, но с полноценным радиатором и продуманным потоком воздуха.
То же касается блока питания. В играх средняя нагрузка заметно ниже максимальной, в рендере она держится у верхней границы. Блок работает в этом режиме круглосуточно, температура внутри него выше, ресурс конденсаторов расходуется быстрее, а вентилятор выходит на постоянные обороты — то есть тихая в играх система становится слышимой.
Ядра, частота и характер задачи
Трассировка лучей на процессоре делится на независимые участки и масштабируется почти линейно по числу ядер до тех пор, пока хватает пропускной способности памяти. Сеточные решатели, симуляции жидкостей и линейная алгебра упираются в память намного раньше: добавление ядер перестаёт помогать, а расширение числа каналов даёт прирост.
Есть и обратная сторона. Подготовка сцены, разбор исходников, компиляция шейдеров, загрузка ассетов часто однопоточны. При большом числе ядер и низкой базовой частоте эта фаза растягивается и съедает часть выигрыша. Поэтому перед выбором стоит понять, какая доля времени уходит на параллельную часть, а какая на последовательную — соотношение частоты и количества ядер выбирается уже из этого, а не из общего рейтинга. Различия между линейками и то, как читать их характеристики, разобраны в разделе про процессоры.
Память: объём, каналы, контроль ошибок
Объём оперативной памяти для расчётной станции — жёсткий порог, а не параметр производительности. Пока сцена помещается, скорость определяется процессором. Как только не помещается, начинается обмен с накопителем, и время выполнения растёт в разы независимо от того, насколько быстрый процессор стоит.
Каналы заполняются симметрично: незанятый канал означает потерю значительной доли пропускной способности, а на задачах, чувствительных к памяти, это прямая потеря производительности. При этом установка модулей во все слоты повышает нагрузку на контроллер, и стабильная частота может оказаться ниже паспортной для комплекта — на длительных расчётах это лучше, чем работа на пределе.
Отдельный вопрос — контроль ошибок. Одиночный сбой бита в течение многочасового расчёта не приводит к падению программы: он просто портит результат, и обнаруживается это в лучшем случае при сравнении с контрольным прогоном. Для задач, где результат нельзя проверить глазом, память с коррекцией ошибок перестаёт быть избыточностью; принцип её работы и требования к платформе описаны в разделе про память ECC.
Видеопамять как жёсткая стена
В GPU-рендеринге объём видеопамяти работает по бинарному принципу: сцена вместе с текстурами и ускоряющей структурой либо помещается, либо нет. При переполнении часть данных остаётся в системной памяти и передаётся через шину, и производительность падает в разы — шина медленнее локальной памяти на порядок. Никакой запас вычислительной мощности этого не компенсирует.
Отсюда следует, что для рендера объём видеопамяти важнее скорости ядра, а сравнение карт по игровой производительности вводит в заблуждение. При установке нескольких ускорителей добавляются механические и электрические ограничения: число линий PCIe, доступных каждому слоту, расстояние между картами для притока воздуха, суммарные пиковые броски потребления, которые блок питания должен переносить без срабатывания защиты. Данные между картами при рендере обычно не синхронизируются, поэтому объём памяти не складывается — каждая карта должна вместить сцену целиком.
Накопители и приоритет стабильности
Расчётный конвейер пишет много: секвенции кадров, промежуточные кэши, файлы симуляции. Здесь важны и скорость последовательной записи, и ресурс — суточный объём записи на рабочей станции может на порядки превышать бытовой сценарий. Разумная схема — быстрый NVMe под активный проект и кэш, ёмкие накопители под архив, отдельный том под систему.
Наконец, приоритет стабильности над максимальной производительностью. Разгон, который в игре проявляется редким вылетом, в расчёте означает потерю многочасовой работы или, что хуже, тихо испорченный результат. Проверять конфигурацию стоит длительным прогоном под полной нагрузкой, а не короткими тестами: большинство проблем с питанием и охлаждением проявляется только после того, как система прогреется целиком.
