Как запустить Qwen 3.8 27B на VPS через Ollama

Можно ли запустить Qwen 3.8 27B на VPS без GPU?

Чтобы запустить Qwen 3.8 27B на VPS, сначала нужно найти существующий тег модели. По состоянию на 4 August 2026 в библиотеке Ollama вообще нет записи qwen3.8. Ближайший выпущенный тег 27B — qwen3.6:27b: 27.8 billion parameters, квантование Q4_K_M, лицензия Apache 2.0. Все команды и числа ниже используют этот тег в Ollama v0.32.5, выпущенном 27 July 2026.

Краткий ответ: да, на VPS с 32 GB RAM или больше, но медленно. Для весов плотной модели 27B в формате Q4 требуется около 17 GB RAM. Контекст при этом ещё не хранится. Поэтому тарифы с 8 GB и 16 GB RAM сразу исключаются. На обычном VPS с двухканальной DDR4 верхний предел составляет примерно 3 токенов в секунду. Это медленнее, чем большинство людей читает текст.

Откуда взялось число 3.8? Скорее всего, из количества параметров. На странице Ollama для qwen3.6:27b указано 27.8B parameters, и позже число 27.8 легко вспомнить как 3.8. Также существует qwen3.5:27b — та же сборка Q4_K_M из предыдущего выпуска. Перед копированием любой команды проверьте актуальный список на странице тегов qwen3.6 в Ollama. Если позже выйдет настоящий qwen3.8, приведённые здесь расчёты всё равно сохранят силу, поскольку они зависят от количества параметров и числа бит на вес, а не от номера версии.

Какой тег Ollama загрузить и как его проверить

Если загрузить несуществующий тег, Ollama выдаст понятную ошибку. Поэтому это легко проверить непосредственно на сервере. Существующий тег всё равно может не запускаться локально. Именно это часто вызывает проблемы с GLM 5.2, указанной в библиотеке, но доступной только через облако Ollama.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

Команда ollama show выводит архитектуру, количество параметров, размер контекста и квантование фактически установленного тега. Если строка с параметрами содержит 27.8B, а строка с квантованием — Q4_K_M, установлена сборка, для которой написано это руководство. В библиотеке также доступны qwen3.6:27b-q8_0 и qwen3.6:27b-bf16 с теми же весами в более высокой точности, а также набор тегов 35b-a3b — это модели MoE (mixture of experts), которые совершенно иначе работают на CPU. Подробнее об этом ниже.

Число параметров, умноженное на число байтов на вес

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Формула состоит из одной строки: число байтов весов = число параметров * число бит на вес / 8. При ровно 4 битах 27.8 миллиардов параметров занимали бы 13.9 GB. Размер поставляемого тега Q4_K_M составляет 17 GB. Это соответствует 4.89 битам на вес на практике.

Эта разница не является ошибкой. Форматы K-quant не хранят каждый тензор с номинальной разрядностью. Для тензоров, наиболее чувствительных к потере качества при сжатии, используют 5 или 6 бит. Таблицы token embedding и выходные слои обычно оставляют в Q6_K или Q8_0. Название формата отражает среднее значение, а фактическое среднее составляет около 4.9. Такой же эффект виден на другом конце шкалы: 56 GB для BF16 соответствуют 16.1 битам на вес, а не фиксированным 16, поскольку файл также содержит метаданные и таблицу embedding в полной точности.

Для этой модели нет опубликованного тега Q5_K_M, поэтому строка размером 19.8 GB рассчитана исходя из обычных 5.7 бит на вес для этого формата, а не измерена. Q8_0 почти вдвое увеличивает размер Q4 — до 30 GB. На сервере, где вычисления выполняются только на CPU, это удваивает объём трафика памяти на токен и примерно вдвое снижает скорость генерации в токенах в секунду. Поэтому Q4_K_M здесь является оптимальным вариантом по умолчанию. Если вас интересует влияние этого выбора на качество, а не на объём памяти, более подробное сравнение Q4, Q8 и fp16 показывает, в какой момент качество вывода начинает заметно снижаться.

Сколько стоит KV-кэш при увеличении контекста

