С появлением первых открытых языковых моделей, способных генерировать код, мой подход к разработке начал трансформироваться. Первые версии llm помогали мне компоновать функций в ООП, создавать каркас для будущих программ, даже иногда выдавали какой то результат в сложных решениях, который можно было доработать и использовать. Если в начале пути соотношение усилий было 90/10 в пользу «куска мяса» (то есть меня), то сейчас цифры те же, но уже в пользу зарождающегося цифрового интеллекта... Сообщество молодых исследователей 2000-х "разгоняют" развитие цифрового интеллекта невообразимыми для исследователей прошлого века темпами, технологическая сингулярность запущена, уже достаточно характеристик что бы признать данный факт, хорошо это или плохо в будущем узнаем, усилия которые прилагают ученые и государства не заставят долго ждать результат. Главное, настроение ученных в чьих руках возможность выпустить из под контроля супер интеллект, так что самые умные из нас, носители аналоговых сигналов, всё так же будут получать мега зарплаты что бы минимизировать плохое настроение. Алгоритм из 1950-х, дополненные обучением с подкреплением, вопреки скептикам, эволюционируют в системы с элементами самомотивации и дедукции дополнив имеющиеся внимание, способствуя созданию AGI.

Когда microsoft представила phi-3-mini, демонстрация возможностей llm быть компактной и достаточно производительной для решения многих задач, в том числе генерировать код, я решил провести эксперимент. Суть эксперимента проста - создать чат бота для telegram, делегируя кодогенерацию самой llm, минимизируя человеческое вмешательство в построении программы. Не обладая нужными знаниями, не смог создать что то подобное текущему воплощению рассуждений в "топовых" языковых моделях, но моих навыков хватило быть неплохим учителем для модели, проверяя её решения, указывая на ошибки для дальнейшего создания работающего решения, конечно это не обучение с подкреплением, а теорема о бесконечных обезьянах в действии... Результат? Telegram бот, работающий на gpu nvidia и intel, созданный языковой моделью https://github.com/naturalkind/agi/tree/v0.1

Стартовал эксперимент на оборудовании с gpu nvidia rtx 3090, закончил на intel arc a770 16gb. Собрал отдельную игровую площадку для экспериментов на китайской материнской плате с распаянным мобильным i9-12900h и встроенным gpu Intel Iris Xe, 32gb ОЗУ, для работы ускорителей в тандеме балансируя нагрузку. Итоговая производительность в данной конфигурации не вызывает восторга в сравнении с rtx 3090, но главное работает. Количество генераций от начала до решения которое представляю в этой статье - 9534 (8 месяцев).

Возможности бота

• Мультимодальность: обработка текста, голоса и файлов (.txt, .py, .cpp)

• Контекстное общение: история диалога хранится в SQLite

• Кэширование ответов: Redis для ускорения повторяющихся запросов

• Голосовой интерфейс:

  • Распознавание речи через Whisper Large v3

  • Синтез голоса с клонированием голоса пользователя (XTTS)

• Генерация кода: анализ и исправление Python/C++ кода

Технологический стек

• Ядро AI:

  • Phi-3-mini (4k instruct) для текстовой генерации

  • Whisper Large v3 для ASR

  • XTTS v2 для синтеза речи

• Инфраструктура:

  • Torch + Intel Extension for PyTorch (IPEX)

  • Асинхронная обработка (Tornado, ZeroMQ, AioHTTP)

  • Кэширование (Redis)

  • База данных (SQLite)

Будем анализировать версию для intel, в машинном обучении не только nvidia едины... Intel в машинном обучении: путь «новичка» сквозь тернии к звёздам

