Что произошло

В исходной публикации используется Linux-сервер с 64 ГБ памяти, Python 3.10 и набором библиотек PyTorch и Transformers. Автор загружает модель с пониженной точностью: по его оценке, это сокращает потребность в памяти примерно со 120 до 40 ГБ.

Далее он отключает вычисление градиентов, держит размер пакета равным одному и применяет оптимизации для центрального процессора. Первый запуск, по приведённым замерам, занимает от трёх до пяти минут, а энергопотребление сервера составляет около 150 Вт. Это существенно медленнее современных GPU, для которых автор приводит диапазон 100–300 токенов в секунду.

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

Почему это важно

Обсуждение локальных LLM часто сводится к объёму видеопамяти: если GPU нет, задача заранее считается невозможной. На практике ограничением может быть не только память, но и допустимое время ответа. Для пакетной обработки документов, внутреннего тестирования или одиночного диалога ожидание в несколько секунд иногда приемлемо.

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

При этом экономия не гарантирована. Долгий старт, высокий расход энергии и низкая пропускная способность могут сделать CPU-вариант дороже облачного API или аренды ускорителя. Перед выбором стоит считать стоимость владения и измерять задержку на своих запросах.

На практике

1. Начните с памяти. Для заявленной конфигурации нужно не менее 64 ГБ ОЗУ и около 200 ГБ свободного диска. Оставьте запас для ОС, загрузчика модели и контекста.
2. Проверьте путь квантования. Не все методы пониженной точности одинаково работают без GPU. Воспроизведите загрузку на своей версии библиотек и зафиксируйте точный формат весов.
3. Соберите честный замер. Измеряйте отдельно холодный старт, время до первого токена, скорость генерации и пиковую память на типичных промптах.
4. Настройте процессорную часть. Число потоков, BLAS-библиотека и привязка процессов к ядрам заметно влияют на результат. Оптимизация Intel MKL может помочь, но её стоит сравнить с альтернативами на вашей ОС.
5. Определите границу применения. Для нескольких параллельных пользователей или длинных ответов GPU остаётся практичнее. CPU-вариант разумнее для одиночного пользователя, стенда или задач без жёсткого времени ответа.

Итог

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

Если у команды уже есть сервер с большим объёмом ОЗУ, стоит провести небольшой тест на собственных данных. Даже отрицательный результат даст измерения, по которым проще выбрать GPU, облачный API или меньшую модель.