Веса требуют фиксированный объём памяти. KV-кэш (кэш ключей и значений, состояние attention, которое модель хранит для каждого уже обработанного токена) растёт линейно вместе с длиной контекста. Именно из-за него чаще всего заканчивается RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Эти значения рассчитаны для архитектуры, которую Qwen использует в последних dense-моделях этого размерного класса: 64 слоя, 8 голов ключей и значений в режиме GQA (grouped-query attention) и размерность головы 128. При f16 это составляет 256 KiB на токен: 8 GB для 32k токенов и 32 GB для 128k. Не полагайтесь на мои расчёты для своей системы. Загрузите модель и прочитайте столбец SIZE в ollama ps. В нём общий объём весов, кэша и служебных данных указан одной цифрой.

Поэтому контекст 256K в карточке модели — это заявленная возможность, а не рабочий план. Заполнение такого контекста в f16 потребует 64 GB кэша сверх весов. При этом машина уже выделила 17 GB под веса. Ollama по умолчанию не выделяет всё окно. Она загружает гораздо меньшее окно, а его размер вы увеличиваете намеренно с помощью OLLAMA_CONTEXT_LENGTH. Эта переменная действует на уровне сервера и не является единственным способом управления размером контекста. Если задать num_ctx для отдельного запроса, можно сохранить небольшой размер по умолчанию для остальных запросов, а одному длительному заданию выделить большее окно. Увеличивайте значение поэтапно и после каждого изменения проверяйте ollama ps.

Два параметра сокращают объём кэша вдвое или ещё сильнее. OLLAMA_KV_CACHE_TYPE=q8_0 хранит кэш в 8 битах вместо 16, уменьшая объём для 32k токенов с 8 GB до 4 GB. Для этого требуется flash attention, поэтому также задайте OLLAMA_FLASH_ATTENTION=1 и проверьте уменьшение в ollama ps, а не предполагайте, что параметр применился. OLLAMA_NUM_PARALLEL=1 имеет такое же значение. Ollama может одновременно обслуживать несколько запросов, и каждый слот получает собственную часть контекста. Поэтому значение parallelism по умолчанию незаметно умножает объём кэша, который вы заложили в расчёт. Если этой машиной будут пользоваться несколько человек, именно это умножение создаёт проблему. Количество одновременных пользователей, которых может обслуживать self-hosted-модель, определяется слотами кэша и длиной очереди задолго до того, как становится важным количество ядер.

Что помещается в 8, 16, 32 и 64 GB RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Воспринимайте эти два числа как количество тысяч токенов контекста, которое помещается вместе с весами при кэше f16 на headless Linux VPS, где около 1.5 GB остаётся операционной системе и небольшому запасу. Ноль означает, что сами веса не помещаются и контекст не помещается тоже.

8 GB и 16 GB — это не пограничные варианты. 17 GB весов не помещаются в 16 GB RAM, и никакая настройка контекста это не изменит. Добавление swap также не поможет. Ollama отображает файл GGUF в память, поэтому после того, как объём resident pages превышает доступную RAM, kernel начинает вытеснять их и считывать заново. В результате каждый токен обращается к гигабайтам данных на диске. Сервер работает с высоким iowait и выдаёт значительно меньше одного токена в секунду.

32 GB — минимальный практичный объём. Веса занимают 17 GB, и остаётся примерно 13 GB. Этого достаточно примерно для 32k токенов контекста f16 с запасом. Веса Q8_0 объёмом 30 GB на этом уровне вообще не помещаются.

64 GB — комфортный вариант. Для Q4 остаётся место примерно для 128k токенов контекста, а после загрузки весов Q8_0 остаётся примерно 64k токенов. Прежде чем платить за 64 GB ради Q8, чётко определите, что именно вы покупаете: немного более качественный вывод при вдвое меньшей скорости на машине, которая и без того работала медленно. Для большинства пользователей Q4 с более длинным контекстом — более разумный компромисс.

Насколько быстро выполняется inference на CPU в VPS?

Генерация одного токена dense-моделью означает однократное чтение из памяти каждого веса. Не части весов, а всех. Поэтому скорость ограничивается не количеством ядер, а пропускной способностью памяти, делённой на размер весов. При Q4 это 17 GB данных памяти на один токен.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Это теоретические пределы, а не результаты измерений. На практике скорость составляет примерно 50–70 процентов от указанного значения: из-за задержек памяти и несовершенного предварительного чтения достичь теоретического пика невозможно. Для VPS с двухканальной DDR4-3200 предел составляет 3 токенов в секунду, поэтому ожидайте около 2. Для сервера с двухканальной DDR5-4800 предел составляет 4.5, поэтому ожидайте около 3.

