Обновить
18
0.3
Максим @SabMakc

Пользователь

Отправить сообщение

"а если не видно разницы, зачем платить больше?"
Да, все так. Но если LLM решает мои задачи - то так ли нужно это осознание и понимание?

Я даю ИИ код - на выходе тесты. Не факт что я бы написал лучше и уж точно я бы писал дольше (ладно, с учетом подбора промта я бы написал быстрее - но это больше вопрос моего опыта работы с ИИ и однотипности задачи - выигрыш по времени не сразу получился).

И возникает очень философский вопрос - а на сколько человек осознает и понимает это все?

Недавно где-то видел результаты опроса, что пользователи откажутся от LLM, если подписка станет обязательной. А большинство пользователей того же ChatGPT не платят (видел оценки в 500млн активных пользователей в неделю и всего в 15,5млн подписчиков - конверсия около 3% получается).

Так что да, многие используют - спору нет. Станет плата обязательной - много кто перейдет на подписку. Еще больше людей просто перестанет использовать. Но это все и близко не окупит инвестиции.

Я не спорю, что перспективы есть. И польза есть. Но хайп очень сильно раздул ожидания. И в этом очень большая проблема.

не видно каких-то кризисов в индустрии

Проблем достаточно. И главная - это очень дорого. ChatGPT так и не стал прибыльным, хотя и самый популярный.

Рынок LLM называют пузырем - слишком много расходов, слишком много обещаний и слишком мало реальной пользы.

А2А протокол уже есть - это просто общий чат с несколькими LLM (основное применение LLM - это чат с ними, они хорошо заточены на это дело).
Тем более с появлением MCP проще некуда вызвать "соседа", специализирующегося на своей теме.

Но что-то "великого прорыва" на этом поприще не произошло...

RAG, MCP, Agent - это новые возможности для LLM, а не изменения в LLM.

Кардинально LLM - это просто "T9 на супер-стероидах".

Так что да, кардинально LLM останутся примерно такими же. Но знания, заложенные в LLM растут, растут "навыки" использования инструментов и т.д. Уменьшается вес моделей, повышается скорость вычисления, появляются новые алгоритмы работы и обучения.

Так что прогресс есть и он существенен.

Но да, человека (специалиста) LLM не превзойдет (по глубине знаний) - просто потому, что обучается на данных от человека (или компиляции этих данных). А по "ширине" знаний LLM уже впереди - просто потому, что обучается на данных всего человечества, а не в какой-то своей области.

Пускай я и согласен с посылом статьи, но вот аргументация...

ИИ (LLM) - это не компьютер и никогда не позиционировался как замена компьютера. LLM позиционируется как замена человеку. А человек не обладает 100% точностью.

Пускай LLM и отстает от специалиста, но уже превосходит не-специалиста в знаниях. И с этой точки зрения можно считать, что LLM уже превосходит человека - просто потому что LLM превосходит знаниями любого человека, если считать не "глубину" знаний, а "ширину".

Так что да, LLM не дают детерминированный результат (что, впрочем, спорно - детерминированность ответа на одних и тех же данных достижима), тем более не дают 100% надежности в правильности ответов, что значительно сокращает применимость LLM. Но это значительный шаг вперед, в первую очередь в роли личных ассистентов, а не как замена человеку.

Если есть желание гонять LLM - то лучше сразу на полноценный комп закладываться, с видеокартой и прочими ништяками.

Я бы на мини-системник на базе AMD Ryzen AI MAX+ 395 посмотрел - распаяно 128GB быстрой памяти (что хорошо для LLM), но цена - около 200к, что не так уж и бюджетно (хотя если собирать новый комп с похожими характеристиками, то не сильно дешевле выйдет).

Может для умного дома и избыточно, но мощная локальная LLM пригодится и в повседневной жизни.

У phi 4 с русским языком "очень не очень".
Гугл пиарился с gemma-3n, но она только текст и картинки принимает, если не ошибаюсь.
Llama - их множество, дотренированных различным образом, но не пробовал. В целом об их моделях молва идет как о не очень качественных (не знаю, на сколько это соотносится с реальностью).

Я бы посмотрел на Voxtral от mistralai.
В целом, те модели от mistralai, что пробовал, русский понимают, пускай и не лучшим образом (но именно Voxtral не пробовал).

LLM и на CPU работают, вопрос скорости генерации токенов (и обработки запроса). А скорость зависит от пропускной способности памяти, где видеокарты как раз в почете.

С этой точки зрения APU не имеют особого смысла - просто потому, что скорость памяти не меняется.

P.S. Самый большой эффект оптимизаций видел в обработке запросов, но не в генерации (ik_llama.cpp в разы быстрее llama.cpp на CPU).

Может сервер приложений - артефакт былых времен? Навскидку, ни Golang, ни Rust не имеют сервера приложений, что не мешает создавать "что-то серьезное и маштабируемое" на них.

P.S. к слову, за сервер приложений сейчас выступает docker (и k8s). Так что "нет сервера приложений" - очень спорно. Он просто видоизменился и стал универсальным.

