Multimodal AI

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

Что такое мультимодальный ИИ и какую задачу он решает

Мультимодальный ИИ относится к семейству генеративных моделей на архитектуре трансформер. От обычной большой языковой модели (large language model, LLM) он отличается тем что перед языковой частью стоит дополнительный блок, который умеет превращать картинку или звук в последовательность векторов той же формы, что и векторы слов. Такие модели часто называют vision language model (VLM), если речь именно про пару изображение плюс текст.

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

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

Архитектура мультимодальной модели

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

• Энкодер модальности. Отдельная сеть под каждый нетекстовый вход. Для изображений это обычно vision transformer (ViT), который режет картинку на патчи и выдаёт по вектору на патч.
• Проектор. Небольшой обучаемый слой, который переводит выход энкодера в то же векторное пространство, где живут текстовые эмбеддинги. Без него языковая часть просто не поймёт пришедшие числа.
• Языковая модель. Обычный декодер-трансформер, который получает на вход смесь визуальных и текстовых векторов и генерирует ответ по одному токену за раз.

Таким образом, мультимодальность это не отдельная магия внутри нейросети, а аккуратная стыковка энкодера с языковой моделью через проектор. Языковая часть при этом почти не меняется. Меняется только то, что приходит ей на вход.

Раннее и позднее слияние модальностей

Способов соединить модальности два, и выбор между ними определяет, что модель вообще способна заметить. При позднем слиянии (late fusion) каждая модальность обрабатывается своей моделью до конца, а объединяются уже готовые результаты, например текстовое описание картинки и вопрос пользователя. При раннем слиянии (early fusion) векторы разных модальностей попадают в общий поток на входе языковой модели и дальше проходят через все слои внимания вместе.

Разница видна на практике. Позднее слияние дешевле и позволяет собрать систему из готовых кусков, но теряет всё, что не попало в промежуточное описание — интонацию, расположение элементов на странице, мелкие детали. Раннее слияние сохраняет полную картину, потому что языковая часть видит визуальные векторы напрямую, но обходится дороже и требует совместного обучения. Современные фронтирные модели вроде Gemini и Llama 4 строятся именно на раннем слиянии и обучаются на смеси модальностей сразу, а не дообучаются на картинки после текста. Цена такого выбора известна заранее. Это вычисления.

Принцип работы, как изображение превращается в токены

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

Дальше начинаются инженерные детали, ради которых стоит читать технический отчёт Qwen2.5-VL, семейства открытых мультимодальных моделей от команды Qwen в Alibaba Group. Там визуальный энкодер обучен работать с родным разрешением картинки, без приведения всего к одному квадрату, и использует оконное внимание, чтобы стоимость не росла квадратично от числа патчей. Позиционное кодирование при этом разложено на три составляющие: время, высота и ширина, что позволяет одинаково описывать и статичную картинку, и кадр видео.

Как следствие, у мультимодальной модели появляется свойство, которого нет у текстовой. Длина промпта начинает зависеть не только от того, что вы написали, но и от размера файла, который вы приложили. Об этом легко забыть. Счёт напомнит.

Сколько токенов стоит одна картинка

Это тот раздел, который обычно пропускают, а потом удивляются счёту за API. Разные вендоры считают визуальные токены по-разному, но общая логика одна: картинку делят на тайлы и берут фиксированную цену за каждый. В документации Gemini по работе с изображениями формула описана явно. Картинка, у которой обе стороны не больше 384 пикселей, стоит 258 токенов. Изображение крупнее режется на тайлы 768 на 768, и каждый тайл снова стоит 258 токенов. Размер тайла считается как минимальная сторона, делённая на полтора, поэтому кадр 960 на 540 даёт шесть тайлов.

Локальные модели ведут себя похоже, но с собственными порогами. Ниже реальные числа с нашего стенда, когда  одна и та же таблица подавалась в модель qwen2.5vl:7b через Ollama в трёх разрешениях, вопрос при этом не менялся.

Из таблицы видно две вещи.

• Во-первых, у препроцессора есть нижняя граница: крошечная картинка апскейлится и стоит ровно столько же, сколько картинка вчетверо крупнее по каждой стороне. Экономить, ужимая файл до размера почтовой марки, бессмысленно. Первая строка таблицы при этом заняла 17 секунд не из-за размера: на неё пришлась загрузка весов модели в память.
• Во-вторых, на большом разрешении промпт вырастает в 3.7 раза, а время ответа на локальном железе уходит с секунд на полторы минуты. Разрешение входа это параметр производительности, а не мелочь оформления. Его стоит задавать явно. И замерять на своих данных.

Практика, мультимодальная модель на локальной машине

Проверить всё описанное можно без облака и без ключей. Нужны Ollama и модель с поддержкой зрения, в нашем случае qwen2.5vl:7b весом около шести гигабайт. Ключи не нужны. Интернет тоже, после загрузки модели.

По традиции весь код используемый в статье выкладываем на наш GitHub репозиторий