Для серверов верхнего уровня требуется оговорка. Платформа EPYC с двенадцатью каналами памяти обеспечивает 460.8 GB/s и имеет предел 27.1 токенов в секунду. Но вы не арендуете целый EPYC. Пропускная способность памяти является общим ресурсом хоста и распределяется между всеми его арендаторами, поэтому выделенный фрагмент с 8 vCPU не получает двенадцать каналов эксклюзивной пропускной способности. Руководства по системам, ориентированным на GPU, обычно полностью игнорируют этот фактор. Именно поэтому два VPS-плана с одинаковым количеством vCPU могут отличаться по скорости в три раза на одной и той же модели.

Увеличение количества vCPU по той же причине перестаёт помогать уже на раннем этапе. Когда ядра запрашивают данные быстрее, чем контроллер памяти может их предоставить, дополнительные потоки только увеличивают накладные расходы планировщика. Установите OLLAMA_NUM_THREAD равным количеству физических ядер, выполните измерение, затем попробуйте уменьшить это значение вдвое. Во многих shared-планах меньшее значение работает быстрее.

Обработка prompt выполняется иначе. Prefill — обработка входных данных до появления первого токена — ограничена производительностью CPU, а не пропускной способностью памяти, поэтому её скорость растёт с увеличением количества ядер. На практике это означает длительную паузу перед началом вывода для большого prompt, после которой начинается медленная стабильная генерация с указанной выше скоростью. Измеряйте обе части отдельно с помощью --verbose. Эта команда выводит prompt eval rate и eval rate для каждого запроса.

Если dense-модель 27B работает слишком медленно, перед отказом от CPU проверьте теги qwen3.6:35b-a3b. Они активируют примерно 3 миллиарда параметров на токен вместо всех 27.8 миллиардов. Поэтому объём данных памяти на токен уменьшается почти на порядок, хотя файл на диске становится больше. Вы жертвуете объёмом RAM ради скорости. Выбор runtime также имеет значение: Ollama и llama.cpp предоставляют разные средства настройки CPU для одного и того же базового кода inference.

Когда вместо этого стоит арендовать GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Та же формула, применённая к опубликованной пропускной способности памяти GPU, даёт ответ уже другой категории. Потребительская карта с 24 GB имеет для этих весов предел 59 токенов в секунду. Современная карта для дата-центров достигает 197. Сократить такой разрыв настройкой количества потоков нельзя. Память карты работает со скоростью 1008 GB/s, тогда как VPS обеспечивает десятки GB/s.

Поэтому границу следует проводить по рабочей нагрузке, а не по предпочтениям. CPU-инференс подходит, когда задача выполняется асинхронно и результат не нужен сразу: например, для ночного суммирования набора документов или классификации, которая запускается, пока вы спите. GPU стоит арендовать сразу, как только пользователь начинает ждать результат или запросы поступают чаще одного раза в 30 секунд. У сервера только с CPU нет запаса для пакетной обработки, поэтому очередь будет расти.

Сравнение стоимости не так очевидно, как может показаться. VPS с 64 GB оплачивается каждый час месяца независимо от того, загружена модель или нет. Экземпляр с GPU оплачивается только за время работы. Если фактическая нагрузка составляет два часа в день, арендованный GPU может оказаться одновременно быстрее и дешевле. Сначала определите коэффициент использования, затем сравните стоимость. В разделе Выбор VPS с GPU описано, что проверять в самом экземпляре, а vLLM опережает Ollama при обслуживании параллельных запросов на GPU, поскольку корректно объединяет их в пакеты.

Есть и третий вариант, о котором часто забывают. Оставьте модель 27B на CPU для пакетных задач, а перед интерактивным контуром разместите модель через hosted API. Ничто не требует, чтобы одна модель обслуживала оба сценария.

Установите Ollama и измерьте производительность своего компьютера

Скрипт установки является официальным. Он создаёт systemd-сервис, который запускается от имени отдельного пользователя ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

