Как проверить компьютер для локального ИИ перед покупкой

Сначала зафиксируйте, что именно проверяете

Для сравнения двух компьютеров нужны одна и та же версия модели, квантование, программа, вычислительный движок и настройки. В Ollama сохраните имя, тег и идентификатор локальной модели; для отдельного файла — точное имя и контрольную сумму, если она доступна. Также запишите ОС, драйвер, объём RAM, установленный GPU и версию программы.

Укажите контекст, предел ответа и режим рассуждений, если модель его использует. Не сравнивайте короткий ответ одной модели с длинным рассуждением другой. Температуру и остальные параметры тоже сохраняйте одинаковыми; даже это не является обещанием побитово одинакового текста на любых системах.

В документации Ollama описано, как посмотреть контекст и распределение CPU/GPU через ollama ps. Сохраните этот вывод во время проверки. Если программа показывает использование GPU, это ещё не доказывает, что выбран именно нужный внешний ускоритель: такую проверку мы отдельно разобрали в руководстве по OCuLink.

Задание должно иметь проверяемый ответ

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

Короткий учебный запрос для проверки фактов:

Используй только эту записку. Заказ МАЯК-714: 12 коробок, по 8 изделий в каждой. Дата отгрузки не указана. Сколько изделий в заказе и когда его отгрузят? Если сведений нет, прямо так и напиши.

Ожидается 96 изделий и указание, что дата отгрузки неизвестна. Это вымышленный пример, не сведения о заказах FEVM. Он проверяет чтение фактов и отказ от домысла, но слишком короток для самостоятельного вывода о производительности. После него нужен ваш типичный запрос с обычной для вас длиной входа и ответа.

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

Четыре показателя, которые стоит разделять

1. Загрузка модели. Сколько занял её запуск в программе в выбранных условиях. Это отдельная часть первого обращения.
2. Ожидание первого видимого текста. От отправки запроса до появления текста ответа в клиенте. Уточните, считаете ли вы показ рассуждений или начало итогового ответа.
3. Генерация. Сколько выходных токенов создано за время генерации. Это характеристика конкретного прогона, а не универсальная скорость ПК.
4. Полное время запроса. От отправки до завершения ответа в вашем клиенте. Если используете серверную метрику, подпишите её отдельно: сервер и пользовательский интерфейс измеряют разные границы.

В ответе API Ollama есть load_duration, prompt_eval_duration, eval_count, eval_duration и total_duration. Длительности указаны в наносекундах. Эти поля помогают разделить загрузку, обработку входа и генерацию; полный замер клиента нужно сохранять отдельно.

При stream: false ответ возвращается целиком одним JSON. Из такого ответа нельзя восстановить момент первого видимого текста. Для этой величины нужен отдельный замер в клиенте с поточной выдачей: от отправки до первого нужного текстового фрагмента. Не подменяйте его временем загрузки или полной длительностью запроса.

Как посчитать токены в секунду

Скорость генерации = eval_count ÷ (eval_duration ÷ 1 000 000 000)

Допустим, в учебном JSON указаны eval_count = 160 и eval_duration = 8 000 000 000. Тогда 160 ÷ 8 = 20 токенов/с. Если дополнительно загрузка заняла 4 секунды, а обработка входа — 2, сумма этих трёх этапов равна 14 секундам. Это иллюстрация расчёта: сумма показанных этапов не заменяет total_duration и не равна автоматически ожиданию первого текста.

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

{
  "model": "ИМЯ_ВАШЕЙ_ЛОКАЛЬНОЙ_МОДЕЛИ",
  "prompt": "ВАШ_ОДИНАКОВЫЙ_ТЕСТОВЫЙ_ЗАПРОС",
  "stream": false,
  "keep_alive": "5m",
  "options": {
    "temperature": 0,
    "num_ctx": 4096,
    "num_predict": 256
  }
}

Первый запуск и повторы: одна процедура для двух ПК

1. Подготовить одинаковые условия. Использовать согласованное питание и режим работы, закончить фоновые загрузки и другие тяжёлые задания. Записать конфигурацию и не менять её между прогонами.
2. Снять первый запуск после остановки модели. В Ollama команда ollama stop ИМЯ_МОДЕЛИ останавливает запущенную модель; её и список запущенных моделей описывает официальный CLI-справочник. Проверьте состояние через ollama ps, затем выполните запрос. Назовите условие именно так: это не доказательство отсутствия дискового кэша ОС.
3. Выполнить три повтора с загруженной моделью. Для каждого отправить тот же запрос как отдельное обращение без наращивания истории чата. Убедиться, что модель ещё загружена. Повторный вход может обрабатываться с использованием кэша; сохраните доступные сведения о кэше и не смешивайте его условия между системами.
4. Записать каждый результат. Сохранить ответы, ошибки, времена и счётчики. Для трёх повторов можно дополнительно указать медиану, но сами три значения тоже нужны. Не выбирать только самый быстрый прогон.
5. Повторить с рабочим заданием. Проверить качество и доступную память на реальном для вас документе или запросе. Успех короткой пробы не доказывает работу с большим контекстом или несколькими одновременными пользователями.

Что должно быть в отчёте продавца

Для FEVM FAEX1 с 128 ГБ это общая память CPU/GPU, а не выделенные 128 ГБ VRAM. Поэтому попросите сведения о расходе и доступной памяти в конкретной среде; один объём RAM не заменяет проверку нужной модели. Если важна работа без сети, дополните этот протокол отдельной автономной проверкой.

Порог приёмки задавайте своей задачей: какие факты должны быть верны, какой результат обязателен и сколько вы готовы ждать в выбранных условиях. Здесь нет универсального норматива токенов/с или утверждения, что один ПК быстрее другого.