Welcome to my personal place for love, peace and happiness 🤖

Later Ctrl + ↑

Требования к аппаратному обеспечению для DeepSeek-R1 70B

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

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

Компонент Требование
GPU Система с несколькими GPU, где каждая GPU имеет не менее 32 ГБ видеопамяти (VRAM) (например, NVIDIA A100 80GB x16)
ОЗУ Минимум 64 ГБ системной памяти
ЦП Высокопроизводительный многоядерный процессор (например, AMD EPYC или Intel Xeon)

Как установить 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:

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

Модель Параметры (B) Требования к VRAM (ГБ) Рекомендуемый GPU
DeepSeek-R1-Zero 671B ~1,543 ГБ Система с несколькими GPU (например, NVIDIA A100 80GB x16)
DeepSeek-R1 671B ~1,543 ГБ Система с несколькими GPU (например, NVIDIA A100 80GB x16)
DeepSeek-R1-Distill-Qwen-1.5B 1.5B ~3.9 ГБ NVIDIA RTX 3060 12GB или выше
DeepSeek-R1-Distill-Qwen-7B 7B ~18 ГБ NVIDIA RTX 4090 24GB или выше
DeepSeek-R1-Distill-Llama-8B 8B ~21 ГБ NVIDIA RTX 4090 24GB или выше
DeepSeek-R1-Distill-Qwen-14B 14B ~36 ГБ Система с несколькими GPU (например, NVIDIA RTX 4090 x2)
DeepSeek-R1-Distill-Qwen-32B 32B ~82 ГБ Система с несколькими GPU (например, NVIDIA RTX 4090 x4)
DeepSeek-R1-Distill-Llama-70B 70B ~181 ГБ Система с несколькими GPU (например, NVIDIA A100 80GB x3)

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

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

Модель Параметры (B) Требования к VRAM (ГБ) (4-бит) Рекомендуемый GPU
DeepSeek-R1-Zero 671B ~436 ГБ Система с несколькими GPU (например, NVIDIA A100 80GB x6)
DeepSeek-R1 671B ~436 ГБ Система с несколькими GPU (например, NVIDIA A100 80GB x6)
DeepSeek-R1-Distill-Qwen-1.5B 1.5B ~1 ГБ NVIDIA RTX 3050 8GB или выше
DeepSeek-R1-Distill-Qwen-7B 7B ~4.5 ГБ NVIDIA RTX 3060 12GB или выше
DeepSeek-R1-Distill-Llama-8B 8B ~5 ГБ NVIDIA RTX 3060 12GB или выше
DeepSeek-R1-Distill-Qwen-14B 14B ~9 ГБ NVIDIA RTX 4080 16GB или выше
DeepSeek-R1-Distill-Qwen-32B 32B ~21 ГБ NVIDIA RTX 4090 24GB или выше
DeepSeek-R1-Distill-Llama-70B 70B ~46 ГБ Система с несколькими GPU (например, NVIDIA RTX 4090 24GB x2)

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

Эхх 😩

и зерно

но

AI-агенты для хранилищ данных

Перевод: AI-агенты для хранилищ данных

Оригинал: https://dzone.com/articles/ai-agents-for-data-warehousing

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

Автор: Аджай Таниконда · 04 марта 2025 · Анализ

Термин “хранилище данных” был впервые введен в 1980-х годах и относится к практике хранения данных из различных источников внутри организации. Собранные данные затем используются для отчетности, принятия решений, точной аналитики, улучшения понимания клиентов и обработки специальных запросов.

Однако традиционные методы хранилищ данных сопряжены со значительными проблемами, включая высокие затраты на установку и обслуживание, низкую скорость обработки и ограничения масштабируемости. Однако с ростом искусственного интеллекта внедрение DW Agent AI революционизирует управление данными, делая процессы более автоматизированными, эффективными и масштабируемыми.

DW Agent AI относится к агентам с искусственным интеллектом, которые оптимизируют различные аспекты хранилищ данных, от автоматизации ETL/ELT до оптимизации запросов и расширенной аналитики. Эти агенты используют алгоритмы машинного обучения, обнаружение аномалий и методы адаптивной оптимизации для улучшения обработки данных. Благодаря автоматизации они сокращают ручное вмешательство, повышают точность данных и оптимизируют скорость выполнения запросов, особенно на облачных платформах, таких как Google Cloud, AWS Redshift и Snowflake.

Google Cloud предлагает расширенную экосистему для хранилищ данных и аналитики, используя сервисы на основе искусственного интеллекта, такие как BigQuery, Cloud Dataflow и другие.

В этой статье мы рассмотрим, как DW Agent AI преобразует хранилища данных, сосредоточив внимание на его роли в автоматизации ETL/ELT, обработке данных на основе искусственного интеллекта, прогнозной аналитике и отчетности в реальном времени. Мы также обсудим практическую реализацию DW Agent AI и преимущества, которые он приносит современным предприятиям. Итак, как именно AI-агенты улучшают процесс хранилища данных, особенно в контексте анализа данных?

Понимание необходимости AI-агентов в хранилищах данных

Для тех, кто не знаком с концепцией AI-агентов, она относится к моделям искусственного интеллекта, особенно к большим языковым моделям (LLM), предназначенным для выполнения специализированных задач. Эти задачи включают управление данными, преобразование и аналитику, что делает AI-агентов ценным активом в современных хранилищах данных.

Чтобы по-настоящему понять влияние AI-агентов на хранилища данных, мы должны рассмотреть пример использования. Представьте себе компанию, использующую аналитику на основе искусственного интеллекта для улучшения отчетности данных в Google Cloud.

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

Вот как AI-агенты могут помочь процессу хранилища данных с помощью анализа данных для обеспечения отчетности в Google Cloud:

  • Автоматизация ETL/ELT
  • Обработка и оптимизация данных на основе искусственного интеллекта
  • Прогнозная аналитика и обнаружение аномалий
  • Отчетность в реальном времени и BI, улучшенная с помощью искусственного интеллекта

Автоматизация ETL с DW Agent AI

Когда дело доходит до хранилищ данных, AI-агенты играют решающую роль в автоматизации ETL/ELT. ETL (Extract, Transform, Load) — это процесс сбора данных из нескольких источников, преобразования их в структурированный формат и загрузки в централизованное хранилище данных для углубленного анализа.

Традиционно процесс ETL/ELT сталкивался с рядом проблем. Извлечение данных вручную из различных источников является сложным, трудоемким и требует значительных ресурсов для обеспечения совместимости с предопределенной моделью данных. Кроме того, ручные процессы подвержены ошибкам и несоответствиям, которые могут поставить под угрозу целостность данных. AI-агенты устраняют эти неэффективности, автоматизируя процесс ETL/ELT, делая интеграцию данных плавной и значительно сокращая операционные издержки.

Процесс ETL является одним из основных компонентов хранилища данных. В этом процессе необработанные данные извлекаются из различных ресурсов, таких как API, веб-сервисы, CRM-системы и многое другое. Эти данные затем обрабатываются, преобразуются и загружаются в хранилище данных.

В то время как наши существующие хранилища данных нуждаются в большом объеме человеческого ввода от извлечения данных до их очистки, вот как AI-агент помогает сделать этот процесс намного проще:

  • Обработка эволюции источника/схемы.** AI-агенты могут эффективно обнаруживать новые источники данных, извлекать релевантную информацию и обновлять важные наборы данных в режиме реального времени. Автоматическое обнаружение изменений схемы и адаптация ETL-конвейеров. Это приводит к минимальному количеству человеческих ошибок и оптимизирует процесс сбора данных.
  • Преобразование данных с помощью искусственного интеллекта.** С помощью алгоритмов машинного обучения AI-модели могут очищать, нормализовать и представлять данные в структурированном формате, что потребовало бы от традиционных инструментов ETL много времени.
  • Оптимизация инкрементной загрузки.** Идентификация дельт и интеллектуальное управление приемом данных с использованием системы отслеживания изменений данных (CDC) на основе машинного обучения.
  • Гарантия качества данных:** Применение разработанных AI-агентами средств обнаружения аномалий для выявления несоответствий, отсутствующих значений и дублирующихся записей до того, как они повлияют на последующую аналитику.
  • Самовосстанавливающиеся конвейеры.** Без какого-либо вмешательства человека AI-агенты могут не только идентифицировать несоответствия, но и исправлять их, что является революционным. Например, AI может обнаруживать смещение схемы в потоковых данных и автоматически корректировать преобразования, а не вызывать сбои.

Благодаря внедрению процессов ETL/ELT на основе искусственного интеллекта организации могут значительно сократить обслуживание конвейера данных и повысить эффективность обработки.

Примеры использования анализа данных с AI-агентами

*Анализ данных*

Сбор и хранение данных

