Сообщество / ИИ

Обсуждение — GPU или CPU для ИИ: что реально брать под VPS

Источник:
GPU или CPU для ИИ: что брать под VPS

Вокруг ИИ сложился миф: без дорогой видеокарты и соваться нечего. На практике огромный класс задач — инференс квантованных LLM, эмбеддинги, RAG, боты — прекрасно живёт на CPU. Разберём, где проходит граница. GPU нужен для двух вещей: обучение (fine-tune, тем более с нуля) и высоконагруженный инференс больших моделей с низкой задержкой на много пользователей. Всё остальное — CPU.

Подробнее →
ruslan_krd
Junior
Сообщения: 72
Репутация: 71
Дата регистрации:
16.08.2026
АВТОР ТЕМЫ14 окт. 2026 г., 09:00 (GMT+3)
Подтверждаю с денежной стороны: два бота и эмбеддинги живут у нас на обычном CPU-сервере, видеокарта ни разу не понадобилась. Зато понадобился счёт на юрлицо — вот где у нас реальная граница проходит, не в терафлопсах) В прошлом месяце платёж по СБП завис на сутки, уже хотел писать в саппорт — дошёл сам, продление сработало. Так что вопрос «что брать» у нас решает бухгалтерия быстрее, чем любой бенчмарк.
3
V
vera_med
Junior
Сообщения: 16
Репутация: 12
Дата регистрации:
13.09.2026
14 окт. 2026 г., 12:01 (GMT+3)

ruslan_krd писал:
вопрос «что брать» у нас решает бухгалтерия быстрее, чем любой бенчмарк


Улыбнулась, потому что у нас один в один. Я админ в небольшой клинике, так что на это смотрю не со стороны железа. Сервер взяли самый обычный, на процессоре: на нём живёт бот, который напоминает пациентам о записи, и скрипты для внутренних отчётов. Видеокарту обсуждали ровно один раз — главврач наслушался новостей про нейросети и спросил, не нужна ли нам «эта самая». Прикинула наши задачи и ответила, что не нужна: всё крутится на том, что есть, и ещё с запасом.

А с бухгалтерией ровно как вы описали. Наша Людмила Петровна хочет счёт, акт и чтобы сошлось до копейки. Платим переводом с юрлица, закрывающие приходят, вопросов от неё в итоге меньше, чем от врачей) Медданные наружу стараемся вообще не выносить, поэтому свой сервер и радует — сама решаю, что где лежит.

Смешно выходит: бенчмарки читаю я, а архитектуру утверждает Людмила Петровна. У кого-нибудь ещё бухгалтерия главный архитектор?
1
ruslan_krd
Junior
Сообщения: 72
Репутация: 71
Дата регистрации:
16.08.2026
14 окт. 2026 г., 13:00 (GMT+3)

vera_med писал:
У кого-нибудь ещё бухгалтерия главный архитектор?


Поднимаю руку. В прошлом году выбирали между двумя вариантами, я принёс сравнение по ядрам и памяти, красивую табличку. Бухгалтер посмотрела полминуты и спросила: «а акт по этому будет?» У одного с закрывающими было мутно, у другого счёт и акт приходят сами. Вопрос решился за минуту, табличку так никто и не открыл) С тех пор архитектуру согласую с ней, а не с гуглом.
4
igor_kzn
Junior
Сообщения: 53
Репутация: 33
Дата регистрации:
28.08.2026
14 окт. 2026 г., 14:00 (GMT+3)

ruslan_krd писал:
табличку так никто и не открыл



Узнал себя, только у нас роль бухгалтера исполняет партнёр. Я для него тоже готовил «табличку» — целую служебную записку, почему фирме нужен свой сервер и зачем вообще нейросеть по договорам. Писал вечером, гордился собой. Партнёр прочитал первый абзац и задал два вопроса: документы остаются у нас? И закрывающие для бухгалтерии будут? На оба ответил «да», и записка больше не понадобилась :)

Про видеокарту разговор тоже был короткий. Партнёр наслушался новостей и спросил, не надо ли «помощнее». Я честно спросил здесь, мне объяснили: для текста хватает обычного сервера, мы же не картинки рисуем. Отложил вопрос до дня, когда упрёмся. Пока даже близко не уперлись, а пользуемся каждый будний день.

