Введение

После сборки домашнего сервера для работы с LLM DeepSeek-R1 подробно о нём можно прочитать в статье Локальный DeepSeek-R1-0528. Когда скорость улитки – не приговор, а точка старта возникла потребность сравнить разные квантизации для оптимизации скорости/качества работы. Запуская работу с разными моделями, я заметил что квантизация зачастую приводит к ускорению генерации токенов.
Сейчас почти каждая вновь появляющаяся топовая модель в скором времени уже существует на huggingface в нескольких вариантах квантизаций. Понять сразу баланс между размером, скоростью, и качеством не всегда представляется возможным. Я решил скачать несколько разных моделей и понять какая из них работает быстрее и заодно постараться субъективно оценить качество.
В рамках исследования были выбраны четыре варианта квантизированных DeepSeek-R1 0528 от unsloth

• UD-Q5_K_XL 481GB

• UD-Q4_K_XL 384GB

• UD-Q3_K_XL 296GB

• UD-IQ2_M 229GB

Оборудование для теста

• EPYC 7K62

• Supermicro H11SSL-i Version: 2.00

• 8 x hynix 64GB 2Rx4 PC4-3200AA-RB4-12. (total 512GB)

• NVIDIA RTX 3090

сервер позволяет запускать LLM как с использованием GPU+CPU так и с использованием только CPU. Подробно о сборке сервера я написал в статье Локальный DeepSeek-R1-0528. Когда скорость улитки – не приговор, а точка старта

Методология

Для каждой модели будет проведено тестирование с только на CPU и на CPU+GPU
Я буду просить LLM написать игру змейка. Сам промпт будет максимально простой и наивный.

'''text
Напиши игру змейка на Python.
- Игровое поле должно иметь сетку
- игра должна иметь приятную цветовую гамму
- меню
- анимацию поедания еды
- интересную изюминку
'''

значение температуры установим 0 в соответствии с рекомендациями с сайта DeepSeek

Тестовая среда llama.cpp в docker контейнере запущенна в ubuntu 24.

примеры docker compose файлов

CPU

services:
  cpu-llm:
    container_name: cpu-${MODEL_NAME}-${TEMP:-0.0}
    image: ${IMAGE_CPU:-ghcr.io/ggml-org/llama.cpp:server}
    user: "${UID:-1000}:${GID:-1000}"
    ports:
      - "${PORT:-29004}:${PORT:-29004}"
    volumes:
      - ./${MODEL_DIR}:/models:ro
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    command: [
      "-m", "/models/${MODEL_FILE}",
      "--cache-type-k", "${CACHE_TYPE_K:-q4_0}",
      "--threads", "${THREADS:--1}",
      "--ctx-size", "${CTX_SIZE:-16384}",
      "--prio", "${PRIO:-3}",
      "--temp", "${TEMP:-0.0}",
      "--min-p", "${MIN_P:-0.01}",
      "--top-p", "${TOP_P:-0.95}",
      "--port", "${PORT:-29004}",
      "--host", "${HOST:-0.0.0.0}"
    ]
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:${PORT:-29004}/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 2m
    restart: unless-stopped

GPU+CPU

services:
  gpu_cpu-llm:
    container_name: gpu_cpu-${MODEL_NAME}-${TEMP:-0.0}
    image: ${IMAGE_GPU:-ghcr.io/ggml-org/llama.cpp:server-cuda}
    user: "${UID:-1000}:${GID:-1000}"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              capabilities: [gpu]
    ports:
      - "${PORT:-29004}:${PORT:-29004}"
    volumes:
      - ./${MODEL_DIR}:/models:ro
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    command: [
      "-m", "/models/${MODEL_FILE}",
      "--cache-type-k", "${CACHE_TYPE_K:-q4_0}",
      "--threads", "${THREADS:--1}",
      "--ctx-size", "${CTX_SIZE:-16384}",
      "--n-gpu-layers", "${GPU_LAYERS:-998}",
      "-ot", ".ffn_.*_exps.=CPU",
      "--prio", "${PRIO:-3}",
      "--temp", "${TEMP:-0.0}",
      "--min-p", "${MIN_P:-0.01}",
      "--top-p", "${TOP_P:-0.95}",
      "--port", "${PORT:-29004}",
      "--host", "${HOST:-0.0.0.0}"
    ]
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:${PORT:-29004}/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 2m
    restart: unless-stopped

результаты тестов

Потребление ресурсов

Для начала приведу сравнение потребляемых ресурсов. как видно что для всех моделей кроме самой маленькой нужен сервер с более чем 256 гб памяти. И только с UD-IQ2_M из представленных в тесте возможен переход в сборке на более бюджетные модули памяти по 32GB вместо модулей по 64GB.

Если есть знатоки почему q5-k-xl потребляет меньше памяти чем q4-k-xl при запуске только на CPU поделитесь пожалуйста в комментариях

Какие игры получились

Игры получились разными и, скажу, неплохими. Конечно они все были далеки от идеального кода но позволяли оценить как скорость генерации токенов итак и качество исполнения игры.
Так как в мою первоначальную задачу не входила оценка качества получаемого контента а основной целью я видел именно скорость то для удобства удобство оценки качества ответов я собрал все результате в одном GitHub репозитории. Вы можете сами посмотреть все 24 варианта игры.
Моё субъективное мнение что чем больше модель тем качественнее получалась игра, интереснее визуальная составляющая, интересные игровые механики. Конечно на сколько это возможно при таком маленьком запросе. Те результаты которые совсем не запускались или змейки не ели еду я отнёс к неудачным запускам. и отразил в дальнейшем на графике.
Далее я приведу несколько примеров на мой взгляд самых удачных вариантов игры. Все остальные варианты рекомендую посмотреть в репозитории для получения собственного мнения о качестве генерациии.

скорость генерации токенов в секунду

Для оценки скорости работы я не стал делать отдельные замеры на 1000, 2000 и 5000 токенов, а собрал в диаграмму все итоговые скорости по генерации и создал сводные графики. На графиках отчётливо видно зависимость скорости генерации токенов при уменьшении размера модели. Данная тенденция сохраняется как на CPU так и GPU+CPU.

В начале я собирался провести сравнение только скорости генерации токенов, но обратил внимание что маркеры ответов сдвигаются в право для более компактных версий. Данная тенденция говорит об увеличении длины ответа для более компактных моделей. Решил сравнить не только скорость генерации токена, но и общее время потраченное моделью на ответ.

Время ответа на запрос

Данные были также собраны в удобные графики и подсвечены те запуски которые по моему мнению вернули не корректное решение. Получившиеся данные стали для меня откровением. Оказалось что несмотря увеличение скорости генерации токена, общее время ответа растёт, модели дают ответы содержащие больше токенов. При этом ещё и снижается качество ответов.

Содержание репозитория на github

репозиторий
В репозитории содержиться:

• Два json файла с численными значениями результатов каждого запуска.

• Для каждый запуска сделано два файла:

  • .md содержит весь ответ целиком включая секцию размышления

  • .py содержит только код программы для удобства запуска

Выводы

Переходить на более компактные в случае с написанием кода и использование DeepSeek-R1 0528 не имеет смысла, так как это приводит к ухудшению качества генерируемого контента и к увеличению времени потраченному на получение ответа за счёт увеличения его длины. Если учитывать ещё и время потраченное на неудачные запуски, то ситуация становится ещё печальнее.