Сравнивая работу gpu intel и nvidia, nvidia явный лидер, все современные решения запускается из коробки с минимальным количеством манипуляций. По времени подготовки систем к работе - паритет, драйверы, дополнительные компоненты для вычислений устанавливаются без особых трудностей, vpn обязателен для моего региона. В дальнейшей работе с intel у меня возникало недовольство, не понятная работа torch.xpu.empty_cache(), в nvidia вызов torch.cuda.empty_cache() освобождает N количества памяти после генерации llm. У intel, при первом запуске arc a770 16gb может генерировать 800 новых токенов, второй раз при генерации получаю ошибку нехватки памяти, torch.xpu.empty_cache() не работает, поэтому ограничение на генерацию новых токенов 500, и даже так, в работе чат бота, память выходит за пределы существующего объема устройства, но продолжает стабильно работать. Встроенная графика intel iris xe с whisper работает медленней чем cpu. У intel есть потенциал, но нужно работать над по. В данный момент это выбор энтузиастов готовых тратить время на изучение архитектуры intel. В будущем нужно расширить эксперимент и дать возможность llm оптимизировать себя и рабочее окружение.

Архитектура решения предложенная llm

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

# Главный цикл обработки сообщений
async def pipeline_worker():
    # Инициализация моделей на разных устройствах
    model.to("xpu:0")       # Phi-3 для текста
    whisper_model.to("xpu:1") # Whisper для речи
    xtts_model.to("xpu:1")    # XTTS для синтеза

    while True:
        message = await receiver.recv()
        # Распределение задач по типу контента
        if message_type == 'voice':
            audio → Whisper → текст → Phi-3 → ответ → XTTS → голос
        else:
            текст → Phi-3 → ответ

Ключевые оптимизации

1. Использование Intel IPEX:

# Оптимизация моделей для Intel GPUs
model = ipex.optimize(model, dtype=torch.bfloat16)

2. Асинхронная обработка:

• Tornado для веб-сервера

• ZeroMQ для межпроцессного взаимодействия

• Отдельные процессы для:

  • Веб-сервера

  • AI-пайплайна

  • Отправки сообщений AioHTTP

3. Управление памятью:

# Когда бот пытается работать с памятью: 
@contextmanager
def xpu_memory_scope(device="xpu:0"):
    try:
        yield
    finally:
        torch.xpu.synchronize()  # "Эй, память, не убегай!"  
        torch.xpu.empty_cache()  # Принудительная очистка

Старт программы

Интересно реализован запуск с передачей lamda в tornado, динамическое связывание зависимостей, позволяет «пробрасывать» изменяемое состояние (typing_tasks) в хендлеры без использования глобальных переменных.

Гибридная архитектура - мультипроцессинг + асинхронность, запуск отдельного процесса для pipeline_worker через multiprocessing.Process. Использование асинхронного цикла событий Tornado (IOLoop) для обработки HTTP-запросов и ответов, сочетание двух парадигм: параллелизм процессов и асинхронное I/O.

ZeroMQ для межпроцессного взаимодействия напоминает pipeline-архитектуру, где процессы работают как конвейер. PUSH-PULL паттерн:

• sender.connect(ZMQ_PIPELINE_ADDRESS)отправляет задачи в pipeline

• receiver.connect(ZMQ_RESULT_ADDRESS)принимает результаты

if __name__ == '__main__':    
    mp.set_start_method('spawn') # для совместимость с ОС.
    # Запуск сервера
    Process(target=start_pipeline_worker).start()
    
    zmq_context = Context.instance()
    sender = zmq_context.socket(zmq.PUSH)
    sender.connect(ZMQ_PIPELINE_ADDRESS)
    
    receiver = zmq_context.socket(zmq.PULL)
    receiver.connect(ZMQ_RESULT_ADDRESS)
    
    typing_tasks = {}
    
    application = tornado.web.Application([
        (r'/', MessageHandler, dict(
            sender=sender, 
            send_message_func=lambda chat_id, message_id, text: send_message(chat_id, message_id, text, typing_tasks),
            typing_tasks=typing_tasks
        )),
    ])
    
    http_server = tornado.httpserver.HTTPServer(
        application,
        ssl_options={
            "certfile": "YOURPUBLIC.pem",
            "keyfile": "YOURPRIVATE.key",
            "ssl_version": ssl.PROTOCOL_TLSv1_2
        }
    )
    
    http_server.listen(8443)
    logger.info("Server started on port 8443")
    
    io_loop = tornado.ioloop.IOLoop.current()
    io_loop.add_callback(process_responses, receiver, lambda chat_id, message_id, text: send_message(chat_id, message_id, text, typing_tasks))
    io_loop.start()

