Сколько памяти нужно для развёртывания Qwen3.5 на CPU в 2026 году? Сначала рассчитайте модель, затем выберите сервер

Модель не загружается, хотя её файл помещается на диске? Обычно при оценке забывают о контексте и службах, работающих рядом.

Победитель для тестов, редких запросов и пакетной обработки — CPU-only, если измеренный пик памяти помещается с запасом; для высокой пропускной способности или множества одновременных запросов выбирайте GPU-ресурс, а не просто сервер с большим объёмом RAM.

Эта инструкция для разработчиков и небольших команд, которые планируют самостоятельно разместить Qwen3.5 и пока не знают, сколько памяти заложить. Она поможет отдельно оценить модель, контекст и соседние процессы, а затем решить, соответствует ли CPU требованиям к задержке и нагрузке.

Последняя проверка — 24 октября 2026 года. Сведения сверены с официальным репозиторием Qwen3.5 и каталогом моделей Ollama; доступные теги и характеристики файлов нужно проверить повторно перед развёртыванием.

Память модели: начальная оценка, а не ответ целиком

Начните с конкретного файла модели, который планируется загрузить, а не с названия семейства. В репозитории Qwen3.5 проверьте тип и карточку выбранной модели, лицензию и доступные файлы. В каталоге Ollama найдите именно тот тег, который будет использоваться в проекте, и сверяйте размер соответствующего файла. Теги, квантования и состав каталога могут меняться.

Для первой оценки весов используйте формулу:

число параметров × разрядность квантования ÷ 8 = ориентировочный объём весов в байтах.

Разрядность здесь выражена в битах; деление на 8 переводит биты в байты. Это оценка нижнего уровня, а не обещание, что такой объём оперативной памяти будет достаточен. Файл модели может включать дополнительные данные, а формат хранения, метаданные, буферы загрузки и реализация конкретного движка влияют на фактическое потребление.

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

Сколько оперативной памяти нужно Qwen3.5 на сервере без GPU? Универсального значения нет: оно зависит от конкретной модели, квантования, контекста, движка и соседних служб. Запуск считается возможным только после проверки фактического пика на целевой конфигурации; размер файла сам по себе не определяет нужный объём RAM.

Последовательность измерений

1. Зафиксируйте целевую модель. Запишите точный тег и квантование. Сохраните ссылку на карточку и проверьте условия лицензии до включения модели в рабочий продукт.
2. Задайте рабочий сценарий. Укажите ожидаемый размер входных данных, контекст, формат ответа и способ доступа к модели. Тест с короткой командой не заменяет проверку на типичных запросах проекта.
3. Измерьте исходное состояние сервера. До загрузки модели зафиксируйте доступную и занятую память. В Linux для первичной проверки подойдут free -h и просмотр /proc/meminfo; описание интерфейса /proc дано в документации ядра Linux.
4. Запустите модель с целевыми параметрами. Используйте штатный способ запуска выбранного движка, не меняя тег или настройки контекста между тестами. Если задействован серверный режим llama.cpp, его параметры нужно сверить с документацией сервера.
5. Повторите реальные запросы. Проверьте типичные и наиболее тяжёлые входные данные, затем оцените поведение при одновременной работе. Не переносите результат одного запроса на режим с параллельной обработкой.
6. Снимите пик всего хоста. Отдельно смотрите на процесс модели и на систему в целом: контейнер может иметь собственный лимит, который не равен объёму RAM всей машины.
7. Повторите тест вместе с приложениями. Запустите поиск, API и другие службы, которые будут работать рядом с моделью. Решение о конфигурации принимайте по совокупному пику, а не по изолированному прогону.

Контекст, параллельность и мультимодальные входы

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

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

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

Не сравнивайте результаты по одному только тегу модели. Для воспроизводимого замера сохраняйте тег, квантование, настройки контекста, версию движка и характер тестовых запросов.

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

CPU-only: пропускная способность и границы ожиданий

Возможность загрузить веса и приемлемая скорость генерации — разные критерии. Большой объём памяти может позволить разместить модель и её рабочие данные, но сам по себе не делает вычисления быстрее. Значение имеют CPU, программная реализация и пропускная способность памяти. Поэтому сначала зафиксируйте требование приложения к задержке и объёму работы, а уже затем оценивайте сервер.

В продуктовых данных CloudUDP для доступной конфигурации указан AMD EPYC 7543P. Его архитектурные характеристики можно сверить с официальной спецификацией AMD EPYC 7543. Этот процессор относится к поколению Zen 3 и поддерживает AVX2, но не AVX-512. Для CPU-инференса это означает, что нельзя рассчитывать на ускорение через AVX-512: итог зависит от инструкций, реально поддерживаемых моделью и сборкой используемого движка. При этом одно лишь наличие AVX2 не позволяет предсказать скорость генерации.

