DataHub 1.0 уже здесь! Получите максимальную отдачу от нового UX

00:00:00 Введение и анонсы

• Приветствие участников и анонс гостей.
• Мэгги расскажет об обновлении дорожной карты DataHub.
• Паулина и Анна представят новый UX DataHub 10.
• Харшел из команды DataHub поделится новостями от Block.
• Шершанка, технический директор и соучредитель, подведет итоги.

00:01:01 Анонс DataHub 10

• Анонс DataHub 10 и ссылки на блог и видеоролики.
• Видео о начале проекта DataHub.

00:02:33 Важность DataHub

• DataHub как важный компонент инфраструктуры.
• Переход на DataHub и отключение собственного инструмента lineage.
• Расширение модели DataHub для поддержки элементов данных.

00:04:11 Обновления дорожной карты DataHub

• Мэгги рассказывает о последних обновлениях DataHub.
• Четыре столпа: открытие, управление, метаданные и наблюдаемость.
• Фокус на открытии данных и интеграции с новыми инструментами.

00:05:09 Открытие данных

• Фокус на человеко-ориентированном понимании данных.
• Интеграция с новыми инструментами, такими как MLflow и Cockroach DB.
• Разработка новых интеграций, включая Hex и Vertex AI.

00:07:32 Управление данными

• Введение иерархической родословной для упрощения графиков.
• Расширение поддержки терминов в глоссарии.
• Обеспечение всеобщего доступа к данным и централизованного соответствия требованиям.

00:10:52 Наблюдаемость данных

• Обеспечение доступности и демократизация качества данных.
• Централизованное отслеживание и разрешение инцидентов.
• Улучшения в утверждениях и расширенный поток инцидентов.

00:12:53 Основные направления проекта

• Фокус на API и SDK для автоматизации регистрации, обогащения и поиска данных.
• Важность качества обслуживания и аудита ведения журнала.
• Улучшение отслеживаемости событий в центре обработки данных.

00:13:40 Пакет SDK для Python

• Работа над улучшением пакета SDK для Python версии 2.
• API для регистрации, обогащения и извлечения данных.
• Вклад в документацию для улучшения понимания улучшений.

00:14:42 Учетные записи служб

• Внедрение учетных записей служб для команд.
• Управление автоматизацией и рабочими процессами.
• Призыв к обратной связи и сотрудничеству.

00:15:41 Будущие обновления и DataHub Cloud

• Опрос о будущих обновлениях DataHub и DataHub Cloud.
• DataHub Cloud как управляемый сервис с дополнительными возможностями.
• Переход к повестке дня и представлению UX-дизайнеров.

00:16:47 Дизайн продуктов в DataHub

• Инвестиции в дизайн продуктов в DataHub.
• Важность дизайна для инноваций и постоянного совершенствования.
• Использование данных и отзывов пользователей для улучшения продукта.

00:18:44 Принципы дизайна

• Философия дизайна: простота, обратная связь, последовательность.
• Создание системы проектирования в Figma и Storybook.
• Внедрение токенов и принципов для компонентов.

00:19:43 Примеры изменений

• Изменения в цветах и стилях кнопок и диаграмм.
• Введение специальных дизайнерских жетонов.
• Постепенные обновления пользовательского интерфейса.

00:20:54 Панель навигации и структурированные свойства

• Улучшение панели навигации для удобства пользователей.
• Гибкость отображения структурированных свойств.
• Постоянное совершенствование продукта на основе отзывов пользователей.

00:23:37 Введение и принципы последовательности

• Обсуждение предварительных просмотров вкладки “Стоп”.
• Введение в принципы согласованности и последовательности.
• Создание графической библиотеки для визуализации данных.

00:24:02 Итеративность и визуализация данных

• Итеративный процесс создания графических элементов.
• Примеры различных диаграмм и их эволюция.
• Переход от высокой плотности данных к более сжатым диаграммам.

00:25:46 Новые функции и панель вкладок

• Введение новой панели вкладок “Статистика”.
• Улучшение представления данных для пользователей.
• Демонстрация новых функций и взаимодействий.

00:28:27 Взаимодействие с пользователями

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

00:31:19 Обнаружение данных с агентами ИИ

• Введение в тему обнаружения данных с агентами ИИ.
• Представление Сэма Осборна и его роли в компании Block.
• Обзор управления данными и блокчейна в компании.