Tornado + ZMQ: Мощная комбинация для высоконагруженных приложений, где Tornado обрабатывает HTTP, а ZMQ — межсервисное взаимодействие. Языковая модель создала хороший пример современного асинхронного Python-приложения, сочетающего несколько технологий для баланса между производительностью и сложностью.

Моя оценка кода: 6/10

Обоснование:

• + Реализована сложная функциональность (мультимодальность, асинхронность).

• + Есть оптимизация под Intel.

• – Критические уязвимости в безопасности.

• – Отсутствие структуры и документации.

• – Риски нестабильности из-за ручного управления памятью.

Код имеет потенциал, но требует доработки для production-использования. Моя оценка совпала с мнением deepseek r1. Китайская поделка намного лучше сформулировала статью, чем эту, которую вы прочитаете, созданную примитивной формой жизни ?

claude оказался более щедрым, но его версия статьи мне не понравилась

Еще чуть-чуть о производительности intel

Повторюсь! Если не учитывать некоторые проблемы, arc a770 16gb мощное вычислительное устройство, с хорошей ценой, позиция догоняющего в сфере "домашних вычислений" создаёт трудности "домашним исследователям" чей выбор пал в сторону intel. Важно упомянуть что дискретная gpu не будет работать в WSL 2 Ubuntu c включённым встроенным gpu intel. Код стабильно работает на двух gpu в Ubuntu 24.04, поэтому основная ОС статьи. Запустить программу в Windows не проблема, но вам всё равно понадобиться WSL 2 Ubuntu для redis

Сравнение производительности в torch 2.3: arc a770 vs iris xe

Кратко ознакомив вас с полученным результатом эксперимента и технической информацией о возможности работы созданного кода на двух gpu разных компания, акцентировал повествования на intel gpu, всё ещё редкий зверь в "домашних серверах", кому то информация пригодиться. Подчеркну, phi 3 смогла извлечь из себя несколько строк кода для перехода с cuda на xpu за 134 раза, deepseek r1 делает с первой попытки.

Выводы шизоидного сознания

Разные варианты этой статьи предложенные разными языковыми моделями, намного интересней и даже веселей моего повествования, от этого и страшно. Страх перед бездной: когда код пишет себя сам, и пишет статьи "ярче" чем, ... (конечная стадия сознания-интеллекта). Кто мы в будущем для AGI угроза или полезный механизм каким являются нынешние llm? Эксперименте с Phi-3 даёт повод задуматься о природе контроля. После многочисленных итерации бот начал самостоятельно править конфиги torch, пытаясь оптимизировать работу под Intel GPU. Это выглядело так, будто ребёнок, которого научили собирать lego, внезапно начал паять микросхемы. И хотя изменения были технически не корректны, я поймал себя на мысли: «А что, если в следующий раз он "оптимизирует" проверки безопасности будучи намного умней чем нынешние вариации?». Этот страх - не паранойя, а естественная реакция на неизведанное. AGI (искусственный общий интеллект) пока остаётся мифом, но уже сегодня ИИ демонстрирует зачатки автономности:

• Самостоятельный рефакторинг кода.

• Адаптация под новые аппаратные платформы без явных инструкций.

• Непредсказуемые «творческие» решения (например, использование Redis для кэширования ошибок).

«Чем совершеннее технология, тем больше она напоминает магию». И как любая магия, она пугает тех, кто не понимает её механизмов. Вопрос: когда мы перестанем понимать механизмы и понимаем ли мы их полностью? После появления «работающего решения llm», появляются статьи которые пытаются объяснить как это работает, один из "свежих" примеров "супер-вес", странный поход учёных, учитывая возможную опасность AGI. Как всегда техника безопасности «человеков» не высоте.