Файл make_sample.py рисует тестовую таблицу продаж по кварталам и заодно отдаёт её же обычным текстом. Синтетика здесь удобнее фотографии: правильный ответ известен заранее, поэтому видно, прочитала модель данные или придумала.

# Pillow 12.3.0, Python 3.12.13, прогнано на стенде 2026-08-24
from PIL import Image, ImageDraw

ROWS = [
    ("Квартал", "Выручка, млн", "Заказы"),
    ("Q1", "12.4", "1840"),
    ("Q2", "15.9", "2110"),
    ("Q3", "11.2", "1605"),
    ("Q4", "18.7", "2480"),
]

# Тот же контент, но текстом. Нужен второму демо для честного сравнения.
AS_TEXT = "\n".join(" | ".join(row) for row in ROWS)


def build(path="sales_table.png", width=1200, height=800):
    """Рисует таблицу и сохраняет её в PNG заданного размера."""
    img = Image.new("RGB", (width, height), "white")
    draw = ImageDraw.Draw(img)
    cell_w, cell_h = width // 3, height // (len(ROWS) + 2)
    top = cell_h  # отступ сверху, чтобы таблица не липла к краю
    for r, row in enumerate(ROWS):
        for c, text in enumerate(row):
            x0, y0 = c * cell_w, top + r * cell_h
            draw.rectangle([x0, y0, x0 + cell_w, y0 + cell_h], outline="black", width=3)
            # шрифт по умолчанию мелкий, поэтому увеличиваем его масштабом
            draw.text((x0 + 20, y0 + cell_h // 2 - 10), text, fill="black", font_size=36)
    img.save(path)
    return path

Второй файл, text_vs_image.py, задаёт один и тот же вопрос дважды: сначала таблицей-картинкой, потом той же таблицей текстом. Модель и вопрос не меняются, меняется только модальность входа.

# ollama 0.6.2, модель qwen2.5vl:7b, Ollama 0.32.13, прогнано на стенде 2026-08-24
import time

import ollama

from make_sample import AS_TEXT, build

MODEL = "qwen2.5vl:7b"
QUESTION = "В каком квартале выручка максимальная и чему она равна?"


def run(label, message):
    """Один запрос к модели с замером токенов промпта и времени."""
    started = time.time()
    reply = ollama.chat(
        model=MODEL,
        messages=[message],
        options={"num_ctx": 8192, "temperature": 0},
    )
    print(
        f"{label}: токенов промпта {reply['prompt_eval_count']}, "
        f"время {round(time.time() - started, 1)} с"
    )
    print(f"  ответ: {reply['message']['content'].strip()}")


def main():
    path = build("sales_table.png", 1200, 800)
    print(f"модель {MODEL}, вопрос: {QUESTION}")
    # модальность 1: та же таблица картинкой
    run("картинка", {"role": "user", "content": QUESTION, "images": [path]})
    # модальность 2: та же таблица обычным текстом
    run("текст", {"role": "user", "content": f"{QUESTION}\n\n{AS_TEXT}"})


if __name__ == "__main__":
    main()

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

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

Сценарии использования и отличительные черты

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

• Разбор документов. Скан счёта или договора, где важна не только строка текста, но и её позиция в таблице или подпись под печатью.
• Визуальный контроль качества. Фотография узла на линии и вопрос, есть ли дефект, без обучения отдельного детектора под каждый тип брака.
• Анализ интерфейсов. Скриншот приложения и запрос на описание того, что видит пользователь, вплоть до координат элементов.
• Работа с видео. Поиск момента в записи по текстовому описанию события, когда расшифровки звука недостаточно.

Общее у этих сценариев одно: смысл заперт в неструктурированном формате, и вытащить его классическими средствами дорого. Раньше на это уходили месяцы разметки. Практический разбор того, как собирают такие модели своими руками, есть в материале блога про разработку мультимодальных ML-моделей с TorchMultimodal.

Обратная сторона тоже есть, и о ней говорят реже. Мультимодальный вход дороже текстового в разы, задержка растёт вместе с разрешением, а точность на мелких деталях остаётся слабым местом: наш прогон это наглядно показал. Кроме того, модель не сообщает, что чего-то не разглядела, она уверенно называет число из соседней колонки. Тихая ошибка хуже громкой. Поэтому в задачах, где цена ошибки высока, ответ по картинке проверяется отдельно, а сам конвейер проектируется с оглядкой на нагрузку и стоимость. Тем, кто собирает такие системы в продакшене, эти вопросы разбирают на курсе Нейросети на Python.

Заключение

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

Референсные ссылки

• Qwen2.5-VL Technical Report, технический отчёт команды Qwen про визуальный энкодер с родным разрешением и оконным вниманием
• Image understanding, официальная документация Gemini API с формулой подсчёта токенов на изображение и лимитами
• Understand and count tokens, официальная документация Gemini API про подсчёт токенов по модальностям
• Vision, официальная документация Ollama про работу с мультимодальными моделями локально
• Разработка мультимодальных ML-моделей с TorchMultimodal, статья блога BigDataSchool про сборку мультимодальных моделей