как будто бы после перезагрузки вообще все установленные пакеты сбрасываются

Да, при перезапуске контейнера все, что не в образе или volume сбрасывается. Это полностью ожидаемое поведение docker.
Решение простое: собрать свой образ с нужными пакетами - тогда сбрасываться не будут.

К слову, при сборке своего образа можно средствами мульти-этапной сборки скинуть скомпилированный github-mcp-server с "родного" образа, а не собирать руками (что потребует установки Golang).

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

В доках и работа с бинарником расписана, чуть ниже примера с docker )

Доступ к докеру в контейнере - идея не лучшая. Этим полный root-доступ к системе предоставили.
Не проще было бинарник github-mcp-server скопировать в контейнер и через него работать?

P.S. не все инструкции WASM детерминированы, но его реально сделать детерминированным на уровне VM.

Простейший способ - скомпилировать движок вывода в WASM, проконтролировав детерминированность API с хост-системой.

На выходе получим детерминированный вывод LLM - потому как виртуальная машина WASM строго детерминирована, а вся недетерминированность может возникать исключительно при вызове функций хоста.

Но скорость работы будет очень низкой. Мало того, что выполнение исключительно на процессоре, причем в виртуальной машине (пускай и не сильно большую лишнюю нагрузку она дает). Так еще и множество низкоуровневых оптимизаций не сделать из-за ограниченного числа инструкций виртуальной машины.

Судя по этой записи в X, кластер из пары M3 Ultra 512GB действительно имеет место быть )))

18t/s вполне соответствует пропускной способности памяти в 819 ГБ/с.
Глобальный "ой" - просто по тому, что 512ГБ мало для длинного контекста (хотя со свапом MoE-модели работают относительно быстро, насколько я видел, но как раз pp и страдал).

И опять же, любитель запросов "hi" показал, что маки хорошо кластеризируются. Так что пара Mac Studio M3 Ultra на 512Gb должна решить и эту проблему.

В любом случае, Mac Studio M3 Ultra на 512Gb - это то, лучшее, на мой взгляд, что можно купить за более-менее адекватные деньги для локальной работы с deepseek с адекватной скоростью.

Да, это не идеальный вариант, маловато памяти для действительно больших моделей. Да и стоимость очень высока. Но альтернативные варианты какие есть?

Недетерминированность LLM в софте, а не в моделях.
В целом, ничего не мешает сделать строго детерминированный вывод LLM. Но да, куча нюансов полезет, особенно если за скоростью вывода гнаться.

Откуда такие цифры?
Тесты показывают 18 ток/сек для deepseek-r1 в q4-кванте.

Вот я про это и говорю. RAG просто "обогащает" запрос по похожим данным. Это не память для модели, это не "ассоциативные цепочки" для модели, не база знаний или еще что. Это просто "что-то похожее было, вот оно".

Просто я недавно поработал с WIT-описанием для WebAssembly Component Model. И допустил ошибку в описании - описал resource в world. И самое интересное, что кодогенерация по описанию работала, но невозможно было использовать сгенерированные классы. Да, в спецификациях сказано, что в world допустимы только импорт/экспорт функций и интерфейсов. Но упустить этот нюанс не сложно (особенно если спецификацию не наизусть знаешь).

Когда уже разобрался, в чем проблема - мне стало интересно, а ИИ найдет эту ошибку в WIT (про решение исходной проблемы, с кодом, даже не говорю)? Топовые модели не справляются (как минимум deepseek-r1, grok-4, kimi-k2, gemini-2.5-pro, gpt-4.1, может что еще пробовал), хотя и знают что это WIT, Component Model и т.д. (к слову, это знали все опробованные модели, в том числе и локальные).

Но если в контекст добавить спецификации WIT (благо, что это просто один относительно объемный файл), то локальный Qwen3-30A-A3B успешно справляется с нахождением проблемы.

Пробовал в RAG загрузить (в OpenWebUI, параметры по умолчанию, кроме модели эмбеддинга - использовал nomic-embed-text) - он находит какие-то похожие куски (3 штуки, как задано в параметрах по умолчанию), но нужной фразы туда не попадает - и он не находит ничего полезного.

Вот я и думаю - а как вообще можно решать подобные кейсы, чтобы спецификации руками не кидать каждый раз. Хорошо, если модель явно несет ерунду - сразу видно, что спецификации не помешают. Но что делать, если ответ более качественный или ты в вопросе совсем не разбираешься (чтобы понять, что в ответе ерунда)?

Так что умная модель - это хорошо. Но не всегда есть модель, которую обучали на твоих сценариях использования и на твоих данных. Но модели способны "понять" новый материал и по нему сформировать ответ. Только нужно добавить нужные данные в контекст. RAG тут может и помогает, но явно не лучшим образом. А вот как это сделать лучшим образом - вопрос открытый.

Информация

В рейтинге
2 391-й
Откуда
Россия
Зарегистрирован
Активность