ЛАБОРАТОРНАЯ ПРОВЕРКА · CPU-ИНФЕРЕНС

Проверяем POCKET-35B без GPU: скорость, память и качество

Уровень: продвинутый Чтение: до 12 минут Результат: независимые замеры POCKET-35B и Bonsai-27B на одном компьютере — токены в секунду, расход памяти и качество ответов

Фраза «35 миллиардов параметров работают на обычном процессоре» подтверждает только возможность запуска. Она не отвечает на рабочие вопросы: сколько ждать первый токен, как быстро генерируется ответ, переживёт ли компьютер длинный контекст и не исчезло ли качество после экстремального сжатия.

Что именно мы сравниваем

POCKET-35B и Bonsai-27B — обозначения моделей с разным числом параметров. Но число в названии само по себе ничего не говорит о размере файла, фактически загруженных слоях и точности весов. На результат сильнее влияют формат, вариант квантизации, версия среды выполнения, длина контекста и набор инструкций процессора.

Корректный CPU-тест должен зафиксировать для обеих моделей одинаковые условия:

один компьютер, одна операционная система и один исполняемый файл;
отключённая выгрузка слоёв на GPU;
одинаковые контекст, число потоков, seed и параметры выборки;
одни и те же запросы в одном порядке;
отдельный холодный запуск и минимум три прогретых повтора;
хеш каждого файла модели и полный необработанный лог.

Сравнивать POCKET в одном рантайме с Bonsai в другом допустимо только как тест готовых продуктов. Такое сравнение нельзя выдавать за измерение различий между самими моделями.

Стенд: что записать до запуска

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

mkdir -p cpu-benchmark/logs
cd cpu-benchmark

{
  date --iso-8601=seconds
  uname -a
  lscpu
  free -h
} > system.txt

sha256sum /полный/путь/pocket.gguf > model-hashes.txt
sha256sum /полный/путь/bonsai.gguf >> model-hashes.txt

/path/to/llama-cli --version > runtime.txt 2>&1

/полный/путь/pocket.gguf, bonsai.gguf и /path/to/llama-cli — примеры-заполнители, а не названия проверенных файлов. Используйте только модели, которые вы получили из выбранного вами доверенного источника. Перед запуском сверяйте лицензию, размер и контрольную сумму. Не исполняйте скачанные скрипты установки с правами администратора.

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

Одинаковая конфигурация для двух моделей

Ниже приведён пример конфигурации для совместимого с GGUF консольного рантайма. Перед тестом проверьте поддерживаемые параметры через llama-cli --help: интерфейс конкретной версии может отличаться.

MODEL_POCKET=/полный/путь/pocket.gguf
MODEL_BONSAI=/полный/путь/bonsai.gguf
THREADS=8
CONTEXT=4096
TOKENS=256
SEED=42

PROMPT='Кратко объясни, почему атомарная запись файла защищает конфигурацию от частичного обновления. Затем приведи безопасный алгоритм из четырёх шагов.'

Число потоков лучше начать с количества физических ядер. Удвоение потоков через SMT не гарантирует ускорения: модель может упереться в пропускную способность памяти. Контекст 4096 выбран здесь как воспроизводимый пример, а не как рекомендация для любой задачи.

Запуск без GPU

Сначала выполните один прогревочный запрос для каждой модели. Его результат не включается в медиану.

taskset -c 0-7 /path/to/llama-cli \
  -m "$MODEL_POCKET" \
  -ngl 0 -t "$THREADS" -c "$CONTEXT" \
  -n 32 --seed "$SEED" --temp 0 \
  -p "Ответь одним словом: готово."

taskset -c 0-7 /path/to/llama-cli \
  -m "$MODEL_BONSAI" \
  -ngl 0 -t "$THREADS" -c "$CONTEXT" \
  -n 32 --seed "$SEED" --temp 0 \
  -p "Ответь одним словом: готово."

-ngl 0 запрещает перенос слоёв на GPU в совместимых версиях llama.cpp. Не ограничивайтесь наличием этого аргумента: во время запуска проверьте лог и загрузку устройств. Встроенная графика, специализированный ускоритель или другой backend могут сделать тест уже не чисто процессорным.

Для измеряемого повтора используйте системный time. Он сообщает пиковый резидентный объём памяти процесса и полное время выполнения.

/usr/bin/time -v taskset -c 0-7 /path/to/llama-cli \
  -m "$MODEL_POCKET" \
  -ngl 0 -t "$THREADS" -c "$CONTEXT" \
  -n "$TOKENS" --seed "$SEED" --temp 0 \
  -p "$PROMPT" \
  > logs/pocket-run-1.txt \
  2> logs/pocket-run-1.metrics.txt

/usr/bin/time -v taskset -c 0-7 /path/to/llama-cli \
  -m "$MODEL_BONSAI" \
  -ngl 0 -t "$THREADS" -c "$CONTEXT" \
  -n "$TOKENS" --seed "$SEED" --temp 0 \
  -p "$PROMPT" \
  > logs/bonsai-run-1.txt \
  2> logs/bonsai-run-1.metrics.txt

Повторите пары запусков три раза, меняя только номер файла. Чередуйте порядок моделей: POCKET → Bonsai, затем Bonsai → POCKET. Это уменьшает влияние нагрева CPU, кеша файловой системы и фоновых процессов.

Какие числа извлекать

Не сводите производительность к одному значению «токенов в секунду». У интерактивной модели есть как минимум три разных показателя:

Prompt processing: Скорость обработки входного текста. Она определяет задержку на длинном документе.
Time to first token: Время от запуска запроса до первого видимого фрагмента ответа. Это главный показатель отзывчивости интерфейса.
Token generation: Скорость последовательной генерации ответа. Именно её чаще всего называют tokens/s.
Maximum resident set size: Пиковая физическая память процесса по данным /usr/bin/time -v. Размер файла модели на диске этим показателем не является.

