перевод: https://www.openpioneers.com/p/the-state-of-open-source-llms

С возвращением в Open Pioneers #32.

Прошло несколько месяцев с момента моей последней рассылки. Жизнь и работа в Linux Foundation занимали много времени, но я поставил перед собой цель снова писать еженедельно, начиная с этого момента.

Я также использую этот перезапуск, чтобы кое-что изменить: помимо нового брендинга, я перешел с платформы Beehiiv на Substack для своей рассылки. Я также решил сделать контент более личным и углубляться в темы с открытым исходным кодом, которые мне интересны. Я по-прежнему буду рассказывать об альтернативах с открытым исходным кодом, объявлять о раундах финансирования или интересных вакансиях в секторе открытого исходного кода, но скорее в качестве побочного замечания.

Я почистил список подписчиков и оставил в нем только тех, кто регулярно открывал мои электронные письма, так как не хочу никому рассылать спам.

Тем не менее, я очень рад снова начать это делать. В сфере открытого исходного кода происходит так много интересного, и я с нетерпением жду возможности продолжать узнавать об этом вместе с вами!

Состояние открытых больших языковых моделей (LLM)

Большие языковые модели (LLM) с открытым исходным кодом превратились из нишевых академических проектов в устойчивые, управляемые сообществом платформы, которые бросают вызов проприетарным гигантам, таким как Microsoft или Google. Сегодня LLM с открытым исходным кодом не только способствуют прозрачности и сотрудничеству, но и обеспечивают более экономичный и адаптируемый подход к разработке искусственного интеллекта.

Новая эра товарного ИИ

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

Последние разработки показали потенциал LLM с открытым исходным кодом. Например, китайская модель R1 от DeepSeek привлекла всеобщее внимание, поскольку она соответствует характеристикам ведущих моделей, таких как o1 от OpenAI, при этом обучаясь за небольшую часть стоимости и вычислительной мощности. Использование DeepSeek обучения с подкреплением и архитектуры “смесь экспертов” позволяет ей активировать только подмножество из своих 671 миллиарда параметров на запрос, тем самым снижая энергопотребление и требования к оборудованию.

Преимущества и проблемы LLM с открытым исходным кодом

LLM с открытым исходным кодом предлагают несколько убедительных преимуществ:

• Прозрачность и доверие:** Благодаря общедоступным данным обучения, исходному коду и весам моделей, LLM с открытым исходным кодом позволяют проводить тщательную проверку, что делает их менее “черным ящиком” по сравнению с проприетарными аналогами. Эта прозрачность приводит к доверию сообщества и совместному устранению неполадок.
• Низкие затраты:** Модели с открытым исходным кодом снижают барьер для входа. Экономическая эффективность открытого исходного кода особенно выгодна для академических учреждений и стартапов с ограниченными ресурсами – другими словами: это способствует инновациям.
• Настройка и гибкость:** Открытый доступ означает, что разработчики могут точно настраивать модели для нишевых приложений, интегрировать знания, специфичные для конкретной области, или даже адаптировать модели для местных языков – ключевое соображение для таких инициатив, какOpenEuroLLM, которая стремится обслуживать языковое разнообразие Европы.

Однако остаются и проблемы. LLM с открытым исходным кодом могут быть уязвимы для атак с использованием состязательных методов, и качество доступных данных обучения может варьироваться. Более того, хотя открытые модели способствуют инновациям, они также поднимают вопросы об ответственном использовании, поскольку мощные инструменты ИИ в чужих руках могут привести к злоупотреблениям. Баланс между открытостью и безопасностью – это продолжающийся разговор внутри сообщества, к которому мы должны отнестись серьезно.

Ключевые LLM с открытым исходным кодом, о которых вам следует знать

Ниже приведен снимок текущего ландшафта открытого исходного кода, согласно таблице лидеров Hugging Face Open LLM.

Следующие LLM с открытым исходным кодом выделяются для меня, потому что они очень часто смешиваются и сочетаются более широким сообществом ИИ:

• Llama 3.1 (Meta):** Серия Llama 3.1 от Meta — от небольших моделей до массивной версии с 405 млрд параметров — неизменно занимает высокие позиции в области генерации общего текста, многоязыковой обработки и задач кодирования.
• Mistral Large 2 (Mistral AI):** Благодаря мощной архитектуре с 123 миллиардами параметров и впечатляющему контекстному окну (до 128 тысяч токенов), Mistral Large 2 превосходно справляется как с пониманием языка, так и с задачами кодирования. Его разреженная конструкция “смесь экспертов” оптимизирует производительность при одновременном снижении затрат на вывод, что делает его лидером в эффективности и масштабируемости.
• DeepSeek R1 (DeepSeek):** Модель R1 от DeepSeek использует обучение с подкреплением и подход “смесь экспертов” для обеспечения конкурентоспособных возможностей рассуждения, математики и кодирования. Хотя DeepSeek предположительно использует менее сложное оборудование по сравнению со своими западными конкурентами (в США действует запрет на экспорт в Китай графических процессоров Nvidia), он достигает высокой производительности при небольшой доле затрат на обучение. Этот факт привел к множеству обсуждений, в том числе и в основных СМИ.
• DeepSeek v3 (DeepSeek):** Основываясь на серии R1, DeepSeek v3 использует архитектуру Mixture-of-Experts с 671 миллиардом параметров – с 37 миллиардами активированных параметров на токен – для обеспечения впечатляющей эффективности при генерации общего текста, многоязычной обработке и задачах кодирования.
• Qwen 2.5 (Alibaba):** Qwen 2.5 от Alibaba произвел фурор благодаря своим сильным многоязычным возможностям, специализированной производительности в области кодирования и математических рассуждений, а также эффективным стратегиям развертывания. Его компоненты с открытым исходным кодом выпущены под лицензией Apache 2.0.
• Falcon-180B (Technology Innovation Institute):** Модель Falcon-180B является свидетельством возможностей крупномасштабных LLM с открытым исходным кодом. Обученная на более чем 3,5 триллионах токенов, она обеспечивает первоклассную производительность по множеству тестов, что делает ее одной из самых конкурентоспособных доступных альтернатив с открытым исходным кодом. ( Вам потребуется примерно 8 видеокарт A100 с 80 ГБ памяти или эквивалентное оборудование для запуска этой модели )

Перспективы

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

Большинство экспертов считают, что будущее ИИ будет построено на основе открытого исходного кода, где общие знания ускоряют инновации и приводят к более равноправному технологическому прогрессу.

Я думаю, что это будущее только началось.

Новые и популярные проекты с открытым исходным кодом 🔥

• Second Me:** Прототип с открытым исходным кодом, где вы создаете своего собственного “ИИ-клона”: новый вид ИИ, который сохраняет вас, передает ваш контекст и защищает ваши интересы. GitHub

• Cursor Talk to Figma MCP:** Model Context Protocol (MCP), позволяющий Cursor взаимодействовать с Figma для чтения дизайнов и программного внесения изменений в них. GitHub

На что способен MCP в области дизайна Cursor Talk to Figma MCP см. видео

• Classless.css:** Легкий CSS-фреймворк для веб-сайтов с безупречным вкусом, но без желания добавлять классы. GitHub

Раунды финансирования проектов с открытым исходным кодом 💸

• Supabase, альтернатива Google Firebase с открытым исходным кодом, привлекла $100 млн при оценке стоимости в $2 млрд. Ссылка
• AheadComputing, игрок из экосистемы RISC-V, объявила о посевном финансировании в размере $21,5 млн. Ссылка
• Rerun, создатели платформы для ведения журналов и визуализации мультимодальных данных, привлекли посевное финансирование в размере $17 млн под руководством PointNine. Ссылка
• Onyx, решение для корпоративного поиска с открытым исходным кодом, привлекло посевное финансирование в размере $10 млн под совместным руководством Khosla Ventures и First Round Capital. Ссылка
• Lingo.dev, создатели инструментария для локализации с открытым исходным кодом, привлекли $4,2 млн. Ссылка

Очень интересные проекты:

• [https://github.com/onyx-dot-app/onyx](https://github.com/onyx-dot-app/onyx)** – Помогите своей инженерной команде, службе поддержки, отделу продаж и команде эксплуатации продукта быстрее находить информацию. Искусственный интеллект с открытым исходным кодом, подключенный к документам, приложениям и сотрудникам вашей компании.

• [https://github.com/rerun-io/rerun](https://github.com/rerun-io/rerun)** – Визуализируйте потоки мультимодальных данных. Бесплатно, быстро, просто в использовании и легко интегрируется. Написано на Rust.

• [https://github.com/lingodotdev/lingo.dev](https://github.com/lingodotdev/lingo.dev)** – Фиксируйте. Переводите. AI-локализация для команд, которые быстро выпускают продукты. Переводите приложения, веб-сайты и целые базы данных, используя лучшие LLM-модели.

• [https://github.com/sonnylazuardi/cursor-talk-to-figma-mcp](https://github.com/sonnylazuardi/cursor-talk-to-figma-mcp)** – Этот проект реализует интеграцию Model Context Protocol (MCP) между Cursor AI и Figma, позволяя Cursor взаимодействовать с Figma для чтения дизайнов и программного внесения изменений в них.

https://github.com/n8n-io/n8n

n8n – Платформа для безопасной автоматизации рабочих процессов для технических команд
n8n – это платформа автоматизации рабочих процессов, которая предоставляет техническим командам гибкость кода со скоростью no-code. Благодаря 400+ интеграциям, встроенным возможностям AI и лицензии fair-code, n8n позволяет создавать мощные автоматизации, сохраняя при этом полный контроль над вашими данными и развертываниями.
Платформа автоматизации рабочих процессов с моделью Fair-code и встроенными AI-возможностями. Объедините визуальное построение с пользовательским кодом, разместите у себя (self-host) или в облаке, 400+ интеграций.
Ключевые возможности

Код, когда это необходимо: Пишите на JavaScript/Python, добавляйте npm-пакеты или используйте визуальный интерфейс.

AI-Native платформа: Создавайте рабочие процессы AI-агентов на основе LangChain, используя собственные данные и модели.

Полный контроль: Размещайте у себя (self-host) с нашей лицензией fair-code или используйте наше облачное предложение.

Готовность к работе в enterprise-среде: Расширенные разрешения, SSO и развертывания с “воздушным зазором” (air-gapped deployments).

Активное сообщество: 400+ интеграций и 900+ готовых к использованию шаблонов.

Развертывание с помощью Docker:

docker volume create n8n_data
docker run -it rm name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Получите доступ к редактору по адресу http://localhost:5678

скоро добавят MCP https://habr.com/ru/articles/893482/

Перевод: https://medium.com/adevinta-tech-blog/from-lakehouse-architecture-to-data-mesh-c532c91f7b61

От архитектуры data lakehouse к data mesh

В Adevinta мы верим в то, что данные являются продуктом, который позволяет принимать обоснованные решения и внедрять инновации во все наши бизнес-подразделения. Чтобы извлечь максимальную пользу из наших данных, нам необходимо предоставить нашим командам инструменты и инфраструктуру для обнаружения, доступа и анализа данных автономно. Наш путь к этой цели начался с централизованной архитектуры data lakehouse, и теперь мы переходим к более децентрализованной парадигме data mesh. В этой статье мы поделимся нашей мотивацией, этапами и решениями на этом пути.

От централизованного к децентрализованному: почему мы это делаем?

В начале у нас была централизованная команда данных, которая отвечала за сбор, обработку и обслуживание всех данных в организации. Мы построили data lakehouse на основе облачных хранилищ, таких как AWS S3, и движков обработки, таких как Spark и Databricks. Эта централизованная архитектура хорошо работала в начале, когда наши потребности в данных были относительно простыми.

Однако по мере роста Adevinta и увеличения сложности наших бизнес-операций централизованная архитектура стала узким местом. Централизованной команде данных было сложно удовлетворить разнообразные и меняющиеся потребности различных бизнес-подразделений. Существовали следующие проблемы:

• Медленная доставка:** Требования к данным должны были проходить через централизованную команду, что порождало задержки и снижало скорость итераций.
• Ограниченное владение:** Бизнес-подразделения имели небольшой контроль над данными, которые им были необходимы, что препятствовало инновациям и экспериментированию.
• Отсутствие масштабируемости:** Централизованной команде данных было сложно масштабировать свои операции, чтобы соответствовать растущему объему и сложности данных.

Чтобы преодолеть эти проблемы, мы решили перейти к архитектуре data mesh. Data mesh – это децентрализованный подход к управлению данными, который наделяет конкретные бизнес-подразделения (domain) ответственностью за их собственные данные. Каждое business domain владеет своими данными, разрабатывает и обслуживает свои конвейеры данных, а также предоставляет свои данные другим domain в виде продуктов данных.

Путь к Data Mesh: этапы и решения

Наш переход к data mesh является постепенным процессом, который включает в себя несколько этапов.

Шаг 1: Выявление и приведение в соответствие Domains:

Первым шагом было выявление основных domains в Adevinta, например, маркетинг, финансы, поиск и монетизация. Важно соответствие domains организационной структуре и то, что каждая domain имеет четкого владельца и понимание данных, за которые они несут ответственность.

Шаг 2: Объявление Domain Data Owners:

После определения domains нам нужно было назначить владельцев данных для каждой domain. Domain data owners являются владельцами данных, генерируемых их domain, и отвечают за качество, доступность и управляемость данных.

Шаг 3: Определение продукта данных:

Затем каждая domain должна определить свои продукты данных. Продукты данных – это переиспользуемые компоненты данных, предоставляющие ценность различным командам. Примеры продуктов данных включают агрегации данных, машинное обучение и отчетность.

Шаг 4: Создание самостоятельной платформы данных:

Чтобы дать возможность domains управлять своими данными, нам нужно было создать самостоятельную платформу данных. Платформа предоставляет инфраструктуру и инструменты, необходимые domains для создания, развертывания и обслуживания своих конвейеров данных. Платформа должна быть самообслуживаемой, надежной и безопасной.

В Adevinta мы опираемся на существующую инфраструктуру data lakehouse и развиваем ее для поддержки data mesh. Это включает в себя:

• Централизованный каталог данных:** Каталог данных предоставляет всем domains доступ к метаданным и схемам данных, позволяя им обнаруживать и понимать продукты данных, доступные в организации.
• Стандарты качества данных:** Централизованная команда данных поддерживает стандарты качества данных и политики, чтобы обеспечить высокое качество данных. Команды доменов несут ответственность за соблюдение этих стандартов и политик.
• Аутентификация, авторизация и аудит (AAA):** Централизованная AAA защищает доступ к данным и соответствие требованиям безопасности.
• Мониторинг и оповещения:** Платформа предоставляет централизованные панели мониторинга и оповещения, позволяющие domains проактивно отслеживать состояние и производительность своих конвейеров данных.

Шаг 5: Обучение, пропаганда и повторение:

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

Решения, которые нам необходимо было принять:

Переход к парадигме data mesh требует принятия ряда важных решений. Некоторые из наиболее серьезных из них включают в себя:

• Определение границ domain:** Критически важно определить границы каждого domain четким и однозначным образом. Это гарантирует, что каждая domain четко понимает данные, за которые она несет ответственность.
• Выбор технологии:** необходимо тщательно выбирать правильную технологию для data mesh. Платформа должна быть самообслуживаемой, надежной и безопасной.
• Управление изменениями:** Переход к data mesh требует значительных изменений в том, как организация относится к управлению данными. Важно справиться с этими изменениями эффективным образом.

Преимущества Data Mesh

Реализовав архитектуру data mesh, мы ожидаем получить следующие преимущества:

• Улучшенная скорость доставки:** domains могут самостоятельно разрабатывать и развертывать свои конвейеры данных, сокращая время, необходимое для предоставления новых продуктов данных.
• Повышенное владение:** domains имеют полный контроль над своими данными, что позволяет им внедрять инновации и экспериментировать с использованием данных.
• Улучшенная масштабируемость:** архитектура data mesh более масштабируема, чем централизованная архитектура, позволяя нам адаптироваться к растущему объему и сложности данных.
• Повышение качества данных:** domains лучше осведомлены о своих данных, что ведет к более высокому качеству данных.

Вывод

Переход от архитектуры data lakehouse к data mesh – это значительное изменение для Adevinta. Однако мы полагаем, что это необходимо для того, чтобы раскрыть весь потенциал наших данных. Наделив наши бизнес-domains ответственностью за их собственные данные, мы сможем ускорить инновации, принимать более обоснованные решения и, в конечном счете, лучше обслуживать наших клиентов. Этот путь является непрерывным процессом, и мы полны решимости сделать data mesh успешным в Adevinta.

Статья переведена с помощью gtp4o search preview – без доступа через VPN

Зачем бизнесу LLM: стратегический взгляд

Выбор локальной LLM модели. Публикация на сайт с чатом

MCP (Model Context Protocol)

От растущей специализации до развития рынков инфраструктуры — вот где скрываются возможности в быстро развивающейся сфере AI-агентов.

Оригинал: https://www.cbinsights.com/research/ai-agent-trends-to-watch-2025/

AI-агенты доминируют в обсуждениях. Упоминания о них на конференц-звонках компаний, посвященных прибыли, выросли в 4 раза по сравнению с предыдущим кварталом в 4 квартале 2024 года. И они, похоже, удвоятся снова в этом квартале.

Эти системы, основанные на больших языковых моделях (LLM), знаменуют собой эволюцию по сравнению с просто “копилотами”: AI-агенты могут выполнять сложные задачи от имени пользователя с минимальным вмешательством, начиная от поиска потенциальных клиентов и заканчивая принятием решений о соответствии требованиям.
На быстрорастущем рынке инфраструктуры и приложений для агентов более половины компаний были основаны после 2023 года. Тем временем финансирование стартапов в этой сфере увеличилось почти в 3 раза в 2024 году.
Ниже мы представляем 4 тренда в области AI-агентов, за которыми стоит следить в 2025 году, основываясь на данных CB Insights:

Крупные технологические компании и ведущие разработчики LLM доминируют в сценариях использования AI-агентов общего назначения: Разработки в области AI от технологических гигантов сделают агентов лучше, дешевле и более распространенными в 2025 году, оказывая при этом большее давление на частных игроков. Благодаря огромным каналам распространения (например, у OpenAI 400 миллионов еженедельных активных пользователей) и тому, что многие предприятия предпочитают проверенных поставщиков из-за меньшего риска, крупные технологические компании имеют значительные преимущества в приложениях для AI-агентов общего назначения.

На рынке частных AI-агентов наблюдается тенденция к большей специализации: Во все более переполненной горизонтальной сфере AI-агентов — на которую приходится половина всех сделок с акционерным капиталом с 2020 года — успешные компании выделяются в таких областях, как поддержка клиентов и разработка кода, за счет более глубокой интеграции рабочих процессов и данных о клиентах. На горизонте появляются отраслевые решения, которые готовы к более широкому внедрению, согласно оценкам CB Insights Commercial Maturity.

Инфраструктурный стек AI-агентов кристаллизуется: Фрагментированная среда становится более структурированной, появляются специализированные решения для различных аспектов разработки агентов. Ключевые категории включают курирование данных, веб-поиск и использование инструментов, оценки и возможность наблюдения, а также полнофункциональные платформы разработки AI-агентов — крупнейшая категория инфраструктуры, которую мы отслеживаем, основываясь на активности компаний.

Предприятия переходят от экспериментов к внедрению: Организации активно изучают возможности внедрения AI-агентов, и 63% опрошенных CB Insights придают им большое значение в ближайшие 12 месяцев. Однако остаются ключевые проблемы, связанные с надежностью и безопасностью, внедрением и наличием квалифицированных кадров. Контроль со стороны человека и надежное управление инфраструктурой данных могут помочь решить эти проблемы.

Автор: Yiren Lu @YirenLu
Оригинал: https://modal.com/blog/vllm-vs-tgi-article

Зачем использовать фреймворк для инференса?

Почему разработчики не могут просто использовать библиотеку вроде Transformers для обслуживания своих моделей?

Хотя библиотеки, такие как Transformers, отлично подходят для обучения и базового инференса, у них есть ограничения, когда дело доходит до масштабного развертывания и обслуживания LLM:

• Эффективность использования памяти:** LLM требуют значительных ресурсов памяти. Универсальные библиотеки могут не оптимизировать использование памяти, что приводит к неэффективному распределению ресурсов. Для получения дополнительной информации о требованиях VRAM для обслуживания LLM, прочитайте здесь.
• Скорость инференса:** Стандартным библиотекам часто не хватает оптимизаций, специфичных для инференса, что приводит к замедлению времени обработки больших моделей.
• Пакетная обработка и очереди:** Эффективная обработка нескольких запросов требует сложных механизмов пакетной обработки и очередей, которые обычно не включаются в библиотеки, ориентированные на обучение.
• Масштабируемость:** Обслуживание LLM в масштабе требует тщательного управления вычислительными ресурсами, что выходит за рамки большинства универсальных библиотек.

Вместо этого, для большинства случаев обслуживания моделей в production, чтобы максимизировать пропускную способность и минимизировать задержку, вам следует использовать inference server. Двумя наиболее популярными inference serverами для случаев использования LLM являются vLLM и TGI.

Что такое vLLM и TGI?

vLLM

vLLM — это библиотека с открытым исходным кодом, разработанная для быстрого инференса и обслуживания LLM. Разработанная исследователями из Калифорнийского университета в Беркли, она использует PagedAttention, новый алгоритм внимания, который эффективно управляет ключами и значениями внимания. vLLM обеспечивает до 24 раз более высокую пропускную способность, чем Hugging Face Transformers, без каких-либо изменений в архитектуре модели.

Ключевые особенности vLLM включают в себя:

• Эффективное управление памятью
• Непрерывная пакетная обработка
• Оптимизированные реализации ядра
• Поддержка различных архитектур моделей

TGI (Text Generation Inference)

TGI, сокращение от Text Generation Inference (Инференс для генерации текста), — это инструментарий для развертывания и обслуживания больших языковых моделей (LLM). Разработанный компанией Hugging Face, TGI обеспечивает высокопроизводительную генерацию текста для самых популярных LLM с открытым исходным кодом, включая Llama, Falcon, StarCoder, BLOOM, GPT-NeoX и другие. Он ориентирован на предоставление готового к production решения для развертывания и обслуживания больших языковых моделей с особым упором на задачи генерации текста.

Сравнение производительности: Что быстрее?

Когда дело доходит до производительности, vLLM и TGI предлагают значительные улучшения по сравнению с базовыми реализациями. Однако определить, что быстрее, не так просто, поскольку производительность может варьироваться в зависимости от конкретного случая использования, архитектуры модели и конфигурации оборудования.

• Пропускная способность:** vLLM часто демонстрирует более высокую пропускную способность, особенно для больших размеров пакетов, благодаря механизму PagedAttention и оптимизации непрерывной пакетной обработки.
• Эффективность использования памяти:** Метод PagedAttention в vLLM позволяет более эффективно использовать память, потенциально обеспечивая более высокую параллельность на одном и том же оборудовании.
• Простота использования:** Поскольку TGI создан Hugging Face, обслуживание любой модели Hugging Face (включая частные/gate-модели) с помощью TGI относительно просто. Стандартный способ запуска TGI, через официальный Docker-контейнер, также поднимает API endpoint.
• Готовность к производству (Production-readiness):** TGI предлагает встроенную телеметрию через OpenTelemetry и метрики Prometheus. У vLLM меньше “готовых к производству” наворотов.

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

Синтез “The Big Book of MLOps – 2nd Edition”:

2023-10-eb-big-book-of-mlops-2nd-edition-v2-final.pdf

1. Основы MLOps
   MLOps объединяет DataOps, DevOps и ModelOps для управления жизненным циклом ML-моделей. Ключевые принципы:
• Разделение сред (разработка, тестирование, продакшн).
• Автоматизация CI/CD для ускорения вывода моделей в продакшн.
• Управление данными, кодом и моделями через единую платформу (Databricks Lakehouse).

2. Ключевые обновления в версии 2
   • Unity Catalog: Централизованное управление данными и моделями с трекингом происхождения, безопасностью и доступом.
   • Model Serving: Серверное решение для развертывания моделей в реальном времени с интеграцией MLflow и автоскейлингом.
   • Lakehouse Monitoring: Мониторинг данных и моделей с автоматической записью метрик в Delta-таблицы.

3. Рекомендации по проектированию
   • Организация данных и моделей в Unity Catalog через каталоги (`dev`, `staging`, `prod`), схемы (`bronze`, `silver`, `gold`) и алиасы моделей (например, “Champion” и “Challenger”).
   • Тестирование инфраструктуры перед деплоем (нагрузочное тестирование, проверки задержки).

4. Эталонная архитектура
   • Разработка: EDA, обучение моделей, валидация.
   • Тестирование: Интеграционные тесты в staging-среде.
   • Продакшн: Автоматизированные пайплайны обучения, валидации, деплоя и мониторинга.

5. LLMOps
   • Prompt Engineering: Оптимизация текстовых запросов для улучшения ответов LLM.
   • RAG (Retrieval-Augmented Generation): Комбинация LLM с векторными базами данных для доступа к актуальным данным.
   • Тонкая настройка (Fine-tuning): Адаптация LLM под специфические задачи с использованием параметрически эффективных методов (LoRA).
   • Оценка и мониторинг: Использование LLM как оценщиков, интеграция человеческой обратной связи.
   • Управление затратами: Оптимизация размера моделей, квантование, распределенные вычисления.

6. Заключение
   MLOps и LLMOps требуют модульности, автоматизации и ориентации на данные. Databricks предоставляет единую платформу для управления данными, моделями и мониторингом, что ускоряет внедрение AI-решений.

---

Обработано страниц: 78 (с 1 по 78, включая оглавление, главы и иллюстрации). DeepSeek

Будущие компоненты и архитектура MLOps на основе документа

Архитектура строится на принципах data-centric AI, автоматизации и унифицированного управления данными, моделями и кодом.
Ниже представлены ключевые компоненты и их взаимодействие:

---

1. Управление данными и моделями (Data & Model Governance)

• Unity Catalog:
  • Централизованный каталог для данных, моделей, функций и объемов.
  • Структура:
    • Каталоги по средам (`dev`, `staging`, `prod`).
    • Схемы: `bronze` (сырые данные), `silver` (очищенные), `gold` (обогащенные), `use_case` (фичи/модели).
  • Функции:
    • Трекинг происхождения (lineage) между данными и моделями.
    • Управление доступом (RBAC) и версионирование моделей через MLflow.
    • Алиасы моделей (например, `Champion` для продакшна).

---

2. Разработка и обучение моделей (Model Development)

• Среда разработки:
  • Интерактивные notebooks (EDA, прототипирование).
  • AutoML для генерации базовых моделей и анализа данных.
  • Интеграция с MLflow Tracking для записи экспериментов.
• Обучение моделей:
  • Пайплайны обучения с использованием Databricks Workflows.
  • Параметризация гиперпараметров и данных (из `gold` или `prod` каталогов).
  • Логирование артефактов, метрик и зависимостей в MLflow.

---

3. Тестирование и CI/CD (Continuous Integration/Deployment)

• Среда тестирования (staging):
  • Интеграционные тесты (проверка совместимости компонентов).
  • Нагрузочное тестирование Model Serving:
    • Проверка задержки (latency), пропускной способности (QPS).
  • Тестирование инфраструктуры (например, обновление алиасов моделей).
• CI/CD:
  • Автоматизация через Git (ветки `dev` → `main` → `release`).
  • Unit-тесты на CI-раннерах, интеграционные тесты в staging.
  • Развертывание через Databricks Asset Bundles.

---

4. Продакшн-развертывание (Model Deployment)

• Batch/Streaming Inference:
  • Пакетная обработка через Spark, публикация в Delta-таблицы или key-value хранилища.
• Real-time Inference:
  • Model Serving:
    • REST API для онлайн-предсказаний.
    • Поддержка A/B-тестов, канареечных развертываний и shadow-режима.
    • Автоматическое логирование запросов/ответов в `inference tables`.
  • Обновление моделей:
    • Сравнение `Champion` (текущая) vs. `Challenger` (новая) моделей.
    • Алгоритмы постепенного переноса трафика (gradual rollout).

  ---

  5. Мониторинг и управление (Monitoring & Maintenance)

  • Lakehouse Monitoring:
    • Автоматический сбор метрик (дрейф данных, точность моделей).
    • Интеграция с Databricks SQL для дашбордов и алертов.
  • Ретрейнинг:
    • Триггеры на основе мониторинга (например, дрейф данных).
    • Периодическое обновление моделей по расписанию.
  • Управление затратами:
    • Оптимизация ресурсов (автоскейлинг Model Serving).
    • Квантование моделей, использование PEFT для LLM.

  ---

  6. LLMOps (специфика для больших языковых моделей)

  • Компоненты:
    • Векторные базы данных (Chroma, Milvus) для RAG.
    • Prompt Engineering:
      • Шаблоны запросов, версионирование через MLflow.
      • Интеграция с LangChain для сложных цепочек.
    • Fine-tuning:
      • Использование PEFT (LoRA) для эффективной настройки.
      • Инструменты: Hugging Face Transformers, MosaicML.
    • Оценка LLM:
      • Автоматическая оценка через LLM-судьи (например, GPT-4).
      • Сбор человеческой обратной связи через UI.
    • Архитектурные изменения:
      • Модель Serving с поддержкой GPU для самохостатых LLM.
      • Интеграция с MLflow AI Gateway для управления сторонними API (OpenAI, Anthropic).

    ---

    Ключевые инновации будущего

    1. Полная автоматизация жизненного цикла с AI-driven триггерами (например, авторетрайнинг при дрейфе).
    2. Гибридные пайплайны для совместной работы классических ML и LLM.
    3. Унифицированная аналитика данных и моделей через Lakehouse.
    4. Безопасность и compliance:
       • Шифрование данных/моделей.
       • Аудит через Unity Catalog.

    ---

    Архитектура обеспечивает масштабируемость, воспроизводимость и управляемость ML-решений, адаптируясь как к классическим задачам, так и к вызовам Generative AI. DeepSeek

Анализ “Future of Jobs Report 2025”

Ключевые тренды: https://reports.weforum.org/docs/WEF_Future_of_Jobs_Report_2025.pdf

Технологические изменения (особенно ИИ, робототехника, цифровизация) станут основным драйвером трансформации.

• 86% работодателей ожидают, что ИИ изменит их бизнес к 2030 году.
• Автоматизация заменит 8% рабочих мест (92 млн), но создаст 14% новых (170 млн), с чистым ростом 7% (78 млн).

Зеленая трансформация:

• Создание рабочих мест в сфере возобновляемой энергетики, экологии и электромобильности (инженеры по ВИЭ, экологи).
• 47% компаний видят климатические инициативы как ключевой фактор изменений.

Демографические сдвиги:

• Старение населения в развитых странах vs. рост трудоспособного населения в развивающихся.
• Увеличение спроса на профессии в здравоохранении, образовании и уходе.

Геополитическая фрагментация и экономическая неопределенность:

• Торговые ограничения и локализация цепочек поставок.
• Рост спроса на специалистов по кибербезопасности и логистике.

Изменения в структуре рабочих мест:

Рост:

• Технологические роли (специалисты по большим данным, ИИ, кибербезопасности).
• Зеленые профессии (инженеры ВИЭ, экологи).
• Здравоохранение и образование (медсестры, учителя).

Сокращение:

• Административные и канцелярские должности (секретари, бухгалтеры, кассиры).

Навыки будущего:

Топ-5 навыков к 2030 году:

• Аналитическое мышление.
• Устойчивость и гибкость.
• Лидерство и социальное влияние.
• Креативное мышление.
• Технологическая грамотность (ИИ, big data, кибербезопасность).

Снижение спроса: ручной труд, чтение/письмо, глобальная гражданственность.

Стратегии адаптации:

Обучение: 59% работников потребуется переподготовка к 2030 году.
Автоматизация: 73% компаний ускорят внедрение технологий.
Инклюзивность: 83% работодателей внедрят программы diversity & inclusion.
Гибкость: поддержка здоровья сотрудников, удаленная работа, гибридные модели.
Региональные особенности:

Азия: Акцент на цифровизацию и геополитические риски (Сингапур, Южная Корея).
Европа: Старение населения, зеленая трансформация, регулирование.
США: Лидерство в ИИ, но сокращение низкоквалифицированных ролей.
Африка и Ближний Восток: Демографический дивиденд, но нехватка инфраструктуры.

Обработано страниц: 85 (полный документ). DeepSeek.

Оригинал: https://www.ixbt.com/news/2025/03/18/iipomoshnik-grok-vzbuntovalsja-otkazalsja-pisat-kod-i-otpravil-polzovatelja-uchit-python.html

Искусственный интеллект, созданный для помощи в программировании, неожиданно отказался выполнять задачу и вместо этого предложил пользователю освоить кодирование самостоятельно. Этот случай произошёл с Grok — ИИ-помощником, разработанным компанией xAI.

Для желающих поиграть с deepseek

Жирная конечно моделька. Оригинал тут: https://dev.to/askyt/deepseek-r1-70b-hardware-requirements-1kd0

Как установить DeepSeek-R1 70B локально на Windows

0. Берем две ипотеки, страхуем жизни, умираем, родственник получает страховку, покупает 16 карт a100 и следует инструкции далее:

1. Установка Подсистемы Windows для Linux (WSL):

• Убедитесь, что WSL включена в вашей системе Windows.
• Установите дистрибутив Linux из Microsoft Store (например, Ubuntu).

2. Настройка окружения:

• Откройте терминал WSL.
• Обновите списки пакетов:

sudo apt-get update

• Установите необходимые зависимости:

sudo apt-get install -y git-lfs python3-pip

3. Клонирование репозитория DeepSeek-R1:

• Установите Git Large File Storage (Git LFS):

git lfs install

• Клонируйте репозиторий:

git clone https://huggingface.co/deepseek-ai/DeepSeek-R1
    cd DeepSeek-R1

4. Настройка виртуального окружения Python:

• Установите virtualenv:

pip3 install virtualenv

• Создайте и активируйте виртуальное окружение:

virtualenv venv
    source venv/bin/activate

5. Установка зависимостей Python:

• Внутри виртуального окружения установите необходимые пакеты:

pip install -r requirements.txt

6. Настройка поддержки GPU:

• Убедитесь, что драйверы вашей GPU обновлены в Windows.
• Установите CUDA и cuDNN, совместимые с вашей GPU.
• Убедитесь, что GPU доступна в WSL.

7. Запуск модели:

• Выполните скрипт вывода модели:

python run_inference.py --model_path ./DeepSeek-R1

Оригинал: https://apxml.com/posts/gpu-requirements-deepseek-r1

DeepSeek-R1 и связанные с ним модели представляют собой новый эталон в машинном мышлении и производительности искусственного интеллекта в больших масштабах. Эти модели, особенно DeepSeek-R1-Zero и DeepSeek-R1, установили новые стандарты в рассуждениях и решении задач. Благодаря открытому доступу к этим передовым инструментам разработчики и исследователи могут использовать их мощь, только если их оборудование соответствует требованиям.

Это руководство предоставляет подробный анализ GPU-ресурсов, необходимых для эффективной работы DeepSeek-R1 и его различных вариаций.

Обзор DeepSeek-R1

DeepSeek-R1-Zero был обучен с использованием масштабного обучения с подкреплением (RL) без контролируемой тонкой настройки, демонстрируя исключительную производительность в рассуждениях. Будучи мощным, он сталкивался с проблемами, такими как повторы и читаемость. DeepSeek-R1 решил эти проблемы, включив данные “холодного старта” перед RL, улучшив производительность в задачах математики, кодирования и рассуждений.

И DeepSeek-R1-Zero, и DeepSeek-R1 демонстрируют передовые возможности, но требуют значительного аппаратного обеспечения. Квантование и распределенные GPU-конфигурации позволяют им обрабатывать огромное количество параметров.

Требования к VRAM для DeepSeek-R1

Размер модели, количество ее параметров и методы квантования напрямую влияют на требования к VRAM. Вот подробная разбивка потребностей в VRAM для DeepSeek-R1 и его дистиллированных моделей, а также рекомендуемые GPU:

Полная модель

Квантованные модели

Ниже приведена разбивка требований к VRAM для 4-битного квантования моделей DeepSeek-R1:

Примечания по использованию VRAM

• Для больших моделей требуется распределенная GPU-конфигурация:** DeepSeek-R1-Zero и DeepSeek-R1 требуют значительного объема VRAM, что делает обязательным использование распределенных GPU-конфигураций (например, NVIDIA A100 или H100 в конфигурациях с несколькими GPU) для эффективной работы.
• GPU с более низкими спецификациями:** Модели все еще могут работать на GPU с более низкими спецификациями, чем указано выше, при условии, что GPU соответствует или превышает требования к VRAM. Однако такая конфигурация не будет оптимальной и, вероятно, потребует некоторой настройки, такой как регулировка размеров пакетов и настроек обработки.

Когда выбирать дистиллированные модели

Для разработчиков и исследователей, не имеющих доступа к высокопроизводительным GPU, отличной альтернативой являются дистиллированные модели DeepSeek-R1-Distill. Эти дистиллированные версии DeepSeek-R1 разработаны для сохранения значительных возможностей рассуждения и решения задач, при этом уменьшая размеры параметров и вычислительные требования.

Преимущества дистиллированных моделей

• Сниженные аппаратные требования:** Благодаря требованиям к VRAM, начиная с 3.5 ГБ, дистиллированные модели, такие как DeepSeek-R1-Distill-Qwen-1.5B, могут работать на более доступных GPU.
• Эффективные, но мощные:** Дистиллированные модели сохраняют надежные возможности рассуждения, несмотря на меньший размер, часто превосходя модели аналогичного размера из других архитектур.
• Экономичное развертывание:** Дистиллированные модели позволяют экспериментировать и развертывать на менее мощном оборудовании, экономя затраты на дорогие много-GPU системы.

Рекомендации

• Для High-End GPU:**
  Если у вас есть доступ к распределенным много-GPU конфигурациям со значительным объемом VRAM (например, NVIDIA A100 80GB x16), вы можете запускать полномасштабные модели DeepSeek-R1 для достижения наивысшей производительности.

• Для смешанных рабочих нагрузок:**
  Рассмотрите возможность использования дистиллированных моделей для начальных экспериментов и приложений меньшего масштаба, оставляя полномасштабные модели DeepSeek-R1 для производственных задач или когда критична высокая точность.

• Для ограниченных ресурсов:**
  Используйте дистиллированные модели, такие как 14B или 32B (4-битные). Эти модели оптимизированы для конфигураций с одним GPU и могут обеспечить приличную производительность по сравнению с полной моделью при гораздо меньших требованиях к ресурсам.

• Для очень ограниченных ресурсов:**
  Используйте 7B, если они хорошо справляются с вашей задачей. Они могут работать быстро, но их ответы часто оказываются некачественными или неверными. Однако это может зависеть от вашего сценария использования, поскольку они могут хорошо работать для конкретных задач классификации.

Заключение

DeepSeek-R1 представляет собой значительный скачок вперед в производительности моделей ИИ, предназначенных для рассуждений, но эта мощь предъявляет и высокие требования к аппаратным ресурсам. Распределенные GPU-системы необходимы для запуска таких моделей, как DeepSeek-R1-Zero, в то время как дистиллированные модели предлагают доступную и эффективную альтернативу для тех, у кого ограничены вычислительные ресурсы.

Понимая и согласуя свою GPU-конфигурацию с требованиями модели, вы сможете полностью использовать потенциал DeepSeek-R1 для исследований, продвинутых рассуждений или задач решения проблем.

Эхх 😩

и зерно

но