Запуск Qwen 3.8 27B через Ollama на VPS: требования к ОЗУ

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

Для запуска Qwen 3.8 27B на VPS вам потребуется тег qwen3.8:27b. По состоянию на 21 октября 2026 года библиотека Ollama содержит его как локально доступный тег: 27,3 миллиарда параметров, квантование Q4_K_M, лицензия Apache 2.0, контекстное окно 256K и загружаемый файл объемом 18 ГБ, включающий vision projector размером около 0,9 ГБ. Поддержка Qwen 3.8 27B была добавлена в Ollama в версии v0.32.12, выпущенной 14 августа 2026 года, поэтому более старую установку необходимо сначала обновить. На 29 октября 2026 года последним стабильным релизом является v0.40.13, опубликованный 28 октября 2026 года.

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

Более ранние теги 27B по-прежнему доступны в библиотеке: qwen3.6:27b и qwen3.5:27b представляют собой сборки Q4_K_M аналогичного размера. Qwen3.8-27B сохраняет архитектуру Qwen3.6-27B, и официальные файлы конфигурации для них задают одинаковую структуру слоев, поэтому приведенные ниже расчеты памяти применимы к обеим моделям. Перед выполнением любой команды проверяйте актуальный список на странице тега qwen3.8 в Ollama. Приведенные здесь расчеты зависят от количества параметров, бит на вес и структуры внимания, а не от номера версии.

Какой тег Ollama выбрать и как проверить

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

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama show выводит архитектуру, количество параметров, длину контекста и квантование для тега, который у вас уже есть. Если в строке параметров указано 27.3B, а в строке квантования — Q4_K_M, значит, у вас установлена сборка, для которой написано это руководство. В библиотеке также представлены qwen3.8:27b-q8_0 и qwen3.8:27b-bf16 для тех же весов с более высокой точностью, варианты 27b-mtp, а также теги 27b-nvfp4, 27b-mxfp8, 27b-mlx и 27b-mlx-bf16, которые на странице тегов помечены как MLX — формат, предназначенный для Apple Silicon, а не для Linux VPS. В отличие от qwen3.6, запись qwen3.8 не имеет тегов 35b-a3b. Эти модели MoE (mixture of experts) по-прежнему находятся в категории qwen3.6 и ведут себя совершенно иначе при работе на CPU. Подробнее об этом ниже.

Расчет объема памяти по количеству параметров и весов

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

Формула выглядит следующим образом. Байты весов = параметры * бит на вес / 8. При честных 4 битах 27,3 миллиарда параметров занимают 13,7 ГБ. Файл языковой модели в поставляемом теге Q4_K_M имеет размер 17 ГБ, что на практике составляет 4.98 бит на вес.

Этот разрыв не является ошибкой. Форматы K-quant не хранят каждый тензор с номинальной разрядностью. Тензоры, которые теряют больше всего качества при сжатии, получают больше бит. Список тензоров Ollama для поставляемого файла qwen3.8:27b показывает, что в формате Q6_K хранятся: выходной слой, около половины нисходящих проекций (down projections) полносвязных слоев, проекции V (value) механизма внимания примерно в половине слоев с полным вниманием, а также около половины объединенных проекций QKV в слоях с линейным вниманием. Небольшие тензоры нормализации остаются в полной 32-битной точности. Токенизированные эмбеддинги, проекции Q и K механизма внимания, а также гейтовые и восходящие проекции полносвязных слоев остаются в формате Q4_K, как и большая часть модели. Название формата отражает среднее значение, которое приближается к 5. Тот же эффект наблюдается и на другом конце шкалы: 55 ГБ для BF16 соответствует 16.1 бит на вес, а не ровно 16. В этом случае токенизированные эмбеддинги представлены в BF16, как и все остальное, а небольшой избыток объема обусловлен метаданными файла, тензорами нормализации, которые хранятся в 32-битном формате, и округлением итогового размера до ближайшего гигабайта.

Планируйте ресурсы для всего тега, а не только для файла языковой модели. Каждый GGUF-тег qwen3.8:27b также содержит проектор зрения объемом около 0,9 ГБ, поэтому тег Q4_K_M указан как 18 ГБ.