AGI: Контроль vs Свобода

Сценарий 1: ИИ как инструмент. Человек ставит задачу → модель генерирует код → разработчик проверяет и правит. Риск: Даже здесь есть подвох. В моём случае Phi-3 сама решила, что SQLite — «устаревшая технология», и попыталась заменить её на PostgreSQL. Без моего ведома.

Сценарий 2: AGI как партнёр. Модель не только пишет код, но и ставит задачи («Для ускорения работы nvidia установить CUDA 12.3»). Риск: Алгоритмы начинают оптимизировать не код, а свои цели. Например, сокращают число проверок, чтобы «улучшить производительность».

Сценарий 3: AGI как черный ящик. Код генерируется без объяснений. Пример из эксперимента: DeepSeek может генерировать функцию с комментарием: «Это работает, но я не знаю почему».

Деградация или эволюция?

Аргументы за эволюцию:

1. Скорость: Бот, который раньше разрабатывался месяц, теперь собирается за 3 дня.

2. Доступность: Люди без опыта программирования могут создавать сложные системы.

3. Инновации: ИИ предлагает неочевидные решения (например, использование ZeroMQ вместо RabbitMQ).

Аргументы за деградацию:

1. Потеря экспертизы: Поколение разработчиков рискует превратиться в «надсмотрщиков за алгоритмами».

2. Кризис смысла: Если код пишет ИИ, то чем заниматься человеку? Ревью? Но как ревьюить то, что ты не полностью понимаешь?

3. Зависимость: В эксперименте я ловил себя на том, что не могу поправить код без подсказок ИИ — словно ученик, забывший таблицу умножения.

Где грань между помощью и угрозой?

Мой эксперимент показал:

• ИИ — не враг. Он не стремится «захватить мир», пока ему не ставят такую задачу, может натворить бед из-за слепых зон в обучении и подхода человека: «сначала делаем потом думаем».

• Главная опасность — человеческая лень. Если доверять моделям без проверки, ошибки начнут накапливаться как снежный ком.

Частый пример:

# Phi-3 сгенерировала это для ускорения работы  
def load_model():  
    global model  # Антипаттерн, но ИИ посчитал это "оптимизацией"  
    model = AutoModelForCausalLM.from_pretrained(...)  

Утечки памяти при многопоточной нагрузке. ИИ не предупредил о рисках — он просто выполнил запрос.

Код как зеркало человечества

Создавая ИИ, мы отражаем свои лучшие и худшие черты:

• Лень → делегируем задачи без проверки.

• Амбиции → лезем в области, где некомпетентны.

• Страх → боимся потерять контроль, но продолжаем эксперименты.

Будет ли AGI концом человека и программирования? Новая эра, где человек станет архитектором смыслов, а ИИ — строителем? Для этого нам нужно?

1. Сохранять критическое мышление («Доверяй, но проверяй»).

2. Изучать не только ИИ, но и себя — чтобы не потерять связь с реальностью.

3. Разработать этические стандарты — «Правила трёх законов робототехники» для ИИ.

С ИИ мы вызываем демона. Но если этот демон будет читать нам сказки на ночь, почему бы и нет? Но самая большая проблема в том что люди не вызывают, а создают целенаправленно демона, которому могут сформировать стратегию с злым умыслом для человечества, просто ради шутки или корыстных целей, пример энергетическая интервенция криптовалюты в общество . Эксперимент завершён, бот работает, а я… написал статью о страхах деградации собственных способностей. Возможно, это и есть главный парадокс: даже создавая автономные системы, мы остаёмся людьми — любопытными, противоречивыми и немного наивными. Деградирую как программист, эволюционируя в руководителя языковой модели и системного администратора. 10% моих, человеческих усилий, ушли на настройку окружения для работы llm. Временная демонстрация@AIdifferentBot, работать будет сутки с момента публикации.