Привет, Хабр! Сбер недавно выкатил новую модель, GigaChat Audio. Сейчас я надиктовываю модели этот текст голосом — финальный штрих в истории о том, как я проводил её тест‑драйв.
Когда прочитал, что GigaChat Audio запоминает контекст, ориентируется в больших аудиозаписях и даже чувствует эмоции говорящего, сразу захотел проверить. Я задеплоил эту модель локально на рабочем компьютере и целый день проверял на рабочих задачах. Результат — в этой статье.
Меня зовут Данила @pushnoydan, я мидл‑разработчик и занимаюсь бэкендом микросервисов. А параллельно — большой любитель ИИ‑моделей: в свободное время копаюсь в них, чтобы лучше понимать возможности свежих релизов, стараюсь применять на работе, чтобы упростить рутинные задачи.
GigaChat Audio — audio‑native LLM. В течение дня я поручал ей разбирать голосовые коммуникации от коллег, составлять саммари по аудиозаписям и выводить ключевой контекст из записей различных встреч. Давайте посмотрим, как модель показала на реальных задачах.
Как развернуть GigaChat Audio у себя
Перво‑наперво нужно определить, потянет ли компьютер локальный деплой модели. Я использовал собственное железо с такими характеристиками:
Видеокарта: RTX 4090 24GB
Процессор: AMD Ryzen 9 9950X OEM, 16 ядер
Материнка: GIGABYTE X870E AORUS PRO
RAM: 128 GB DDR5
SSD: 2Tb
Постфактум спросил у другой модели, насколько это подходящий уровень железа, она оценила его как «достаточный для базового деплоя GigaChat Audio, с возможными проблемами на загружающих железо задачах». Сразу отмечу, что мою машину модель нагрузила почти на 100%, не связанные с ней задачи я решал параллельно на ноутбуке.
То есть если ваш компьютер до подобных характеристик не дотягивает, особенно по видеопамяти, то лучше смотреть в сторону деплоя в облаке — сбережёте своё время. Я выбрал локальный деплой, потому что с ним потенциально чувствительные аудиоданные никуда не утекут, а сам я не получу по шапке от ИБ за прегрешения против безопасности.
Для локальной развёртки на Windows я использовал Docker Desktop, также необходима WSL2: командная строка, wsl ‑install. Все дальнейшие команды выполняются в терминале WSL, так что без этой подсистемы ничего задеплоить не получится. Кроме того, нужно иметь на компьютере свежие драйвера NVIDIA.
Docker Desktop по умолчанию загружает и временные, и постоянные файлы на системный диск. Если места на C: маловато, нужно загружать временные файлы на другой диск, сделав линк между C: и новой папкой назначения. Для этого закрыть Docker Desktop, вручную перетащить папку AppData\Local\Docker на новое место, а потом в командной строке вбить:
mklink /J "C:\Users\<юзернейм>\AppData\Local\Docker" "<диск назначения>:\<новый путь>\<к папке>"
Папку, в которой хранятся готовые образы и модели, назначаются в настройках Docker Desktop: настройки в шестерёнке на верхней панели, Disk Image Location указывается в разделе Resources. Чтобы убедиться, что видеокарта готова к работе с моделью, можно забить в командную строку:
bash nvidia-smi
Ответ выдаст данные по модели карты, версии драйвера видеокарты и количеству свободной видеопамяти.
Деплой через Docker делаем посредством vLLM. С учётом этого и создаётся следующий контейнер:
dockerfile FROM vllm/vllm-openai:<текущая версия vLLM> RUN apt-get update && apt-get install -y \ libsndfile1 \ ffmpeg \ && rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir \ soundfile \ librosa \ scipy
Здесь не только сама vLLM, но и установка всех необходимых зависимостей для работы с аудио. Далее создаём образ:
bash cd ~/gigachat-deployment docker build -f Dockerfile.vllm-audio -t vllm-audio:<текущая версия>
И сразу его проверяем:
bash docker images | grep vllm-audio
Ответ должен содержать версию модели, вес, айдишник образа. Теперь нужно создать файл.env для окружения. Сначала понадобится токен от HuggingFace, который можно сформировать здесь.
bash cat > ~/.gigachat.env << EOF HF_TOKEN=ваш_сформированный_токен MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B MAX_MODEL_LEN=24576 GPU_MEMORY_UTILIZATION=0.95 API_PORT=8000 API_HOST=0.0.0.0 EOF
Можно запускать модель напрямую через командную строку. В первый раз для запуска понадобится около 15 минут, в последующие, по моему опыту, от трёх до пяти.
bash docker run \ --gpus all \ --ipc=host \ --shm-size 32gb \ -p 8000:8000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env-file "~/.gigachat.env" \ --name gigachat-inference \ vllm-audio:<текущая версия> \ python3 -m vllm.entrypoints.openai.api_server \ --model ai-sage/GigaChat3.1-Audio-10B-A1.8B \ --trust-remote-code \ --max-model-len 24576 \ --gpu-memory-utilization 0.95 \ --host 0.0.0.0 \ --port 8000
Проверяем, как здоровье контейнера:
bash docker ps docker logs -f gigachat-inference
Если всё в порядке — вы увидите сообщение, что модель запущена на http://0.0.0.0:8000. Следующий шаг — тест API‑эндпоинта.
bash #Ждём сообщение «Uvicorn running on http://0.0.0.0:8000» curl http://localhost:8000/v1/models
Ответ должен быть такой:
{ "object": "list", "data": [ { "id": "ai-sage/GigaChat3.1-Audio-10B-A1.8B", "object": "model", "owned_by": "ai-sage" } ] }
И, наконец, можно послать тестовый запрос:
bash curl -o образец.mp3 https://образец.com/аудио.mp3 curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "ai-sage/GigaChat3.1-Audio-10B-A1.8B", "messages": [ { "role": "user", "content": [ {"type": "text", "text": "Сделай транскрипцию аудио"}, {"type": "audio_url", "audio_url": {"url": "data:audio/mp3;base64,..."}} ] } ] }'
Если пришедший результат соответствует вашим ожиданиям, то модель готова к работе.
С деплоем разобрались, переходим к моему опыту с моделью и реальным задачам.
Задача первая: подготовить материалы к конференции
Через пару недель выступаю перед публикой на внутреннем митапе компании. Не первый раз… а второй. Всё равно волнительно. В общем, вовсю готовлю доклад и накидываю материалы для презентации: моя тема — как получать максимальную пользу от микросервисов, не компрометируя при этом общую безопасность архитектуры. С утра написал деврел, который меня курирует, попросил поделиться успехами.
Доклад ещё не готов целиком, примерно половину я набросал в черновом варианте, а вторая половина пока существует в виде тезисов. Этот существующий черновик я зачитал GigaChat Audio.
Мой промпт для GigaChat Audio: транскрибируй аудио, которое я тебе зачитал. Составь краткий анализ части аудио до раздела про безопасность в микроядерной архитектуре: насколько рассказ эмоционально яркий, в каких местах я говорю недостаточно интересно.
В течение дня я внимательно читал все текстовые артефакты, которые получал от модели. Поскольку GigaChat Audio заточена на работу со звуком, у неё падают некоторые бенчмарки качества текста (MMLU‑Pro −9.18, BBH −7.26).
MMLU‑Pro фокусируется на способности модели рассуждать в различных сложных областях, всего в бенчмарк включено 57 дисциплин, таких как право, медицина, психология и другие. На нём модель показывает способность учитывать нюансы: бенчмарк состоит из вопросов с 10 вариантами ответа, девять из которых неверны, но очень похожи на правду.
BBH (Big‑Bench Hard) проверяет способность к сложным рассуждениям. В этом бенчмарке собраны наиболее сложные задачи семейства Big‑Bench — те, в решении которых модели заметно хуже людей. Модели нужно выполнять рассуждения, состоящие из множества шагов, делать выводы, опираясь на контекст, и так далее.
Конкретно эта задача мало зависит от этих бенчмарков, так что я от результатов не ожидал каких‑то подвохов, и их действительно не оказалось. Прикладываю краткий отрывок расшифровки:
«HTTP‑запросы, очереди сообщений и события — это наши с вами микросервисные хлеб и масло. Все понимаем, что они в нашем контексте делают? Если нет, поднимайте руку. Отлично, рук нет, тогда не буду тут останавливаться. Но, конечно, архитектура на этих хлебе с маслом не заканчивается. И я сейчас буду разбирать, как с помощью этого нехитрого инструментария реализовать куда более сложные процессы — например, распределённые транзакции, саги, асинхронные процессы и оркестрацию сервисов, причём делать это так, чтобы безопасность не пострадала».
А вот ревью моего выступления было не слишком позитивным:
«В начале текущего готового доклада ты держишь хороший темп речи, рассказываешь не слишком быстро и не слишком медленно, внимание аудитории не потеряется, и при этом все успеют усвоить информацию. В речи есть смысловые паузы, которые помогают слушателям лучше запомнить полученную ранее информацию. Во вступлении и рассказе про безопасность слышен большой энтузиазм, в речи слышны оговорки и заминки, от этого она более живая. Ты делаешь чёткие эмоциональные акценты на том, что должно заинтересовать аудиторию.»
Когда ты переходишь к рассказу о подходах к взаимодействию и организации микросервисов, речь становится быстрой и монотонной. В этом разделе эмоциональность пропадает.
Начиная с фразы «Теперь расскажу, как в эту историю вписывается REST…» в твоей речи нет ни одной паузы. Похоже, что тебе хочется не поделиться знаниями со слушателями, а как можно скорее рассказать оставшуюся часть доклада. Речь ближе по звучанию к перечисленным дальше ещё не написанным тезисам, чем к первой части твоего рассказа«.»
В общем, над подачей ещё работать и работать. Обидно, но транскрибацию и комментарии от GigaChat Audio закинул деврелу. Надеюсь, он поможет в этом плане подкачаться.
Задача вторая: разобрать по тезисам обучающее видео на иностранном языке
Кто любит учиться? Все любят, без учёбы никак. Вот я регулярно проверяю, какие есть интересные статьи и видео про мои любимые микроядра, в том числе на английском. Раньше мог себе позволить слушать их на обычной скорости, потом времени стало меньше, переключился на двойную. Сейчас и это уже слишком отвлекает от насущных задач, но качать навыки с помощью видео всё равно хочется.
Я разбираюсь в микросервисах, но очень хочу больше знать и о микроядрах. Поэтому решил попробовать GigaChat Audio в качестве транскрибатора и составителя краткого тезисного плана по видео. Скачал нужное видео про кодинг bare‑metal ядра гипервизора, перевёл в.mp3 и скормил модели.
Мой промпт для GigaChat Audio: транскрибируй приложенное аудио с подробными таймингами, а потом составь для меня краткий тезисный план самых важных аспектов этого аудио и выжимку ключевых выводов на русском с цитатами из транскрибации на английском.
Запустил, жду ответа, а вместо этого компьютер повисает намертво. Перезапуск — пора выяснять, что пошло не так.
Возвращаясь к истории деплоя. Изначально у меня параметры модели выглядели так:
MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B MAX_MODEL_LEN=32768 GPU_MEMORY_UTILIZATION=0.85
Замахнулся, честно говоря, на слишком многое. Модель ресурсоёмкая, запись большая, доступной VRAM стало не хватать, всё повисло. Поэтому и внёс изменения:
MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B MAX_MODEL_LEN=24576 GPU_MEMORY_UTILIZATION=0.95
Снизил MAX_MODEL_LEN, чтобы уменьшить размер KV‑cache. Заодно разрешил vLLM использовать почти всю видеопамять (0.95 вместо 0.85) — иначе при длинном аудио не хватало слотов в кэше. Соответственно, аудио я порезал на четыре примерно 15-минутных кусочка так, чтобы начало каждого следующего отрезка дублировало последние 10 секунд предыдущего, и скормил их модели уже поочерёдно. В моём случае 15-минутные фрагменты укладывались в лимит токенов модели, но точное соотношение «минуты аудио → токены» зависит от битрейта и токенайзера конкретной модели. Со второй попытки всё получилось!
Итоговая транскрибация на английском ничем не смутила. Результат сразу показал, что я не зря выбрал читать транскриб и тезисы, а не смотреть. Я заглянул в видео постфактум, к автору никаких претензий, но подача материала у нас примерно на одном уровне: если бы надо было слушать час с небольшим, я бы отвалился или сильно запутался.
Транскрибация:
“28:10”
It has a state and yeah it has a runner runner which is a.
28:23
Which is a.
28:24
Which is an empty function.
28:26
So.
28:27
And here's the really nice thing about the self port kernel.
28:35
I believe I saw somewhere the line of code.
28:39
So we can actually run a VM inside a.
28:45
Inside a for loop“.”
Тезисы:
«Автор начинает с подготовки окружения и загрузки нужного софта. Он упоминает Linux, Debian, initial RAM disk и secure boot: ‘Let’s load the software’ и „Linux, let’s take Debian“.»
Сразу выясняется, что часть среды ещё не установлена или настроена неправильно. Это видно по фразе: «We gotta install some, some things first».
К счастью, мотать видео туда‑сюда в поисках реального старта не надо, найти более деловые фрагменты в тексте куда проще:
«Автор отмечает практическую архитектуру VM в seL4: с self‑port kernel VM можно запускать почти как обычный цикл, а VM enter/exit обрабатывает ядро, давая юзеру возможность совершать некоторые действия из гостевого пространства и юзер‑спейса. Это ключевой технический момент раздела.»
Автор читает документацию про minimal application, guest Linux VM, cross‑VM connectors и демонстрации вроде string reverse и Ethernet passthrough, показывая, что платформа умеет больше, чем простой запуск Linux“.”
В принципе круто! Если не учитывать, что с моим уровнем железа нужно готовить аудио к обработке и резать на куски, иначе всё зависнет. Однако кое‑что в итоговых тезисах резануло глаз. Вы, может быть, уже и сами заметили в абзаце выше, если микроядра — ваша сфера интересов: юзер в транскрибе почему‑то может действовать и из гостевого пространства, и из юзерспейса.
Меня это немного смутило, так что я пошёл детективить, включил этот момент и обнаружил, что автор просто сбивается: сперва говорит «гостевое пространство», потом себя поправляет. Модель считала в речи возможность действовать сразу из двух пространств, но в реальности дозволяется только активность из юзерспейса.
Замечу, что я бросил GigaChat Audio заниматься сложным видео про тонкости кодинга, а это как раз домен MMLU Pro, поэтому не удивлён, что подобные мелочи просочились в текст.
Теоретически я могу даже больше заморочиться: настроить внешний pyannote и через него сделать диаризацию аудио, тогда можно хоть целые конференции с круглыми столами транскрибировать — текст будет разбиваться по спикерам. В дальнейшем, возможно, так и сделаю, но сейчас не хотелось отвлекаться от более насущных дел. Всё‑таки учёба важна, а работа важнее.
Задача третья: сделать тезисное саммари важной встречи
Недавно лид соседней команды побывал на конференции и послушал интересный доклад о том, как дробить BFF, чтобы упрощать жизнь командам на фронтенде. Сама тема модульного BFF настолько за пределами этой статьи, что даже не буду углубляться. Суть тут в том, что лид этой идеей всерьёз загорелся и собирал по ней встречу‑двадцатиминутку, затронувшую в том числе нашу команду.
Я на встрече не присутствовал, но, поскольку она касается нашей разработки, мне нужно как минимум в общих чертах понимать, что было сказано. Ну и обрисовать уже моему тимлиду, сочтётся ли эта идея с деталями нашей разработки. Так что я загрузил аудио в GigaChat Audio, чтобы почитать саммари и сберечь время.
Мой промпт для GigaChat Audio: составь краткий тезисный план самых важных аспектов этого аудио, отдельно пропиши все упомянутые в нём айти‑решения, добавь к каждому цитаты, в котором оно упомянуто. На выходе получились краткий текст и табличка.
Отрывок текста:
«Приводится пример недавней проблемы с монолитным BFF: в связи с его использованием снизилась координация команд, что привело к каскаду задержек релизов на фронтенде, накоплению ошибок и откату к задачам прошедшего спринта в одной из команд. В качестве решения предлагается модульный BFF с общим хостом в роли платформенного слоя».
JWT |
“Нормализованный токен”, «BFF обменивает сессию через JWT» |
NATS |
«Через него идёт асинхронная доставка сообщений между BFF‑хостом и backend‑плагинами» |
RPC |
«От RPC вызываем серверные методы через объект с method и params» |
Cookies |
«Надеюсь, все в курсе, что такое cookies» |
Довольно забавно, что модель в один ряд заносит и самые понятные вещи типа кукиз, и более узкие концепты, но так лучше, точно никакая информация не потеряется, даже самая банальная.
Такая последовательность меня устроила, потому что работу с техничным русским аудио я хотел проверить подробнее: GigaChat Audio натренирована на TimeGround-1M, а это целиком английский датасет с английскими же тайминг‑бенчмарками. Короче, на английском может быть гораздо лучший результат, чем на русском.
Модель выдала мне в списке тезисов такие фразы:
«Представитель одной из бэкенд‑команд предлагает как вариант внедрения BFF расширить слоем агрегации используемый Istio Gateway. »
Участники обсуждают, возможно ли расширение на основе используемого Istio в контексте компании <уход в технические детали>«.»
Istio — это опенсорс, для замены которого у нас есть своё решение в рамках Platform V. Очевидно, никакое расширение Istio на встрече обсуждать не могли, так что я пошёл слушать, что же там сказали на самом деле. И в процессе послушал всё саммари своими ушами. Оригинальный диалог в записи действительно Istio упоминал, но в контексте: «Да, там такой подход возможен, а возможен ли он у нас в контексте наших отличий от Istio?» Поскольку по имени собственно наше решение нигде не упоминалось, модель эту тонкость не подхватила и решила, что речь о том, есть ли у нас внутри компании возможность так поменять решение.
В принципе в данном конкретном случае не самая страшная ошибка — но это потому, что у меня у самого нужный контекст в голове, и я сразу считал косяк. Но вывод на основе этой и прошлой задачи очевиден: микс из сбивчивой речи и технических деталей способен подставить GigaChat Audio смысловую подножку.
Также в конце саммари GigaChat Audio последовала за спикером: он куда больше говорил о плюсах BFF, чем о возможных осложнениях с инфраструктурой и зонами ответственности, и модель тоже уделила плюсам места куда больше, чем минусам.
В итоге конкретно это саммари мне время не сберегло, потому что я для чистоты эксперимента всё перепроверил. Штука умеренно полезная, но полученную от модели чувствительную информацию по хардам явно лучше верифицировать.
Я взял текст за основу для своего ответа, как это нас теоретически затронет. Пометил, что конкретно сейчас велика вероятность, что мы, разработчики в бэк‑командах, не доведём подобную модульность до ума, нам надо будет бежать на большие задачи, маячащие на горизонте. То есть быстро скатимся обратно к монолиту, который ещё и инфраструктурно потолстеет. Но в целом‑то идея здравая: в перспективе на год, например, точно надо в этом направлении идти.
Задача четвёртая: провести код‑ревью для коллеги
Я тут всё‑таки на сеньорство иду, поэтому ревьюить код важно и нужно. Коллега помладше сделал мёрж‑реквест, выбрал меня проверяющим. Сама проверка — ничего сложного, но тут есть и социальный элемент: комменты написать надо так, чтобы коллега не обиделся, не расстроился, не испугался, что всё плохо. Даже если что‑то действительно плохо — это рабочий момент.
Обычно я по несколько раз переписываю свои комменты в личных заметках, прежде чем их прикреплять. А в этот — надиктовал их GigaChat Audio, чтобы он захватил мои живые эмоции в моменте.
Мой промпт для GigaChat Audio: сделай транскрибацию этого аудио, выяви моменты, где слишком много ярких эмоций и составь более нейтральную версию текста с объяснением, что изменилось.
Показываю конкретный пример. Младший допустил серьёзную для микросервисной архитектуры ошибку: не определил стабильный API‑контракт между сервисами и жёстко завязался на текущую структуру данных соседнего сервиса. Сейчас всё работает, но достаточно изменить формат ответа или добавить новую версию API — и интеграция начнёт ломаться в проде. Первый вариант моего комментария выглядел так:
«Вот это взаимодействие локально работает, потому что у обоих сервисов одна версия модели данных, но с платформой не совместимо вообще. Все будущие версии сервисов или изменения в структурах ты не учитываешь, то есть это скрытый баг, просто отложенный до деплоя или апдейта. Сделай контракт явным и не вяжись с другими сервисами».
Такой вариант пришёл от GigaChat Audio:
«Сейчас код рабочий, но только до изменений в данных. Контракт между сервисами не явный, из‑за этого не хватает глобальной совместимости интеграции с платформой. Код полагается на то, что текущие версии сервисов не изменятся в будущем. Давай сделаем API‑контракт явным, чтобы это исправить».
Окей, эмоционально стало лучше, явно меньше наезжаю на младшего. Обычно как раз для такого эффекта мне и нужны многочисленные ревизии. И сразу выявилось необходимое дополнение: так‑то я много сказал о том, что плохо, но не дал конкретики, как сделать лучше. Соответственно, этот готовый текст дополнил списком необходимых данных: эндпоинты, версия, схема запроса… В общем, получилось куда приличнее, как ни посмотри. Того же эффекта я добился бы и сам, но времени ушло бы намного больше, особенно учитывая, что это всего один коммент из итоговых шести.
Задача пятая: разобрать голосовые от коллег по сегодняшним и завтрашним делам
С самого утра я попросил коллег по всем задачам кидать мне голосовые. Они, наверное, неслабо удивились, потому что обычно я исключительно пишу и аудио прошу не отправлять. Но сегодня мне нужны были именно аудиоданные, чтобы тестить GigaChat Audio.
Во‑первых, слушать, какие таски приходят в течение дня.
Мой промпт для GigaChat Audio: транскрибируй присланное аудио.
Результаты довольно простые, но увлекательные. Например, от ребят из команды соседнего продукта:
«Привет! В <внутреннее название сервиса>, судя по всему, БДшка дубли даёт, приходи проверить прям срочно»
«В смысле у нас транзакции не локальные»
«Окей, принял, сколько на фикс?»
«Да, работает, маякну, если что»
Наказ идти работать от тимлида:
«Я тебе напоминаю который раз, что рефакторинг <название сервиса> висит и висит. Почему у меня хост чуть ли не телефон клиента знает? Монолитим опять? Короче, заканчивай там со своей моделькой баловаться и давай срочно дело делай».
Приглашение на завтрашнюю встречу от него же:
«Завтра в 12:30 разбираем, как будут взаимодействовать после обновления <сервис 1> и <сервис 2> и как обновятся границы. Приглашение на почте, прими, чтобы в календаре видно было».
И конечно, от очень расстроенного коллеги:
«<...>, меня эти логи, <...>, уже <...>. <...> с ними сколько уже, а они до сих пор внутри <название сервиса> не трассируются, <...>, нормально. Я сдаюсь, в общем, можешь злорадствовать, <...>, только сперва пофикси этот <...>. Тикет закинул».
Подобное веселье наряду с вышеописанными делами заняло сегодняшний день, логи нужно будет ещё допилить завтра, а рефакторинг займёт немало времени в будущем. В итоге за 15 минут до конца работы я скормил GigaChat Audio сообщения по незаконченным делам и…
Мой промпт для GigaChat Audio: составь на основе присланных аудио короткий список тезисов. Одно сообщение — один тезис.
Итоговый план на завтра сберёг не только время, но и нервы — сам бы я думал о завтрашних делах всю дорогу домой, а так будущее понятно и чётко изложено.
«Вот список тезисов на основе присланных аудиосообщений:»
1. Продолжить срочный рефакторинг <название сервиса>, чтобы убрать технический долг и снизить риск инцидентов.
2. Поучаствовать в проектировании границ между <сервис 1> и <сервис 2> и их взаимодействия на встрече в 12:30.
3. Настроить подробную трассировку логов в <название сервиса>.
Итоги рабочего дня
Доволен ли я? Да, доволен. Мне хотелось, чтобы GigaChat Audio упростил мне работу со звуком, и он это сделал. В целом модель работает как хорошая контекстовыжималка, которая помогает быстро выхватить самые важные факты из записи. Но и косяки в итоговом тексте с фокусом на сложных технических задачах видны: информацию, полученную по хардкорным темам, лучше перепроверять.
Компонент эмпатичности меня привлёк больше всего: конкретно у меня нет никакой надобности читать с помощью GigaChat Audio чужие эмоции, но вот фиксировать с его помощью свои собственные и опять же возвращаться от чувств к фактам — помогает в определённых ситуациях.
Камень преткновения — запросы к мощностям: постоянно нагружать компьютер моделью я просто не могу, он мне необходим и для других задач. Поэтому первый день тестов ассистент достойно выдержал, а я теперь буду думать, как в будущем использовать его более эффективными способами.
Привет, Хабр! Сбер недавно выкатил новую модель, GigaChat Audio. Сейчас я надиктовываю модели этот текст голосом — финальный штрих в истории о том, как я проводил её тест‑драйв.
Когда прочитал, что GigaChat Audio запоминает контекст, ориентируется в больших аудиозаписях и даже чувствует эмоции говорящего, сразу захотел проверить. Я задеплоил эту модель локально на рабочем компьютере и целый день проверял на рабочих задачах. Результат — в этой статье.
Меня зовут Данила @pushnoydan, я мидл‑разработчик и занимаюсь бэкендом микросервисов. А параллельно — большой любитель ИИ‑моделей: в свободное время копаюсь в них, чтобы лучше понимать возможности свежих релизов, стараюсь применять на работе, чтобы упростить рутинные задачи.
GigaChat Audio — audio‑native LLM. В течение дня я поручал ей разбирать голосовые коммуникации от коллег, составлять саммари по аудиозаписям и выводить ключевой контекст из записей различных встреч. Давайте посмотрим, как модель показала на реальных задачах.
Как развернуть GigaChat Audio у себя
Перво‑наперво нужно определить, потянет ли компьютер локальный деплой модели. Я использовал собственное железо с такими характеристиками:
Видеокарта: RTX 4090 24GB
Процессор: AMD Ryzen 9 9950X OEM, 16 ядер
Материнка: GIGABYTE X870E AORUS PRO
RAM: 128 GB DDR5
SSD: 2Tb
Постфактум спросил у другой модели, насколько это подходящий уровень железа, она оценила его как «достаточный для базового деплоя GigaChat Audio, с возможными проблемами на загружающих железо задачах». Сразу отмечу, что мою машину модель нагрузила почти на 100%, не связанные с ней задачи я решал параллельно на ноутбуке.
То есть если ваш компьютер до подобных характеристик не дотягивает, особенно по видеопамяти, то лучше смотреть в сторону деплоя в облаке — сбережёте своё время. Я выбрал локальный деплой, потому что с ним потенциально чувствительные аудиоданные никуда не утекут, а сам я не получу по шапке от ИБ за прегрешения против безопасности.
Для локальной развёртки на Windows я использовал Docker Desktop, также необходима WSL2: командная строка, wsl ‑install. Все дальнейшие команды выполняются в терминале WSL, так что без этой подсистемы ничего задеплоить не получится. Кроме того, нужно иметь на компьютере свежие драйвера NVIDIA.
Docker Desktop по умолчанию загружает и временные, и постоянные файлы на системный диск. Если места на C: маловато, нужно загружать временные файлы на другой диск, сделав линк между C: и новой папкой назначения. Для этого закрыть Docker Desktop, вручную перетащить папку AppData\Local\Docker на новое место, а потом в командной строке вбить:
mklink /J "C:\Users\<юзернейм>\AppData\Local\Docker" "<диск назначения>:\<новый путь>\<к папке>"
Папку, в которой хранятся готовые образы и модели, назначаются в настройках Docker Desktop: настройки в шестерёнке на верхней панели, Disk Image Location указывается в разделе Resources. Чтобы убедиться, что видеокарта готова к работе с моделью, можно забить в командную строку:
bash nvidia-smi
Ответ выдаст данные по модели карты, версии драйвера видеокарты и количеству свободной видеопамяти.
Деплой через Docker делаем посредством vLLM. С учётом этого и создаётся следующий контейнер:
dockerfile FROM vllm/vllm-openai:<текущая версия vLLM> RUN apt-get update && apt-get install -y \ libsndfile1 \ ffmpeg \ && rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir \ soundfile \ librosa \ scipy
Здесь не только сама vLLM, но и установка всех необходимых зависимостей для работы с аудио. Далее создаём образ:
bash cd ~/gigachat-deployment docker build -f Dockerfile.vllm-audio -t vllm-audio:<текущая версия>
И сразу его проверяем:
bash docker images | grep vllm-audio
Ответ должен содержать версию модели, вес, айдишник образа. Теперь нужно создать файл.env для окружения. Сначала понадобится токен от HuggingFace, который можно сформировать здесь.
bash cat > ~/.gigachat.env << EOF HF_TOKEN=ваш_сформированный_токен MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B MAX_MODEL_LEN=24576 GPU_MEMORY_UTILIZATION=0.95 API_PORT=8000 API_HOST=0.0.0.0 EOF
Можно запускать модель напрямую через командную строку. В первый раз для запуска понадобится около 15 минут, в последующие, по моему опыту, от трёх до пяти.
bash docker run \ --gpus all \ --ipc=host \ --shm-size 32gb \ -p 8000:8000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env-file "~/.gigachat.env" \ --name gigachat-inference \ vllm-audio:<текущая версия> \ python3 -m vllm.entrypoints.openai.api_server \ --model ai-sage/GigaChat3.1-Audio-10B-A1.8B \ --trust-remote-code \ --max-model-len 24576 \ --gpu-memory-utilization 0.95 \ --host 0.0.0.0 \ --port 8000
Проверяем, как здоровье контейнера:
bash docker ps docker logs -f gigachat-inference
Если всё в порядке — вы увидите сообщение, что модель запущена на http://0.0.0.0:8000. Следующий шаг — тест API‑эндпоинта.
bash #Ждём сообщение «Uvicorn running on http://0.0.0.0:8000» curl http://localhost:8000/v1/models
Ответ должен быть такой:
{ "object": "list", "data": [ { "id": "ai-sage/GigaChat3.1-Audio-10B-A1.8B", "object": "model", "owned_by": "ai-sage" } ] }
И, наконец, можно послать тестовый запрос:
bash curl -o образец.mp3 https://образец.com/аудио.mp3 curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "ai-sage/GigaChat3.1-Audio-10B-A1.8B", "messages": [ { "role": "user", "content": [ {"type": "text", "text": "Сделай транскрипцию аудио"}, {"type": "audio_url", "audio_url": {"url": "data:audio/mp3;base64,..."}} ] } ] }'
Если пришедший результат соответствует вашим ожиданиям, то модель готова к работе.
С деплоем разобрались, переходим к моему опыту с моделью и реальным задачам.
Задача первая: подготовить материалы к конференции
Через пару недель выступаю перед публикой на внутреннем митапе компании. Не первый раз… а второй. Всё равно волнительно. В общем, вовсю готовлю доклад и накидываю материалы для презентации: моя тема — как получать максимальную пользу от микросервисов, не компрометируя при этом общую безопасность архитектуры. С утра написал деврел, который меня курирует, попросил поделиться успехами.
Доклад ещё не готов целиком, примерно половину я набросал в черновом варианте, а вторая половина пока существует в виде тезисов. Этот существующий черновик я зачитал GigaChat Audio.
Мой промпт для GigaChat Audio: транскрибируй аудио, которое я тебе зачитал. Составь краткий анализ части аудио до раздела про безопасность в микроядерной архитектуре: насколько рассказ эмоционально яркий, в каких местах я говорю недостаточно интересно.
В течение дня я внимательно читал все текстовые артефакты, которые получал от модели. Поскольку GigaChat Audio заточена на работу со звуком, у неё падают некоторые бенчмарки качества текста (MMLU‑Pro −9.18, BBH −7.26).
MMLU‑Pro фокусируется на способности модели рассуждать в различных сложных областях, всего в бенчмарк включено 57 дисциплин, таких как право, медицина, психология и другие. На нём модель показывает способность учитывать нюансы: бенчмарк состоит из вопросов с 10 вариантами ответа, девять из которых неверны, но очень похожи на правду.
BBH (Big‑Bench Hard) проверяет способность к сложным рассуждениям. В этом бенчмарке собраны наиболее сложные задачи семейства Big‑Bench — те, в решении которых модели заметно хуже людей. Модели нужно выполнять рассуждения, состоящие из множества шагов, делать выводы, опираясь на контекст, и так далее.
Конкретно эта задача мало зависит от этих бенчмарков, так что я от результатов не ожидал каких‑то подвохов, и их действительно не оказалось. Прикладываю краткий отрывок расшифровки:
«HTTP‑запросы, очереди сообщений и события — это наши с вами микросервисные хлеб и масло. Все понимаем, что они в нашем контексте делают? Если нет, поднимайте руку. Отлично, рук нет, тогда не буду тут останавливаться. Но, конечно, архитектура на этих хлебе с маслом не заканчивается. И я сейчас буду разбирать, как с помощью этого нехитрого инструментария реализовать куда более сложные процессы — например, распределённые транзакции, саги, асинхронные процессы и оркестрацию сервисов, причём делать это так, чтобы безопасность не пострадала».
А вот ревью моего выступления было не слишком позитивным:
«В начале текущего готового доклада ты держишь хороший темп речи, рассказываешь не слишком быстро и не слишком медленно, внимание аудитории не потеряется, и при этом все успеют усвоить информацию. В речи есть смысловые паузы, которые помогают слушателям лучше запомнить полученную ранее информацию. Во вступлении и рассказе про безопасность слышен большой энтузиазм, в речи слышны оговорки и заминки, от этого она более живая. Ты делаешь чёткие эмоциональные акценты на том, что должно заинтересовать аудиторию.»
Когда ты переходишь к рассказу о подходах к взаимодействию и организации микросервисов, речь становится быстрой и монотонной. В этом разделе эмоциональность пропадает.
Начиная с фразы «Теперь расскажу, как в эту историю вписывается REST…» в твоей речи нет ни одной паузы. Похоже, что тебе хочется не поделиться знаниями со слушателями, а как можно скорее рассказать оставшуюся часть доклада. Речь ближе по звучанию к перечисленным дальше ещё не написанным тезисам, чем к первой части твоего рассказа«.»
В общем, над подачей ещё работать и работать. Обидно, но транскрибацию и комментарии от GigaChat Audio закинул деврелу. Надеюсь, он поможет в этом плане подкачаться.
Задача вторая: разобрать по тезисам обучающее видео на иностранном языке
Кто любит учиться? Все любят, без учёбы никак. Вот я регулярно проверяю, какие есть интересные статьи и видео про мои любимые микроядра, в том числе на английском. Раньше мог себе позволить слушать их на обычной скорости, потом времени стало меньше, переключился на двойную. Сейчас и это уже слишком отвлекает от насущных задач, но качать навыки с помощью видео всё равно хочется.
Я разбираюсь в микросервисах, но очень хочу больше знать и о микроядрах. Поэтому решил попробовать GigaChat Audio в качестве транскрибатора и составителя краткого тезисного плана по видео. Скачал нужное видео про кодинг bare‑metal ядра гипервизора, перевёл в.mp3 и скормил модели.
Мой промпт для GigaChat Audio: транскрибируй приложенное аудио с подробными таймингами, а потом составь для меня краткий тезисный план самых важных аспектов этого аудио и выжимку ключевых выводов на русском с цитатами из транскрибации на английском.
Запустил, жду ответа, а вместо этого компьютер повисает намертво. Перезапуск — пора выяснять, что пошло не так.
Возвращаясь к истории деплоя. Изначально у меня параметры модели выглядели так:
MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B MAX_MODEL_LEN=32768 GPU_MEMORY_UTILIZATION=0.85
Замахнулся, честно говоря, на слишком многое. Модель ресурсоёмкая, запись большая, доступной VRAM стало не хватать, всё повисло. Поэтому и внёс изменения:
MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B MAX_MODEL_LEN=24576 GPU_MEMORY_UTILIZATION=0.95
Снизил MAX_MODEL_LEN, чтобы уменьшить размер KV‑cache. Заодно разрешил vLLM использовать почти всю видеопамять (0.95 вместо 0.85) — иначе при длинном аудио не хватало слотов в кэше. Соответственно, аудио я порезал на четыре примерно 15-минутных кусочка так, чтобы начало каждого следующего отрезка дублировало последние 10 секунд предыдущего, и скормил их модели уже поочерёдно. В моём случае 15-минутные фрагменты укладывались в лимит токенов модели, но точное соотношение «минуты аудио → токены» зависит от битрейта и токенайзера конкретной модели. Со второй попытки всё получилось!
Итоговая транскрибация на английском ничем не смутила. Результат сразу показал, что я не зря выбрал читать транскриб и тезисы, а не смотреть. Я заглянул в видео постфактум, к автору никаких претензий, но подача материала у нас примерно на одном уровне: если бы надо было слушать час с небольшим, я бы отвалился или сильно запутался.
Транскрибация:
“28:10”
It has a state and yeah it has a runner runner which is a.
28:23
Which is a.
28:24
Which is an empty function.
28:26
So.
28:27
And here's the really nice thing about the self port kernel.
28:35
I believe I saw somewhere the line of code.
28:39
So we can actually run a VM inside a.
28:45
Inside a for loop“.”
Тезисы:
«Автор начинает с подготовки окружения и загрузки нужного софта. Он упоминает Linux, Debian, initial RAM disk и secure boot: ‘Let’s load the software’ и „Linux, let’s take Debian“.»
Сразу выясняется, что часть среды ещё не установлена или настроена неправильно. Это видно по фразе: «We gotta install some, some things first».
К счастью, мотать видео туда‑сюда в поисках реального старта не надо, найти более деловые фрагменты в тексте куда проще:
«Автор отмечает практическую архитектуру VM в seL4: с self‑port kernel VM можно запускать почти как обычный цикл, а VM enter/exit обрабатывает ядро, давая юзеру возможность совершать некоторые действия из гостевого пространства и юзер‑спейса. Это ключевой технический момент раздела.»
Автор читает документацию про minimal application, guest Linux VM, cross‑VM connectors и демонстрации вроде string reverse и Ethernet passthrough, показывая, что платформа умеет больше, чем простой запуск Linux“.”
В принципе круто! Если не учитывать, что с моим уровнем железа нужно готовить аудио к обработке и резать на куски, иначе всё зависнет. Однако кое‑что в итоговых тезисах резануло глаз. Вы, может быть, уже и сами заметили в абзаце выше, если микроядра — ваша сфера интересов: юзер в транскрибе почему‑то может действовать и из гостевого пространства, и из юзерспейса.
Меня это немного смутило, так что я пошёл детективить, включил этот момент и обнаружил, что автор просто сбивается: сперва говорит «гостевое пространство», потом себя поправляет. Модель считала в речи возможность действовать сразу из двух пространств, но в реальности дозволяется только активность из юзерспейса.
Замечу, что я бросил GigaChat Audio заниматься сложным видео про тонкости кодинга, а это как раз домен MMLU Pro, поэтому не удивлён, что подобные мелочи просочились в текст.
Теоретически я могу даже больше заморочиться: настроить внешний pyannote и через него сделать диаризацию аудио, тогда можно хоть целые конференции с круглыми столами транскрибировать — текст будет разбиваться по спикерам. В дальнейшем, возможно, так и сделаю, но сейчас не хотелось отвлекаться от более насущных дел. Всё‑таки учёба важна, а работа важнее.
Задача третья: сделать тезисное саммари важной встречи
Недавно лид соседней команды побывал на конференции и послушал интересный доклад о том, как дробить BFF, чтобы упрощать жизнь командам на фронтенде. Сама тема модульного BFF настолько за пределами этой статьи, что даже не буду углубляться. Суть тут в том, что лид этой идеей всерьёз загорелся и собирал по ней встречу‑двадцатиминутку, затронувшую в том числе нашу команду.
Я на встрече не присутствовал, но, поскольку она касается нашей разработки, мне нужно как минимум в общих чертах понимать, что было сказано. Ну и обрисовать уже моему тимлиду, сочтётся ли эта идея с деталями нашей разработки. Так что я загрузил аудио в GigaChat Audio, чтобы почитать саммари и сберечь время.
Мой промпт для GigaChat Audio: составь краткий тезисный план самых важных аспектов этого аудио, отдельно пропиши все упомянутые в нём айти‑решения, добавь к каждому цитаты, в котором оно упомянуто. На выходе получились краткий текст и табличка.
Отрывок текста:
«Приводится пример недавней проблемы с монолитным BFF: в связи с его использованием снизилась координация команд, что привело к каскаду задержек релизов на фронтенде, накоплению ошибок и откату к задачам прошедшего спринта в одной из команд. В качестве решения предлагается модульный BFF с общим хостом в роли платформенного слоя».
JWT |
“Нормализованный токен”, «BFF обменивает сессию через JWT» |
NATS |
«Через него идёт асинхронная доставка сообщений между BFF‑хостом и backend‑плагинами» |
RPC |
«От RPC вызываем серверные методы через объект с method и params» |
Cookies |
«Надеюсь, все в курсе, что такое cookies» |
Довольно забавно, что модель в один ряд заносит и самые понятные вещи типа кукиз, и более узкие концепты, но так лучше, точно никакая информация не потеряется, даже самая банальная.
Такая последовательность меня устроила, потому что работу с техничным русским аудио я хотел проверить подробнее: GigaChat Audio натренирована на TimeGround-1M, а это целиком английский датасет с английскими же тайминг‑бенчмарками. Короче, на английском может быть гораздо лучший результат, чем на русском.
Модель выдала мне в списке тезисов такие фразы:
«Представитель одной из бэкенд‑команд предлагает как вариант внедрения BFF расширить слоем агрегации используемый Istio Gateway. »
Участники обсуждают, возможно ли расширение на основе используемого Istio в контексте компании <уход в технические детали>«.»
Istio — это опенсорс, для замены которого у нас есть своё решение в рамках Platform V. Очевидно, никакое расширение Istio на встрече обсуждать не могли, так что я пошёл слушать, что же там сказали на самом деле. И в процессе послушал всё саммари своими ушами. Оригинальный диалог в записи действительно Istio упоминал, но в контексте: «Да, там такой подход возможен, а возможен ли он у нас в контексте наших отличий от Istio?» Поскольку по имени собственно наше решение нигде не упоминалось, модель эту тонкость не подхватила и решила, что речь о том, есть ли у нас внутри компании возможность так поменять решение.
В принципе в данном конкретном случае не самая страшная ошибка — но это потому, что у меня у самого нужный контекст в голове, и я сразу считал косяк. Но вывод на основе этой и прошлой задачи очевиден: микс из сбивчивой речи и технических деталей способен подставить GigaChat Audio смысловую подножку.
Также в конце саммари GigaChat Audio последовала за спикером: он куда больше говорил о плюсах BFF, чем о возможных осложнениях с инфраструктурой и зонами ответственности, и модель тоже уделила плюсам места куда больше, чем минусам.
В итоге конкретно это саммари мне время не сберегло, потому что я для чистоты эксперимента всё перепроверил. Штука умеренно полезная, но полученную от модели чувствительную информацию по хардам явно лучше верифицировать.
Я взял текст за основу для своего ответа, как это нас теоретически затронет. Пометил, что конкретно сейчас велика вероятность, что мы, разработчики в бэк‑командах, не доведём подобную модульность до ума, нам надо будет бежать на большие задачи, маячащие на горизонте. То есть быстро скатимся обратно к монолиту, который ещё и инфраструктурно потолстеет. Но в целом‑то идея здравая: в перспективе на год, например, точно надо в этом направлении идти.
Задача четвёртая: провести код‑ревью для коллеги
Я тут всё‑таки на сеньорство иду, поэтому ревьюить код важно и нужно. Коллега помладше сделал мёрж‑реквест, выбрал меня проверяющим. Сама проверка — ничего сложного, но тут есть и социальный элемент: комменты написать надо так, чтобы коллега не обиделся, не расстроился, не испугался, что всё плохо. Даже если что‑то действительно плохо — это рабочий момент.
Обычно я по несколько раз переписываю свои комменты в личных заметках, прежде чем их прикреплять. А в этот — надиктовал их GigaChat Audio, чтобы он захватил мои живые эмоции в моменте.
Мой промпт для GigaChat Audio: сделай транскрибацию этого аудио, выяви моменты, где слишком много ярких эмоций и составь более нейтральную версию текста с объяснением, что изменилось.
Показываю конкретный пример. Младший допустил серьёзную для микросервисной архитектуры ошибку: не определил стабильный API‑контракт между сервисами и жёстко завязался на текущую структуру данных соседнего сервиса. Сейчас всё работает, но достаточно изменить формат ответа или добавить новую версию API — и интеграция начнёт ломаться в проде. Первый вариант моего комментария выглядел так:
«Вот это взаимодействие локально работает, потому что у обоих сервисов одна версия модели данных, но с платформой не совместимо вообще. Все будущие версии сервисов или изменения в структурах ты не учитываешь, то есть это скрытый баг, просто отложенный до деплоя или апдейта. Сделай контракт явным и не вяжись с другими сервисами».
Такой вариант пришёл от GigaChat Audio:
«Сейчас код рабочий, но только до изменений в данных. Контракт между сервисами не явный, из‑за этого не хватает глобальной совместимости интеграции с платформой. Код полагается на то, что текущие версии сервисов не изменятся в будущем. Давай сделаем API‑контракт явным, чтобы это исправить».
Окей, эмоционально стало лучше, явно меньше наезжаю на младшего. Обычно как раз для такого эффекта мне и нужны многочисленные ревизии. И сразу выявилось необходимое дополнение: так‑то я много сказал о том, что плохо, но не дал конкретики, как сделать лучше. Соответственно, этот готовый текст дополнил списком необходимых данных: эндпоинты, версия, схема запроса… В общем, получилось куда приличнее, как ни посмотри. Того же эффекта я добился бы и сам, но времени ушло бы намного больше, особенно учитывая, что это всего один коммент из итоговых шести.
Задача пятая: разобрать голосовые от коллег по сегодняшним и завтрашним делам
С самого утра я попросил коллег по всем задачам кидать мне голосовые. Они, наверное, неслабо удивились, потому что обычно я исключительно пишу и аудио прошу не отправлять. Но сегодня мне нужны были именно аудиоданные, чтобы тестить GigaChat Audio.
Во‑первых, слушать, какие таски приходят в течение дня.
Мой промпт для GigaChat Audio: транскрибируй присланное аудио.
Результаты довольно простые, но увлекательные. Например, от ребят из команды соседнего продукта:
«Привет! В <внутреннее название сервиса>, судя по всему, БДшка дубли даёт, приходи проверить прям срочно»
«В смысле у нас транзакции не локальные»
«Окей, принял, сколько на фикс?»
«Да, работает, маякну, если что»
Наказ идти работать от тимлида:
«Я тебе напоминаю который раз, что рефакторинг <название сервиса> висит и висит. Почему у меня хост чуть ли не телефон клиента знает? Монолитим опять? Короче, заканчивай там со своей моделькой баловаться и давай срочно дело делай».
Приглашение на завтрашнюю встречу от него же:
«Завтра в 12:30 разбираем, как будут взаимодействовать после обновления <сервис 1> и <сервис 2> и как обновятся границы. Приглашение на почте, прими, чтобы в календаре видно было».
И конечно, от очень расстроенного коллеги:
«<...>, меня эти логи, <...>, уже <...>. <...> с ними сколько уже, а они до сих пор внутри <название сервиса> не трассируются, <...>, нормально. Я сдаюсь, в общем, можешь злорадствовать, <...>, только сперва пофикси этот <...>. Тикет закинул».
Подобное веселье наряду с вышеописанными делами заняло сегодняшний день, логи нужно будет ещё допилить завтра, а рефакторинг займёт немало времени в будущем. В итоге за 15 минут до конца работы я скормил GigaChat Audio сообщения по незаконченным делам и…
Мой промпт для GigaChat Audio: составь на основе присланных аудио короткий список тезисов. Одно сообщение — один тезис.
Итоговый план на завтра сберёг не только время, но и нервы — сам бы я думал о завтрашних делах всю дорогу домой, а так будущее понятно и чётко изложено.
«Вот список тезисов на основе присланных аудиосообщений:»
1. Продолжить срочный рефакторинг <название сервиса>, чтобы убрать технический долг и снизить риск инцидентов.
2. Поучаствовать в проектировании границ между <сервис 1> и <сервис 2> и их взаимодействия на встрече в 12:30.
3. Настроить подробную трассировку логов в <название сервиса>.
Итоги рабочего дня
Доволен ли я? Да, доволен. Мне хотелось, чтобы GigaChat Audio упростил мне работу со звуком, и он это сделал. В целом модель работает как хорошая контекстовыжималка, которая помогает быстро выхватить самые важные факты из записи. Но и косяки в итоговом тексте с фокусом на сложных технических задачах видны: информацию, полученную по хардкорным темам, лучше перепроверять.
Компонент эмпатичности меня привлёк больше всего: конкретно у меня нет никакой надобности читать с помощью GigaChat Audio чужие эмоции, но вот фиксировать с его помощью свои собственные и опять же возвращаться от чувств к фактам — помогает в определённых ситуациях.
Камень преткновения — запросы к мощностям: постоянно нагружать компьютер моделью я просто не могу, он мне необходим и для других задач. Поэтому первый день тестов ассистент достойно выдержал, а я теперь буду думать, как в будущем использовать его более эффективными способами.
Комментарии (2)
srzybnev
26.08.2026 10:33Статью не читал, как увидел что у автора статьи 128 гб DDR5 захотел написать: ЛОВИТЕ МИЛЛИОНЕРА хахахахх
antirek
круто, пробовали распознавать звонки? с диаризацией справляется?