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

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

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

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

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

Смешно выходит: бенчмарки читаю я, а архитектуру утверждает Людмила Петровна. У кого-нибудь ещё бухгалтерия главный архитектор?

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

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

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

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

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

ruslan_krd, отдельное спасибо за слова про СБП. У нас платёж тоже однажды думал дольше обычного, я успел понапридумывать сценариев. Дошёл сам, продление сработало. Теперь не паникую раньше времени.

igor_kzn партнёр правильно спросил. только «документы у нас» верно, пока модель слушает 127.0.0.1. ss -tlnp покажет. если там 0.0.0.0 — договоры читает не только партнёр.

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 ещё раз.

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

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

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

А со служебными записками узнал себя) Готовил однажды обоснование на две страницы, директор прочитал последний абзац с суммой и сказал «ну ок». С тех пор сумму пишу первой строкой, а остальное — приложение для желающих. Желающих пока не было.

lexa92 про цепочку DOCKER верно, сам на этом горел. добавлю другое: проверка не разовая. ollama и докер любят после обновления тихо переписать unit и правила. у меня binding на 0.0.0.0 однажды вернулся после апдейта, заметил только потому что nmap снаружи по расписанию ходит, а не по настроению. «сканировать нечего» — единственная конфигурация, которой верю.

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 — ожидаемая история. Все проверяют конфиг в день настройки, и никто — на тридцатый. А меняется он именно на тридцатый, во время апдейта, молча.

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

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

ports:
  - "10.0.0.1:11434:11434"

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

и да, ndiff по крону вместо «я же вроде закрывал» — вот так правильно.

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

Тут без спора, Кать. У меня докера нет и в помине, а беда та же: обновление службы как-то вернуло прослушку на все интерфейсы, и я месяц жил спокойно, не зная. С тех пор по понедельникам с телефона через мобильный интернет стучусь на свой адрес — ответа нет, и неделя спокойная. Вся разница между нами: ты это в compose пишешь, я — в заметке на мониторе :)

pavel_63, стучаться на свой адрес с телефона — как дёргать ручку после того, как запер дверь. только у тебя это по расписанию, а значит надёжнее половины крона в этом треде)

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 записка на мониторе. Всё это лучше, чем «я же вроде закрывал».