Метаданные пакетов Conda и PyPI тормозят установку: в чём проблема масштабирования и как её решить

Ты ждёшь 15 минут, а Conda всё ещё "решает зависимости"

Знакомо? Запускаешь conda install pytorch и идёшь пить кофе. Возвращаешься - а он всё ещё качает какой-то repodata.json. В 2026 году это выглядит как архаизм. Особенно когда работаешь с ML-песочницами на k8s, где каждая минута сборки стоит денег.

Архитектурный тупик: почему всё так плохо

Проблема не в том, что разработчики Conda и PyPI ленивые. Проблема в фундаментальном несоответствии между архитектурой 2010-х годов и масштабами экосистемы 2026 года.

Монолитные индексы в распределённом мире

И Conda, и PyPI используют подход "один большой файл со всеми метаданными". В 2015 году, когда в PyPI было 60 тысяч пакетов, это работало. В 2026 году - 450 тысяч пакетов только в PyPI, плюс conda-forge с бинарниками для 15 архитектур и 8 версий Python.

Но загрузка - это только начало. Дальше начинается парсинг. Conda загружает весь JSON в память и строит гигантский граф зависимостей. Для 312 МБ JSON это примерно 2-3 ГБ оперативной памяти и 30-45 секунд чистого CPU времени.

Что внутри этого монстра?

Открой repodata.json (если хватит терпения):

{
  "packages": {
    "pytorch-2.4.0-cuda12.1_py310h12345678_0.tar.bz2": {
      "build": "cuda12.1_py310h12345678_0",
      "build_number": 0,
      "depends": [
        "python >=3.10,<3.11.0a0",
        "cudatoolkit >=12.1,<12.2",
        "ninja",
        "... ещё 15 зависимостей"
      ],
      "license": "BSD-3",
      "license_family": "BSD",
      "md5": "abc123...",
      "name": "pytorch",
      "sha256": "def456...",
      "size": 987654321,
      "subdir": "linux-64",
      "timestamp": 1737763200000,
      "version": "2.4.0"
    },
    "... и так для 250,000 пакетов"
  }
}

Видишь проблему? Для установки pytorch тебе нужны метаданные только pytorch и его зависимостей. Но Conda качает метаданные ВСЕХ 250 тысяч пакетов. Это как зайти в библиотеку за одной книгой, а тебе выдают каталог всех книг на всех языках.

Почему это особенно больно для ML/AI

В машинном обучении зависимости - это ад. PyTorch зависит от CUDA, CUDA зависит от драйверов, драйверы зависят от ядра... Когда ты пытаешься заставить работать RTX 5090 с последними моделями, каждая минута установки превращается в час отладки.

А теперь представь, что ты делаешь распределённое обучение Llama 3.2 на 8 GPU. Тебе нужно поднять 10 контейнеров. Каждый качает по 300 МБ метаданных. Это 3 ГБ трафика и 30 минут чистого ожидания, прежде чем начнётся реальная работа.

Как это исправить: от костылей до архитектурных решений

1 Используй локальные зеркала (но это не панацея)

Самый очевидный совет, который дают все: "поставь Artifactory / devpi / conda-mirror". Да, это ускорит загрузку в локальной сети. Но не решит проблему парсинга 300 МБ JSON.

# Типичная настройка зеркала conda
conda-mirror --upstream-channel conda-forge \
             --target-directory /mnt/conda_mirror \
             --platform linux-64 \
             --num-threads 20

Проблема: теперь ты должен синхронизировать 300+ ГБ данных ежедневно. И поддерживать это хозяйство. И объяснять коллегам, почему их пакет появится только через 6 часов после публикации.

2 Кэшируй агрессивно (особенно в CI/CD)

Если используешь GitHub Actions, GitLab CI или Jenkins:

# .github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Cache conda packages
      uses: actions/cache@v4
      with:
        path: ~/conda_pkgs_dir
        key: conda-${{ runner.os }}-${{ hashFiles('environment.yml') }}
    
    - name: Cache conda repodata
      uses: actions/cache@v4
      with:
        path: ~/.conda/pkgs/cache
        key: conda-repodata-${{ runner.os }}-${{ hashFiles('environment.yml') }}

Важный нюанс: кэш repodata работает только если не менялись версии Python или не добавлялись новые каналы. На практике это срабатывает в 70% случаев.

3 Переходи на mamba или pixi (серьёзно)

Mamba - это форк Conda на Rust, который решает зависимости в 10-50 раз быстрее. Не магия, просто нормальная архитектура:

• Загружает только сжатые индексы (repodata.json.zst вместо .json)
• Использует многопоточный парсинг
• Имеет кэш зависимостей на диске
• Поддерживает все команды Conda

# Установка mamba
conda install mamba -n base -c conda-forge

# Использование вместо conda
mamba install pytorch torchvision torchaudio -c pytorch -c nvidia

Pixi - это новый игрок от prefix.dev. Он вообще не использует монолитные индексы. Вместо этого - GraphQL API, который запрашивает только нужные метаданные.

4 Используй Docker-образы с предустановленными пакетами

Для продакшена, особенно когда работаешь с тяжёлыми моделями типа GigaChat 3, лучший вариант - готовые образы.

# Вместо этого:
FROM python:3.10
RUN pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Используй это:
FROM pytorch/pytorch:2.4.0-cuda12.1-cudnn8-runtime
# Все зависимости уже установлены

NVIDIA, PyTorch, TensorFlow - все поддерживают официальные Docker-образы. Экономь 30 минут на сборке.

А что с PyPI? Там ведь тоже проблемы

PyPI использует "simple index" - гигантские HTML-страницы со ссылками на все версии пакета. Для pip это выглядит так:

# Что делает pip при установке:
1. Качает https://pypi.org/simple/numpy/ (500 КБ HTML)
2. Парсит все ссылки (100+ версий numpy)
3. Для каждой версии проверяет метаданные
4. Повторяет для каждой зависимости

Решение? Используй pip install --use-deprecated=legacy-resolver для простых случаев (быстрее, но может сломать сложные зависимости). Или переходи на uv - новый пакетный менеджер от Astral (создателей Ruff), который в 100 раз быстрее pip.

# Установка uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# Использование
uv pip install torch transformers datasets

Будущее: что изменится к 2027 году

Сообщество понимает проблему. На 25.01.2026 уже есть работающие решения:

1. Conda 24.11+ поддерживает инкрементальные обновления индекса (только дельта изменений)
2. PyPI Warehouse тестирует GraphQL API (как у pixi)
3. OSTree для пакетов - экспериментальная технология от Red Hat, где пакеты хранятся как git-репозиторий
4. Content-addressable storage - как в Docker, где каждый пакет идентифицируется хешем

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

Чеклист для немедленного применения

• Замени conda на mamba для установки пакетов (но оставь conda для управления окружениями)
• В CI/CD кэшируй ~/.conda/pkgs/cache и ~/conda_pkgs_dir
• Используй официальные Docker-образы для тяжёлых зависимостей (PyTorch, TensorFlow, CUDA)
• Для чистого Python попробуй uv вместо pip
• Разделяй environment.yml на базовые зависимости и development-зависимости
• Если делаешь свой пакет, указывай точные версии зависимостей (не >=, а ==)

Ошибки, которые совершают все (и ты тоже)

Самая большая ирония? Пока мы ждём, когда Conda скачает метаданные о пакетах для ускорения вычислений, мы теряем время, которое могли бы потратить на вычисления. Особенно смешно это выглядит в эпоху, когда Ray позволяет распределять вычисления на сотни ядер, но установить его - квест на полчаса.

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