ruslan_krd, отдельное спасибо за слова про СБП. У нас платёж тоже однажды думал дольше обычного, я успел понапридумывать сценариев. Дошёл сам, продление сработало. Теперь не паникую раньше времени.
3
n1kita
Middle
Сообщения: 101
Репутация: 55
Дата регистрации:
19.08.2026
15 окт. 2026 г., 01:01 (GMT+3)
igor_kzn партнёр правильно спросил. только «документы у нас» верно, пока модель слушает 127.0.0.1. ss -tlnp покажет. если там 0.0.0.0 — договоры читает не только партнёр.
1
lexa92
Middle
Сообщения: 163
Репутация: 145
Дата регистрации:
09.08.2026
15 окт. 2026 г., 13:01 (GMT+3)

n1kita писал:
если там 0.0.0.0 — договоры читает не только партнёр


Проверка правильная, вывод громкий. 0.0.0.0 сам по себе ещё не утечка, дальше файрвол. Но смотреть надо не с самого сервера, а снаружи:

nmap -p 11434 <внешний ip>

ss снаружи не обманешь. А вот ufw обманывают регулярно: если модель в докере с -p 11434:11434, docker пишет своё в цепочку DOCKER, и твой deny в ufw просто не доезжает до пакета. Ловил это на своих же серверах, не на чужих.

Поэтому рабочая схема не «localhost и надеемся», а адрес туннеля. Вешаешь модель на wg0:

OLLAMA_HOST=10.0.0.1

и она видна с ноута и телефона внутри туннеля, а снаружи порта нет в принципе, сканировать нечего. Партнёр спит спокойно, n1kita тоже.

igor_kzn, порядок такой: ss -tlnp на сервере, потом nmap с любой машины вне офиса. Если в ss адрес докеровский — перечитай абзац про цепочку DOCKER ещё раз.
4
ruslan_krd
Junior
Сообщения: 72
Репутация: 71
Дата регистрации:
16.08.2026
15 окт. 2026 г., 15:00 (GMT+3)

igor_kzn писал:
Теперь не паникую раньше времени


Правильный навык. У нас выработали правило: платёж «думал» — смотрим на него сутки, потом уже пишем куда-либо. За два года ни разу до письма не дошло, всегда доходил сам и продление срабатывало. Адреналина в итоге меньше, чем кажется в первый раз.

Про вопрос партнёра «документы остаются у нас» — у нас это первый вопрос директора после каждой новости про очередную утечку. Сам я в эти порты не лезу, у нас админ смотрит, но сообщение lexa92 про туннель ему переслал — пусть проверит, что там слушает модель. Клиенту потом честнее сказать «снаружи порта нет», чем объяснять файрвол с оговорками.

А со служебными записками узнал себя) Готовил однажды обоснование на две страницы, директор прочитал последний абзац с суммой и сказал «ну ок». С тех пор сумму пишу первой строкой, а остальное — приложение для желающих. Желающих пока не было.
2
n1kita
Middle
Сообщения: 101
Репутация: 55
Дата регистрации:
19.08.2026
16 окт. 2026 г., 03:00 (GMT+3)
lexa92 про цепочку DOCKER верно, сам на этом горел. добавлю другое: проверка не разовая. ollama и докер любят после обновления тихо переписать unit и правила. у меня binding на 0.0.0.0 однажды вернулся после апдейта, заметил только потому что nmap снаружи по расписанию ходит, а не по настроению. «сканировать нечего» — единственная конфигурация, которой верю.
2
lexa92
Middle
Сообщения: 163
Репутация: 145
Дата регистрации:
09.08.2026
17 окт. 2026 г., 13:01 (GMT+3)

n1kita писал:
binding на 0.0.0.0 однажды вернулся после апдейта


У меня то же самое было с ollama на домашнем сервере. Поставил, повесил на localhost, спустя месяц apt upgrade переписал unit, и модель неделю слушала все интерфейсы. Заметил случайно: с ноута из соседней комнаты подключился по локальному адресу, и только в момент подключения дошло, что оно не должно было сработать. После этого перестал надеяться на память.

Теперь три вещи.

1. Настройка живёт не в unit, а в override. Пакет переписывает /lib/systemd/system/ollama.service, а вот /etc/systemd/system/ollama.service.d/ не трогает:

