Зміст
Коротко
Автор матеріалу стверджує, що запустив велику мовну модель Gemma 4 26B на сервері з Xeon E5 v2 — процесорі приблизно 2013 року — без графічного прискорювача. Заявлений результат: близько 12 токенів за секунду за споживання приблизно 45 ГБ оперативної пам’яті.
Це не рецепт для навантаженого сервісу. Проте дослід корисний як нагадування: для локальної перевірки гіпотези, закритого прототипу або нечастих запитів старий сервер може стати альтернативою оренді GPU.
Що сталося
В оригінальній публікації використано Linux-сервер із 64 ГБ пам’яті, Python 3.10 та бібліотеками PyTorch і Transformers. Автор завантажує модель зі зниженою точністю; за його оцінкою, це зменшує потребу в пам’яті приблизно зі 120 до 40 ГБ.
Потім він вимикає обчислення градієнтів, залишає розмір пакета рівним одному та застосовує оптимізації для центрального процесора. За наведеними вимірами, перший запуск триває від трьох до п’яти хвилин, а споживання сервера становить близько 150 Вт. Це помітно повільніше за сучасні GPU, для яких автор називає 100–300 токенів за секунду.
Ці числа варто сприймати саме як результати автора, а не як універсальну властивість моделі. Швидкість залежить від формату ваг, збірки бібліотек, довжини контексту, кількості потоків, пам’яті й способу підрахунку токенів.
Чому це важливо
Розмови про локальні LLM часто зводяться до обсягу відеопам’яті: немає GPU — начебто немає й задачі. Насправді рішення визначає також прийнятний час відповіді. Очікування кілька секунд неприйнятне для інтерактивного продукту, але може підійти для обробки документів, внутрішнього стенда або інструмента для однієї людини.
Повторне використання наявного сервера дає змогу тримати дані поруч із командою. Це не скасовує контролю доступу та обов’язків з адміністрування, однак під час оцінювання не потрібно передавати кожен запит зовнішньому постачальнику.
Економія не є гарантованою. Довгий старт, витрати електроенергії та невелика кількість одночасних запитів можуть зробити CPU-розгортання дорожчим за API або оренду прискорювача. Порівнювати слід повну вартість і затримку на реальному навантаженні.
На практиці
- Спочатку сплануйте пам’ять. Для заявленої конфігурації потрібні щонайменше 64 ГБ ОЗП і близько 200 ГБ вільного диска. Залиште запас для ОС, завантажувача моделі та контексту.
- Перевірте спосіб квантування. Методи зниженої точності не однаково працюють без GPU. Відтворіть завантаження на точних версіях бібліотек і зафіксуйте формат ваг.
- Зберіть чесні виміри. Окремо вимірюйте холодний старт, час до першого токена, швидкість генерації та пікову пам’ять на типових запитах.
- Налаштуйте процесорну частину. Кількість потоків,
BLAS-бібліотека та прив’язка процесів до ядер відчутно впливають на результат.Intel MKLможе допомогти, але його варто порівняти з альтернативами на цільовому хості. - Визначте межу застосування. Для кількох одночасних користувачів або довгих відповідей GPU лишається практичнішим. CPU-вивід моделі краще підходить для одного користувача, тестового середовища чи асинхронних задач.
Підсумок
Стаття не доводить, що старий Xeon замінить прискорювач: різниця у швидкості велика, а технічні деталі потребують незалежної перевірки. Натомість вона показує корисний принцип: можливість локального ШІ визначають пам’ять, формат моделі, вимоги до затримки й вартість експлуатації, а не лише вік процесора.
Якщо команда вже має сервер із великим обсягом ОЗП, варто провести невеликий тест на власних запитах. Навіть негативний результат дасть виміри, з якими легше обрати GPU, хмарний API або меншу модель.