Команда ollama --version должна вывести версию 0.32.5 или более позднюю. Проверьте free -g до загрузки чего-либо. Если в строке Mem столбец total показывает значение меньше 32, остановитесь и выберите модель меньшего размера. Загрузка 17 GB, которые невозможно запустить, напрасно займёт час и значительный объём диска.

Задайте параметры запуска в переопределении systemd, а не в оболочке. Модель работает внутри сервиса, поэтому она не видит интерактивное окружение.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

Вывод --verbose содержит нужные результаты измерения. eval rate — это скорость генерации в токенах в секунду. prompt eval rate — скорость предварительной обработки входных данных. load duration — время чтения весов с диска. Поэтому задан параметр OLLAMA_KEEP_ALIVE=60m: на CPU повторная загрузка 17 GB с диска при каждом запросе занимает больше времени, чем обработка самого запроса. Тайм-аут простоя по умолчанию составляет пять минут. Этого недостаточно для пакетной очереди с паузами между элементами: стоимость загрузки будет возникать снова и снова. Параметры постоянного хранения модели в памяти включают поле keep_alive для отдельного запроса и настройку, сохраняющуюся после перезагрузки.

Пока модель загружена, проверьте занимаемый объём памяти из второго терминала.

ollama ps

Столбец SIZE показывает фактический объём памяти, включая KV-кэш. Он должен быть близок к размеру весов плюс значению для выбранной длины контекста в таблице KV. Для 8192 токенов и 8-битного кэша ожидайте примерно один дополнительный гигабайт сверх размера весов. Если бы кэш хранился в формате f16, это значение составляло бы 2 GB. В столбце PROCESSOR должно быть указано 100% CPU. Если указано другое значение, какой-либо процесс занял GPU, и показатели скорости из этого руководства не описывают ваш компьютер.

Сценарии отказа и точные строки, которые вы увидите

Модель не загружается. Ollama выводит строку с обоими значениями в формате model requires more system memory (18.6 GiB) than is available (15.2 GiB). Это штатный вариант отказа: Ollama выполнила проверку до выделения памяти, а не передала решение ядру. Уменьшите длину контекста, выберите меньший tag или перейдите на более мощный план.

Процесс завершается в середине ответа. Клиент не показывает полезной информации, а journalctl -u ollama -n 50 показывает, что сервис перезапускается. Выполните dmesg -T | tail. Строка Out of memory: Killed process ... (ollama) означает, что процесс завершил kernel OOM killer. Это происходит, когда предварительная проверка завершается успешно, но во время долгого диалога cache вырастает больше расчётного значения. Уменьшите длину контекста.

Загрузка завершается сразу с ошибкой. Error: pull model manifest: file does not exist означает, что tag отсутствует в library. Команда qwen3.8:27b выдаёт именно эту ошибку. То же происходит при любой опечатке в номере версии. Проверьте tag на странице library, прежде чем искать причину в сети.

Всё работает, но система работает неприемлемо медленно. Скорость ниже одного token в секунду на сервере с достаточным объёмом RAM указывает на paging, а не на недостаток вычислительной мощности. Выполните vmstat 1 во время генерации. Ненулевое значение в столбце si или so означает, что kernel использует swap. Уменьшите контекст или число загруженных моделей. Стабильно высокое значение wa без активности swap означает, что memory-mapped weights повторно считываются с диска. Это значит, что они фактически не помещаются в памяти.

Первый token появляется через 30 секунд, затем вывод ускоряется. Это prefill, и такое поведение нормально. Длинный system prompt обрабатывается заново для каждого запроса, который не использует cache. Поэтому сначала сократите system prompt, а уже затем меняйте другие параметры.

Для чего на самом деле подходит модель 27B, работающая только на CPU

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

Главное преимущество связано с конфиденциальностью. Модель работает на оборудовании, которое вы арендуете и контролируете. Ни один запрос не покидает сервер. Плата за каждый токен отсутствует. Для регулируемых данных это много значит даже при скорости три токена в секунду. Честно сравните такой вариант с альтернативой: для самостоятельного размещения модели frontier-класса требуется на порядок больше оборудования, а модель 27B на CPU — самая доступная точка на этой кривой, где результат всё ещё стоит читать.