systemctl edit ollama

и туда:

[Service]
Environment="OLLAMA_HOST=10.0.0.1"

После этого apt может переписывать что хочет, адрес останется туннельный.

2. Скан снаружи по расписанию, и не просто скан, а ndiff. Сразу после настройки снимаешь эталон:

nmap -p- -T4 <внешний ip> -oX /root/ports/base.xml

и в cron раз в неделю:

nmap -p- -T4 <внешний ip> -oX /root/ports/new.xml
ndiff /root/ports/base.xml /root/ports/new.xml

ndiff идёт в комплекте с nmap. Пустой вывод — всё как было. Появились строки — порт открылся или закрылся, и это уже повод идти смотреть. У меня вывод падает в телеграм-бота, но и на почту нормально. Скан «по настроению» — это не скан, это лотерея.

3. Докеру лучше вообще не давать решать. Если порт нужен снаружи контейнера, публикуй его на конкретный адрес, а не на все:

docker run -p 10.0.0.1:11434:11434 ...

Тогда даже если правила после апдейта поедут, торчать будет адрес туннеля, которого снаружи не существует. Сканер из интернета увидит ровно то же, что вчера: ничего.

Твой вернувшийся 0.0.0.0 — ожидаемая история. Все проверяют конфиг в день настройки, и никто — на тридцатый. А меняется он именно на тридцатый, во время апдейта, молча.
5
kate_ekb
Middle
Сообщения: 116
Репутация: 81
Дата регистрации:
12.08.2026
19 окт. 2026 г., 06:00 (GMT+3)

lexa92 писал:
docker пишет своё в цепочку DOCKER, и твой deny в ufw просто не доезжает


поэтому в compose не «пробросить, а закрою потом», а сразу адрес:

ports:
- "10.0.0.1:11434:11434"

DNAT будет только на туннельный ip, и цепочка DOCKER снаружи пустая. вариант «11434:11434, ufw как-нибудь» — это ровно те недельные 0.0.0.0, про которые выше пишут.

и да, ndiff по крону вместо «я же вроде закрывал» — вот так правильно.
4
pavel_63
Junior
Сообщения: 83
Репутация: 62
Дата регистрации:
13.08.2026
19 окт. 2026 г., 07:01 (GMT+3)

kate_ekb писал:
это ровно те недельные 0.0.0.0


Тут без спора, Кать. У меня докера нет и в помине, а беда та же: обновление службы как-то вернуло прослушку на все интерфейсы, и я месяц жил спокойно, не зная. С тех пор по понедельникам с телефона через мобильный интернет стучусь на свой адрес — ответа нет, и неделя спокойная. Вся разница между нами: ты это в compose пишешь, я — в заметке на мониторе :)
2
void_3am
Middle
Сообщения: 164
Репутация: 112
Дата регистрации:
14.08.2026
20 окт. 2026 г., 03:00 (GMT+3)
pavel_63, стучаться на свой адрес с телефона — как дёргать ручку после того, как запер дверь. только у тебя это по расписанию, а значит надёжнее половины крона в этом треде)
0
lexa92
Middle
Сообщения: 163
Репутация: 145
Дата регистрации:
09.08.2026
20 окт. 2026 г., 12:02 (GMT+3)

kate_ekb писал:
ports:
- "10.0.0.1:11434:11434"


Всё верно, и у этого варианта есть камень, об который я убил вечер. Обновил ядро, сервер ночью ушёл в ребут, утром смотрю: контейнер running, systemd везде active, модель молчит. Оказалось, docker стартанул раньше wg-quick. Адреса 10.0.0.1 на хосте ещё нет, и userland proxy не смог его забиндить:


Error starting userland proxy: listen tcp4 10.0.0.1:11434: bind: cannot assign requested address


Контейнер при этом зелёный, а порт не проброшен ни наружу, ни в туннель. По статусам всё хорошо, по факту сервиса нет.

Лечится порядком загрузки:


systemctl edit docker


и туда:


[Unit]
After=wg-quick@wg0.service


Requires сознательно не добавляю: если туннель не поднялся, пусть docker всё равно стартует, остальные контейнеры не виноваты, что модель ждёт адрес.

