GPU-терминалы: от TTY до глиф-атласов

В 1978 году Digital Equipment Corporation выпустила VT100. Это была скорее мебель, чем техника: ЭЛТ-экран в бежевом корпусе, подключённый к миникомпьютеру по последовательному кабелю. Он не запускал программы и не умел выводить графику. Он показывал текст в фиксированной сетке 80 на 24 символа, и это был весь интерфейс между человеком и работающей системой. Почти полвека спустя то, на что разработчики смотрят весь день, концептуально всё та же сетка. Но архитектура под ней изменилась так, как создателям VT100 и не снилось. Новое поколение эмуляторов терминала, таких как Ghostty, Alacritty, Kitty и WezTerm, выводит текст через GPU-конвейеры рендеринга, изначально созданные для видеоигр. И разница в производительности здесь не инкрементальная. Она структурная.

Почему ваш терминал по умолчанию тормозит

Terminal.app на macOS, GNOME Terminal в Linux и Windows Console Host идут в комплекте с ОС, и они работают. Долгое время этого хватало: вы вводили команды, читали вывод и двигались дальше. Но рабочие процессы разработчиков уже не такие. Мы стримим подробные логи сборки, запускаем TUI-приложения вроде lazygit и btop, которые перерисовывают весь экран при каждом нажатии клавиши, отправляем структурированный вывод из AI-инструментов для написания кода и держим несколько панелей с параллельным выводом. Устаревшие терминалы под такое никогда не проектировались.

Корень проблемы простой: рендеринг упирается в CPU. Устаревшие терминалы рисуют текст через платформенные текстовые API, которые обрабатывают символы последовательно. Когда тестовый набор выплёвывает десять тысяч строк разом, терминал должен растеризовать каждый глиф на процессоре, наложить его на фреймбуфер и вывести результат на экран, и всё это в главном потоке. Кадры теряются, задержка ввода скачет, прокрутка тормозит. Вы это чувствуете: та самая полусекундная пауза, когда выводите через cat большой файл.

Это не мелкая неприятность. Задержка ввода напрямую влияет на скорость мышления. Исследования задержки между нажатием клавиши и появлением символа на экране показывают, что задержки свыше 10 миллисекунд заметны, а свыше 50 миллисекунд измеримо замедляют набор текста. Если терминал добавляет 20–30 мс сверх собственной задержки редактора, вы буквально думаете медленнее, чем могли бы.

Как на самом деле работает рендеринг терминала на GPU

Отправлять текст на GPU звучит как забивать гвозди микроскопом. Моноширинные символы в фиксированной сетке, что тут сложного? Но суть GPU-терминалов не в том, что рендерить текст трудно. Суть в том, что GPU невероятно хороши в выполнении одной и той же небольшой операции тысячи раз параллельно, а именно это и нужно терминалу: расставить одинаковые текстуры глифов по сетке, тысячи ячеек за кадр.

Ключевой приём называется глиф-атлас. Когда символ появляется впервые, терминал растеризует его (через FreeType, CoreText или DirectWrite, в зависимости от платформы) и кладёт получившийся битмап в текстурный атлас на GPU, то есть в большой спрайтшит с заранее отрисованными символами. Во всех последующих кадрах вывод этого символа сводится к поиску в текстуре и отрисовке квада. Никакой растеризации и никакого участия CPU, кроме передачи данных сетки. Эту технику игровые движки используют десятилетиями для вывода текста в 3D-сценах.

Terminal Rendering Pipeline:
PTY byte stream
→ VT parser (interprets ANSI escape sequences)
→ Cell grid (char + fg color + bg color + attributes per cell)
→ Glyph atlas lookup (GPU texture coordinates for each character)
→ Batch draw calls (one draw per distinct texture/color combination)
→ GPU compositing (text + cursor + selection + background effects)
→ Displayed frame
The expensive step in legacy terminals — per-glyph CPU rasterization —
becomes a cache hit in the atlas. That's the whole trick.