Если рантайм печатает отдельные строки prompt eval и eval, переносите их без пересчёта. Если такой статистики нет, сохраните полное время и число реально сгенерированных токенов, но явно обозначьте метод расчёта. Не делите заданный лимит -n 256 на время, если модель остановилась раньше.

Таблица первичных измерений на одном компьютере
Модель	Формат	Файл	Prompt, ток/с	Генерация, ток/с	Пиковая RAM	Статус
POCKET-35B	указать из метаданных	указать размер и SHA-256	не измерено	не измерено	не измерено	нужны логи
Bonsai-27B	указать из метаданных	указать размер и SHA-256	не измерено	не измерено	не измерено	нужны логи

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

Проверяем качество, а не только скорость

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

Следование инструкции. Ответ должен соблюдать формат, количество пунктов и ограничения.
Работа с данными. Дайте небольшой текст и задайте вопрос, ответ на который содержится только в нём.
Логика. Используйте задачу с однозначно проверяемым результатом и попросите короткое обоснование.
Код. Попросите исправить маленькую функцию и проверьте решение автоматическим тестом в изолированном каталоге.
Русский язык. Проверьте смысл, терминологию, склонения и отсутствие самопроизвольного перехода на другой язык.
Устойчивость. Повторите запрос с другим seed и посмотрите, сохраняется ли правильный вывод.

Пример шкалы для каждого задания: 0 — неверно или формат нарушен; 1 — частично верно, нужна существенная правка; 2 — верно без существенной правки. Максимум зависит от числа заданий, поэтому публикуйте не только сумму, но и сами запросы, эталонные критерии и обезличенные ответы.

Форма оценки качества
Категория	POCKET-35B	Bonsai-27B	Как проверить
Формат инструкции	не оценено	не оценено	точное совпадение с требованиями
Ответ по контексту	не оценено	не оценено	сверка с исходным фрагментом
Логическая задача	не оценено	не оценено	заранее записанный эталон
Код	не оценено	не оценено	одинаковые автоматические тесты
Русский язык	не оценено	не оценено	слепая ручная оценка

Как проверить, что результат настоящий

Независимый результат можно перепроверить без доверия к автору. Для этого пакет эксперимента должен содержать:

system.txt с характеристиками компьютера;
runtime.txt с версией среды выполнения;
model-hashes.txt с SHA-256 обоих файлов;
точные команды и неизменённые запросы;
stdout и stderr каждого запуска;
первичные оценки качества до вычисления итоговой суммы;
описание прогрева, порядка запусков и фоновой нагрузки.

Дополнительно откройте системный монитор во время теста. Нагрузка GPU должна оставаться на уровне простоя, объём swap — не расти, а процесс не должен завершаться из-за нехватки памяти. Если CPU снижает частоту после первого повтора, укажите это в отчёте или повторите тест после исправления охлаждения.

Типовые ошибки

Сравнивать разные контексты

KV-кеш увеличивается вместе с контекстом и способен заметно изменить расход памяти. Результат при 2048 токенах нельзя напрямую сравнивать с результатом при 32 768.

Считать размер файла расходом RAM

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

Смешивать обработку промпта и генерацию

Высокая скорость чтения входа не означает столь же быстрой генерации. Для чата важны оба показателя, а также задержка первого токена.

Менять шаблон диалога

Неправильный chat template способен испортить качество сильнее, чем квантизация. Используйте шаблон из метаданных модели или документируйте его полностью.

Оценивать качество по одному эффектному вопросу

Один ответ показывает единичное поведение. Нужен заранее зафиксированный набор задач, проверяемые критерии и одинаковые настройки генерации.

Игнорировать swap

Модель может формально запуститься, но постоянно обращаться к диску. Такая конфигурация проходит тест совместимости и проваливает тест интерактивной пригодности.

Когда CPU-запуск можно считать рабочим

Универсальной границы tokens/s нет. Для пакетной ночной обработки допустима задержка, которая неприемлема в чате. Поэтому критерий следует записать до измерения. Например: ответ заданного размера укладывается в установленный бюджет времени, система не использует swap, параллельно остаётся память для рабочего приложения, а качество проходит заранее выбранный порог.

Правильный вывод выглядит не как «35B работает на CPU», а так: «эта конкретная сборка с таким SHA-256, на таком процессоре, при контексте N и версии рантайма X дала медианную скорость Y, пиковую память Z и прошла K из M заданий». Пока хотя бы одна часть отсутствует, результат нельзя переносить на чужой компьютер.

Ограничения проверки

Результат одной машины не описывает все CPU: важны память, кеш, инструкции и охлаждение.
Одинаковое число параметров не означает одинаковую вычислительную стоимость.
Разные варианты одной модели могут иметь разные размер, скорость и качество.
Короткий тест не показывает деградацию на длинном контексте и многочасовую стабильность.
Ручная оценка качества остаётся субъективной без слепой разметки и второго проверяющего.
Обновление рантайма способно изменить оптимизации и сделать старые числа несопоставимыми.

Итог

Запуск POCKET-35B без GPU технически интересен, но сам по себе не доказывает пригодность модели. Честное сравнение с Bonsai-27B требует одинакового рантайма, одинаковых запросов, нулевой GPU-выгрузки, трёх прогретых повторов, пиковой памяти и заранее определённой проверки качества.

Без файлов моделей и первичных журналов любые конкретные цифры в этой статье были бы выдумкой. Представленный протокол превращает рекламное «запускается на обычном компьютере» в проверяемый инженерный результат — и явно показывает момент, когда локальная модель действительно подходит для вашей нагрузки.

← Все практические материалы · Лабораторный словарь →