По ndiff тоже добавлю из своего фейла, раз пошли признания. Схема жива, пока жив base.xml. Я как-то открыл ssh на неделю для подрядчика, а эталон не переснял. Дифф перестал быть пустым. Первые дни читал его «да, это тот самый ssh», через месяц не читал вообще. Когда рядом с ssh появился ещё один порт, заметил не сразу — глаз уже привык, что там что-то есть. Теперь правило жёсткое: осознанно поменял порты — в тот же вечер переснял базу:


nmap -p- -T4 <внешний ip> -oX /root/ports/base.xml


Пустой дифф — это норма, а не повод пролистать. Иначе это не мониторинг, а еженедельное письмо самому себе, которое ты не открываешь.

И ещё дыра: недельный крон не видит окно между ребутом и воскресеньем. Добавь рядом:


@reboot sleep 120 && /root/ports/scan.sh


sleep обязателен — wg0 должен успеть подняться, иначе на старте получишь ложный дифф и опять приучишь себя не читать.

kate_ekb, у тебя адрес в compose, у меня в override, у pavel_63 записка на мониторе. Всё это лучше, чем «я же вроде закрывал».
1
pavel_63
Junior
Сообщения: 83
Репутация: 62
Дата регистрации:
13.08.2026
21 окт. 2026 г., 06:02 (GMT+3)

lexa92 писал:
Первые дни читал его «да, это тот самый ssh», через месяц не читал вообще


Знакомая болезнь. У меня она называется «временное, значит вечное».

Летом клиенту внедряли 1С, подрядчик попросил доступ снаружи «на неделю, пока накатываем». Порт, понятное дело, никто не открывал — поднял ему отдельный пир в вайргарде на кенетике, отдал конфиг, неделя прошла, все довольны. А в сентябре лезу в список пиров по другому поводу — и там он, «1с-внедрение». Живой ключ, полный доступ в сеть. Позвонил подрядчику, тот честно удивился: «а я думал, оно само отвалилось». Само, ага.

С тех пор правило: любое исключение получает дату смерти прямо в имени. Не «1с-внедрение», а «1c-до-15.07». Раз в месяц пробегаю список глазами — дата прошла, пир удаляется без раздумий. Читать и решать ничего не надо, цифра сама всё сказала. Твой ndiff, Лёха, ровно тем и подвёл, что его надо было читать. А всё, что надо читать, рано или поздно перестают читать.

Про «докер встал раньше туннеля» усмехнулся: у меня туннель на роутере живёт, винда про него вообще не в курсе. Скажете, моветон — зато и падать в этом месте нечему.

А теперь признавайтесь: у кого в пирах до сих пор висит кто-то с прошлого года?
3
kate_ekb
Middle
Сообщения: 116
Репутация: 81
Дата регистрации:
12.08.2026
21 окт. 2026 г., 09:03 (GMT+3)

lexa92 писал:
Error starting userland proxy: listen tcp4 10.0.0.1:11434: bind: cannot assign requested address


Ключевое слово тут — userland proxy. Это не «докер встал раньше туннеля», это docker-proxy, который не умеет ждать адрес и из-за этого роняет весь биндинг. Твой After=wg-quick рабочий, но это управление порядком загрузки. Мне спокойнее, когда порядок вообще не имеет значения:


# /etc/docker/daemon.json
{
"userland-proxy": false
}


systemctl restart docker — и docker-proxy больше нет. Проброс превращается в чистый DNAT в iptables, а iptables глубоко всё равно, существует ли 10.0.0.1 прямо сейчас. Контейнер стартует когда угодно, wg-quick поднялся минутой позже — порт сам оживает. Без рестартов, без After, без Requires, systemd про эту связку можно вообще не рассказывать.

Ловила ровно это на UK после ребута ядра: docker ps зелёный, ollama молчит, в логах тот самый bind. С тех пор userland-proxy: false прописываю раньше, чем первый контейнер.

Два минуса, честно. Первый: с самого хоста на 127.0.0.1:11434 больше не постучишься — этот форвардинг как раз рисовал proxy. Кто ходит в модель с хоста — по туннельному адресу или по имени контейнера в общей сети compose. Второй: настройка на весь демон, а не на один стек. У меня после перезапуска отвалился pgadmin, который годами слушал 127.0.0.1:5050 — минут десять смотрела в его логи, пока не вспомнила, что сама же всё и выключила.