API рендеринга зависит от платформы. Alacritty и WezTerm используют OpenGL в Linux и Metal в macOS. У Ghostty собственный Metal-бэкенд на macOS, а в Linux поддерживается Vulkan. Kitty работает на OpenGL везде. Выбор важен для переносимости и совместимости с драйверами, но все эти подходы разделяют одно фундаментальное преимущество: они превращают растеризацию каждого кадра в пакетную задачу выборки из текстур, которую GPU решает почти бесплатно.

Сравнение GPU-терминалов: Ghostty, Alacritty, WezTerm и Kitty

Эти четыре терминала придерживаются одной философии рендеринга, но во всём остальном сильно расходятся. Каждый отвечает на вопрос «за что должен отвечать терминал?» по-своему.

Ghostty: нативный UI без компромиссов

Ghostty Митчелла Хашимото написан на Zig с нативной интеграцией UI: AppKit и Metal на macOS, GTK в Linux. Большинство кроссплатформенных терминалов одинаково выглядят и ведут себя на всех системах, что также означает, что на каждой из них они чужеродны. Ghostty же уважает соглашения каждой платформы по управлению окнами, горячим клавишам и визуальному оформлению. На macOS он ощущается как приложение macOS, а в GNOME как приложение GNOME. Это может звучать как косметика, но когда терминал — приложение, в котором вы проводите больше всего времени, нативность накапливается и ощущается через месяцы.

Alacritty: делать одно дело и делать его быстро

Alacritty запустил движение GPU-терминалов. Написанный на Rust, он намеренно не включает вкладки, сплиты и встроенный мультиплексор. Философия в духе Unix: делать одно дело хорошо, а остальное оставить другим инструментам. Если вы уже используете tmux или тайловый оконный менеджер, Alacritty даст самый быстрый чистый рендеринг при минимальном потреблении ресурсов. Он не выиграет в сравнении по функциям, и в этом весь смысл.

WezTerm: всё сразу, и сделано правильно

WezTerm занимает противоположную позицию. Встроенный мультиплексор, интеграция с SSH, конфигурация на Lua, поддержка лигатур, вывод изображений: это максималистский терминал. Его скриптовый движок на Lua действительно мощный: можно писать условные горячие клавиши, динамические заголовки вкладок и логику переключения рабочих пространств, для которой в других связках понадобились бы три-четыре отдельных инструмента. Если хотите, чтобы одно приложение заменяло терминал, мультиплексор и половину скриптов из dotfiles, пробуйте WezTerm.

Kitty: пионер протоколов

Главный долгосрочный вклад Kitty заключается не в движке рендеринга, а в протоколах. Графический протокол Kitty позволяет приложениям выводить растровые изображения прямо в строке. Протокол клавиатуры Kitty наконец решает давнюю проблему неоднозначной передачи клавиш (попробуйте отличить Ctrl+I от Tab в устаревшем терминале, это невозможно). Эти протоколы переняли другие терминалы и TUI-фреймворки вроде Textual и Ratatui. Kitty двинул вперёд всю экосистему, и инструменты, которыми вы пользуетесь сегодня, стали лучше благодаря ему.

Бенчмарки производительности терминалов: что важно, а что нет

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

Задержка ввода: время между нажатием клавиши и её появлением на экране. GPU-терминалы стабильно укладываются в 2–5 мс, а устаревшие держатся на уровне 15–30 мс. Это вы чувствуете при каждом наборе текста.
Стабильность кадров: важна не средняя частота кадров, а её разброс. Терминал, который рисует 60 fps, но проседает до 15 fps при большом объёме вывода, ощущается хуже, чем тот, что держит ровные 30 fps. Здесь выигрывает GPU-композитинг, потому что стоимость рендеринга почти постоянна независимо от того, какая часть экрана меняется.
Потребление ресурсов в простое: открытый терминал с приглашением шелла не должен заметно грузить CPU. У некоторых GPU-терминалов раньше были проблемы с энергопотреблением в простое из-за лишних перерисовок, но в основном их решили. Alacritty и Ghostty в простое обычно занимают 30–60 МБ памяти. WezTerm использует 80–150 МБ из-за своей среды Lua.

