Как клещами тяну информацию, если там nda или просто 'жаба душит' делиться, так и скажите.
Про базу нужно сказать структуру и особенности использования все редакторов модели (количественные характеристики связей м-1/м например).
Можно показать примеры sql с переменными, словесным описанием...
Или вы буквально написали несколько запросов и ИИ только выбирает нужный, в этом случае вы у модели спрашиваете итоговый запрос или детерминированный алгоритм выбирает и заполняет переменные?
p.s. что бы не опасаться внутреннего саботажа, нужно собирать очень подробную телеметрию, и потом обрабатывать ее
о какой безопасности в зоне ру идет речь? от кого безопасность?
даже если сам владелец будет 'белый и пушистый', в один прекрасный момент к владельцу сервиса приходят 'с предложением от которого нельзя отказаться' и вот сервис уже не такой безопасный.
я читал, что с этим электролитом нет особой мороки, затраты на подготовку после длительной эксплуатации считанные проценты энергии от его емкости, а где то тупо разрядить и перемешать... больше следить что бы с кислородом не контактировал и водород сцеживать.
проточные аккумуляторы идеальны там где нет проблем с местом и весом, т.е. со стационарным размещением.
p.s. была тут статья, кто то экспериментировал с электролитом на основе железного купороса, так вот, он нереально дешев правда и низкая емкость (и да, требует обслуживание, но не сложное), по мне так вообще идеально для персонального буферного аккумулятора дома (разместить пару баков по 200л в подвале не проблема)
что бы 260 миллионов литров электролита в случае чего не потекли рекой а остались под землей, и вроде бы так удобнее размещать все это компактно с точки зрения площади
поделитесь пожалуйста вашими технологиями работы ваших агентов на общение, как вы защищаете вашу инфраструктуру от злонамеренны сообщений? на сколько я знаю, ни один готовый агент по умолчанию нормальной защиты не дает... т.е. либо полностью изолировать агентов от функционала либо рисковать
p.s. глаз зацепился за ваше сообщение про правильные таблички от ИИ. сделать корректную и детерминированную аналитику на базе ИИ это тот еще квест.
добавьте что будут использовать водный раствор ванадиевых солей (еще не ясно какая концентрация), на каждый киловат*час емкости это обходится в сотни $200-$500 (речь про емкость а не стоимость энергии из розетки)
ИИ вам 10 sql запросов сделает правильными, а 11-ый с ошибокй, 12- удалит базу а 13-ый сольет бакапы вашим конкурентам, потому что вы автоматизировали общение с народом в чате, не подумав о безопасности
Все веса модели и kv-cache помещаются в gpu vram? тогда ваш крутой 100500ядерный процессор и крутая ddr100500 память не задействована более чем полностью. Если между gpu нет интерконнекта, то процессор чуть чуть занят перекидыванием данных между gpu, и это очень маленькая нагрузка, упирается в pci-e шину.
Я допускаю, что есть отдельная задача, запуск очень маленьких моделей на мощном железе (например вычисление embending но там контекст мизерный) при большом контекстном окне, в режиме агентских задач или длинных чат сессиях (каждое следующее сообщение заставляет токенизер повторно обрабатывать этот контекст) процессор станет заметным.
Вот это и нужно было тестировать, или опять заголовок и посыл статьи - прямая ложь.
selectel, вы датацентр, у вас железо, у вас возможности, сделайте хоть раз правильно что-нибудь. Вы же физически можете протестировать cpu+ram железо слабое и сильное с одной и той же gpu, в разных сценариях (да хватит синтетики - длинный контекст и короткий), не умеете? самый тупой агент вам готовые команды сделает, тесты проведет, табличку составит.
Рекомендация, что можно протестировать:
Две сборки из слабого процессора (условно прошлого поколения, ddr4 ram, в идеале заниженные частоты и тайминги, в биосе это пару кликов, и последнего) с 4-мя/8-мью gpu.
Проверить, как влияет для одной и той же llm модели размещение ее на разных gpu (т.е. на 1, на 2, на 4,..) и как влияет на это выбор процессора и памяти.
Все проверки проводить на сценариях (с последовательными не параллельными запросами и отдельно параллельными, перебирая предел одновременных запусков): - короткий контекст + короткая генерация - короткий контекст + длинная генерация - длинный контекст + короткая генерация - длинный контекст + длинная генерация и длинные тесты дополнительно проводить в режиме чата для теста работы попадания части контекста в кеш, еще отдельно тестировать наличие изображений в промпте, как одного, так и нескольких.
Затем эти тесты закинуть сообществу, такая табличка будет в миллион раз полезнее рекламной статьи о том что на ваших серверах работает kimi-k2 (если что намекну, что сейчас в топах glm-5.2, рекомендую хвастаться ею), даже если это будет единственное содержимое статьи
Спешно выкатывают корпоративного ассистента — чат поверх LLM, обёрнутый в фирменные цвета
а зачем, не сказали.
Народ заходит в чат с ИИ, кидает пару вопросов на засыпку, офигивает от ответов и больше не возвращается.
---
Кто то по своей инициативе пробует этим пользоваться, кто то, чуть более умный, исследует границы применимости,..
Единицы исследуют, какие алгоритмы стоят в основе и почему одни задачи даже слабая llm в основе агента решает, а другие, вроде бы не такие сложные, даже топовые модели - спотыкается.
Вот это знание и понимание, на текущий момент, и нужно программистам. Сделать это можно в общем случае только потратив время и токены на эксперименты. Делайте это за счет работодателя, только не забудьте его предупредить, что сейчас ИИ слабый, дорогой, требует больше времени и создает кучу отложенных проблем в задачах.
нет доступного железа по адекватной цене что бы запускать топовые открытые модели 'для своих'.
Условная glm-2.5 (вроде она считается лучшей на текущий момент из доступных для запуска) требует для работы железо (600gb-800gb vram) с ценой порядка $8k-$10k в месяц (vas.ai можно набрать на $12 в час, и позволит оптимизировать аренду с почасовой оплатой почти на треть, особенно если команда в одном часовом поясе, но будет проблема с весами, пол терабайта развернуть за час не получится, нужно напрямую связываться с хостером). Одна машина сможет обрабатывать без заметной деградации скорости порядка 8 одновременных запросов (вроде бы всего двухкратное понижение скорости генерации относительно одного, но скорость обработки input упадет сильнее, оно не паралелится)... в общем не сходится никак маркетинг.
Крупные провайдеры могут оптимизировать инференс за счет большого количества клиентов и плавно подруливать количеством серверов и используя почасовую оплату (условно bare metall для постоянной нагрузки, а пиковые разруливать более дорогой почасовой арендой). Мелким это недоступно.
p.s. llama.cpp умеет собирать в единый кластер машины по сети, в т.ч. cpu, в т.ч. разнородное железо. В некотором смысле, собрать из десятка машин с десктопным железом (оно дешевле почти в 10 раз) а так как там moe архитектура, даже не сильно платить за это скоростью... условные 2.5 милиона рублей и кластер из 40-штук 5060ti 16гб у вас в кармане, делим на условные 3 года (это все начнет ломаться) и получаем примерно 2т.р. в сутки.. уже более реально но все еще грустно для небольших команд
роботы пока умеют учиться только ходить, а вот 'работу делать' пока не очень, нет у нас готовых алгоритмов
по поводу одежды - она рвется, она пачкается, она гибкая.. вы не представляете на сколько это сложно просто роботу раздеть/одеть другого робота (но в принципе решаемо, если придумать разборную одежду на условных магнитных застежках, они же узлы взаимодействия.. разбиение одежды на секции упрощает алгоритмы до детерменированных, типа специальной камеры, все это тяжелое, требует дополнительной энергии, очистки, ремонта и т.п... но энергии в первую очередь)
а на сколько плохо делать сцепку гибкой и подруливать где надо двигателями ориентации и гироскопами?
p.s. мне больше нравится идея, исключить в баках в принципе газообразной фазы (ведь проблему создает существование границы газ-жидкость), сделав баки динамически изменяемого объема (условный 'воздушный шарик' или 'поршень') ... послушал ИИ, оказывается это уже используется в той или иной форме
Вы проводили какую-то численную оценку качества вашего решения и как строили базу тестовых вопросов и ответов?
Вы пробовали сравнивать ваше решение с типовыми решениями 'на рынке', какой-нибудь opensource rag заточенный на работу с базой ваших документов?
p.s. попробуйте протестировать ваше решение на маленьком датасете, под сотню-другую документов, сравнивая с эталонным алгоритмом, который каждый документ целиком прогоняет через поисковый вопрос с системным промптом типа 'подходит ли этот документ под запрос:'. Эталонный алгоритм, пока документ влезает в условные 16к..32к токенов, даже слабые модели дают неплохой результат... только такой алгоритм очень дорогой и медленный
p.p.s.
а ведь его можно сделать еще лучше, для документов бОльшего размера, использовать скользящее окно с накоплением важной информации о документе в целом (контекстное окно: системный промпт, поисковый вопрос, накопленная выжимка по теме, скользящее окно из документа - системный промпт должен обязать собирать выжимку по теме, и давать оценку, подходит ли текущий кусок из документа под запрос или инет).
еще, не очень понимаю, как добавление предыдущего чанка к следующему поможет в ситуациях, когда важная информация находится буквально в начале документа... уже через 2-3 чанка она будет потеряна и не будет учитываться... например в начале документа описывается условие применимости (те же даты или особенности участников) всего документа целиком.
на android у вас хотя бы варианты есть, а вот с iphone безальтернативно нет, кто-нибудь 'скажите им' что со своими айфончиками свои же законы нарушают... ой а им пофиг
'спасибо' ИИ за такой развернутый и бесполезный комментарий.
Я всего лишь указал что заголовок и первоначальный посыл статьи - не совпадает с ее содержанием, и указал какое это содержание должно быть.
Тесты и нужны, что бы привести теорию к практической конкретике, вот такие то модели в такой то ситуации на столько то зависят от процессора.
Как клещами тяну информацию, если там nda или просто 'жаба душит' делиться, так и скажите.
Про базу нужно сказать структуру и особенности использования все редакторов модели (количественные характеристики связей м-1/м например).
Можно показать примеры sql с переменными, словесным описанием...
Или вы буквально написали несколько запросов и ИИ только выбирает нужный, в этом случае вы у модели спрашиваете итоговый запрос или детерминированный алгоритм выбирает и заполняет переменные?
p.s. что бы не опасаться внутреннего саботажа, нужно собирать очень подробную телеметрию, и потом обрабатывать ее
@al-chemist, интересно, можете поделиться хоть каким-нибудь примером, в каком виде описаны эти шаблоны и сами шаблоны.
о какой безопасности в зоне ру идет речь? от кого безопасность?
даже если сам владелец будет 'белый и пушистый', в один прекрасный момент к владельцу сервиса приходят 'с предложением от которого нельзя отказаться' и вот сервис уже не такой безопасный.
я читал, что с этим электролитом нет особой мороки, затраты на подготовку после длительной эксплуатации считанные проценты энергии от его емкости, а где то тупо разрядить и перемешать... больше следить что бы с кислородом не контактировал и водород сцеживать.
проточные аккумуляторы идеальны там где нет проблем с местом и весом, т.е. со стационарным размещением.
p.s. была тут статья, кто то экспериментировал с электролитом на основе железного купороса, так вот, он нереально дешев правда и низкая емкость (и да, требует обслуживание, но не сложное), по мне так вообще идеально для персонального буферного аккумулятора дома (разместить пару баков по 200л в подвале не проблема)
что бы 260 миллионов литров электролита в случае чего не потекли рекой а остались под землей, и вроде бы так удобнее размещать все это компактно с точки зрения площади
поделитесь пожалуйста вашими технологиями работы ваших агентов на общение, как вы защищаете вашу инфраструктуру от злонамеренны сообщений? на сколько я знаю, ни один готовый агент по умолчанию нормальной защиты не дает... т.е. либо полностью изолировать агентов от функционала либо рисковать
p.s. глаз зацепился за ваше сообщение про правильные таблички от ИИ.
сделать корректную и детерминированную аналитику на базе ИИ это тот еще квест.
добавьте что будут использовать водный раствор ванадиевых солей (еще не ясно какая концентрация), на каждый киловат*час емкости это обходится в сотни $200-$500 (речь про емкость а не стоимость энергии из розетки)
ИИ вам 10 sql запросов сделает правильными, а 11-ый с ошибокй, 12- удалит базу а 13-ый сольет бакапы вашим конкурентам, потому что вы автоматизировали общение с народом в чате, не подумав о безопасности
Все веса модели и kv-cache помещаются в gpu vram? тогда ваш крутой 100500ядерный процессор и крутая ddr100500 память не задействована более чем полностью. Если между gpu нет интерконнекта, то процессор чуть чуть занят перекидыванием данных между gpu, и это очень маленькая нагрузка, упирается в pci-e шину.
Я допускаю, что есть отдельная задача, запуск очень маленьких моделей на мощном железе (например вычисление embending но там контекст мизерный) при большом контекстном окне, в режиме агентских задач или длинных чат сессиях (каждое следующее сообщение заставляет токенизер повторно обрабатывать этот контекст) процессор станет заметным.
Вот это и нужно было тестировать, или опять заголовок и посыл статьи - прямая ложь.
selectel, вы датацентр, у вас железо, у вас возможности, сделайте хоть раз правильно что-нибудь. Вы же физически можете протестировать cpu+ram железо слабое и сильное с одной и той же gpu, в разных сценариях (да хватит синтетики - длинный контекст и короткий), не умеете? самый тупой агент вам готовые команды сделает, тесты проведет, табличку составит.
Рекомендация, что можно протестировать:
Две сборки из слабого процессора (условно прошлого поколения, ddr4 ram, в идеале заниженные частоты и тайминги, в биосе это пару кликов, и последнего) с 4-мя/8-мью gpu.
Проверить, как влияет для одной и той же llm модели размещение ее на разных gpu (т.е. на 1, на 2, на 4,..) и как влияет на это выбор процессора и памяти.
Все проверки проводить на сценариях (с последовательными не параллельными запросами и отдельно параллельными, перебирая предел одновременных запусков):
- короткий контекст + короткая генерация
- короткий контекст + длинная генерация
- длинный контекст + короткая генерация
- длинный контекст + длинная генерация
и длинные тесты дополнительно проводить в режиме чата для теста работы попадания части контекста в кеш,
еще отдельно тестировать наличие изображений в промпте, как одного, так и нескольких.
Затем эти тесты закинуть сообществу, такая табличка будет в миллион раз полезнее рекламной статьи о том что на ваших серверах работает kimi-k2 (если что намекну, что сейчас в топах glm-5.2, рекомендую хвастаться ею), даже если это будет единственное содержимое статьи
проблема в тех кто сказал
А главное, внедряют
а зачем, не сказали.
Народ заходит в чат с ИИ, кидает пару вопросов на засыпку, офигивает от ответов и больше не возвращается.
---
Кто то по своей инициативе пробует этим пользоваться, кто то, чуть более умный, исследует границы применимости,..
Единицы исследуют, какие алгоритмы стоят в основе и почему одни задачи даже слабая llm в основе агента решает, а другие, вроде бы не такие сложные, даже топовые модели - спотыкается.
Вот это знание и понимание, на текущий момент, и нужно программистам. Сделать это можно в общем случае только потратив время и токены на эксперименты. Делайте это за счет работодателя, только не забудьте его предупредить, что сейчас ИИ слабый, дорогой, требует больше времени и создает кучу отложенных проблем в задачах.
нет доступного железа по адекватной цене что бы запускать топовые открытые модели 'для своих'.
Условная glm-2.5 (вроде она считается лучшей на текущий момент из доступных для запуска) требует для работы железо (600gb-800gb vram) с ценой порядка $8k-$10k в месяц (vas.ai можно набрать на $12 в час, и позволит оптимизировать аренду с почасовой оплатой почти на треть, особенно если команда в одном часовом поясе, но будет проблема с весами, пол терабайта развернуть за час не получится, нужно напрямую связываться с хостером). Одна машина сможет обрабатывать без заметной деградации скорости порядка 8 одновременных запросов (вроде бы всего двухкратное понижение скорости генерации относительно одного, но скорость обработки input упадет сильнее, оно не паралелится)... в общем не сходится никак маркетинг.
Крупные провайдеры могут оптимизировать инференс за счет большого количества клиентов и плавно подруливать количеством серверов и используя почасовую оплату (условно bare metall для постоянной нагрузки, а пиковые разруливать более дорогой почасовой арендой). Мелким это недоступно.
p.s. llama.cpp умеет собирать в единый кластер машины по сети, в т.ч. cpu, в т.ч. разнородное железо. В некотором смысле, собрать из десятка машин с десктопным железом (оно дешевле почти в 10 раз) а так как там moe архитектура, даже не сильно платить за это скоростью... условные 2.5 милиона рублей и кластер из 40-штук 5060ti 16гб у вас в кармане, делим на условные 3 года (это все начнет ломаться) и получаем примерно 2т.р. в сутки.. уже более реально но все еще грустно для небольших команд
подождите, значит накладываемое видео человека - создано по каким технологиям?
роботы пока умеют учиться только ходить, а вот 'работу делать' пока не очень, нет у нас готовых алгоритмов
по поводу одежды - она рвется, она пачкается, она гибкая.. вы не представляете на сколько это сложно просто роботу раздеть/одеть другого робота (но в принципе решаемо, если придумать разборную одежду на условных магнитных застежках, они же узлы взаимодействия.. разбиение одежды на секции упрощает алгоритмы до детерменированных, типа специальной камеры, все это тяжелое, требует дополнительной энергии, очистки, ремонта и т.п... но энергии в первую очередь)
а на сколько плохо делать сцепку гибкой и подруливать где надо двигателями ориентации и гироскопами?
p.s. мне больше нравится идея, исключить в баках в принципе газообразной фазы (ведь проблему создает существование границы газ-жидкость), сделав баки динамически изменяемого объема (условный 'воздушный шарик' или 'поршень')
...
послушал ИИ, оказывается это уже используется в той или иной форме
в статье есть прекрасные статичные модели с волосами, но только одна десятая секунды движения с танцующей девушкой и у той волосы собрали в клубок.
Нет ли анимации волос? потому что на этом все ломается.
Вы проводили какую-то численную оценку качества вашего решения и как строили базу тестовых вопросов и ответов?
Вы пробовали сравнивать ваше решение с типовыми решениями 'на рынке', какой-нибудь opensource rag заточенный на работу с базой ваших документов?
p.s. попробуйте протестировать ваше решение на маленьком датасете, под сотню-другую документов, сравнивая с эталонным алгоритмом, который каждый документ целиком прогоняет через поисковый вопрос с системным промптом типа 'подходит ли этот документ под запрос:'. Эталонный алгоритм, пока документ влезает в условные 16к..32к токенов, даже слабые модели дают неплохой результат... только такой алгоритм очень дорогой и медленный
p.p.s.
а ведь его можно сделать еще лучше, для документов бОльшего размера, использовать скользящее окно с накоплением важной информации о документе в целом (контекстное окно: системный промпт, поисковый вопрос, накопленная выжимка по теме, скользящее окно из документа - системный промпт должен обязать собирать выжимку по теме, и давать оценку, подходит ли текущий кусок из документа под запрос или инет).
еще, не очень понимаю, как добавление предыдущего чанка к следующему поможет в ситуациях, когда важная информация находится буквально в начале документа... уже через 2-3 чанка она будет потеряна и не будет учитываться... например в начале документа описывается условие применимости (те же даты или особенности участников) всего документа целиком.
полагаю выбор будет тут по 'есть или нет деньги что бы отобрать', нет денег - кому ты нафиг нужен.
правда скорее наличие денег не по проекту а по человеку будет рассматриваться, а закон будет использоваться как повод наехать на человека.
таких ловушек в законе явно не одна.
Вы проводили качественную оценку вашего подхода, что бы было с чем сравнивать?
Вы пользовались только yandex моделями? Только облачными? а открытыми локальными не пробовали?
на android у вас хотя бы варианты есть, а вот с iphone безальтернативно нет, кто-нибудь 'скажите им' что со своими айфончиками свои же законы нарушают... ой а им пофиг