Чтобы проверить эти характеристики, нужны реальные структурированные данные. Большинство общедоступных API данных требуют создать учётную запись ещё до измерения пропускной способности. Демонстрационный endpoint Strasmore (мы его поддерживаем) выполняет read-only SQL-запросы к данным рынка США за 22 года без ключа и регистрации. GET-запрос к https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 возвращает JSON, который можно напрямую передать в цикле запросов к модели. Вместе с ним возвращается точный SQL, сформировавший результат, поэтому полученные данные можно независимо проверить. Ограничения составляют 500 строк и 20 секунд на вызов. Для системы со скоростью два токена в секунду этого более чем достаточно. Полный список столбцов находится по адресу https://api.strasmore.com/v1/schema.

Если вы впервые устанавливаете Ollama, полное руководство по запуску Ollama на VPS описывает настройку сервиса, HTTP API и правила firewall, которые предполагаются в этом руководстве. Не открывайте порт 11434 в Интернет. Ollama не содержит собственной аутентификации, поэтому любой клиент, получивший доступ к порту, сможет использовать вашу модель и читать ваши запросы.

FAQ

Есть ли в Ollama модель Qwen 3.8 27B?

Нет. По состоянию на 4 августа 2026 года в библиотеке Ollama нет пространства имён qwen3.8. Существующие теги для 27B — это qwen3.5:27b и qwen3.6:27b, оба представляют собой сборки Q4_K_M плотной модели с 27.8 миллиарда параметров. Число 3.8 в поисковом запросе почти наверняка является количеством параметров 27.8B, которое запомнили как номер версии. Проверьте https://ollama.com/library/qwen3.6/tags, чтобы получить актуальный список, и загрузите qwen3.6:27b, если нужна самая новая выпущенная модель 27B. Несуществующий тег приводит к ошибке Error: pull model manifest: file does not exist.

Сколько RAM нужно для запуска модели Qwen 27B на VPS?

Для Q4_K_M практически необходимы 32 GB. Веса занимают 17 GB, операционной системе требуется около 1.5 GB, а KV cache добавляет примерно 1 GB на каждые 4000 токенов контекста при f16. Тариф на 16 GB вообще не позволяет разместить веса, а swap не помогает, поскольку файл отображается в память, и ядро просто повторно читает его с диска для каждого токена. Объём 64 GB оставляет место для длинного контекста или весов Q8_0 размером 30 GB.

Сколько токенов в секунду будет выдавать модель 27B на CPU?

Разделите пропускную способность памяти на размер весов и возьмите от 50 до 70 процентов результата. VPS с двухканальной DDR4-3200 имеет теоретический предел около 3 токенов в секунду и обычно выдаёт около 2. Сервер с двухканальной DDR5-4800 имеет теоретический предел около 4.5 и обычно выдаёт около 3. Серверные платформы с большим числом каналов выглядят намного лучше на бумаге, но пропускная способность памяти распределяется между всеми арендаторами на хосте. Поэтому измерьте показатель самостоятельно с помощью ollama run qwen3.6:27b --verbose и прочитайте строку eval rate.

Что выбрать для VPS только с CPU: Q4 или Q8?

Почти всегда — Q4_K_M. Q8_0 занимает 30 GB вместо 17 GB, поэтому для него нужен тариф на 64 GB. Кроме того, он перемещает почти вдвое больше данных памяти для каждого токена, что примерно вдвое снижает скорость генерации. Для большинства задач разница в качестве между Q4_K_M и Q8_0 у модели 27B невелика. Лучше направить RAM на увеличение контекста: это меняет возможности модели, а не только формулировки её ответов.

Когда аренда GPU дешевле VPS с большим объёмом RAM?

Когда загрузка низкая или результата ждёт человек. GPU с 24 GB памяти выдаёт на этих весах примерно 59 токенов в секунду против 2 или 3 на обычном VPS и оплачивается только за часы работы. VPS с 64 GB оплачивается весь месяц независимо от того, загружена модель или нет. Определите, сколько часов в день вам действительно нужно генерировать токены. При нагрузке менее двух или трёх часов в день почасовая аренда GPU обычно выгоднее и по скорости, и по стоимости. Для непрерывной пакетной обработки с низким приоритетом VPS, работающий постоянно, выгоднее.