Основываясь на нашем текущем примере, компания использует Google Cloud для сбора и хранения любых релевантных необработанных данных в различных форматах. Некоторые из этих форматов включают JSON, CSV и т. д. Google Pub/Sub облегчает прием данных в режиме реального времени и связь между микросервисами, обеспечивая бесперебойную интеграцию. Это обеспечивает плавный прием и обработку данных в Google Cloud.

Обработка и оптимизация данных на основе искусственного интеллекта

Теперь, когда данные собраны, их необходимо отфильтровать, преобразовать и скорректировать таким образом, чтобы можно было провести расширенный анализ. В этом контексте AI-агент автоматизирует этапы обработки и преобразования с помощью некоторых из самых популярных бессерверных инструментов Google Cloud. AI-агенты оптимизируют этот процесс, используя следующие сервисы и шаги Google Cloud:

  • Использование интеграции BigQuery AI.** AI-агенты используются и внедряются в BigQuery для удаления ошибок и дубликатов, а также для стандартизации категоризации продуктов в примере использования розничной компании.
  • Cloud dataflow для ETL.** AI-агенты улучшают процесс ETL с помощью Cloud Dataflow и преобразуют такие данные, как конвертация валют и расчеты скидок из необработанных источников.
  • Внесение корректировок.** AI-агенты уточняют и структурируют данные, обеспечивая их оптимизацию для анализа тенденций.
  • Адаптивная оптимизация запросов.** Использование методов обучения с подкреплением для постоянного улучшения планов выполнения запросов на основе исторической рабочей нагрузки.
  • Автоматизация материализованных представлений.** Динамическое создание и обновление материализованных представлений для ускорения часто используемых агрегаций и объединений.
  • Настройка параллельной обработки.** Оптимизация распределенного выполнения запросов путем интеллектуального распределения вычислительных ресурсов на основе моделей рабочей нагрузки.
  • Интеллектуальное индексирование.** Автоматическая рекомендация индексов и управление ими для повышения производительности запросов без чрезмерных затрат на хранение.

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

Прогнозная аналитика и обнаружение аномалий

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

Реальный вариант использования AI-агентов для хранилищ данных в этом контексте может включать следующее:

  • Прогнозирование продаж с помощью прогнозирования временных рядов.** С помощью AI-агентов компании могут анализировать исторические данные о продажах, чтобы предсказать, что их ждет в будущем. Помимо базового прогнозирования, AI может анализировать сезонность и рекламное воздействие для улучшения прогностических данных. Использование моделей глубокого обучения, таких как LSTM и архитектуры на основе Transformer, для прогнозирования спроса, продаж и операционных показателей.
  • Анализ клиентов и обнаружение аномалий.** AI-агенты анализируют модели покупок и поведение клиентов. Это позволяет компаниям разрабатывать персонализированные маркетинговые стратегии для улучшения оборота. Использование AI-моделей, таких как Isolation Forest и Autoencoders, для выявления необычных закономерностей в финансовых транзакциях, системных журналах и поведении клиентов.
  • Анализ запасов и аналитика в реальном времени.** AI-агенты могут идентифицировать запасы, которые продаются не оптимально. Таким образом, компания может оптимизировать свои стратегии пополнения запасов для обеспечения улучшения продаж. Развертывание предварительно обученных моделей в хранилищах данных для немедленной оценки и вывода, обеспечивающее оперативное понимание.

Отчетность в реальном времени и BI, улучшенная с помощью ИИ

После завершения обработки и анализа данных AI-агенты могут автоматизировать создание отчетов с помощью инновационных инструментов отчетности Google Cloud. Вот как работает процесс:

  • Looker от Google Cloud.** Используя Looker и интеграцию с AI, компании могут создавать интерактивные панели мониторинга. Это позволяет заинтересованным сторонам компании всегда иметь важную информацию о KPI (Key Performance Indicators, ключевые показатели эффективности). Примером отчетности на основе искусственного интеллекта может служить функция обнаружения AI-driven аномалий Looker. Автоматически сгенерированные аналитические данные с использованием естественного языка (например, функция Explain в Looker)
  • Отчеты с голосовым управлением.** С помощью NLP в Google Cloud AI-powered чат-боты могут предоставлять отчеты с голосовым управлением, которые помогают менеджерам и заинтересованным сторонам с упрощенными версиями данных.
  • Оповещения и уведомления.** Настраивая оповещения, AI-агенты могут запускать алармы и другие важные уведомления, чтобы ничего не осталось незамеченным.

Внедрив мощь AI-агентов, бизнес любого рода может извлечь большую выгоду из хранилища данных на основе искусственного интеллекта.

Практическая реализация AI-агентов в хранилищах данных: DW Agent AI

DW Agent AI — это платформа, которая демонстрирует практическое применение искусственного интеллекта в хранилищах данных. Она преобразует базовые запросы в оптимизированные версии, используя такие методы, как:

  • Взаимодействие с данными на естественном языке
  • Автоматизация создания инсайтов
  • Оптимизация системы

Например, AI-агенты могут оптимизировать запросы для уменьшения сканирования данных в BigQuery:

Исходный запрос:

```sql
SELECT * FROM large_table WHERE status = ‘active’;
```

AI-оптимизированный запрос:

```sql
SELECT id, name, status
FROM large_table
WHERE status = ‘active’
AND created_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
```

Этот запрос применяет отсечение разделов (partition pruning), уменьшая объем сканируемых данных в BigQuery.

Каковы преимущества AI-агентов в хранилищах данных?

Когда дело доходит до внедрения AI-агентов в процессы хранилищ данных в Google Cloud, мы получаем несколько преимуществ, в том числе:

  • Больше никаких ручных усилий.** Когда дело доходит до избыточных и повторяющихся задач, AI устраняет их, преобразовывая роль инженеров в стратегических экспертов. Таким образом, инженерам и ученым по данным не нужно будет беспокоиться о фактическом извлечении данных; они могли бы использовать уже собранные данные, чтобы получить исключительные сведения.
  • Улучшенная точность.** Системы на основе искусственного интеллекта сведут к минимуму человеческие ошибки, гарантируя, что собранные данные будут точными, согласованными и более работоспособными.
  • Улучшенная масштабируемость.** Благодаря бессерверной инфраструктуре Google Cloud масштабируемость становится намного проще с ростом объемов данных. Это особенно полезно, поскольку уменьшается вероятность потери данных и подобных ошибок.
  • Экономичность.** Традиционная система хранилища данных требует не только различных инструментов, но и всей рабочей силы, чтобы всегда быть начеку. Когда мы внедряем оптимизацию на основе искусственного интеллекта, вы не только сокращаете использование облака, но и операционные издержки невозможно отрицать.

Будущее AI-агентов в хранилищах данных

В своей нынешней форме AI-агенты имеют свои ограничения, такие как сложность обучения модели, поскольку AI необходимо обучать на больших объемах данных для оптимальной работы. Более того, существуют также проблемы безопасности, поскольку организация будет использовать стороннее расширение для сбора важных данных. Однако самым большим является интеграция. Интеграция AI с устаревшими системами займет годы, чтобы стать новой нормой.

Когда мы смотрим в будущее, AI в хранилище данных обязательно получит развитие. Мы можем увидеть бум хранилищ данных, которые будут самооптимизироваться без участия людей. Это может сэкономить время, деньги и усилия, когда компаниям необходимо анализировать данные и принимать важные решения. Примерами этого могут быть автономные хранилища данных (такие как автоматическая оптимизация Snowflake), автоматическое масштабирование BigQuery от Google и настройка ресурсов на основе искусственного интеллекта.

Окончательный вердикт

AI-агенты преобразуют процессы хранилищ данных, автоматизируя сбор данных, внедряя расширенную отчетность и используя инструменты, предоставляемые на SaaS-платформах, таких как Google Cloud. По мере развития AI мы увидим новые будущие тенденции. Но одно можно сказать наверняка: AI действительно является будущим для хранилищ данных и аналитики.

Процессоры SiFive серий P650, P670, P870 и P870-A

очень ждем

Процессоры SiFive серий P650, P670, P870 и P870-A ( кстати есть еще P870-D ) относятся к высокопроизводительным ядрам RISC-V, предназначенным для таких задач, как ИИ, автомобильные системы, сетевые решения и мобильные устройства. На момент 2024 года информация о коммерческих продуктах с этими процессорами ограничена, но есть данные о партнерствах и потенциальных применениях:

---

