Qwen 3.8 27B на VPS через Ollama: требования

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

Чтобы запустить Qwen 3.8 27B на VPS, сначала нужно убедиться, что существует соответствующий тег модели. По состоянию на 4 августа 2026 года в библиотеке Ollama вообще нет записи qwen3.8. Ближайший выпущенный тег для 27B — qwen3.6:27b: 27.8 миллиарда параметров, квантование Q4_K_M, лицензия Apache 2.0. Во всех командах и числах ниже используется этот тег в Ollama v0.32.5, выпущенном 27 июля 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 параметров, и число 27.8 со временем легко запомнить как 3.8. Также существует qwen3.5:27b — та же сборка Q4_K_M из предыдущего выпуска. Перед копированием любой команды проверьте актуальный список на странице тегов qwen3.6 в Ollama. Если позже выйдет настоящий qwen3.8, приведённые здесь расчёты всё равно останутся применимыми, поскольку они зависят от количества параметров и числа бит на вес, а не от номера версии.

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

Если загрузить несуществующий тег, 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 и output обычно оставляют в формате 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 здесь является оптимальным вариантом по умолчанию.

Сколько занимает 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. Это составляет 256 KiB на токен при f16: 8 GB для 32k токенов и 32 GB для 128k. Не полагайтесь на этот расчёт вместо проверки на своей системе. Загрузите модель и посмотрите столбец SIZE в ollama ps. В нём общий объём включает веса, кэш и служебные данные.

Поэтому контекст 256K, указанный на странице модели, — это скорее максимальное значение, чем практический план. Заполнение всего окна при f16 потребует 64 GB кэша сверх объёма весов. При этом на веса на машине уже занято 17 GB. Ollama по умолчанию не выделяет всё окно. Она загружает значительно меньшее окно, а увеличить его можно вручную через OLLAMA_CONTEXT_LENGTH. Увеличивайте значение поэтапно и после каждого изменения проверяйте 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 по умолчанию незаметно увеличивает общий объём кэша, который нужно учитывать.

Что помещается в 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."
  }
]

Считайте эти два числа тысячами токенов контекста, которые помещаются вместе с весами при cache 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 с более длинным контекстом — более разумный компромисс.

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

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

[
  {
    "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 ГБ/с и верхний предел 27.1 токенов в секунду. Но в аренду обычно предоставляется не весь EPYC. Пропускная способность памяти является общим ресурсом всего хоста, которым пользуются все арендаторы этой машины. Поэтому срез 8 vCPU не получает двенадцать каналов выделенной пропускной способности. В руководствах, посвящённых GPU, это обычно не учитывается. Именно поэтому два VPS-тарифа с одинаковым количеством vCPU могут различаться по скорости в 3 раза на одной и той же модели.

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

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

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

Когда выгоднее арендовать 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-инстанс оплачивается только за время работы. Если фактическая нагрузка составляет 2 часа в день, арендованный 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, которую невозможно запустить, зря занимает час и значительный объём диска.

Задайте параметры запуска в override-файле 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 с диска для каждого запроса занимает больше времени, чем обработка самого запроса.

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

ollama ps

Столбец SIZE показывает фактический объём памяти, включая KV cache. Он должен быть близок к размеру весов плюс значению для выбранной длины контекста в таблице KV. При длине контекста 8192 токенов и 8-битном cache ожидайте примерно один гигабайт сверх размера весов. Если бы cache оставался в формате 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

Ориентируйтесь на фактические показатели, а не на ожидания. При скорости от 2 до 4 токенов в секунду ответ на 500 токенов занимает от 2 до 4 минут. Для чата это непригодно, но для очереди задач подходит. Суммаризация документов, массовая разметка, извлечение полей из накопившихся файлов и автоматическая проверка кода допускают такую скорость, поскольку результат не нужно получать немедленно.

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

Если вы впервые устанавливаете 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. Если нужна самая новая выпущенная модель 27B, выполните pull для qwen3.6: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 не помогает, потому что файл отображается в память, и kernel просто повторно читает его с диска для каждого токена. Объём 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.

Использовать Q4 или Q8 на VPS только с CPU?

Почти всегда 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. Оплата GPU начисляется только за часы работы. VPS с 64 GB оплачивается весь месяц независимо от того, загружена модель или нет. Посчитайте, сколько часов в день действительно требуется для генерации токенов. При нагрузке менее двух или трёх часов в день почасовая аренда GPU обычно выигрывает и по скорости, и по стоимости. Для непрерывной пакетной обработки с низким приоритетом выгоднее постоянно работающий VPS.