Глава про CPU и GPU полезна не сравнением маркетинговых цифр, а разницей в самой природе вычислений: универсальное последовательное управление против массивного параллелизма.
На практике она помогает выбирать вычислительный контур по профилю задачи: что чувствительно к задержке, что хорошо уходит в batch, а где стоимость передачи и подготовки данных съедает выигрыш от GPU.
В интервью и design review это дает внятный язык для выбора compute-стека через форму нагрузки, пропускную способность и цену владения, а не через модные тренды.
Практическая польза главы
Профиль workload
Помогает выбирать CPU/GPU по природе задачи: latency-чувствительность, batch, параллелизм и объем данных.
Экономика ресурса
Учит оценивать не только производительность, но и стоимость владения вычислительным контуром.
Capacity planning
Формирует подход к расчету ресурсов для inference, аналитики и смешанных сценариев.
Interview framing
На интервью позволяет объяснять выбор compute-стека через измеримые критерии, а не через тренды.
Источник
Central processing unit
Общее устройство CPU и роль в вычислениях.
CPU и GPU решают одну задачу — выполнение вычислений, но делают это по-разному. CPU ориентирован на универсальность и низкую задержку, а GPU — на массовый параллелизм и throughput.
Устройство CPU (базово)
- Ядра (cores) — выполняют инструкции и управляют потоками.
- ALU — выполняет арифметические и логические операции.
- Control Unit — управляет порядком исполнения инструкций.
- Регистры — самая быстрая память рядом с ядром.
- Кэш L1/L2/L3 — снижает задержку доступа к данным.
- Контроллер памяти и шины — связь с RAM и устройствами.
Источник
Graphics processing unit
Архитектура GPU и особенности параллельных вычислений.
Устройство GPU (базово)
- SM/CU (multiprocessors) — блоки массово-параллельного исполнения.
- Пулы потоков — запуск тысяч lightweight threads.
- Scheduler/dispatch — распределяет warps/wavefronts по вычислителям.
- VRAM — локальная память высокой пропускной способности.
- Кэш и контроллер памяти — ускоряют доступ к данным.
- Command processor — принимает и ставит задачи от CPU.
Сравнение CPU и GPU
CPU
- Небольшое число сложных ядер
- Высокая производительность на поток
- Хорошо для ветвлений и latency-критичных участков
Несколько мощных ядер выполняют разные задачи.
GPU
- Много относительно простых ядер
- Высокий throughput на однотипных операциях
- Отлично для data-parallel вычислений
Много простых ядер выполняют одну задачу параллельно.
Динамическая визуализация: симулятор нагрузки
Выберите профиль нагрузки и размер батча. Ниже — упрощённая модель, которая показывает, когда выигрывает CPU, а когда — GPU.
Размер батча: 32
Диапазон: 8 - 256
CPU
Fit для профиля: 88%
Время обработки батча: 7 ms
Оценка throughput: 4571 req/s
GPU
Fit для профиля: 35%
Время обработки батча: 8 ms
Оценка throughput: 4000 req/s
Результат симуляции
Ускорение CPU/GPU по времени батча: 0.88x (CPU быстрее).
Узкое место: ветвления, локи и хвостовые задержки. Рекомендация: CPU как primary runtime, GPU только для отдельных вычислительных подзадач.
Динамическая визуализация: гибридный pipeline CPU + GPU
В реальных системах почти всегда работает связка CPU+GPU. Переключайте этапы и смотрите профиль загрузки.
Валидация входа, feature extraction, сериализация и формирование батча.
Ключевая метрика
Время подготовки батча
Фокус оптимизации
векторизация на CPU, уменьшение копирований и аллокаций
Где работает лучше
CPU
- Серверные запросы с сложной бизнес-логикой
- Транзакции, координация сервисов, задачи ОС
- Сценарии с непредсказуемыми ветвлениями
GPU
- Графика и рендеринг
- Машинное обучение и матричные операции
- Массовые параллельные вычисления и симуляции
Частые ошибки при выборе CPU/GPU
GPU ради самого факта GPU
Перенос branch-heavy логики на GPU без оценки kernel launch overhead часто ухудшает latency.
Игнорирование data transfer cost
При малых батчах время перемещения данных CPU→GPU и обратно может съесть весь выигрыш.
Метрики только на уровне хоста
Смотреть только на CPU/RAM недостаточно: нужны GPU utilization, memory bandwidth и queue depth.
Отсутствие деградации при недоступности GPU
Без fallback-пути на CPU система теряет устойчивость при дефиците GPU-ресурсов.
Практические рекомендации
Hybrid pipeline
Оставляйте orchestration, контроль потоков и бизнес-решения на CPU; массовые math-операции выносите на GPU.
Batch sizing by SLO
Подбирайте размер батча от SLA: слишком мелкий батч не раскрывает GPU, слишком крупный бьёт по latency.
Профилирование до и после
Снимайте flamegraph/pprof на CPU и kernel traces на GPU, чтобы решения опирались на измерения, а не на гипотезы.
Capacity planning по двум доменам
Считайте отдельно CPU-bound и GPU-bound участки, чтобы корректно планировать стоимость и масштабирование.
Практический вывод
В production-системах CPU и GPU почти всегда работают в связке: CPU управляет логикой и оркестрацией, а GPU берет на себя массовые вычисления. Архитектурный выбор зависит от характера нагрузки: latency и ветвления — в пользу CPU, параллельные и однотипные операции — в пользу GPU.
Почему это важно при проектировании приложений
- Помогает выбрать целевой runtime под тип нагрузки и правильно спроектировать pipeline обработки.
- Влияет на стоимость инфраструктуры: CPU-доменные и GPU-доменные сервисы масштабируются по-разному.
- Определяет требования к памяти и сети: для GPU-контуров критичны bandwidth, transfer path и batch strategy.
- Снижает архитектурные риски: fallback на CPU и корректные SLO защищают систему при дефиците GPU-ресурсов.
Связанные главы
- Зачем нужны фундаментальные знания - объясняет, как ограничения железа влияют на архитектурные решения в System Design.
- Structured Computer Organization (short summary) - даёт аппаратный фундамент: уровни абстракции, ISA, память и взаимодействие CPU с устройствами.
- Операционная система: обзор - дополняет тему планированием потоков, системными вызовами и влиянием kernel-space на latency.
- RAM и persistent storage - показывает, почему memory bandwidth и data locality часто важнее чистой compute-мощности.
- Performance Engineering в System Design - даёт практический подход к профилированию CPU/GPU нагрузки и оптимизации end-to-end производительности.
- История появления Google TPU и их эволюции - расширяет сравнение аппаратных ускорителей и помогает понять, когда GPU или TPU дают лучший эффект.