1. Подтвержденные или анонсированные проекты

  • Автомобильная электроника
    Renesas Electronics: Совместно с SiFive разрабатывает решения для ADAS и автономного вождения. Возможно использование P870-A (автомобильная версия).
    Mobileye (Intel): Исследует RISC-V для систем автономного управления, потенциально с ядрами SiFive.
  • Сетевые устройства и инфраструктура
    Microchip Technology: Внедряет RISC-ядра SiFive в сетевые чипы. P650/P670 могут использоваться для маршрутизаторов и коммутаторов.
    Qualcomm: Тестирует SiFive P670 для IoT и модемов 5G.
  • Потребительская электроника
    Samsung: Экспериментирует с RISC-V в смартфонах и планшетах. P870 может стать альтернативой ARM в будущих устройствах.
    Intel Foundry Services: Предлагает клиентам лицензирование SiFive P650/P870 для кастомизации чипов.

---

2. Планируемые применения

  • Серверы и HPC
    Ventana Micro Systems: Разрабатывает серверные процессоры на RISC-V. Не исключено сотрудничество с SiFive для P870.
    Китайские компании (например, Alibaba, Huawei): Могут использовать P870 для снижения зависимости от x86/ARM из-за санкций.
  • SSD-контроллеры
    Phison/Silicon Motion: Внедрение P650/P670 для управления NVMe-накопителями.
  • Одноплатные компьютеры
    HiFive серия: Будущие платы для разработчиков с P650/P670 (ожидаются в 2024-2025 гг.).

---

3. Ключевые отрасли и прогноз

  • Автоиндустрия: P870-A может стать основой для ECU и систем автономного вождения (2025+).
  • ИИ-ускорители: Интеграция P870 с нейросетевыми процессорами (например, компании Tenstorrent).
  • Военные/космические системы: Благодаря открытой архитектуре RISC-V и надежности SiFive.

---

