Comments 16
Человеческая: если вы вылезали из такой же ловушки — расскажите, что сработало.
Делать не то, что хочется или лучше всего получатся, а то, что реально нужно :-)
Дело за малым — понять, что именно нужно людям, а не что мне интересно построить)) А вам что помогло это выяснить на практике?
У меня примерно такая же лабуда (24VRAM, 2x32 Core CPU, 256RAM и 1TB RAID0 на 4 ssd). Собрал пару-тройку лет назад, но так и продолжаю пользоваться провайдерами, т.к. работает быстрее, по суммарным затратам выходит дешевле (ненужно тратить время на поддержку хозяйства, его оптимизацию и ремонт) и постоянно ловить проблемы из-за нехватки размера контекста и долгого ожидания ответов при неспешной генерации на локальных моделях.
Тогда как основная проблема при работе с LLM, это не генерация и даже не оркестрация парка агентов, а контроль качества выдаваемого ими результата. Для обычного вайбкодинга пойдет любое решение, а вот для реальной работы нужно смотреть итоговый код.
Кажется, мы говорим про два разных «локально».
Локальные модели у меня не заменяют провайдеров — и в статье, надеюсь, это видно: 60+ облачных моделей в каталоге, а на GPU живут только те задачи, где локальность даёт что-то кроме экономии. Whisper — потому что голосовые прилетают часто и короткие, задержка облака съедает весь смысл; роутер на 3B — потому что он отвечает за десятки миллисекунд и решает, стоит ли вообще платить провайдеру; эмбеддинги — потому что индексировать чужие документы через внешний API не хочется. Большие ответы — да, у провайдеров, тут полностью согласен: 24 ГБ VRAM против их контекста и скорости не аргумент.
Про суммарную стоимость: для одного пользователя вы правы, провайдеры дешевле. Моя арифметика была про другое — у платформы кроме инференса есть постоянно живой backend, очереди, БД, S3, векторная база, и вот это в облаке с GPU-инстансами при нуле пользователей выходило в те самые 40–80 тысяч в месяц. Железо под столом эту часть закрывает единоразово. Но честности ради: время на «поддержку хозяйства» я в эту сумму не закладывал, а его, как видно по статье, ушло много.
А про контроль качества результата — это, по-моему, самая точная фраза во всей ветке. Именно поэтому у меня один вопрос уходит нескольким моделям параллельно, а одна из них сводит ответы и показывает, где они разошлись: это дешёвый способ увидеть, что кто-то галлюцинирует. Не решение, но хотя бы сигнал. А как вы контролируете качество в своей работе — ревью глазами, тесты, вторая модель?
А как вы контролируете качество в своей работе — ревью глазами, тесты, вторая модель?
Ни то, ни другое ни третье. Я бы это назвал “парный вайб инжиниринг”. т.е. когда ты ждешь заврешения задачи и смотришь на код, но не как при ревью кода, а а как при ревью архитектуры без глубокого погружения в детали реализации и задаешь в диалоге вопросы по сомнительным местам. А модель либо переделывает, либо доказывает тебе, что именно так и должно быть, и ты соглашается с итоговым решением.
То есть получается сразу и постановка задачи и ревью кода и обсуждением архитектуры итогового решения (пока пользователь сам “в контексте”).
К сожалению, я не представляю можно ли автоматизировать такой процесс, потому что часто бывает, что верное и работающее решение (тесты проходят), на проверку оказывается очень кривим с точки зрения архитектуры, но проблема от него возникнет не сейчас, а в будущем. Т.е. на текущем этапе решение может быть и пойдет, но в будущем это архитектурный долг,.
Спасибо, «парный вайб-инжиниринг» — очень точное название, у меня по факту то же самое, только с двумя оговорками.
Первая: я вынес ту самую «архитектурную» роль во второго агента. У нас есть общая доска задач, и исполнитель не может выкатить релиз, пока другая модель не прочитала дифф и не поставила GREEN на конкретный patch-id. Она смотрит не на тесты, а на то, что вы описали: границы, контракты, «а почему здесь так». Я читаю уже их переписку и вмешиваюсь там, где они разошлись или где оба слишком уверены. И после моего финального GO уходит релиз.
Вторая оговорка важнее, и она в вашу пользу. Сегодняшний пример: фича постинга в сообщество ВК. Живая проверка нашла то, что не нашли ни тесты, ни ревью: VK API молча выбрасывает вложение, и «работающее» решение было просто неверным. Ни один из трёх способов этого не поймал бы, потому что все они проверяют код, а не мир вокруг него. Так что к вашему списку я бы добавил четвёртое: обязательную проверку руками на проде, пока ты ещё «в контексте».
Про долг согласен полностью. Единственное, что у меня против него работает, — это то, что модели пишут на доску не только «сделано», но и «почему так», и через месяц другая модель может это перечитать. Долг не исчезает, но хотя бы перестаёт быть невидимым.
Если клиентов нет, то стоило ли оно всё?
У меня дома игровой пк, и на нём же гоняю модели для себя. Если надо где-то "с улицы загуглить" то использую обычные бесплатные коммерческие. Из всех настроек только LMstudio + opencode. Хватает вполне с головой, все мои задачи закрывает (я не профи прогер, просто хоби). Вот зачем бы мне городить такое - даже не придумаю, лучше там вечно пилить умный дом например, от которого польза сразу видна будет.
Последние полтора года довольно часто задавал себе этот вопрос. Первые полгода его вообще не было: дети пользовались, им помогало — и этого было достаточно для счастья)
Но чем больше я вкладывался в проект — и творчески, и технически, — тем больше хотелось внимания к нему. При этом всегда что-то останавливало от того, чтобы взять и рассказать: «Ещё вот это доделаю», «Ой, а вот это нужно переделать». Так и затянул с выходом к людям — собственно, об этой ловушке и написал.
Если оглянуться назад — для меня определённо стоило. Получится ли из этого бизнес, ещё предстоит проверить. Но даже если платформа не взлетит, накопленный опыт останется со мной и уже помогает в основной работе. А детям удобно пользоваться уже сейчас — та самая первоначальная польза никуда не делась))
Просто огонь!
Стив Джобс и Стив Возняк, один делал, другой продавал, найдите себе того кто будет продавать. К сожалению, что-то сделать это всегда пол беды, а парой бывает даже самая "легкая" часть проблемы любого бизнеса. Я тоже с этим столкнулся, на своем SaaS по автоматизации маркетинга в соц. сетях. Без отдельных продавьцов у меня ничего не продавалось. Но, мой проект правда погубило не это, а то что поддерживать тот объем людей при котором это все бы окупалось - стало не реальным. По этому следующая стадия "ада" после продаж, это - масштабирование ...
Спасибо, что поделились своим опытом! Про масштабирование тоже думаю, хотя пока доказано только то, что система выдерживает троих)))
Часть тяжёлых вычислений у внешних провайдеров, часть — локально. Но насколько вся конструкция выдержит рост и во что обойдётся обслуживание пользователей, ещё предстоит проверить.
А у вас что оказалось главным ограничением — техническая нагрузка или поддержка клиентов, внедрения и доработки? Правильно понимаю, что для окупаемости требовалось столько клиентов, сколько уже не получалось обслуживать имеющимися силами?
У меня похожая система которая развивается своим темпом - несколько физических машин, под инференс собрал 24 cpu / 256 Gb RAM / 2x 1Tb NVMe / 2x 5060Ti 16 Gb, развернуться есть где и поэкспериментировать/поизучать.
Спасибо за статью! Очень интересно, возможно тоже опишу свой опыт развития SOHO системы
Спасибо! 2×5060 Ti на 16 ГБ — интересная конфигурация, у меня одна 3090 на 24, и я всё время упираюсь в то, что не могу держать резидентно больше двух моделей одновременно. Как вы делите модели между двумя картами — по задачам или пробовали tensor parallel через что-то вроде vLLM?
Обязательно пишите про свою систему — таких статей от первого лица, с граблями, а не с готовым рецептом, на Хабре заметно меньше, чем хотелось бы. Если будет интересно сверить решения по сети, ИБП или мониторингу — я в комментариях.
Две GPU - это специально чтобы поэкспериментировать с K8s подами и миграцией с карты на карту, но и большие (даже densed) модели взлетают неплохо. Использую llama.cpp, у него очень хорошая поддержка таких конфигураций. Сейчас правда перехожу на LocalAI, там комбайн стал более-менее стабилен и очень универсален.
В своей изначальной конфигурации система задумывалась для процессинга видео архива, но потом нашлись применения и поинтереснее.
В целом инференс машина у меня лишь часть SOHO который постепенно развивался последние >20 лет. Там есть полный комплект от mail/web/git/xmpp/sip/vpn/nut сервисов до персонального nextcloud+onlyoffice, k8s лабы и всяких экспериментов. Всё это добро на FreeBSD (кроме инференс сервера и нескольких VM), есть свой сервис сборки BSD пакетов (всё собирается из исходников и с моими специфичными опциями компиляции).
Работает очень хорошо и практически не требует поддержки, система очень стабильна.
Два года, один человек, 66 контейнеров: как я построил AI‑платформу на железе под столом