Для Q5_K_M в официальной библиотеке qwen3.8 нет опубликованного тега, поэтому значение 19.5 ГБ для этой строки является расчетным (исходя из стандартных 5,7 бит на вес для данного формата), а не измеренным. Q8_0 почти удваивает объем Q4 до 29 ГБ. На системе, работающей только на CPU, это удвоение увеличивает нагрузку на память в два раза на каждый токен, что примерно вдвое снижает скорость генерации токенов в секунду. Уже по одной этой причине Q4_K_M является оптимальным выбором по умолчанию. Если вас интересует вопрос качества, а не потребления памяти, более детальное сравнение Q4, Q8 и fp16 показывает, на каком этапе качество вывода начинает снижаться.

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

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

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

Эти цифры взяты из конфигурационного файла модели. Qwen3.8-27B, как и Qwen3.6-27B, является моделью с гибридным механизмом внимания. Только 16 из 64 слоев используют полное внимание и хранят кэш, растущий с каждым токеном; эти слои имеют 4 головы ключей/значений в рамках GQA (grouped-query attention) с размерностью головы 256. Остальные 48 слоев используют линейное внимание (Gated DeltaNet) и хранят состояние фиксированного размера, которое, по моим расчетам, составляет около 150 МБ на слот диалога независимо от длины контекста. Это дает 64 КБ на токен в формате f16, что составляет 2 ГБ при 32k токенов и 8 ГБ при 128k. Не полагайтесь на мои расчеты больше, чем на показатели вашей системы. Загрузите модель и изучите столбец SIZE в ollama ps, где суммируются веса, кэш и накладные расходы.

Контекст 256K, указанный в карточке модели, достижим на этой архитектуре, но требует ресурсов. Заполнение такого контекста в формате f16 потребует около 16 ГБ кэша сверх весов, на машине, которая уже потратила 17 ГБ на сами веса. Ollama не предоставляет полное окно по умолчанию. Документация по длине контекста определяет значения в зависимости от объема VRAM: 4k токенов при объеме менее 24 ГБ, 32k при объеме от 24 до 48 ГБ и 256k при 48 ГБ и более. На VPS без GPU нет VRAM, поэтому применяется уровень 4k, а увеличить его можно принудительно через OLLAMA_CONTEXT_LENGTH. Эта глобальная переменная — не единственный способ управления; настройка num_ctx для отдельного запроса позволяет сохранить экономные настройки по умолчанию для всех задач, выделив большее окно только для одной длительной операции. Увеличивайте значение постепенно и проверяйте ollama ps после каждого изменения.

Две настройки позволяют ограничить размер кэша. OLLAMA_KV_CACHE_TYPE=q8_0 сохраняет кэш в 8-битном формате вместо 16-битного, что уменьшает объем для 32k токенов с 2 ГБ до 1 ГБ. Для этого требуется flash attention, поэтому также установите OLLAMA_FLASH_ATTENTION=1 и убедитесь в снижении потребления через ollama ps, вместо того чтобы предполагать, что настройка применилась. Если вы ранее не меняли тип кэша, руководство по сравнению q8_0 и f16 для KV-кэша в Ollama описывает процесс установки обеих переменных и сравнение показателей до и после. OLLAMA_NUM_PARALLEL=1 имеет не меньшее значение. Ollama может обрабатывать несколько запросов одновременно, и каждый слот получает свою часть контекста, поэтому увеличение параллелизма незаметно умножает объем кэша, который вы запланировали. Текущее значение по умолчанию равно 1, и приведенный ниже параметр принудительно фиксирует его на этом уровне. Если сервером будет пользоваться более одного человека, именно это умножение станет источником проблем, а количество одновременных пользователей, которое может обслужить локальная модель определяется количеством слотов кэша и глубиной очереди задолго до того, как на это повлияет количество ядер процессора.

Что помещается в 8, 16, 32 и 64 ГБ оперативной памяти