Где искать актуальную информацию?

  • Официальный сайт SiFive: [sifive.com](https://www.sifive.com) (раздел Products → Performance).
  • Новостные ресурсы: AnandTech, EE Times, Tom’s Hardware.
  • Конференции RISC-V Summit и выставки CES.

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

 No comments   1 mo   AI   RISC-V

Анализ влияния текущей политики США на ИИ: ключевые тезисы и выводы

Анализ влияния текущей политики США на ИИ: ключевые тезисы и выводы

Анализ подготовил тоже ИИ на содержание одной дискуссионной доски. Так что не принимайте близко к сердцу. Оригинал: https://substack.com/chat/396235/post/87e3ae0b-5441-4cdc-bd3d-718377563363

1. Политика в отношении Китая и экспортный контроль
  • Экспортные ограничения: Администрация Трампа усилила контроль над экспортом ИИ-чипов (например, NVIDIA) в Китай, чтобы замедлить его технологический рост. Однако пользователи отмечают, что это может стимулировать Китай к ускоренной инновации, как видно на примере open-source моделей DeepSeek и Alibaba Cloud [washingtonpost.com](https://www.washingtonpost.com/politics/2025/01/24/stargate-trump-ai-altman-musk/).
  • Военно-технологическая конкуренция: Китай демонстрирует преимущества в производстве, дронах и робототехнике, что вызывает опасения о военном превосходстве. Сокращение бюджета Пентагона на $50 млрд может усилить зависимость США от частных компаний (Palantir, Anduril), что повышает риски автоматизации военных систем [jdsupra.com](https://www.jdsupra.com/legalnews/trump-administration-issues-new-ai-8835720/).
2. Регулирование ИИ и роль Big Tech
3. Инфраструктура ИИ и энергетические вызовы
  • Инвестиции в дата-центры: Проекты вроде Stargate (OpenAI) и $200 млрд кампуса Meta подчеркивают рост инфраструктуры. Однако энергопотребление ИИ становится узким местом: Китай эффективнее внедряет ВИЭ, тогда как США отстают в планировании [datacenterdynamics.com](https://www.datacenterdynamics.com/en/news/meta-targets-sites-for-200bn-ai-data-center-campus-report/).
4. Военная стратегия и приватизация
  • Сокращение оборонных расходов: Планы сокращения бюджета Пентагона на 8% ежегодно могут привести к потере рабочих мест и передаче функций ИИ-стартапам. Это усиливает риски неконтролируемой автоматизации в военной сфере [npr.org](https://www.npr.org/2025/02/20/nx-s1-5303947/hegseth-trump-defense-spending-cuts).
  • Роль Илона Маска: Подозрения в передаче технологий SpaceX Китаю и влияние Маска на политику Трампа создают конфликт интересов, особенно на фоне зависимости Tesla от китайского рынка.
5. Международные отношения и изоляционизм
  • Выход из НАТО: Риски снижения влияния США в Европе и усиления позиций Китая/России. Пользователи отмечают, что это ослабляет экономику ЕС и делает страны более зависимыми от Китая [uscc.gov](https://www.uscc.gov/sites/default/files/2024-11/Chapter_3--U.S.-China_Competition_in_Emerging_Technologies.pdf).
  • Роль Индии и Global South: Индия и страны БРИКС становятся ключевыми игроками, балансируя между США и Китаем. Однако коррупция и бюрократия замедляют технологический прогресс Индии.
6. Эволюция ИИ и рынки
  • Китайские open-модели: DeepSeek и Grok 3 демонстрируют эффективность, что ставит под вопрос конкурентоспособность OpenAI (GPT-4.5 разочаровывает). Китай фокусируется на потребительских приложениях и робототехнике, используя низкие затраты [youtube.com](https://www.youtube.com/channel/UClYGvRt1xo3TET_ZwBfU9UA).
  • Пузырь ИИ-стартапов: Рынок перегрет, а венчурные инвестиции вне ИИ сокращаются. Снижение акций NVIDIA на 10% в 2025 г. отражает риски экспортных ограничений.

---

Заключение

Администрация Трампа делает ставку на экономический национализм и технологическое доминирование, но ее политика несет риски:

  • Для США: Централизация ИИ в руках Big Tech, энергетические пробелы, военная приватизация.
  • На глобуле: Усиление Китая через экспортные ограничения, изоляция ЕС, рост влияния BRICS.
  • Этические риски: Приоритет конкуренции над регулированием увеличивает вероятность злоупотреблений ИИ в военной и социальной сферах.

Стратегия «America First» может дать краткосрочные преимущества, но в долгосрочной перспективе ослабит позиции США из-за отсутствия системного подхода к ИИ-инфраструктуре, этике и международному сотрудничеству.

Вторая версия:

Ключевые темы и точки обсуждения:

* Соперничество США и Китая в сфере ИИ: Доминирующая тема. Участники выражают опасения, что Китай быстро догоняет или даже опережает США в ключевых областях разработки и внедрения ИИ. Отмечаются преимущества Китая в производстве, планировании возобновляемой энергетики для дата-центров и экономической эффективности.
* Экспортный контроль: Спорный вопрос — влияние ограничений США на экспорт ИИ-чипов в Китай ([stratechery.com](https://stratechery.com/2025/ai-promise-and-chip-precariousness/)). Некоторые считают, что эти меры дают обратный эффект: Китай ускоряет инновации, а компании вроде Nvidia теряют позиции (падение акций может навредить фондовому рынку США).
* Инфраструктура ИИ: Обсуждаются масштабные инвестиции, например, проект Meta стоимостью $200 млрд ([datacenterdynamics.com](https://www.datacenterdynamics.com/en/news/meta-targets-sites-for-200bn-ai-data-center-campus-report/)). Высказывается беспокойство, что США недостаточно решают энергетические потребности таких проектов, в отличие от Китая.
* Регулирование ИИ: Отмечается слабое регулирование ИИ в США по сравнению с ЕС. Участники опасаются, что исполнительные приказы Трампа могут отменить достижения предыдущей администрации, усиливая централизацию власти у крупных технологических компаний и способствуя развитию «дистопического ИИ».
* Подход Трампа к ИИ: Его политику описывают как «невмешательство», благоприятствующую BigTech и сделкам в интересах союзников. Упрекают в ориентации на краткосрочную выгоду и «мафиозный капитализм».
* DeepSeek как вызов: Экономичная модель ИИ с открытым исходным кодом из Китая рассматривается как символ прогресса Китая и угроза лидерству США.
* Военный ИИ и расходы: Возможное сокращение военных расходов при Трампе и зависимость от компаний вроде Palantir и Anduril (связанных с Питером Тилем) могут привести к потере рабочих мест и повышению рисков использования ИИ в военных системах.
* Влияние Маска: Деловые интересы Илона Маска в Китае и его связи с мировыми лидерами вызывают подозрения, включая возможную утечку интеллектуальной собственности.
* Разрыв между США и Европой: Подчеркивается разница в подходах к военно-технологическому комплексу в Вашингтоне и ЕС.

Анализ источников:
* Блог Microsoft: Указывает на попытки BigTech влиять на нарратив вокруг политики ИИ и «глобальной гонки».
* Публикация USIP ([ссылка](https://www.usip.org/publications/2025/02/ai-geopolitical-crossroads-tension-between-acceleration-and-regulation)): Акцентирует ИИ как геополитическое поле битвы, конфликт между развитием технологий и регулированием.
* Документ Белого дома ([ссылка](https://www.whitehouse.gov/fact-sheets/2025/01/fact-sheet-president-donald-j-trump-takes-action-to-enhance-americas-ai-leadership/)): Продвигает идею усиления лидерства США в ИИ при Трампе.

Текущая политика (из обсуждения и источников):
* Экспортный контроль: Продолжение ограничений на поставки ИИ-чипов в Китай.
* Инвестиции в инфраструктуру: Рост вложений в производство полупроводников и дата-центры.
* Смягчение регулирования: Возможный отказ от строгих норм в пользу конкурентоспособности ([источник](https://www.jdsupra.com/legalnews/trump-administration-issues-new-ai-8835720/)).
* Фокус на безопасность: Приоритет военного применения ИИ (поддерживается обеими партиями).

Регулирование ИИ:
* Конфликт приоритетов: США делают ставку на конкуренцию, ЕС — на этику ([источник](https://www.arnoldporter.com/en/perspectives/advisories/2025/01/the-trump-ai-executive-order)).
* Опасения штатов: Риски для сельских регионов осознаются на местном уровне.

Эволюция ИИ (по мнению участников):
* Сдвиг в пользу Китая: Рост эффективных open-source моделей вроде DeepSeek.
* Успехи в приложениях: Китай лидирует в потребительских продуктах на базе генеративного ИИ.

Важные аспекты:
* Роль аналитических центров: Скепсис в отношении компетентности вашингтонских think tanks в оценке технологий Китая.
* Отчет NSCAI (2025): Призыв к сотрудничеству власти, бизнеса и общества для безопасного развития ИИ ([ссылка](https://reports.nscai.gov/final-report/chair-and-vice-chair-letter)).

Итог: Обсуждение рисует сложную картину гонки за лидерство в ИИ между США и Китаем, неопределенности политики Трампа и этических дилемм. Участники сомневаются в готовности США противостоять китайскому вызову.

 No comments   1 mo   AI   Politics

Я перестал использовать Kubernetes – AI разбор статьи

Статья Я перестал использовать Kubernetes. Наша команда DevOps счастлива как никогда описывает решение компании отказаться от Kubernetes (K8s) и положительные результаты, которые они получили. Вот подробный разбор основных моментов статьи:

Gemini Flash 2 с web search помогла разобрать статейку, мне кажется неплохо сделала и избавила меня от необходимости читать самостоятельно и включать VPN.

Проблема:

  • Сложность и страх дежурства:** Статья начинается с подчеркивания проблем, связанных с Kubernetes. Команда DevOps автора боялась дежурств, что подразумевает, что K8s значительно увеличивал нагрузку и стресс, связанные с обслуживанием инфраструктуры.
  • Высокие затраты на инфраструктуру:** В статье прямо говорится о высоких затратах на инфраструктуру (позже это было выражено в снижении на 62% после отказа от K8s).
  • Проблемы с развертыванием:** Автор также предполагает, что их настройка K8s усложнила развертывания, поскольку, по их утверждению, процент успешности увеличился на 89% после перехода.
  • Управление многочисленными кластерами:** Автор также упоминает об управлении 47 кластерами Kubernetes в трех облачных провайдерах, что указывает на очень сложную настройку ([linkedin.com](https://www.linkedin.com/posts/cserepj_i-stopped-using-kubernetes-our-devops-team-activity-7266703223959273472-5cnI) отмечает это).

Решение:

  • Удаление Kubernetes:** Основная часть статьи – это решение *удалить* Kubernetes из своего стека инфраструктуры. Это было представлено как кажущийся радикальный шаг.
  • Более простые альтернативы (подразумевается):** В статье явно не детализируется, *на что* они переключились, но подразумевается, что они перешли к более простым, более управляемым стратегиям развертывания, предположительно включающим более традиционные серверы или решения PaaS (Platform as a Service).

Результаты:

  • Увеличение процента успешных развертываний:** Значительное увеличение процента успешных развертываний на 89%. Это говорит о том, что развертывания стали более надежными и менее подвержены сбоям после удаления K8s.
  • Сокращение затрат на инфраструктуру:** Существенное сокращение затрат на инфраструктуру на 62%. Это указывает на то, что более простое решение, которое они приняли, было более экономически эффективным, чем их настройка Kubernetes.
  • Более счастливая команда DevOps:** Утверждение в заголовке подтверждается заявлением о том, что команда DevOps впервые за два года смогла взять непрерывный отпуск. Это указывает на значительное снижение стресса и рабочей нагрузки для команды.

Основные причины (вывод / предположение):

Хотя в статье явно не затрагиваются *причины* этих улучшений, мы можем сделать несколько выводов:

  • Чрезмерная сложность (Over-Engineering):** Компания, возможно, использовала Kubernetes для рабочих нагрузок, которым фактически *не требовалась* его сложность. K8s – мощный инструмент, но его также сложно настроить и управлять им. Для более простых приложений накладные расходы K8s могут перевесить его преимущества.
  • Неэффективная конфигурация K8s:** Возможно, инфраструктура Kubernetes была настроена неэффективно, что привело к пустой трате ресурсов и увеличению затрат. Плохо настроенные кластеры K8s могут быть требовательными к ресурсам. Один из комментариев на Hacker News предполагает, что утверждения могут потребовать больше доказательств относительно использования ресурсов компонентами K8s ([news.ycombinator.com](https://news.ycombinator.com/item?id=42246883)).
  • Экспертиза команды:** Команде, возможно, не хватало необходимых знаний для эффективного управления таким большим количеством кластеров Kubernetes. В сообщении LinkedIn упоминается управление 47 кластерами в трех облачных провайдерах ([www.linkedin.com](https://www.linkedin.com/posts/cserepj_i-stopped-using-kubernetes-our-devops-team-activity-7266703223959273472-5cnI)).

Противоречия и нюансы:

Важно отметить, что статья несколько противоречива:

  • Потенциал кликбейта:** Как отметил один из комментаторов на Hacker News, статья может быть кликбейтом ([news.ycombinator.com](https://news.ycombinator.com/item?id=42234097)).
  • Недостаток конкретики:** Самая большая критика заключается в отсутствии технических деталей о том, *на что* они переключились и *как* они достигли этих результатов. Это затрудняет оценку достоверности заявлений и того, будет ли этот же подход работать для других.
  • Kubernetes часто ценен:** Kubernetes – ценный инструмент для многих организаций, особенно с комплексными архитектурами на основе микросервисов. Опыт, описанный в статье, вряд ли будет универсально применим.

В заключение:

В статье представлен кейс компании, которая утверждает, что значительно улучшила свои результаты DevOps, удалив Kubernetes. Хотя конкретные детали отсутствуют, статья предполагает, что Kubernetes не всегда является правильным решением и что более простые альтернативы иногда могут быть более эффективными, особенно если команде сложно с его сложностью или если он используется для рабочих нагрузок, которые не требуют его. Однако читателям следует проявлять осторожность в отношении обобщения этих результатов, не учитывая тщательно свои конкретные потребности и контекст.

 No comments   1 mo   AI   Kubernetes

Когда использовать AI-агентов: Простая блок-схема

Перевод: Когда использовать AI-агентов: Простая блок-схема

Оригинал: https://www.llmwatch.com/p/when-to-use-ai-agents-a-simple-flowchart

Когда и как использовать AI-агентов против AI-воркфлоу для ваших задач.

Ключевые моменты

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

AI-агенты против AI-воркфлоу – 30-секундная версия

Что это такое?

  • AI-агенты, или агенты с ИИ, – это системы, которые автономно планируют и адаптируются, принимая решения на лету. Они отлично подходят для сложных, неструктурированных задач. AI-воркфлоу**, с другой стороны, следуют предопределенным шагам, что идеально подходит для последовательных, повторяющихся процессов.

Как выбрать?

Сначала проверьте, может ли простой вызов LLM с поиском (retrieval) справиться с вашей задачей, например, ответить на быстрый вопрос. Если нет, решите: Ваша задача хорошо определена с четкими шагами? Если да, используйте воркфлоу; если нет, и требуется гибкость, выбирайте AI-агентов. Этот подход обеспечивает простоту и эффективность.

Стоимость и задержка

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

AI-агенты против AI-воркфлоу – Подробно

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

Давайте более подробно рассмотрим, когда использовать AI-агентов, а когда AI-воркфлоу, во многом опираясь на систему классификации Anthropic в качестве отправной точки. Таким образом, остальная часть этой статьи призвана направлять принятие решений, предлагая как теоретические идеи, так и практические применения, с акцентом на создание эффективных AI-систем.

Предпосылки и определения

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

  • AI-воркфлоу**: Это системы, в которых большие языковые модели (LLM) и инструменты оркеструются посредством предопределенных путей в коде. Они предназначены для задач с четкими, предсказуемыми шагами, обеспечивая согласованность и простоту отладки. Примеры включают автоматизацию обработки заказов или управление учетными записями клиентов, где последовательность действий хорошо установлена.
  • AI-агенты**: Это, с другой стороны, системы, в которых LLM динамически управляют своими собственными процессами и использованием инструментов, сохраняя контроль над тем, как выполняются задачи. Они подходят для неструктурированных, сложных задач, требующих адаптивности, таких как автономные помощники по кодированию или виртуальные помощники, обрабатывающие различные запросы пользователей.

Это различие имеет решающее значение, и рекомендуется начинать с максимально простого решения, увеличивая сложность только при необходимости. Очень редко AI-агенты должны быть вашим первым выбором для решения проблемы.

Основа для принятия решений

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

Описание блок-схемы

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

  • Начало:** Начните с оценки стоящей перед вами задачи.
  • Решение 1:** Может ли задача быть решена одним вызовом LLM с поиском (retrieval)?
    • Да:** Используйте один вызов LLM с поиском, которого достаточно для простых запросов, таких как ответы на фактические вопросы или генерация простого текста. Этот подход использует механизмы поиска для предоставления контекста, поддерживая низкие затраты и сложность.
    • Нет:** Если задача не может быть решена одним вызовом, перейдите к следующему решению.
  • Решение 2:** Является ли задача четко определенной с ясными, предопределенными шагами?
    • Да:** Используйте AI-воркфлоу. Они идеально подходят для задач, которые можно разбить на последовательность предопределенных шагов, обеспечивая предсказуемость и согласованность. Примеры включают автоматизированные ответы службы поддержки или конвейеры обработки данных.
    • Нет:** Используйте AI-агентов. Они необходимы для задач, которые являются неструктурированными или требуют динамического принятия решений, таких как помощники по кодированию, решающие проблемы GitHub, или виртуальные помощники, планирующие и выполняющие различные задачи.

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

Руководство по реализации

Чтобы предоставить практические рекомендации, мы можем классифицировать варианты использования и соображения для каждого варианта:

  • Одиночный вызов LLM с поиском (Retrieval):**
    • Вариант использования:** Подходит для простых запросов, когда LLM может предоставить прямой ответ, возможно, дополненный извлечением релевантной информации из базы данных или базы знаний. Например, ответ на вопрос клиента о технических характеристиках продукта.
    • Преимущества:** Низкая стоимость, низкая задержка и минимальная настройка. Это соответствует рекомендации Anthropic оптимизировать отдельные вызовы LLM поиском и примерами в контексте для многих приложений.
    • Пример:** Чат-бот, отвечающий: “Каковы часы работы вашего магазина?” путем извлечения информации и прямого ответа.
  • AI-воркфлоу:**
    • Вариант использования:** Лучше всего подходит для задач, которые хорошо определены и повторяются, с четкими шагами, которые не требуют от LLM принятия решений о том, какой следующий шаг следует предпринять. Примеры включают процессы выполнения заказов, от получения заказа до отправки, или управление учетными записями клиентов.
    • Преимущества:** Предсказуемость, согласованность и простота отладки. Воркфлоу следуют предопределенным путям в коде, что делает их подходящими для таких задач, как маршрутизация запросов клиентов в различные отделы на основе категорий (например, выставление счетов, техническая поддержка).
    • Соображения:** Убедитесь, что входы и выходы для каждого шага четко определены, чтобы избежать ошибок. Часто реализуется с помощью таких шаблонов, как объединение и маршрутизация подсказок как часть рабочих процессов, которые можно реализовать в нескольких десятках строк кода без сложных фреймворков.
    • Пример:** Банковский AI-чат-бот, который обрабатывает проверку баланса, выполняя предопределенную последовательность: проверяет пользователя, извлекает данные учетной записи, форматирует ответ.
  • AI-агенты:**
    • Вариант использования:** Идеально подходит для задач, которые являются сложными, неструктурированными или требуют гибкости и принятия решений на основе моделей. К ним относятся сценарии, в которых LLM необходимо планировать независимо, использовать внешние инструменты или адаптироваться к меняющимся условиям. Примеры включают агентов кодирования, решающих проблемы GitHub, как видно в тестах, таких как SWE-bench Verified, или виртуальных помощников, обрабатывающих различные запросы пользователей, такие как планирование встреч и создание отчетов.
    • Преимущества:** Высокая адаптивность, подходит для динамических сред. Агенты могут разбивать проблемы на управляемые шаги, сотрудничать с другими агентами и использовать такие инструменты, как веб-поиск или вызовы API, как отмечается в сообщении блога.
    • Соображения:** Более высокие затраты и задержка из-за динамической обработки. Рекомендуется проводить тестирование в изолированной среде и уделять приоритетное внимание прозрачности, показывая этапы планирования. Другим важным фактором для агентов, использующих сложные инструменты (например, Azure CLI, GitHub), является создание тщательного интерфейса между агентом и компьютером (ACI) посредством документации и тестирования инструментов. Ваши агенты смогут использовать правильные инструменты для ваших задач, только если у них есть доступ к достаточной информации о них.
    • Пример:** AI-агент, который автономно пишет и тестирует код для исправления проблемы GitHub, проверенный автоматизированными тестами и проверкой человеком, как часть инициативы SWE-bench.

Дополнительные соображения

Хотя блок-схема и рекомендации обеспечивают четкий путь, это только отправная точка. Основная цель этой статьи – повысить осведомленность о том, что “бросаться AI-агентами во все” – нежизнеспособная стратегия – и предоставить отправную точку для принятия решений.

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

Обслуживание клиентов – отличный пример: оно часто требует задержки, близкой к реальному времени, и строгих мер защиты, поскольку это приложение, ориентированное на клиентов (и многие клиенты, обращающиеся в службу поддержки, уже не в лучшем настроении). Хотя AI-агенты обещают справляться с этим намного лучше, чем предыдущие технологии, требования к надежности и безопасности высоки. И вы уже можете создавать довольно продвинутые чат-боты с помощью рабочих процессов. Фактически, большинство чат-ботов, работающих в настоящее время в промышленной эксплуатации, имеют мало общего с агентным AI (даже если они утверждают обратное). Такие вещи, как инструменты для клиентских данных и истории заказов, гораздо важнее и могут быть реализованы как рабочие процессы для стандартных запросов. Прагматичным компромиссом может быть использование агентов для более неоднозначных запросов. Два подхода к проектированию не исключают друг друга, что является еще одним важным соображением. Используйте то, что лучше всего подходит для вашего варианта использования.

Заключение

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

 No comments   1 mo   AI   LLM

4 Лучшие альтернативы Docker Desktop в 2024 году

4 Лучшие альтернативы Docker Desktop в 2024 году

Перевод: https://www.qovery.com/blog/4-best-docker-desktop-alternatives/
Морган Перри
5 сентября 2024 г. · 4 мин чтения

Docker Desktop был основным инструментом для многих разработчиков, но с тех пор, как он представил свою платную версию для предприятий, многочисленные команды начали изучать альтернативы. Если вы ищете бесплатное решение или инструмент, адаптированный к различным рабочим нагрузкам, в 2024 году есть несколько конкурентоспособных вариантов.

#Что изменилось в Docker Desktop?

Теперь для профессионального использования в крупных компаниях и государственных организациях требуется платная подписка на Docker Desktop. Хотя он остается бесплатным для малого бизнеса, личного использования, а также образовательных или некоммерческих проектов с открытым исходным кодом, предприятиям необходимо выбирать подписку Docker Pro, Team или Business. Это изменение в лицензировании затронуло организации, которые ранее полагались на Docker Desktop, как на бесплатный инструмент, и подстегнуло поиск альтернатив, обеспечивающих аналогичную функциональность без затрат.

Теперь давайте рассмотрим четыре лучшие альтернативы Docker Desktop в 2024 году.

#1. Qovery

Лучше всего подходит для: оптимизации DevOps-процессов с использованием сред на основе Kubernetes.

Благодаря локальному режиму Qovery разработчики могут плавно тестировать и развертывать приложения на своей локальной машине, точно так же, как они это делали бы в продакшене. Qovery обеспечивает удобство для разработчиков, особенно благодаря мощному CLI, позволяющему создавать среды, отличные от продакшена, с помощью команды “qovery demo up”. Вы получаете локально работающие кластеры Kubernetes, использующие ту же инфраструктуру, которую вы использовали бы в облачных провайдерах, что делает его надежным и гибким инструментом для локальной разработки.

Qovery

Qovery: Ключевые особенности:

  • Бесплатно для индивидуальных разработчиков.
  • Упрощенное тестирование и развертывание сред Kubernetes локально.
  • Интеграция с Docker, Kubernetes и другими облачными инструментами.
  • Автоматизирует DevOps-процессы, снижая операционную сложность.
  • Быстрая настройка с помощью Qovery CLI (qovery demo up).

Локальный режим Qovery идеально подходит для тех, кто ищет единый опыт работы как в локальной, так и в производственной среде, и все это без дополнительных затрат для индивидуальных пользователей.

#2. Rancher Desktop

Лучше всего подходит для: Разработки, ориентированной на Kubernetes с легкой настройкой и кроссплатформенной поддержкой.

Rancher Desktop — это альтернатива с открытым исходным кодом, ориентированная на Kubernetes. Он позволяет разработчикам контейнеризировать приложения и запускать их в среде Kubernetes. Благодаря встроенному управлению контейнерами и надежной поддержке как Docker, так и containerd, Rancher Desktop обеспечивает гибкость и интеграцию с современными облачными инструментами.

Rancher Desktop

Ключевые особенности: Rancher Desktop

  • Встроенная поддержка Kubernetes.
  • Совместимость с Docker и containerd.
  • Мультиплатформенная поддержка (Windows, macOS, Linux).
  • Бесплатный и с открытым исходным кодом.

Rancher Desktop идеально подходит для команд, ориентированных на Kubernetes, которым требуется простое, масштабируемое решение без необходимости в корпоративных предложениях Docker.

#3. Podman Desktop

Лучше всего подходит для: Разработчиков, которым нужен Docker-совместимый, но бездемонизированный опыт.

Podman Desktop предлагает безопасную, Docker-совместимую альтернативу без необходимости в работающем демоне, что делает его по своей природе более легким и безопасным. Podman также отличается легкой интеграцией с Kubernetes, что делает его подходящим вариантом для разработчиков, стремящихся к прямому, бездемонизированному подходу к управлению контейнерами.

Ключевые особенности: Podman

  • Docker-совместимый без работающего демона.
  • Акцент на безопасности (контейнеры с rootless правами).
  • Простая интеграция с Kubernetes.
  • Открытый исходный код и бесплатный.

Podman Desktop высоко ценится командами, заботящимися о безопасности, которые хотят получить привычный Docker без необходимости управлять фоновым демоном.

#4. OrbStack

Лучше всего подходит для: Легкой и быстрой альтернативы Docker Desktop для пользователей macOS.

OrbStack разработан специально для пользователей macOS и ориентирован на скорость и простоту. Он предлагает быструю оркестровку контейнеров с минимальным использованием ресурсов, что делает его отличным выбором для разработчиков, работающих с macOS, которым нужна легкая альтернатива Docker Desktop.

OrbStack

Ключевые особенности: OrbStack

  • Чрезвычайно легкий и быстрый.
  • Оптимизирован для macOS.
  • Простой интерфейс с совместимостью с Docker.
  • Низкое потребление ресурсов.

OrbStack идеально подходит для пользователей macOS, ищущих легкую, быструю и эффективную альтернативу Docker.

#Выбор правильной альтернативы Docker Desktop

При выборе альтернативы Docker Desktop учитывайте следующие факторы:

  • Тип рабочей нагрузки: Вы ориентированы на Kubernetes, Docker или на их сочетание?
  • Системные ресурсы: Вам нужно легкое решение или вам подходят более тяжелые инструменты?
  • Платформа: Некоторые инструменты, такие как OrbStack, предназначены только для macOS, в то время как другие, такие как Rancher Desktop, являются кроссплатформенными.
  • Стоимость: Если вы индивидуальный разработчик, такие инструменты, как локальный режим Qovery или Podman Desktop, могут быть идеальными, поскольку они бесплатны.

Оцените эти варианты на основе ваших конкретных потребностей в разработке и эксплуатации и выберите инструмент, который лучше всего соответствует вашему рабочему процессу.

#Заключение

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

Однако, если вы ищете решение, которое выходит за рамки простого управления контейнерами, попробуйте Qovery!!t. Qovery не только оптимизирует развертывание и управление облачными приложениями, но и автоматизирует многие задачи DevOps, позволяя вам сосредоточиться на разработке, а не на инфраструктуре.

Попробовал OrbStack, для Mac OS действительно хорошо. Но для удобства можно Podman поставить, он все таки кроссплатформенный.

И конечно я запускал https://www.openeuler.org/en/wiki/install/macos/ и Trino. :)

openEuler — это не просто ОС, это платформа для создания различных ОС

Перевод: https://news.itsfoss.com/keith-chan-openeuler-summit/

openEuler — это не просто ОС, это платформа для создания различных ОС
Директор CNCF в Китае, Кит Чан, делится своим мнением о росте openEuler в области Cloud Native.
Абхишек

Подробнее тут: https://www.openeuler.org/en/
еще больше тут: https://www.openeuler.org/whitepaper/en/openEuler%20OS%20Technical%20Whitepaper_Innovation%20Projects_EN.pdf

Поскольку It’s FOSS внимательно следил за недавно завершившимся саммитом openEuler, мы представляем несколько бесед, которые проливают свет на openEuler и его вклад в open source.

Это третье из четырех интервью, подготовленных при поддержке openEuler. Четвертое интервью только в видео формате.

Кит Чан — директор по стратегическому планированию Linux Foundation APAC, директор CNCF в Китае и директор Hyperledger в Китае. Он делится своим мнением на недавно завершившемся саммите openEuler 2024.

В: В чем уникальная ценность openEuler в Cloud Native?

Прежде всего, поздравляю openEuler с тем, что экосистема становится все больше и больше. Мы говорим о Cloud Native уже около трех лет. Сочетание CNCF, Kubernetes и openEuler расширит возможности в различных областях благодаря встроенной поддержке openEuler в Kubernetes. Кроме того, он интегрируется со многими различными сценариями, такими как AI, Edge, Cloud, IoT. Они расширяют целую экосистему для Cloud Native разработчиков, поэтому, представьте, например, в AI, если я Cloud Native разработчик, я фактически развертываю PyTorch в различных сценариях. Встроенная поддержка PyTorch меня очень радует. В противном случае, если бы я настраивал PyTorch или Tensorflow, мне пришлось бы делать это самостоятельно. Поэтому использование openEuler и Kubernetes вместе намного лучше и проще для меня.

Q. openEuler интегрировался с CI/CD от CNCF, чтобы предложить встроенную верификацию, и уже подключены два проекта. Есть ли дальнейшие планы по этому сотрудничеству?

Это действительно очень интересно, потому что, когда мы говорим о CI/CD openEuler и проектах CNCF, это действительно хорошо. Это выдающаяся новость для Cloud Native разработчиков, потому что это предоставит им множество различных вариантов ОС. Кроме того, необходимость поддержки openEuler на различных архитектурах упрощает Cloud Native разработчикам использование различных вычислительных ресурсов. Это действительно важно для Cloud Native разработчиков. Это расширяет возможности, потому что сейчас (openEuler) доступен от различных поставщиков облачных услуг, поэтому вам очень легко загрузить эти (архитектурные) версии. Я думаю, что это действительно здорово, и мы очень рады видеть, что это происходит.

Q. По сравнению с прошлым годом, openEuler в этом году выпустила две версии, 24.03 и 24.09. Что вы считаете самым большим достижением и инновацией в openEuler в этом году?

В последней версии много хороших разработок. Например, улучшение производительности, масштабируемости, но самое главное — это AI Native OS. Это то, что ищет рынок, то, что ищет разработчик. Как я уже упоминал выше в примере, если я хочу развернуть PyTorch, потому что сейчас более 80% LLM используют PyTorch, в этом случае встроенная поддержка PyTorch в openEuler делает задачу намного проще. Таким образом, 8 AI Native OS — это действительно здорово, и я думаю, что это поможет многим компаниям, даже в разных отраслях, и облегчит им развертывание AI.

Q. Каков ваш взгляд на перспективы глобального развития openEuler? Каковы его основные конкурентные преимущества и ценность в его глобализации?

Мы много сотрудничаем в различных сценариях. Например, openEuler выступила с основным докладом на Open Source Summit Europe и рассказала об AI Cloud Native OS. Я думаю, что нам следует расширять сотрудничество и говорить о том, как дать возможность Cloud Native разработчикам и разработчикам по всему миру понять, что такое openEuler. Потому что openEuler — это не просто ОС, это платформа ОС для создания различных ОС. Я только что упомянул, что вы можете создать ОС для таких областей, как Cloud, AI, Edge, IoT и т. д. Я думаю, что openEuler готов к сотрудничеству с глобальными разработчиками, чтобы иметь больше участников по всему миру. Мы действительно ожидаем большего сотрудничества с openEuler. Таким образом, openEuler – это новая опция ОС для мира. Очень рад видеть 5-летний юбилей openEuler. Поздравляем!

ПС:
Его российская локализация: https://openscaler.ru
а тут подробно есть: https://openscaler.ru/wp-content/uploads/2023/06/Lichi_A4_44.pdf

Сбер, Личи-тех и Скала-Р активно участвуют в его развитии в России

А тут можно еще глубже поизучать как в целом жить с open source: https://stepik.org/course/212389/promo

Расцвет одноузловой обработки: Бросая вызов подходу – распределённое решение в первую очередь

Введение

В 2024 году наблюдается растущий интерес к одноузловым системам обработки данных. Инструменты вроде DuckDB, Apache DataFusion и Polars привлекли внимание сообщества и стали невероятно популярными. Этот тренд — не просто технологический прогресс, а переосмысление подходов к аналитике данных.

По мере отказа от парадигмы «распределённые системы прежде всего», доминировавшей в эпоху «больших данных», компании обнаруживают, что одноузловые решения часто эффективнее, экономичнее и проще в управлении, особенно при работе с данными умеренного объёма.

Недавний пост «Почему одноузловые системы набирают обороты в обработке данных» в LinkedIn вызвал неожиданно живой отклик сообщества, что подчеркнуло возросший интерес к теме. В этой статье мы рассмотрим её подробнее.

---

Переосмысление «больших данных»

Последнее десятилетие компании активно внедряли стратегии big data, инвестируя в распределённые системы вроде Hadoop и Spark. Однако исследования показывают, что большинству компаний «большие данные» не нужны.

Итоги анализа:

  • Jordan Tigani (основатель Google BigQuery): медианный объём данных у активных пользователей BigQuery — менее 100 ГБ.
  • Исследование 500 млн запросов Amazon Redshift:
    • 99% обрабатывали менее 10 ТБ данных;
    • 90% сессий работали с менее чем 1 ТБ;
    • 98% таблиц содержат меньше миллиарда строк.

Вывод: Для 90% запросов достаточно одноузловых систем вместо распределённых (Spark, Trino, Athena).

---

Паттерны рабочих нагрузок и старение данных

1. Эффект старения данных
Доступ к данным резко сокращается со временем:

  • Горячие данные (0–48 часов): обработка ETL-пайплайнами.
  • Тёплые данные (2–30 дней): основа аналитических запросов.
  • Холодные данные (30+ дней): редко запрашиваются (сохранены для истории или аудита).

Исследование Meta и eBay подтверждает: 95% обращений к данным происходят в первые 48 часов. В «золотой» аналитической зоне 95% запросов выполняются в течение 30 дней.

2. Правило 90/10
90% рабочих нагрузок приходится на 10% данных (за 30 дней). Даже при хранении данных год, аналитики в основном работают с последними 30 днями.

---

Эволюция оборудования: масштабирование вверх вместо распределения

Рост возможностей одноузловых систем:

  • В 2006 году (эпоха Hadoop) серверы имели 1 CPU и 2 ГБ RAM.
  • Сегодня облачные инстансы (например, AWS EC2) предлагают 64+ ядер и 256+ ГБ RAM.

Экономика масштабирования:

  • Стоимость крупных инстансов (например, m5.16xlarge) сопоставима с расходами на несколько мелких узлов (например, 8 × m5.2xlarge) при одинаковой мощности.

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

---

Производительность одноузловых систем
DuckDB, Apache DataFusion и другие движки используют:

  • Векторизованное выполнение запросов;
  • Параллелизм;
  • Оптимизацию использования памяти.

Примеры роста скорости:

  • Переход с Postgres на DuckDB дал ускорение в 4–200 раз (Vantage).
  • DuckDB превзошёл коммерческие хранилища на TPC-DS до 300 ГБ (Fivetran).

---

Причины выбрать одноузловую обработку

  1. Простота: Меньше сложности, чем в распределённых системах.
  2. Эффективность: Реализация до 80% кода на C/C++ (против 10% в распределённых движках).
  3. Совместимость: Интеграция с облачными хранилищами, языками программирования, BI-инструментами.

---

Ограничения

  • Не все движки эффективно используют многоядерные CPU.
  • Пропускная способность RAM/CPU может стать узким местом.
  • Очень большие наборы данных (>1 ТБ) всё ещё требуют распределения.

---

Заключение
Одноузловая обработка — прагматичный ответ на реальные потребности бизнеса. С развитием оборудования и оптимизацией движков необходимость в распределённых системах будет снижаться.

Главный вывод: Выбирайте инструмент под конкретную задачу, а не следуйте трендам. Будущее — за балансом между мощью одноузловых систем и гибкостью распределённых решений.

---

Полный дословный перевод:

Введение

В 2024 году наблюдался растущий интерес к фреймворкам одноузловой обработки, при этом такие инструменты, как DuckDB, Apache DataFusion и Polars, привлекли повышенное внимание и завоевали беспрецедентную популярность в сообществе специалистов по данным.

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

По мере того, как мы отходим от подхода “распределённое решение в первую очередь” эпохи “больших данных”, многие предприятия обнаруживают, что решения одноузловой обработки зачастую обеспечивают более эффективный, экономичный и управляемый подход к своим аналитическим потребностям, когда размер их данных не так велик.

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

В этой статье я углублюсь в эту тему, изучив её более детально и предоставив дополнительные сведения.

Переосмысление больших данных

Последнее десятилетие многие предприятия изо всех сил пытались внедрить стратегии больших данных, при этом многие компании вкладывали значительные средства в фреймворки распределенной обработки, такие как Hadoop и Spark.

Однако недавние анализы выявили удивительную правду: у большинства компаний на самом деле нет “больших данных”.

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

Джордан Тигани, один из инженеров-основателей Google BigQuery, проанализировал шаблоны использования и обнаружил, что медианный размер хранилища данных среди активных пользователей BigQuery составляет менее 100 ГБ.

Ещё более показательным является анализ полумиллиарда запросов, выполненных в Amazon Redshift и опубликованных в статье:

  • Более 99% запросов обработали менее 10 ТБ данных.
  • Более 90% сеансов обработали менее 1 ТБ.

В статье также говорится, что:

  • Большинство таблиц содержит менее миллиона строк, и подавляющее большинство (98%) — менее миллиарда строк. Большая часть этих данных достаточно мала, чтобы её можно было кэшировать или реплицировать.

Этот анализ показывает, что при пороговом значении для больших данных в 1 ТБ более 90% запросов находятся ниже этого порога.

В результате, одноузловые движки обработки потенциально способны обрабатывать рабочие нагрузки, которые ранее требовали распределенных систем, таких как Spark, Trino или Amazon Athena, для обработки на нескольких машинах.

Эта реальность ставит под сомнение распространенное представление о том, что инфраструктура больших данных является необходимостью для всех современных предприятий.

Шаблоны рабочей нагрузки и быстрое устаревание данных

Аргументы в пользу одноузловой обработки становятся ещё более убедительными, когда мы изучаем, как организации в действительности используют свои данные.

Выявляются два ключевых шаблона: эффект устаревания данных и правило 90/10 для аналитических рабочих нагрузок.

Эффект устаревания данных

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

  • Активные данные (0-48 часов): в основном из конвейеров ETL.
  • Теплые данные (2-30 дней): составляют большую часть аналитических запросов.
  • Холодные данные (30+ дней): редко используются, но часто хранятся для соответствия требованиям или исторического анализа.

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

В нашем анализе озера данных петабайтного масштаба мы обнаружили, что необработанные данные остаются активными только в течение 48 часов, причем 95% доступа приходится на это время, в основном со стороны нисходящих конвейеров ETL. В зоне Analytics (Gold) активный период длится около 7 дней, и 95% запросов выполняются только в течение 30 дней.

Правило 90/10 для аналитических рабочих нагрузок

Этот эффект устаревания приводит к правилу 90/10 в аналитических рабочих нагрузках:

  • Если общий активный и теплый период составляет 30 дней и приходится на 90% рабочих нагрузок, то, при годовом сроке хранения, более 90% рабочих нагрузок получают доступ менее чем к 10% данных.

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

Эволюция оборудования и переосмысление масштабирования вверх

Возможности одноузловых систем экспоненциально выросли со времен зарождения больших данных.

Обоснование и мотивация стратегии масштабирования по горизонтали (scale-out), которая стала популярной с появлением Hadoop в середине 2000-х годов в области обработки данных, заключаются в необходимости объединения нескольких машин для решения проблем масштабирования, что позволяет эффективно обрабатывать большие наборы данных в разумные сроки и с приемлемым уровнем производительности.

Интегрируя несколько машин в распределенные системы, мы фактически создаем единый большой блок, объединяя ресурсы, такие как ОЗУ, ЦП, дисковое пространство и пропускную способность, в одну большую виртуальную машину.

Однако нам необходимо переоценить наши предположения о распределенной обработке и проблемах масштабирования, с которыми мы столкнулись в 2000-х годах, чтобы увидеть, остаются ли они актуальными сегодня.

В 2006 году, когда появился Hadoop MapReduce, первые инстансы AWS EC2 (m1.small) имели всего 1 ЦП и менее 2 ГБ ОЗУ. Сегодня облачные провайдеры предлагают инстансы с 64+ ядрами и 256 ГБ+ ОЗУ, что кардинально меняет ситуацию с возможностями одноузловой обработки.

Изучение эволюции сбалансированных инстансов EC2 с точки зрения памяти и ЦП (с соотношением 1:4) на протяжении многих лет выявляет экспоненциальный рост, поскольку эти инстансы со временем становятся все более мощными.

Экономика масштабирования вверх (Scale-Up) против масштабирования по горизонтали (Scale-Out)

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

Стоимость за вычислительную единицу в облаке является постоянной, независимо от того, используете ли вы меньший или больший инстанс, поскольку стоимость увеличивается линейно.

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

Используя семейство инстансов m5 от AWS в качестве примера, независимо от того, масштабируетесь ли вы вверх с помощью одного инстанса m5.16xlarge или масштабируетесь по горизонтали с помощью восьми инстансов m5.2xlarge, цена за час останется той же.

Эта эволюция оборудования имеет важные последствия для решений по архитектуре системы, поскольку:

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

Это поднимает критический вопрос:

  • С точки зрения соотношения цены и производительности, если одноузловой движок запросов может эффективно обрабатывать большинство рабочих нагрузок, есть ли еще выгода от распределения обработки по нескольким узлам?

Аргумент производительности для одноузловой обработки

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

Движки, такие как DuckDB и Apache DataFusion, достигают превосходной производительности благодаря сложным методам оптимизации, включая векторизованное выполнение, параллельную обработку и эффективное управление памятью.

Многочисленные тесты показывают эти улучшения производительности:

  • Vantage сообщила, что при переходе с Postgres на DuckDB для анализа затрат на облако они увидели улучшение производительности в диапазоне от 4X до 200X.
  • Тесты генерального директора Fivetran с использованием наборов данных TPC-DS показали, что DuckDB превосходит коммерческие хранилища данных для наборов данных размером менее 300 ГБ.
  • Эксперимент с 1 миллиардом строк поддельных данных о заказах, сравнивающий DuckDB с Amazon Athena.

Почему стоит выбрать одноузловую обработку?

Аргументы в пользу одноузловой обработки выходят за рамки простой производительности. Для большинства предприятий современные одноузловые движки предлагают несколько веских преимуществ:

  • Они значительно упрощают архитектуру системы, устраняя сложность распределенных систем. Это упрощение снижает эксплуатационные расходы, облегчает отладку и снижает порог входа для команд, работающих с данными.
  • Они часто обеспечивают лучшее использование ресурсов. Без накладных расходов на сетевую связь и распределенную координацию больше вычислительной мощности можно выделить для фактической обработки данных. Эта эффективность напрямую приводит к экономии затрат и повышению производительности.
  • Они предлагают отличную интеграцию с современными рабочими процессами обработки данных. Такие движки, как chDB и DuckDB, могут напрямую запрашивать данные из облачного хранилища, бесперебойно работать с популярными языками программирования и органично вписываться в существующие конвейеры обработки данных.
  • Встраиваемая природа некоторых из этих движков обеспечивает бесшовную интеграцию с существующими системами — от расширений PostgreSQL, таких как pg_analytics и pg_duckdb, до различных современных инструментов Business Intelligence — расширяя аналитические возможности без нарушения установленных рабочих процессов.

Проблемы и ограничения

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

  • Некоторые движки по-прежнему сталкиваются с проблемами полного использования всех доступных ядер ЦП на больших машинах, особенно по мере увеличения количества ядер. Пропускная способность иерархии памяти между ОЗУ и ЦП может стать узким местом для определенных рабочих нагрузок.
  • При чтении из облачного хранилища, такого как S3, скорость передачи данных через одно соединение может быть ограничена, хотя это часто можно смягчить с помощью параллельных соединений и интеллектуальных стратегий кэширования. И, естественно, остаются рабочие нагрузки, включающие очень большие наборы данных, которые превышают доступную память и хранилище, требующие распределенной обработки.

Заключение

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

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

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

Спасибо автору ALIREZA SADEGHI и оригиналу: https://www.pracdata.io/p/the-rise-of-single-node-processing

DeepSeek R1 × SeaTunnel: интеграция данных следующего поколения

перевод: DeepSeek R1 × SeaTunnel: Лидерство в революции интеллектуальной интеграции данных следующего поколения

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

Apache SeaTunnel — проект с открытым исходным кодом для интеграции данных, созданный в Китае и разрабатываемый в рамках глобального сотрудничества, — становится основным движком интеллектуальной обработки данных. Благодаря встроенной интеграции с LLM, прорывным возможностям работы с векторными данными и бесшовной интеграции с более чем 100 источниками данных, он переосмысливает возможности управления корпоративными данными.

Выпуск 2.3.7 стал поворотным моментом благодаря глубокой интеграции технологии DeepSeek LLM, возвестив эру обработки данных «под управлением LLM».

Почему SeaTunnel доминирует в интеграции данных в эпоху LLM?

Традиционные инструменты ETL сталкиваются с тремя критическими проблемами в эпоху LLM:

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

SeaTunnel преодолевает эти барьеры благодаря трем революционным возможностям:

···

  1. Встроенная интеграция LLM

Усиление конвейеров данных, управляемых моделями
Модуль преобразования SeaTunnel теперь изначально интегрирован с DeepSeek и другими LLM, что позволяет напрямую вызывать модели для:

  • Очистки текста и семантического улучшения
  • Распознавания намерений
  • Динамического создания правил

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

···

  1. Векторный движок

Соединение LLM и хранилищ данных
Начиная с версии 2.3.6, SeaTunnel стал пионером в поддержке векторных баз данных (Milvus и др.), а версия 2.3.7 обеспечивает трехкратное повышение производительности обработки векторов.

Пример использования в бизнесе:
Платформы электронной коммерции теперь могут:

  • Реализовывать поиск изображений по сходству с помощью векторных вложений
  • Оптимизировать алгоритмы рекомендаций посредством семантического векторного анализа отзывов пользователей
  • Создавать комплексные конвейеры ИИ, соединяющие исходные медиафайлы с платформами обучения моделей

···

  1. Мастерство работы с неструктурированными данными

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

···
Достижение экспоненциальной ценности: LLM + интеграция данных

Интеллект в реальном времени
На базе движка SeaTunnel Zeta:

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

Экосистема из более чем 160 коннекторов
Готовая интеграция с:

  • Традиционными базами данных (MySQL, Oracle)
  • Облачными платформами (S3, BigQuery)
  • Сервисами SaaS (Salesforce, Zendesk)
  • Платформами LLM (OpenAI, DeepSeek)

Встроенные возможности ИИ
Текущая версия 2.3.7 уже поддерживает:

  • Преобразование LLM
  • Операции встраивания

Запланированные функции:

  • Поддержка пользовательских функций Python
  • Усовершенствованные операторы для неструктурированных данных

···
DeepSeek + SeaTunnel: Реальное влияние

Схема внедрения в организациях

  • Автоматическая маркировка данных
    Классификация отзывов о продуктах по категориям «Качество», «Доставка», «Обслуживание»
  • Семантический механизм рекомендаций
    Сопоставление продуктов с использованием вложений поисковых запросов
  • Автоматизация AI-Ops
    Создание диагностических отчетов из системных журналов (на 70% быстрее MTTR)
  • Анализ настроений
    Количественная оценка моделей жалоб клиентов в чатах поддержки
  • Мультимодальная обработка
    Извлечение ключевой информации из PDF-файлов/изображений посредством интеграции двоичных потоков

···
Дорожная карта: Где LLM встречается с инженерией данных

Амбициозная повестка дня сообщества включает:
🔮 Расширение векторной базы данных — интеграция с Pinecone
🤖 Автоматическая генерация ETL — создание правил на основе DeepSeek
🖥️ Бескодовая конфигурация LLM — визуальный конструктор конвейеров
🎓 Обучение пользовательских моделей — интегрированная платформа RLHF

···
SeaTunnel, самый быстрорастущий проект интеграции данных (более 8,3 тыс. звезд на GitHub), предлагает :

Делиться вариантами использования (WeChat: 18819063834) для отраслевых решений

···
Новая граница данных

В этом слиянии LLM и инженерии данных Apache SeaTunnel переосмысливает парадигмы интеграции. Будь то упрощение внедрения ИИ или ускорение трансформации предприятия, он становится швейцарским ножом для интеллектуальных конвейеров данных.

Earlier Ctrl + ↓