Измеряйте нагрузку именно через тот интерфейс, которым будет пользоваться приложение. Результат локального запуска в командной строке не описывает автоматически работу сервера инференса под одновременными обращениями. В тестовом журнале фиксируйте время ответа, загрузку CPU, использование памяти и количество активных запросов — не публикуйте единичный замер как универсальную производительность Qwen3.5.

Подходит ли CPU-only для Qwen3.5? Для тестов, редких интерактивных запросов и пакетной работы — если измеренные задержка и пик памяти укладываются в требования. Для сервиса, которому нужна высокая пропускная способность или стабильная обработка множества одновременных запросов, до выбора сервера проведите нагрузочный тест и оцените GPU-вариант.

Остальные службы: отдельный бюджет

Модель может делить машину с API, веб-приложением, планировщиком задач, векторным поиском и базой данных. Их расход нельзя считать частью весов модели. Для каждого процесса запишите собственную базовую память, пик под нагрузкой и наличие ограничений контейнера. Иначе ситуация, когда поиск или приложение вытесняет ресурсы модели, будет ошибочно принята за недостаток оперативной памяти именно для Qwen3.5.

Сведите результаты в несколько отдельных строк: операционная система и системные службы; модель и движок; API и приложение; поиск и хранилище; временные процессы и резерв. Учитывайте совокупный пик, но не складывайте слепо максимумы, которые в реальной работе не происходят одновременно. Если они могут совпасть, например при обновлении индекса во время запросов к модели, воспроизведите именно такой режим.

При миграции в контейнеры проверьте два уровня: лимит каждого контейнера и доступную память хоста. Если процесс завершается только внутри контейнера, сначала исследуйте его ограничения и журнал, а не заказывайте более крупную машину. Если же память заканчивается на хосте при включённых приложениях и целевой нагрузке, пересматривайте планирование служб или объём RAM. Для доступа к Linux-серверу и первого подключения пригодится руководство по доступу CloudUDP.

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

Выбор конфигурации по измерениям

У CloudUDP доступны варианты с 128 ГБ и 256 ГБ памяти; текущие условия и конфигурации следует сверять по странице тарифов CloudUDP. Выбор между ними нужно делать не по универсальному списку «модель помещается в такую-то память», а по фактически измеренному пику модели и служб на целевых настройках. В конфигурации с большим объёмом RAM всё равно остаются те же вопросы к задержке CPU и реальной нагрузке.

Примените следующий порядок:

1. Зафиксируйте пик модели на выбранном теге, квантовании и контексте.
2. Добавьте измеренный пик приложений и хранилища, которые будут работать одновременно с моделью.
3. Проверьте, остаётся ли рабочий запас для системы и всплесков нагрузки; определите его по собственным тестам, а не по случайному проценту.
4. Если суммарный пик с запасом укладывается в меньший вариант и нагрузка подходит CPU, рассматривайте его. Если нет — сравните больший вариант или разделение служб.
5. Если памяти достаточно, но задержка или пропускная способность не проходят проверку, не переходите автоматически на ещё больший объём RAM. Сначала оцените другую архитектуру вычислений.

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

Условия выбора:

• Если модель и все соседние службы проходят тест на целевом контексте, а задержка подходит рабочему процессу, выбирайте CPU-only и закрепите параметры запуска в конфигурации.
• Если модель проходит тест отдельно, но не вместе с приложениями, разделите службы или пересмотрите объём RAM, после чего повторите совместный замер.
• Если на хосте достаточно памяти, но не выполняется требование по задержке или пропускной способности, не считайте увеличение RAM решением — оцените GPU-ресурс либо другой способ обработки.
• Если нагрузка ограничивается контейнером, сначала исправьте лимиты контейнера, затем проведите замер заново.
• Если обработка допускает очередь и длительное выполнение, оставьте CPU для пакетных задач, но отдельно контролируйте рост очереди и сроки завершения.

Выбирать сервер следует после того, как зафиксированы модель, настройки контекста, совместная нагрузка и допустимая задержка. Если измерения подтверждают CPU-сценарий, сравните доступные объёмы памяти и условия аренды в тарифах CloudUDP; на странице конфигураций указаны характеристики, которые нужно проверить перед заказом. Если тесты показывают, что CPU не выдерживает требования к задержке или пропускной способности, разумнее сперва подобрать подходящий GPU-ресурс: у CloudUDP GPU-конфигурации не заявлены. Большая RAM полезна для размещения модели и соседних служб, но не превращает CPU-сервер в ускоритель для высоконагруженного инференса.