# Quick throughput test — not the most important metric,
# but reveals rendering architecture differences
time seq 1 1000000 | head -c 10M > /dev/null  # baseline
time seq 1 1000000                              # terminal-limited
# Measure input latency with Typometer (Java) or similar
# https://github.com/pavelfatin/typometer
#
# Typical results on modern hardware:
#   Ghostty:      2-4ms
#   Alacritty:    2-4ms
#   Kitty:        3-5ms
#   WezTerm:      4-6ms
#   Terminal.app: 15-25ms
#   GNOME Term:   20-30ms
# For frame consistency, vtebench is the best tool:
# https://github.com/alacritty/vtebench
vtebench --benchmark scrolling --iterations 100

Самый быстрый терминал не обязательно лучший. Лучший тот, чьи компромиссы совпадают с тем, как вы реально работаете. Пользователю tmux нужно одно, тому, кто полагается на нативные сплиты, другое, а тем, кто живёт в интегрированном терминале VS Code, третье.

Встроенный мультиплексор против tmux: прагматичный взгляд

Это вопрос, с которого начинаются споры. Должен ли терминал управлять сплитами и вкладками или это стоит оставить tmux? Без лишних оговорок: оба подхода хороши, а правильный ответ зависит от одной переменной. Нужна ли вам персистентность сессий?

Сессии tmux переживают падения терминала и обрывы SSH. Нативные сплиты — нет. Если вы подключаетесь по SSH к продакшн-серверам и нужно отключаться и подключаться снова, tmux незаменим. Ничто другое не делает это так надёжно.

Но для локальной разработки у нативного мультиплексирования есть реальное преимущество. Нативные сплиты проходят GPU-композитинг: терминал рисует все панели напрямую в один кадр. Запуск tmux внутри GPU-терминала означает двойной рендеринг: tmux отрисовывает свой виртуальный экран в символьный буфер, а терминал затем перерисовывает этот буфер на GPU. Вы платите налогом на производительность и теряете доступ к современным возможностям терминала, таким как встроенные изображения и протокол клавиатуры Kitty, потому что tmux стоит между приложением и терминалом и не пропускает эти протоколы без искажений.

Прагматичный вариант — гибрид: нативные сплиты для локальной работы и tmux для удалённых сессий. Используйте подходящий инструмент для каждого контекста, а не заставляйте один инструмент справляться с обоими.

Современные протоколы терминала, которые открывают новые сценарии работы

VT100 определил набор управляющих последовательностей, которые терминалы поддерживают десятилетиями. Современные терминалы расширяют их новыми протоколами, которые открывают сценарии, о которых первые разработчики даже не задумывались.

Встроенный вывод изображений через графический протокол Kitty или Sixel позволяет CLI-инструментам показывать графики, диффы и диаграммы без открытия браузера или отдельного окна. Инструменты для анализа данных могут строить графики прямо в терминале. AI-ассистенты для написания кода могут показывать визуальный вывод inline. Звучит как игрушка, пока вы этим не попользуетесь. Потом это кажется очевидным.

Синхронизированный вывод (режим 2026, совпадение, кстати) позволяет приложениям группировать обновления экрана в атомарные кадры. Без него TUI-приложение, которое перерисовывает весь интерфейс (файловый менеджер, дашборд, текстовый редактор), мерцает, потому что терминал выводит каждую управляющую последовательность по мере поступления. С синхронизированным выводом терминал буферизует всё между маркерами начала и конца и выводит за один раз. Фреймворки вроде Ratatui и Textual включают это автоматически, если терминал поддерживает.

# Test Kitty keyboard protocol support
printf '\e[?u'  # Query keyboard protocol flags
# Test Kitty graphics protocol support
printf '\e_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA\e\\'
# Synchronized output — bracket your screen updates
printf '\e[?2026h'  # Begin synchronized update
# ... application writes to screen ...
printf '\e[?2026l'  # End — terminal renders everything at once