[
  {
    "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": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

Рассматривайте эти два числа как тысячи токенов контекста, которые помещаются вместе с весами и vision projector при кэше f16 на headless Linux VPS, где около 1.5 ГБ остается для операционной системы и небольшого запаса сверху. Ноль означает, что сами веса не помещаются, поэтому ничего не поместится; null означает, что веса помещаются, но для этого уровня не подтверждено значение полезного контекста.

8 ГБ и 16 ГБ — это не пограничные случаи. 17 ГБ весов не помещаются в 16 ГБ оперативной памяти, и никакие настройки контекста это не изменят. Добавление swap также не поможет. Ollama использует memory-map для GGUF-файла, поэтому, как только резидентные страницы превышают объем RAM, ядро начинает вытеснять их и считывать заново, и каждый токен начинает вытягивать гигабайты с диска. Сервер переходит в состояние высокого iowait и выдает значительно меньше одного токена в секунду.

32 ГБ — это точка входа. Веса занимают 17 ГБ, vision projector добавляет около 0.9 ГБ, и у вас остается примерно 12.5 ГБ, что покрывает около 128k токенов контекста f16 с запасом. Веса Q8_0 размером 29 ГБ помещаются в 32 ГБ, но полезный контекст также зависит от vision projector, кэша, операционной системы и памяти среды выполнения. Проверьте общий объем занимаемой памяти на вашем сервере, прежде чем считать Q8 пригодным для запуска на этом уровне.

64 ГБ — это комфортный объем. Q4 оставляет место для полного окна в 256k, а веса Q8_0 помещаются вместе с полным контекстом в 256k. Прежде чем платить за 64 ГБ ради Q8, четко осознайте, за что вы платите: немного лучшее качество вывода при вдвое меньшей скорости на машине, которая и так была медленной. Q4 уже достигает 128k токенов на плане 32 ГБ, и для большинства это более выгодный вариант.

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

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

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

Если плотная модель 27B работает слишком медленно, обратите внимание на теги qwen3.6:35b-a3b, прежде чем отказываться от CPU. Они активируют примерно 3 миллиарда параметров на токен вместо всех 27.3 миллиардов, поэтому объем трафика памяти на токен снижается почти на порядок, даже если размер файла на диске больше. Вы жертвуете объемом оперативной памяти ради скорости. Выбор среды выполнения (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 в тот момент, когда пользователь ждет вывода или когда запросы поступают быстрее, чем ваш сервер успевает их обрабатывать. Среды выполнения на CPU не ограничены одним запросом: сервер llama.cpp поддерживает параллельное декодирование и непрерывную пакетную обработку (continuous batching) как на CPU, так и на GPU, а Ollama также может обслуживать параллельные запросы ценой большего потребления кэша. Решающим фактором является соотношение измеренной скорости обслуживания к скорости поступления запросов, поэтому замерьте время обработки типичного пакета на своем оборудовании. Как только запросы начинают поступать быстрее, очередь растет.

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

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

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

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

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

ollama --version должен выводить версию 0.32.12 или выше — это первый релиз с поддержкой Qwen 3.8 27B. Проверьте free -g перед тем, как загружать модели. Утилита отображает данные в ГиБ, поэтому на сервере с заявленными 32 ГБ ОЗУ в столбце total может отображаться около 29 ГБ; сравните доступный объем памяти с весами модели и бюджетом кэша, указанными выше.

Настраивайте параметры среды выполнения через 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.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

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

Пока модель загружена, проверьте потребление ресурсов из второго терминала.

ollama ps

Столбец SIZE показывает реальный объем занимаемой памяти, включая KV-кэш. Это значение должно быть близко к сумме весов, проектора зрения и строки для вашей длины контекста в таблице KV. При 8192 токенах и 8-битном кэше растущая часть кэша составляет всего около четверти гигабайта, в отличие от 0.5 ГБ при использовании f16, плюс фиксированное состояние линейного внимания (linear-attention). В столбце PROCESSOR должно быть указано 100% CPU. Если там указано что-то другое, значит, какой-то процесс занял GPU, и показатели скорости из этого руководства не соответствуют вашей системе.

Режимы сбоев и точные сообщения, которые вы увидите

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

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

Загрузка (pull) завершается ошибкой сразу. Error: pull model manifest: file does not exist означает, что тег отсутствует в библиотеке. Версия, которая еще не была выпущена, вызывает именно эту ошибку, как и любая опечатка в теге. Сам qwen3.8:27b существует, поэтому, если этот конкретный тег не загружается, сначала проверьте его на наличие опечаток. Подтвердите существование тега на странице библиотеки, прежде чем винить сеть. Если существующий тег загружается, но не запускается, сравните ollama --version с версией 0.32.12.

Все работает, но крайне медленно. Скорость менее одного токена в секунду на системе с достаточным объемом ОЗУ указывает на подкачку (paging), а не на нехватку вычислительной мощности. Запустите vmstat 1 во время генерации. Ненулевое значение в столбце si или so означает, что ядро использует swap; решение — уменьшить контекст или количество загруженных моделей. Постоянно высокая нагрузка wa при отсутствии активности swap означает, что веса, отображенные в память (memory-mapped), постоянно считываются с диска заново, что свидетельствует об их нехватке в оперативной памяти.

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

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

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

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

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

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

FAQ

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

Да. По состоянию на 21 октября 2026 года в библиотеке Ollama есть запись qwen3.8, а qwen3.8:27b (также с тегом latest) представляет собой сборку Q4_K_M размером 18 ГБ для плотной модели с 27,3 миллиардами параметров, оснащенную визуальным проектором и контекстным окном на 256K токенов. Она запускается локально и требует Ollama версии v0.32.12 или новее. Более старые теги qwen3.6:27b и qwen3.5:27b по-прежнему доступны в списке. Актуальный список можно проверить по ссылке https://ollama.com/library/qwen3.8/tags. Если тег не существует, команда завершается с ошибкой Error: pull model manifest: file does not exist.

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

32 ГБ — это практический минимум для версии Q4_K_M. Веса модели занимают 17 ГБ, визуальный проектор добавляет около 0,9 ГБ, операционной системе требуется около 1,5 ГБ, а KV-кэш добавляет примерно 1 ГБ на каждые 16 000 токенов контекста в формате f16, так как только 16 из 64 слоев модели поддерживают растущий кэш. Тарифный план с 16 ГБ памяти не сможет вместить веса модели, а использование swap не поможет, так как файл отображается в память (memory-mapped), и ядро будет постоянно считывать его с диска при генерации каждого токена. 64 ГБ памяти позволят использовать полное окно в 256K токенов, даже с весами Q8_0 размером 29 ГБ.

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

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

Что лучше использовать на VPS без GPU: Q4 или Q8?

Почти во всех случаях — Q4_K_M. Веса Q8_0 занимают 29 ГБ против 17 ГБ у Q4_K_M. Они помещаются в 32 ГБ, но проектор, кэш, операционная система и среда выполнения почти не оставляют свободного места; 64 ГБ памяти дадут возможность использовать длинный контекст. При работе с Q8_0 объем данных, считываемых из памяти на каждый токен, почти удваивается, что примерно вдвое снижает скорость генерации. Разница в качестве ответов между Q4_K_M и Q8_0 для модели 27B в большинстве задач невелика. Лучше потратить оперативную память на увеличение длины контекста, так как это меняет функциональные возможности модели, а не просто стиль её речи.

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

Когда нагрузка невелика или когда модель используется в интерактивном режиме. GPU с 24 ГБ памяти имеет теоретический предел около 59 токенов в секунду для данных весов, против 2–3 токенов на обычном VPS. Почасовая оплата за GPU прекращается, когда экземпляр остановлен, хотя за постоянное хранилище данных все равно придется платить. VPS с 64 ГБ памяти оплачивается весь месяц, независимо от того, загружена модель или нет. Рассчитайте, сколько часов в день вы действительно генерируете токены. Точка окупаемости зависит от тарифов аренды, времени работы и стоимости хранения данных. Постоянная фоновая пакетная обработка — это сценарий, в котором выгоднее использовать постоянно включенный VPS.