00:32:39 Проблемы и перспективы управления данными

• Переход на облачный сервис Data Hub.
• Проблемы и возможности каталогизации данных.
• Введение агентов ИИ для улучшения управления данными.

00:34:33 Демонстрация работы с Cloud Desktop

• Cloud Desktop настроен для взаимодействия с LLM.
• Возможность задавать вопросы о данных, связанных с домашними животными.
• Программа ищет данные на сервере Data Hub и предоставляет резюме.

00:35:23 Анализ данных и ключевые показатели

• Программа ищет данные и предоставляет информацию о ключевых показателях.
• Возможность задавать дополнительные вопросы о профилях домашних животных.
• Программа показывает количество строк и активные инциденты.

00:37:05 Использование Slack и Data Hub

• Возможность использовать Slack для планирования изменений в Data Hub.
• Программа помогает определить, на какие данные повлияет изменение.
• Возможность узнать, кому нужно сообщить об изменениях.

00:38:38 Демонстрация работы с Goose

• Goose – агент искусственного интеллекта с открытым исходным кодом.
• Интеграция с локальной и удаленной системами через расширения.
• Пример использования для поиска данных и владельцев данных.

00:43:39 Демонстрация работы в среде IDE

• Проект DBT с использованием идентификатора на базе искусственного интеллекта.
• Возможность проверять изменения в Data Hub и их влияние.
• Программа помогает избежать проблем и обеспечивает безопасность.

00:45:59 Введение в агентов искусственного интеллекта

• Агенты организуют контекстное управление разговорами с LLM.
• Интеграция с системами через протокол MCP.
• Агенты взаимодействуют с LLM и внешними службами данных.

00:47:50 Модель контекстного протокола MCP

• MCP – открытый стандарт для использования данных и инструментов в контексте взаимодействия с ИИ.
• Охватывает аспекты запроса данных, вызова служб и чтения/записи информации.
• Может использоваться для конкретных случаев использования и внешних серверов.

00:48:41 Агенты и спецификация MCP

• Представлен агент искусственного интеллекта с открытым исходным кодом codename goose.
• Спецификация MCP выпущена компанией Anthropic и является стандартным протоколом для ИИ.
• Обсуждается сотрудничество с ACRIL и улучшения Python SDK для приложений ИИ.

00:49:45 Демонстрация и использование codename goose

• Codename goose поддерживает стандарт MCP и позволяет подключаться к различным моделям и поставщикам.
• Демонстрационное видео показывает, как codename goose помогает в выполнении различных задач и упрощении рабочих процессов.

00:50:12 Интеграция и улучшения

• Агенты, стандарты MCP и центр обработки данных помогают быстрее подключать пользователей и интегрироваться с внутренними службами.
• Обсуждаются улучшения Python SDK для поиска сущностей и lineage, оптимизированных для интеграции с ИИ.

00:51:16 Будущее MCP

• В спецификацию MCP добавлены элементы авторизации с помощью OAuth и элементы для выборки и потоковой передачи.
• Ожидается появление множества официальных и неофициальных серверов MCP для различных приложений и сервисов.

00:51:50 Философия Data Hub

• Спецификация MCP вписывается в философию Data Hub, подчеркивающую важность стандартов и переносимости.
• Внедряются стандарты Open Lineage, Iceberg REST Catalog и MCP Model для более эффективного взаимодействия с метаданными.

00:53:02 Рекомендации и советы

• Видео на YouTube и ресурсы на GitHub подробно рассказывают о стандарте MCP.
• Профессиональный совет: делайте сеансы короткими, обобщайте данные и записывайте их в текст для предотвращения разрыва контекстного окна.

00:53:57 Заключение

• Агенты искусственного интеллекта и центр обработки данных помогают в обнаружении данных.
• Проект codename goose и его интеграция с Data Hub являются важными шагами в развитии ИИ.

00:54:38 Введение и прогресс проекта

• Проект быстро развивается, появляются интересные функции.
• Все продемонстрированные элементы, кроме Slack, имеют открытый исходный код.
• Пользовательский интерфейс улучшается, версии 1 и 2 уже доступны.

00:55:50 Проблемы и решения центра обработки данных

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

00:56:32 Важность контекста для различных ролей

• Потребители данных ищут доверие и доступность данных.
• Специалисты по обработке данных беспокоятся о своевременности и изменениях.
• Руководители команд следят за доступом и использованием данных.

