Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
У большинства разработчиков не на чем дообучать модель. Нет банка хороших примеров с именно его специализацией. Поэтому мне интересно, но бесполезно.
Если мы говорим о разработчике в компании, то это не такая проблема, ведь нужна одна видеокарта на всю команду разработчиков, что вполне по силам компаниям (исключая совсем малый бизнес).
Простой пример с сервером для 1С. Сейчас у всех есть понимание, что бухгалтерскому отделу он нужен, компания его покупает, хотя на заре появления 1С большинству компаний это было неочевидно.
Тоже самое с ML. Понимания того, что ИТ отделу нужен ML сервер повсеместно пока еще нет.
Это настоящий код ближайшего будущего и появляться в компаниях он будет очень неравномерно.
По поводу данных, если вашему проекту больше года, то большинство нужного у вас уже есть, просто размазано тонким слоем. Вы правы, сложно собрать это все, особенно в первый раз, но это работа для синьора или техлида команды (если нет ML-инженера).
Возможно, со временем начнут появляться курсы как это делать правильно.
Не получится, один сервер это 1 одновременный prefill на максимальной скорости и максимум 4 одновременно генерируемых промпта (при примерно 2х кратном понижении скорости от 1 запроса, особо мощные сервера до 8 тянут одновременно при 3х кратном понижении скорости). При увеличении количества одновременных запросов скорость будет падать линейно, при этом prefill полностью! нагружает железо, т.е. либо обработка входных данных либо генерация.
Главный ограничитель времени работы с ИИ, это скорость генерации. условные 90% времени человек сидит и ждет ответа (в идеале наблюдая за его размышлениями, это рекомендуется, что бы понять и остановить его вовремя). Когда ИИ обрабатывает 3000 токенов prefill и 100 токенов генерации в секунду, это очень хорошая скорость, и работа агента неплохо синхронизируется с человеком, при падении в 3-4 раза скорость это очень заметно, человек не может столько ждать, приходится переключать контекст, быстрая память сбрасывается, и заниматься другим не эффективно, постоянно переключаться туда сюда, хотя, полагаю, это то направление развития для человека, в котором нужно двигаться для эффективной работы с ИИ.
Так вот, один условный сервер для запуска хотя бы qwen3.8-coder-next в принципе подойдет команде из 3-4 человек (и то, неплохо было бы планировать нагрузку заранее), а дальнейшее увеличение нагрузки чревато сильной когнитивной нагрузкой на разработчиков и почти наверняка повысит шансы выгорания и иных психических расстройств.
p.s. осторожно с минимальными требованиями vram для сервера, они должны включать kv-cache для каждого запущенного одновременно агента (для полного окна контекста это обычно БОЛЬШЕ или сравнимо с объемом весов), иначе в кеш (80%-95% токенов) перестанете попадать, это повысит нагрузку на prefill и кратно (не чуть чуть а в несколько раз) еще понизит скорость работы.
Вы правы в технической части, но ошибаетесь в организационной.
Prefill (обработка входного промпта) действительно является compute-bound и почти полностью занимает GPU, а decode (генерация токенов) упирается в пропускную способность видеопамяти (memory-bound).
Современные inference-серверы с continuous batching устроены так, что до какого-то порога батчинга суммарная пропускная способность (токенов/сек по всем запросам) не падает, а растет почти линейно с числом одновременных запросов, потому что decode изначально недогружает GPU, и добавление параллельных последовательностей просто лучше утилизирует железо.
Деградация на запрос начинается заметнее ближе к границе, где система переходит из memory-bound в compute-bound режим. То так картина, о которой чем вы говорите не строго линейна и не универсальная для "4-8 пользователей" т.к. это сильно зависит от конкретной модели и конкретного стека.
Так вот, один условный сервер для запуска хотя бы qwen3.8-coder-next в принципе подойдет команде из 3-4 человек
Зачем? Вот просто зачем тащить в прод 125B сеть являющуюся ранним архитектурным превью-показом следующей версии архитектуры? Это все равно что в прод ставить инженерный проц.
Есть модели, которые при правильной настройке и адапатции показывают в ежедневной работе схожее качество при втрое меньшем размере и требованиях.
p.s. осторожно с минимальными требованиями vram для сервера
У вас сложилась своя картина с когнитивными искажениями где нужно обязательно брать модель как можно большего размера, я писал об этом искажении в статье. При правильно выбранной модели и KV-кеша хватает на весь контекст и батчинг хорошо работает, и спекулятивное декодирование не сует палки в колеса генерации (а оно может).
Скрытый текст
Я вообще дома принципиально агента гоняю на qwen3.8-27b (а так же сравниваю с облачным glm3.5-flash), считаю что изучать недостатки lm-ок нужно именно на слабых моделях. Если честно модель шикарна, особенно если приспособиться к ней.
qwen coder next приведен как пример, у этой модели требования очень демократичны при относительно неплохом качестве.
Небольшим командам сервер под нее по силам, а вот для топовых открытых с терабайтовыми весами типа glm 5.3 (кстати ее flash рекомендую) или qwen max или deepseek (даже flash версия 600M весов) уже нет, там ценник взлетает совсем негуманный. Мало какие команды сумеют окупить этот сервер.
Естественно, 'если у вас нет хлеба, ешьте пирожные', 'если ты бездомный - купи его'... хорошо рассуждать о том что хорошо а что нет, если деньги в карманы не влезают.
p.s.
а когда экономишь, берешь железо по слабее, все еще менее красиво становится (вообще при превышении штатного контекста в 200к еще и качество начинает падать, но тестов мало потому что это дорого, а для маленькой модели качество начинает падать уже после 100к)
По поводу qwen3.8-27b я с вами полностью согласен.
Естественно, 'если у вас нет хлеба, ешьте пирожные', 'если ты бездомный - купи его'... хорошо рассуждать о том что хорошо а что нет, если деньги в карманы не влезают.
Это неверная аналогия. Давайте рассмотрим индивидуальный и командный имаго-кодинг.
В командном все просто, сервер покупает компания, команда разработчиков использует его продолжая оставаться хоть на ноутбуках.
В индивидуальном сейчас есть варианты либо взять DGX Spark или аналоги либо собрать собственный сервер, пол ютуба забито кейсами как люди это делают.
Поймите, имаго-кодинг это следующий уровень разработки, вариант ближайшего будущего. И очевидно, что он не будет сходу массовым т.к. требует не только дополнительных знаний, но и дополнительных расходов.
По поводу претензий к стоимости, хороший инструмент стоит денег, точно также недовольны строители, что качественный перфоратор Makita стоит дорого. Это даже не от отрасли зависит, а от непонимания того, что хороший качественный инструмент для специалиста всегда не дешев.
В этом плане инструмент для имаго-кодинга все еще проигрывают стоимости инструментов (станков) для слесаря.
Я думаю, тут сильно влияет ML-деформация автора. Лично мне проще скорректировать поведение типовой модели навыками, чем дообучением.
Ну и вот это:
Я работаю с данными предприятий, а там почти всегда есть либо коммерческая тайна, либо персональные данные, либо и то и другое.
Но, если есть готовый корпус данных для обучения, который не "протухает" со временем, то дообученная модель будет, IMHO, эффективнее типовой. Для крупных "контор" вполне себе решение.
Если под навыками вы имеете ввиду скилы, то они также используются, как и харнесс, тут нет противопоставления.
Для простых задач в готовой системе их обычно достаточно, но для сложных (создание системы с нуля, создание подсистемы в большой системе, рефакторинг крупных проектов и тд) этого уже недостаточно и по скорости разработки и по качеству решения.
Для простых задач в готовой системе их обычно достаточно
Я исхожу из того, что промпт (входные данные) влияет на результат инференса сильнее, чем дообучение (коррекция весов, по сути). Поэтому я придерживаюсь другой позиции - дообучение "экономит" токены, позволяя задавать более простые промпты и подмешивая меньше текста из скиллов. Согласен, что дообученная модель сможет работать с бОльшими фрагментами текста, чем "скилизованная". Но декомпозиция кодовой базы на небольшие фрагменты вполне позволяет комфортно работать с типовой моделью и набором скиллов к ней.
У меня в ML опыта нет вообще, я наблюдаю. Поэтому тут наши выводы вполне могут разниться.
Я исхожу из того, что промпт (входные данные) влияет на результат инференса сильнее, чем дообучение (коррекция весов, по сути).
Вы абсолютно правы, но только для относительно простых, одно-двухшаговых задач. Как только начинается что-то более многошаговое (агент в харнесе строит сложную систему с кучей требований) это перестает работать. Модель быстрее забывает "середину контекста" (U-образное забывание контекста) и промтами вы ее не решите, а адапатция как раз хорошо уменьшает эту проблему.
Согласен, что дообученная модель сможет работать с бОльшими фрагментами текста, чем "скилизованная".
Адаптация смещает веса в сторону правильных решений по этой теме, что позволяет избегать хождения по кругу там где неадаптированная модель войдет в цикл (на сложных задачах) или предложит формально рабочее, но вообще не подходящее решение. Я думаю, вы с этим сталкивались неоднократно на сложных задачах.
Но декомпозиция кодовой базы на небольшие фрагменты вполне позволяет комфортно работать с типовой моделью и набором скиллов к ней.
Да, и это прекрасно работает когда нужно что-то поменять в существуюшей базе в паре файлов или написать пару новых функций. Но когда нужно написать новый большой модуль или подсистему, отрефакторить существующую кодовую базу или написать систему с нуля, итд, вот тут и проявится в полной мере ограничение вашего подхода.
Он рабочий, но только на простых задачах. Если у вас только простые задачи (поддержка/багфиксы существующей кодовой базы), то имаго-кодинг вам не нужен.
Если же вы создаете или активно меняете существенные части системы, то без него получает катание на велосипеде без сидения. Я уже накатался. Имаго-кодинг позволяет более качественно и быстро решать сложные задачи в разработке.
Он рабочий, но только на простых задачах.
Мне кажется, что в решении сложных задач ключом является как раз таки разбиение сложной задачи на последовательность простых задач, каждая из которых решается с малым количеством ресурсов.
Ну, или возможно, я просто ещё не дошёл до по настоящему сложных задач.
Мне кажется, что в решении сложных задач ключом является как раз таки разбиение сложной задачи на последовательность простых задач, каждая из которых решается с малым количеством ресурсов.
Это правильный подход (декомпозиция), но если мы говорим о кодогенерации, то ИИ сам разбивает на подзадачи тратя контекст.
Если человек будет сам это делать то и выигрыш от скорости будет околонулевой, т.к. для специалиста зачастую написать код небольшой задачи проще и быстрее, чем объяснить LLM что и как именно нужно реализовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Имаго‑кодинг