Двадцать лет SOHO на FreeBSD со своей сборкой пакетов — это уже само по себе статья, причём редкая. За LocalAI спасибо, у меня в проде llama.cpp через Ollama, и «комбайн» как раз то, чего не хватает, посмотрю. Буду ждать текст.)
Спасибо, «парный вайб-инжиниринг» — очень точное название, у меня по факту то же самое, только с двумя оговорками.
Первая: я вынес ту самую «архитектурную» роль во второго агента. У нас есть общая доска задач, и исполнитель не может выкатить релиз, пока другая модель не прочитала дифф и не поставила GREEN на конкретный patch-id. Она смотрит не на тесты, а на то, что вы описали: границы, контракты, «а почему здесь так». Я читаю уже их переписку и вмешиваюсь там, где они разошлись или где оба слишком уверены. И после моего финального GO уходит релиз.
Вторая оговорка важнее, и она в вашу пользу. Сегодняшний пример: фича постинга в сообщество ВК. Живая проверка нашла то, что не нашли ни тесты, ни ревью: VK API молча выбрасывает вложение, и «работающее» решение было просто неверным. Ни один из трёх способов этого не поймал бы, потому что все они проверяют код, а не мир вокруг него. Так что к вашему списку я бы добавил четвёртое: обязательную проверку руками на проде, пока ты ещё «в контексте».
Про долг согласен полностью. Единственное, что у меня против него работает, — это то, что модели пишут на доску не только «сделано», но и «почему так», и через месяц другая модель может это перечитать. Долг не исчезает, но хотя бы перестаёт быть невидимым.
Спасибо! 2×5060 Ti на 16 ГБ — интересная конфигурация, у меня одна 3090 на 24, и я всё время упираюсь в то, что не могу держать резидентно больше двух моделей одновременно. Как вы делите модели между двумя картами — по задачам или пробовали tensor parallel через что-то вроде vLLM?
Обязательно пишите про свою систему — таких статей от первого лица, с граблями, а не с готовым рецептом, на Хабре заметно меньше, чем хотелось бы. Если будет интересно сверить решения по сети, ИБП или мониторингу — я в комментариях.
Локальные модели у меня не заменяют провайдеров — и в статье, надеюсь, это видно: 60+ облачных моделей в каталоге, а на GPU живут только те задачи, где локальность даёт что-то кроме экономии. Whisper — потому что голосовые прилетают часто и короткие, задержка облака съедает весь смысл; роутер на 3B — потому что он отвечает за десятки миллисекунд и решает, стоит ли вообще платить провайдеру; эмбеддинги — потому что индексировать чужие документы через внешний API не хочется. Большие ответы — да, у провайдеров, тут полностью согласен: 24 ГБ VRAM против их контекста и скорости не аргумент.
Про суммарную стоимость: для одного пользователя вы правы, провайдеры дешевле. Моя арифметика была про другое — у платформы кроме инференса есть постоянно живой backend, очереди, БД, S3, векторная база, и вот это в облаке с GPU-инстансами при нуле пользователей выходило в те самые 40–80 тысяч в месяц. Железо под столом эту часть закрывает единоразово. Но честности ради: время на «поддержку хозяйства» я в эту сумму не закладывал, а его, как видно по статье, ушло много.
А про контроль качества результата — это, по-моему, самая точная фраза во всей ветке. Именно поэтому у меня один вопрос уходит нескольким моделям параллельно, а одна из них сводит ответы и показывает, где они разошлись: это дешёвый способ увидеть, что кто-то галлюцинирует. Не решение, но хотя бы сигнал. А как вы контролируете качество в своей работе — ревью глазами, тесты, вторая модель?
Спасибо, что поделились своим опытом! Про масштабирование тоже думаю, хотя пока доказано только то, что система выдерживает троих)))
Часть тяжёлых вычислений у внешних провайдеров, часть — локально. Но насколько вся конструкция выдержит рост и во что обойдётся обслуживание пользователей, ещё предстоит проверить.
А у вас что оказалось главным ограничением — техническая нагрузка или поддержка клиентов, внедрения и доработки? Правильно понимаю, что для окупаемости требовалось столько клиентов, сколько уже не получалось обслуживать имеющимися силами?
Последние полтора года довольно часто задавал себе этот вопрос. Первые полгода его вообще не было: дети пользовались, им помогало — и этого было достаточно для счастья)
Но чем больше я вкладывался в проект — и творчески, и технически, — тем больше хотелось внимания к нему. При этом всегда что-то останавливало от того, чтобы взять и рассказать: «Ещё вот это доделаю», «Ой, а вот это нужно переделать». Так и затянул с выходом к людям — собственно, об этой ловушке и написал.
Если оглянуться назад — для меня определённо стоило. Получится ли из этого бизнес, ещё предстоит проверить. Но даже если платформа не взлетит, накопленный опыт останется со мной и уже помогает в основной работе. А детям удобно пользоваться уже сейчас — та самая первоначальная польза никуда не делась))
Двадцать лет SOHO на FreeBSD со своей сборкой пакетов — это уже само по себе статья, причём редкая. За LocalAI спасибо, у меня в проде llama.cpp через Ollama, и «комбайн» как раз то, чего не хватает, посмотрю. Буду ждать текст.)
Спасибо, «парный вайб-инжиниринг» — очень точное название, у меня по факту то же самое, только с двумя оговорками.
Первая: я вынес ту самую «архитектурную» роль во второго агента. У нас есть общая доска задач, и исполнитель не может выкатить релиз, пока другая модель не прочитала дифф и не поставила GREEN на конкретный patch-id. Она смотрит не на тесты, а на то, что вы описали: границы, контракты, «а почему здесь так». Я читаю уже их переписку и вмешиваюсь там, где они разошлись или где оба слишком уверены. И после моего финального GO уходит релиз.
Вторая оговорка важнее, и она в вашу пользу. Сегодняшний пример: фича постинга в сообщество ВК. Живая проверка нашла то, что не нашли ни тесты, ни ревью: VK API молча выбрасывает вложение, и «работающее» решение было просто неверным. Ни один из трёх способов этого не поймал бы, потому что все они проверяют код, а не мир вокруг него. Так что к вашему списку я бы добавил четвёртое: обязательную проверку руками на проде, пока ты ещё «в контексте».
Про долг согласен полностью. Единственное, что у меня против него работает, — это то, что модели пишут на доску не только «сделано», но и «почему так», и через месяц другая модель может это перечитать. Долг не исчезает, но хотя бы перестаёт быть невидимым.
Спасибо! Самое «огненное» было в четыре утра, когда Gitea встретила меня чистой установкой ))
Спасибо! 2×5060 Ti на 16 ГБ — интересная конфигурация, у меня одна 3090 на 24, и я всё время упираюсь в то, что не могу держать резидентно больше двух моделей одновременно. Как вы делите модели между двумя картами — по задачам или пробовали tensor parallel через что-то вроде vLLM?
Обязательно пишите про свою систему — таких статей от первого лица, с граблями, а не с готовым рецептом, на Хабре заметно меньше, чем хотелось бы. Если будет интересно сверить решения по сети, ИБП или мониторингу — я в комментариях.
Кажется, мы говорим про два разных «локально».
Локальные модели у меня не заменяют провайдеров — и в статье, надеюсь, это видно: 60+ облачных моделей в каталоге, а на GPU живут только те задачи, где локальность даёт что-то кроме экономии. Whisper — потому что голосовые прилетают часто и короткие, задержка облака съедает весь смысл; роутер на 3B — потому что он отвечает за десятки миллисекунд и решает, стоит ли вообще платить провайдеру; эмбеддинги — потому что индексировать чужие документы через внешний API не хочется. Большие ответы — да, у провайдеров, тут полностью согласен: 24 ГБ VRAM против их контекста и скорости не аргумент.
Про суммарную стоимость: для одного пользователя вы правы, провайдеры дешевле. Моя арифметика была про другое — у платформы кроме инференса есть постоянно живой backend, очереди, БД, S3, векторная база, и вот это в облаке с GPU-инстансами при нуле пользователей выходило в те самые 40–80 тысяч в месяц. Железо под столом эту часть закрывает единоразово. Но честности ради: время на «поддержку хозяйства» я в эту сумму не закладывал, а его, как видно по статье, ушло много.
А про контроль качества результата — это, по-моему, самая точная фраза во всей ветке. Именно поэтому у меня один вопрос уходит нескольким моделям параллельно, а одна из них сводит ответы и показывает, где они разошлись: это дешёвый способ увидеть, что кто-то галлюцинирует. Не решение, но хотя бы сигнал. А как вы контролируете качество в своей работе — ревью глазами, тесты, вторая модель?
Спасибо, что поделились своим опытом! Про масштабирование тоже думаю, хотя пока доказано только то, что система выдерживает троих)))
Часть тяжёлых вычислений у внешних провайдеров, часть — локально. Но насколько вся конструкция выдержит рост и во что обойдётся обслуживание пользователей, ещё предстоит проверить.
А у вас что оказалось главным ограничением — техническая нагрузка или поддержка клиентов, внедрения и доработки? Правильно понимаю, что для окупаемости требовалось столько клиентов, сколько уже не получалось обслуживать имеющимися силами?
Последние полтора года довольно часто задавал себе этот вопрос. Первые полгода его вообще не было: дети пользовались, им помогало — и этого было достаточно для счастья)
Но чем больше я вкладывался в проект — и творчески, и технически, — тем больше хотелось внимания к нему. При этом всегда что-то останавливало от того, чтобы взять и рассказать: «Ещё вот это доделаю», «Ой, а вот это нужно переделать». Так и затянул с выходом к людям — собственно, об этой ловушке и написал.
Если оглянуться назад — для меня определённо стоило. Получится ли из этого бизнес, ещё предстоит проверить. Но даже если платформа не взлетит, накопленный опыт останется со мной и уже помогает в основной работе. А детям удобно пользоваться уже сейчас — та самая первоначальная польза никуда не делась))
Дело за малым — понять, что именно нужно людям, а не что мне интересно построить)) А вам что помогло это выяснить на практике?