00:57:25 Управление искусственным интеллектом

• Важно отслеживать данные, используемые моделями искусственного интеллекта.
• Управление искусственным интеллектом должно быть машинно-ориентированным.
• Понимание доступа моделей к персональным данным и автономных агентов.

00:59:16 Переход к машинно-ориентированному управлению

• Агенты будут действовать автономно, преобразовывать и создавать данные.
• Важно отслеживать действия агентов и гарантировать их правильность.
• Центр обработки данных помогает создавать контекст для машин и агентов.

01:00:53 Заключение и благодарности

• Благодарность участникам за участие и вопросы.
• Обещание предоставить запись и более подробную информацию.
• Призыв обращаться через Slack для дальнейших вопросов и обсуждений.

Казалось не очевидная задача, но победа случилась на второй день.

querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:47] "GET /ds/user/me/ HTTP/1.1" 401 285 0.000000
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:47] "GET /ds/user/login_method/ HTTP/1.1" 200 273 0.000000
querybook_web            | [2025-03-27 Thu 20:36:56] - /opt/querybook/querybook/server/app/auth/ldap_auth.py - DEBUG   "LDAP bind TRY with username: 'uid=jduke,ou=Users,dc=ldap,dc=example'"
querybook_web            | [2025-03-27 Thu 20:36:56] - /opt/querybook/querybook/server/app/auth/ldap_auth.py - DEBUG   "LDAP bind SUCCESS with username: 'uid=jduke,ou=Users,dc=ldap,dc=example'"
querybook_worker         | [2025-03-27 20:36:56,786: INFO/MainProcess] Task celery.local.sync_elasticsearch__debouncer[f407a87d-ae47-450b-95b1-c44df07eb1e7] received
querybook_worker         | [2025-03-27 20:36:56,787: DEBUG/MainProcess] TaskPool: Apply <function fast_trace_task at 0x7fb3791b0d30> (args:('celery.local.sync_elasticsearch__debouncer', 'f407a87d-ae47-450b-95b1-c44df07eb1e7', {'lang': 'py', 'task': 'celery.local.sync_elasticsearch__debouncer', 'id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'shadow': None, 'eta': None, 'expires': None, 'group': None, 'group_index': None, 'retries': 0, 'timelimit': [None, None], 'root_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'parent_id': None, 'argsrepr': "['users', 1]", 'kwargsrepr': '{}', 'origin': 'gen100@6ede59afb0cf', 'ignore_result': False, 'properties': {'correlation_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'reply_to': '70ed7e91-4699-31e4-8f50-86d1a850d89a', 'delivery_mode': 2, 'delivery_info': {'exchange': '', 'routing_key': 'celery'}, 'priority': 0, 'body_encoding': 'base64', 'delivery_tag': '2d6aecef-9aea-4564-9bd0-994731c8eba5'}, 'reply_to': '70ed7e91-4699-31e4-8f50-86d1a850d89a', 'correlation_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'hostname': 'celery@05a545667216', 'delivery_info': {'exchange': '', 'routing_key': 'celery', 'priority': 0,... kwargs:{})
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "POST /ds/login/ HTTP/1.1" 200 655 0.282608
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/user/me/ HTTP/1.1" 200 490 0.011824
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/user/setting/ HTTP/1.1" 200 215 0.020317
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/announcement/ HTTP/1.1" 200 215 0.011983
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/query/transpile/ HTTP/1.1" 200 419 0.017954
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/user/notifiers/ HTTP/1.1" 200 348 0.018368
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/query_execution_exporter/ HTTP/1.1" 200 215 0.023621
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:02] "GET /ds/user/environment/ HTTP/1.1" 200 233 5.029392
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /static/favicon/querybook.svg HTTP/1.1" 200 5544 0.017975
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/query_metastore/ HTTP/1.1" 200 215 0.010979
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/environment/ HTTP/1.1" 200 215 0.029958
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/query_engine/ HTTP/1.1" 200 215 0.017463
querybook_worker         | [2025-03-27 20:37:06,821: INFO/MainProcess] Task celery.local.sync_elasticsearch[185cb78a-0b66-47de-a3db-71e6bea1e53c] received
querybook_worker         | [2025-03-27 20:37:06,821: DEBUG/MainProcess] basic.qos: prefetch_count->6
querybook_worker         | [2025-03-27 20:37:06,823: INFO/ForkPoolWorker-3] Task celery.local.sync_elasticsearch__debouncer[f407a87d-ae47-450b-95b1-c44df07eb1e7] succeeded in 5.021026143018389s: None
querybook_elasticsearch  | [2025-03-27T20:37:19,071][INFO ][o.o.i.i.ManagedIndexCoordinator] [d8d3bb7a5243] Cancel background move metadata process.
querybook_elasticsearch  | [2025-03-27T20:37:19,073][INFO ][o.o.i.i.ManagedIndexCoordinator] [d8d3bb7a5243] Performing move cluster state metadata.
querybook_elasticsearch  | [2025-03-27T20:37:19,074][INFO ][o.o.i.i.MetadataService  ] [d8d3bb7a5243] Move metadata has finished.

Мистер Дюк теперь может заходить в Querybook

Тот кто первый входит будет являться админом

Далее сделал конвектор к Trino и один eviroment, и добавил конектор в него и юзера

Можно писать запросики

Красивый прогресс

Тоже красиво

Работает и даже на русском.

PS: Откуда взялся Ldap?

Вот этот под руку попался https://github.com/intoolswetrust/ldap-server

Он на базе Apache Directory https://directory.apache.org/apacheds/downloads.html
Сделан как раз для тестов, то что нужно.

Вот так делаем:

docker pull kwart/ldap-server
docker run -it --rm kwart/ldap-server

Потом так:

../containers/bundled_querybook_config.yaml

AUTH_BACKEND: 'app.auth.ldap_auth' # Same as import path when running Python
LDAP_CONN: 'ldap://192.168.215.2:389'
LDAP_USER_DN: 'uid={},ou=Users,dc=ldap,dc=example'

И так

LDAP_CONN: "ldap://192.168.215.2:389"   #  без сертификатов, и так сойдет,  но они нужны и корневые особенно для ldaps. 
LDAP_USER_DN: "uid={},ou=Users,dc=ldap,dc=example"
LDAP_UID_FIELD: "uid"
LDAP_EMAIL_FIELD: "uid"  # У меня нет почты в ldap поэтому схитрил, но надо бы добавить атрибут mail в схему LDAP
LDAP_LASTNAME_FIELD: "sn"
LDAP_FIRSTNAME_FIELD: "cn"  # Используйте cn, если givenName отсутствует
LDAP_FULLNAME_FIELD: "cn"
LDAP_BIND_DN: "uid=admin,ou=system"
LDAP_BIND_PASSWORD: "secret"
LDAP_SEARCH_BASE: "dc=ldap,dc=example"

Теперь осталось придумать как всунуть туда hive matastore – это будет чуть сложнее, чем казалось.
Один всунуть можно, но одного мало, а много лень. Может сделать еще один как все и уже его одного добавлять? пока не знаю 🧐

Методы приоритизации задач: как эффективно управлять временем

Картинку стащил из паблика

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

---

1. Матрица Эйзенхауэра

Принцип: Задачи делятся на четыре категории по критериям срочности и важности:

• Срочные и важные (Do): требуют немедленного выполнения (например, кризисные ситуации).
• Важные, но не срочные (Schedule): планируются на будущее (стратегические цели, саморазвитие).
• Срочные, но не важные (Delegate): можно делегировать (рутинные задачи, ответы на письма).
• Несрочные и неважные (Delete): устраняются (бесцельный скроллинг соцсетей).

Пример:

• Do: Срочный отчет для клиента.
• Schedule: Планирование квартальной стратегии.
• Delegate: Ответы на стандартные запросы через ассистента.
• Delete: Просмотр развлекательных видео в рабочее время.

---

2. Time Blocking (Временные блоки)

Принцип: Рабочий день делится на отрезки времени, каждый из которых посвящен конкретной задаче. Это минимизирует многозадачность и повышает концентрацию.

Пример расписания на понедельник:

|Время|Задача|

|-----------|---------------------------|

|9:00–11:00|Глубокая работа (написание статьи).|

|11:00–12:00|Встречи с командой.|

|13:00–14:00|Обработка срочных задач.|

Совет: Используйте буферные периоды между блоками для переключения контекста.

---

3. Метод 3-3-3

Принцип: День делится на три части:

• 3 часа на глубокую работу (сложные проекты).
• 3 часа на выполнение срочных, но менее важных задач.
• 3 часа на рутинные дела (проверка почты, административные задачи).

Преимущество: Баланс между продуктивностью и поддержанием рабочего процесса.

---

4. ABCDE-метод

Принцип: Задачи ранжируются от A (наивысший приоритет) до E (можно исключить):

• A: Последствия невыполнения критичны (например, оплата счетов).
• B: Важно, но не срочно (планирование отпуска).
• C: Желательно, но не обязательно (оптимизация процессов).
• D: Можно делегировать (подготовка документов).
• E: Исключить (устаревшие задачи).

---

5. Moscow-метод

Принцип: Задачи сортируются по категориям:

• Must have: Без этого проект провалится (основной функционал).
• Should have: Важно, но не критично (дополнительные фичи).
• Could have: Желательные улучшения (улучшение UI).
• Won’t have: Откладывается на будущее.

Пример для разработки приложения:

• Must have: Регистрация пользователей.
• Should have: Интеграция с соцсетями.
• Could have: Анимированные переходы.

---

6. Принцип Парето (80/20)

Принцип: 20% усилий дают 80% результата. Фокусируйтесь на задачах с максимальной отдачей.

Пример:

• 20% клиентов приносят 80% прибыли → Уделяйте им больше внимания.
• 20% функций продукта определяют его успех → Сначала реализуйте их.

---

Итоговые рекомендации

1. Комбинируйте методы: Используйте матрицу Эйзенхауэра для ежедневной приоритизации и Time Blocking для планирования.
2. Регулярно пересматривайте задачи: Удаляйте или делегируйте то, что потеряло актуальность.
3. Избегайте перфекционизма: Согласно принципу Парето, иногда «достаточно хорошо» лучше, чем «идеально».

---

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

Управление временем — это не про то, чтобы сделать больше, а про то, чтобы сделать правильные вещи. Выбирайте подходящие методы, экспериментируйте и оптимизируйте свой workflow!

🔗 Подробнее: [scottcaputo.com](https://scottcaputo.com)

Тестируем AI функции в Trino 474

Дока тут: https://trino.io/docs/current/functions/ai.html

Заводим конектор llm.properties

connector.name=ai
ai.provider=openai
ai.model=gpt-4o-mini
ai.openai.api-key=sk-XXXXXXa
ai.openai.endpoint= https://api.XXXXX/openai

немного конфига config.properties

sql.path=llm.ai

Пробуем:

SELECT ai_analyze_sentiment('Ai да заяц какой умный как утка только отруби не есть'); -- mixed
SELECT ai_analyze_sentiment('Ai да заяц какой умный'); -- positive

SELECT ai_classify('Buy fucking deep! and bitcoin', ARRAY['spam', 'not spam']); -- spam
-- spam

SELECT ai_classify('много денег', ARRAY['Хорошо', 'Плохо']); -- Хорошо

SELECT ai_classify('мало денег', ARRAY['Хорошо', 'Плохо']); -- Плохо

SELECT ai_fix_grammar('Пошёл я, значица, на рынок, там нашол один такой магазинчег, где продают всякие запчасти. Думал, прикуплю видюху крутую, чтобы всё летало. Смотрю - лежыт такая, блестит, вся из себя навороченая. Спрашиваю продавца: "Скока стоит эта красота?" А он мне такой цену заломил, у меня глаза на лоб полезли.');
-- Пошёл я, значит, на рынок, там нашёл один такой магазинчик, где продают всякие запчасти. Думал, прикуплю крутую видеокарту, чтобы всё летало. Смотрю - лежит такая, блестит, вся из себя навороченная. Спрашиваю продавца: "Сколько стоит эта красота?" А он мне такую цену назвал, что у меня глаза на лоб полезли.

SELECT ai_gen('Опиши что такое Москва коротко'); 
-- Москва — столица и крупнейший город России, расположенный в центральной части страны. Это политический, экономический и культурный центр, известный своими историческими памятниками, такими как Кремль и Красная площадь, а также современными skyscrapers. Город обладает развитой инфраструктурой, включая транспортную сеть, образовательные учреждения и театры. Москва также является одним из крупнейших мегаполисов мира с разнообразной культурой и многонациональным населением.

SELECT ai_mask(
    'Позвони мне быстро 987 554 32 11 или приходи ул. ленина 43 кв. 32,  скажи, что от Гаврилова Юры',
    ARRAY['телефон', 'Адрес',  'Имя']);
-- Позвони мне быстро [MASKED] или приходи [MASKED], скажи, что от [MASKED]

SELECT ai_translate('Буря мглою небо кроет,
Вихри снежные крутя;
То, как зверь, она завоет,
То заплачет, как дитя,
То по кровле обветшалой
Вдруг соломой зашумит,
То, как путник запоздалый,
К нам в окошко застучит.', 'en');

/*
The storm covers the sky with gloom,  
Whirling snowstorms twist and turn;  
Now, like a beast, it howls,  
Now it cries like a child,  
Now on the dilapidated roof  
Suddenly rustles with straw,  
Now, like a late traveler,  
It knocks at our window.
*/


SELECT name, address,comment, ai_classify(comment, ARRAY['Хорошо', 'Плохо', 'Можно помочь']), ai_translate(comment, 'ru') FROM tpch.sf1000.customer limit 10;

Customer#037500001	rLbDxR0mC,PwQ5QkxWCfXCC	tes; slyly regular pearls cajole quickl	Плохо	лжем; хитро обычные жемчужины уговаривают быстро
Customer#037500002	0bZ7K57TnmFs9goL41xTB64xBTLuXPtGPN	unusual, ironic pinto beans haggle across the regular req	Плохо	необычные, ироничные пинто фасоль торгуются по обычному запросу
Customer#037500003	5QliQMqzyz	ietly. deposits nag sometimes according to the even deposits. f	Плохо	тихо. депозиты иногда зависят от равномерных депозитов. f
Customer#037500004	FMm4JPC9UUSTOdfsfn	ect; slyly even packages haggle. pending inst	Плохо	ждут; хитро даже пакеты торгуются. в ожидании инст
Customer#037500005	a CUUBM75af0IX66Jm	unts are bold, unusual packages. fluffily unusual foxes nag furiously even deposits	Плохо	Унцы — это смелые, необычные пакеты. Пухово-необычные лисы яростно требуют даже депозиты.
Customer#037500006	VoXTOweLVJuiKe7xcn K69l7RoN61,	ar pinto beans haggle blithely. 	Можно помочь	Фасоль "пинто" торгуются беззаботно.
Customer#037500007	fUoQ2Fkssi94OhGGE1UetR w	ages hang blithely among the slyly ruthless accounts. carefully pen	Плохо	возрасты беззаботно свисают среди хитро безжалостных счетов. осторожно пишите
Customer#037500008	xogtDxejUq	 slyly special dependencies use quickly throughout the blithely stealthy accounts. depend	Можно помочь	Лукавые специальные зависимости используются быстро на протяжении безмятежных скрытных отчетов. зависеть
Customer#037500009	ou,BZuF,BMMeEoSUgyODRQZFQJyIsFQMSWp	en requests maintain. carefully ironic requests sleep carefull	Плохо	запросы поддерживают. осторожно ироничные запросы спят осторожно
Customer#037500010	lcP8JaVg2dz	y final packages. accounts along the quietly ironic ideas nag carefully idly express requests. requests detect 	Плохо	Итоговые пакеты. учетные записи вдоль тихо ироничных идей настойчиво и бездумно выражают запросы. запросы обнаруживают

При тестировании ни один заяц не пострадал, но вот hive и iceberg пришлось зарубить, там новые параметры для конфига. Так,что. придется их изучить при обновлении на новые версии, старые работать не будут.

а каталог iceberg я добавил так в итоге

connector.name=iceberg
fs.native-s3.enabled=true
s3.endpoint=https://gateway.storjshare.io
s3.region=us1
hive.metastore.uri=thrift://metastore:9083
hive.metastore.username=trino
hive.metastore.thrift.client.connect-timeout=1m
s3.path-style-access=true
s3.aws-access-key=XXXXX
s3.aws-secret-key=CCCCCCCCC
s3.socket-read-timeout=1m

iceberg.file-format=PARQUET
iceberg.compression-codec=SNAPPY
iceberg.target-max-file-size=128MB

но еще заметил эту багу https://github.com/trinodb/trino/issues/25427

перевод: 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, который обеспечивает хороший баланс между скоростью, поддержкой распределенного инференса (необходимого для больших моделей) и простотой установки.