Протокол клавиатуры Kitty заслуживает особого внимания. Обработка клавиатуры в терминалах сломана уже сорок лет. VT100 кодировал Ctrl+I и Tab одним и тем же байтом (0x09). Escape и клавиши с Alt начинаются с 0x1b. Протокол Kitty заменяет это однозначной передачей событий клавиш: нажатие, отпускание и повтор, с полной информацией о модификаторах. Neovim, Helix и другие редакторы его уже поддерживают. Раз попробовав терминал, где Ctrl+Shift+Enter работает как отдельная горячая клавиша, назад уже не вернуться.

Настройка GPU-терминала для реальной продуктивности

Установка быстрого терминала с настройками по умолчанию даёт примерно 30% пользы. Остальное зависит от конфигурации. Вот что действительно важно.

Выбор шрифта влияет на читаемость, размер глиф-атласа и поведение лигатур. JetBrains Mono, Fira Code и Monaspace популярны и поддерживают лигатуры. Если используете вариант из Nerd Font, получите иконки в приглашении шелла, файловом менеджере и инструментах для git. Ghostty, WezTerm и Kitty поддерживают лигатуры, а Alacritty намеренно их не поддерживает, считая, что в коде они отвлекают.

# Ghostty config (~/.config/ghostty/config)
font-family = "JetBrains Mono"
font-size = 14
adjust-cell-height = 2
font-feature = "calt"
font-feature = "liga"
background-opacity = 0.95
theme = "catppuccin-mocha"
scrollback-limit = 100000
# Shell integration — Ghostty auto-injects on macOS,
# but you may need this on Linux:
# source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"

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

# Shell integration for Ghostty in .zshrc
if [[ -n "$GHOSTTY_RESOURCES_DIR" ]]; then
source "$GHOSTTY_RESOURCES_DIR/shell-integration/zsh/ghostty-integration"
fi
# For Kitty, add to .zshrc:
if [[ -n "$KITTY_INSTALLATION_DIR" ]]; then
autoload -Uz -- "$KITTY_INSTALLATION_DIR/shell-integration/zsh/kitty-integration"
kitty-integration
fi

Кроссплатформенность на практике: macOS, Linux и Windows

Разработка эмуляторов терминала — одна из областей, где кроссплатформенность действительно сложна, а не просто утомительна. У каждой ОС свои GPU-API (Metal, Vulkan, OpenGL, DirectX), свои стеки рендеринга шрифтов (CoreText, FreeType, DirectWrite), свои оконные системы (Cocoa, X11, Wayland, Win32) и свои ожидания от того, как приложения должны себя вести.

На macOS всё лучше всего. Metal — чистый и современный API, CoreText хорошо справляется со шрифтами, а оконная система единообразна. Все четыре популярных GPU-терминала здесь работают хорошо.

Linux более фрагментирован. Главный раскол — X11 против Wayland: одни терминалы поддерживают оба, другие только один. Качество GPU-драйверов различается между проприетарными драйверами NVIDIA, стеком Mesa от AMD и интегрированной графикой Intel. Пользователям тайловых оконных менеджеров часто нужно другое поведение, чем пользователям GNOME или KDE. Всё работает, но, возможно, придётся покопаться.

Windows прошла большой путь. Windows Terminal — надёжный GPU-терминал из коробки. WSL2 и WSLg позволяют запускать нативные для Linux терминалы в Windows с приемлемой производительностью. Alacritty и WezTerm полноценно поддерживают Windows. Ghostty пока новичок в экосистеме Windows, но поддержку расширяет.

Куда движется терминальная технология

GPU-рендеринг уже стал базовым требованием. Следующий рубеж — то, что терминалы делают с семантическим пониманием, которое у них уже есть. GPU-терминал не просто выталкивает пиксели: он поддерживает структурированную модель экрана, где указано, какой символ в какой ячейке, какие цвета и атрибуты заданы и где проходят границы команд. Эта модель — основа для более умных функций.

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

Доступности давно пора уделить внимание. GPU-терминалы могут отдавать свою семантическую модель экрана системным API доступности, что потенциально лучше устаревших терминалов, которые отдают только сырые пиксели. Несколько проектов в 2026 году сделали это приоритетом, и результаты обнадёживают.

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

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