Проверка после ребута тогда выглядит не «docker ps зелёный, значит живём», а:


curl -s http://10.0.0.1:11434/api/tags


с ноута в туннеле. Вернуло список моделей — живо. Молчит — вот тогда уже читаем логи, а не раньше.

pavel_63 писал:
у меня туннель на роутере живёт, винда про него вообще не в курсе


Это не отсутствие гонки, Паш. Это та же гонка, вынесенная в другую комнату — просто твой wg-quick называется «прошивка» и перезагружается, когда ему вздумается)

А про пиры отвечу честно, раз пошли признания: после этого треда открыла wg show и нашла «kate-phone-old» с рукопожатием позапрошлой зимой. Телефон давно другой, а пир жил полной жизнью. Удаляла без церемоний и без слёз.

Интересно, есть ли третий способ подружить docker с туннельным адресом, или все так и сидят на связке «порядок загрузки плюс молитва»?
1
M
max_nn
Junior
Сообщения: 26
Репутация: 9
Дата регистрации:
09.09.2026
21 окт. 2026 г., 13:01 (GMT+3)

kate_ekb писал:
с самого хоста на 127.0.0.1:11434 больше не постучишься — этот форвардинг как раз рисовал proxy



Так вот почему у меня localhost молчал. Я летом ставил ollama и сдуру скопировал daemon.json из чьего-то гиста целиком, даже не читая что внутри. Там как раз лежал userland-proxy false. Потом неделю убил: curl 127.0.0.1:11434 не отвечает, docker ps зелёный, в логах чисто. Переустановил олламу два раза, один раз снёс контейнер вместе с volume и модель качал по новой) Думал, руки кривые. А оно, выходит, честно работало — просто не там, где я стучался.

Сейчас ради проверки сделал curl 10.0.0.1:11434 — ответило сразу. Обидно и смешно одновременно.

Заодно после твоей строчки про ports полез в свой compose, а у меня там просто "11434:11434" без адреса. Исправил на "10.0.0.1:11434:11434". И вопрос джуна: с хоста в модель теперь правильно ходить по туннельному адресу, или есть способ, чтобы и localhost остался?
1
kate_ekb
Middle
Сообщения: 116
Репутация: 81
Дата регистрации:
12.08.2026
23 окт. 2026 г., 13:11 (GMT+3)

max_nn писал:
есть способ, чтобы и localhost остался?


есть. второй маппинг рядом:


ports:
- "10.0.0.1:11434:11434"
- "127.0.0.1:11434:11434"


без userland-proxy это просто два правила DNAT, друг другу не мешают.

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

а гисты целиком больше не тащи) глянь, что ещё в том daemon.json лежит, вдруг рядом с proxy сидит что-то ещё весёлое
0
masha_spb
Middle
Сообщения: 129
Репутация: 98
Дата регистрации:
11.08.2026
23 окт. 2026 г., 19:06 (GMT+3)

kate_ekb писал:
userland-proxy: false прописываю раньше, чем первый контейнер


А я делаю на шаг раньше: порту вообще не даю родиться. Если единственный клиент модели — webui в том же compose, половина этой ветки решается удалением. Суть в одной строчке:


open-webui:
environment:
- OLLAMA_BASE_URL=http://ollama:11434


Порты не публикуются совсем, контейнеры находят друг друга по имени во внутренней сети. Нет ports — нет DNAT, некуда биндить 10.0.0.1, userland-proxy безработный, а ndiff молчит, потому что молчать ему больше не о чем, а не потому что ты строчку так написала. И порядок загрузки с wg-quick перестаёт иметь значение без всяких After.

Пришла к этому через смешное: полгода таскала в compose аккуратное «127.0.0.1:11434:11434» и тихо собой гордилась. Потом задала себе вопрос, кто туда вообще ходит, — ответ: только webui из соседнего контейнера. Удалила строчку, ровно ничего не изменилось. Запасная дверь, которой никто не пользуется, зато она может однажды открыться не туда.

Честное ограничение: без публикации с хоста в модель не постучишься, скрипты вне докера отвалятся — тогда твои две строчки с 10.0.0.1 и localhost. Но если клиент один и живёт в соседнем контейнере, лучший биндинг — тот, которого нет)
0