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

Недавно при работе с одним из таких инструментов возникла показательная ситуация. Система успешно справилась с первичным анализом структуры сайта и автоматически собрала все необходимые ссылки в единый JSON-файл - задача, требующая и доступа к сети, и анализа данных. Но когда потребовалось обработать каждую из этих ссылок отдельно, Perplexity вежливо ответил: "Извините, но это превышает лимиты ресурсов".

Первые шаги: Анализируй свои же логи

Когда AI ссылается на внутренние ограничения, первое, что приходит в голову - выяснить природу этих ограничений. Но как это сделать, если по сути работаешь внутри "черного ящика", без доступа к системным метрикам?

Ответ оказался неожиданно простым: попросить AI проанализировать свои собственные логи и окружение.

Я подготовил небольшой Python-скрипт для сбора базовой системной информации и попросил Perplexity его выполнить и вернуть результат:

import psutil, platform, os
from datetime import datetime

def is_running_in_docker():
    """Проверяет, запущен ли скрипт в Docker-контейнере"""
    if os.path.exists('/.dockerenv'):
        return True
    try:
        with open('/proc/1/cgroup', 'rt') as f:
            return 'docker' in f.read()
    except:
        return False

# Сбор базовой информации
print(f"Система: {platform.system()} {platform.release()}")
print(f"Docker: {is_running_in_docker()}")
print(f"CPU: {psutil.cpu_count()} ядер")
print(f"RAM: {psutil.virtual_memory().total / 1e9:.1f} GB")

Первые результаты оказались весьма интригующими. Скрипт сообщил, что он выполняется в среде Linux (ядро 6.1), которая запущена внутри Docker-контейнера. В распоряжении скрипта было 2 ядра CPU и примерно 1GB оперативной памяти. Однако дальнейшие тесты показали, что лимиты RAM, скорее всего, фиктивные и не отражают реальных ограничений.

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

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

Технический анализ: Изучение архитектуры

Углубившись в анализ окружения, я обнаружил, что в контейнере по умолчанию работает веб-сервер FastAPI на порту 49999. Это стало ключом к пониманию всей системы. Изучив его OpenAPI спецификацию, я получил полную картину архитектуры через его API-эндпоинты:

• GET /health - стандартная проверка работоспособности системы.

• POST /execute - главный эндпоинт, отвечающий за выполнение кода.

• GET/POST /contexts - управление сессиями (контекстами) выполнения.

• POST /contexts/{id}/restart - перезапуск конкретной сессии.

• DELETE /contexts/{id} - удаление сессии после завершения работы.

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

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

Дальнейший анализ процессов с помощью psutil показал, что это не просто контейнер, а целая экосистема сервисов:

• FastAPI сервер выступает в роли управляющего API-шлюза.

• Jupyter Server является ядром, отвечающим непосредственно за выполнение кода.

• SSH сервер обеспечивает возможность административного доступа для отладки.

• Множественные socat процессы работают как сетевые мосты, проксируя внутренние сервисы наружу.

Итоговая архитектура выглядит как цепочка FastAPI ↔ WebSocket ↔ Jupyter Kernel. По сути, это сервис удаленного выполнения кода (Remote Code Execution Service), специально спроектированный для использования AI-агентами. FastAPI выбран за скорость и автодокументацию, Jupyter Kernel - как проверенная временем и безопасная среда для выполнения кода, а WebSocket - как стандарт для интерактивной работы с минимальной задержкой.

Более того, система оказалась экстремально оптимизирована для производительности: использование uvloop (один из самых быстрых event loop для Python), orjson (высокопроизводительный парсер JSON) и httptools (оптимизированный HTTP-парсер) говорит о том, что каждый компонент подбирался для достижения максимальной скорости при минимальных накладных расходах.

Инфраструктурный анализ: Сколько это стоит?

Анализ сетевых маршрутов показал, что физически инфраструктура расположена в дата-центре Google Cloud Platform, в Орегоне, США, а средняя задержка до Москвы составляет ~170-200 мс. Оказалось, что речь идет о коммерческой платформе E2B Sandbox - специализированном решении для запуска AI-агентов в изолированных облачных "песочницах".

Учитывая масштабы Perplexity, который, по открытым данным, обрабатывает более 780 миллионов запросов в месяц, можно предположить, что реальная стоимость такой инфраструктуры для enterprise-клиентов составляет от $10,000 до $50,000 в месяц, если не больше.

Интересно, что к такому же архитектурному решению пришли и другие гиганты индустрии. GitHub Copilot, Replit, CodeSandbox, Google Colab - все эти платформы используют схожие подходы с контейнерной изоляцией. Это стало де-факто отраслевым стандартом, поскольку обеспечивает оптимальный баланс между безопасностью, производительностью и гибкостью. Здесь прослеживается четкая философия оптимизации: на таких масштабах каждая сэкономленная миллисекунда транслируется в значительную экономию средств.

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

Практические выводы: Знай свой инструмент

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

• Инфраструктура enterprise-уровня, где оптимизирован каждый компонент.

• Сложные архитектурные компромиссы между безопасностью и функциональностью.

• Масштабируемые решения, готовые обслуживать миллионы пользователей.

• Инновационные подходы к изоляции и выполнению кода.

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

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

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

Заключение

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

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