llama.cpp AI LLM Engine — Как это работает

Предисловие

llama.cpp — это программа (движок) для запуска больших языковых моделей (LLM) на компьютере или на мобильных устройствах — на процессоре (CPU) или видеокарте (GPU); я написал приложение Offline AI Launcher, которое позволяет использовать этот же движок на Android.

Зачем это нужно:

• чтобы получать ответы от нейросетевых моделей (чат, дополнение текста, код) без отправки данных в облако;
• выбор языка C++ нужен для быстрой работы с памятью и железом; один и тот же код собирается под Windows, Linux, macOS и Android.

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

Движок работает с форматом файлов GGUF. GGUF — формат, в котором лежит сохранённая модель:

• «веса» (числа нейросети);
• метаданные (размеры, тип архитектуры);
• словарь (соответствие «текст ↔ числа» для токенов).

По сути это один файл-контейнер, из которого движок читает всё нужное в память. Поддерживается квантизация (уменьшение размера модели за счёт более грубого хранения чисел) и гибридные вычисления (часть на CPU, часть на GPU). Модели в формате GGUF можно брать с Hugging Face.

Цель статьи — по шагам разобрать, как в llama.cpp устроен инференс: от загрузки модели до появления очередного токена в ответе.

Токен — это число, соответствующее кусочку текста (слову или части слова); модель работает только с числами, а словарь переводит «текст → токены» и обратно.

Статья выстроена как сценарий:

• сначала подготовка (инициализация, загрузка модели, создание контекста);
• затем генерация по запросу (токенизация, батч, decode, сэмплинг).

С какими моделями работает движок:

• LLaMA (Meta);
• Qwen (Alibaba);
• Gemma (Google);
• Mistral;
• Phi и другие.

Отличия — в размере, длине контекста и деталях; в коде это разные гиперпараметры и тензоры весов. Общий сценарий один и тот же.

В каких проектах используется:

• LM Studio;
• Ollama;
• GPT4All;
• Offline AI Launcher (запуск моделей на смартфоне);
• KoboldCpp;
• Text Generation WebUI.

Репозиторий: github.com/ggml-org/llama.cpp. Код в статье приведён по ветке master на коммите 8887a48f, сразу после релиза b10736; в другой версии детали могут отличаться.

Как читать статью:

• разделы идут в порядке выполнения сценария;
• в каждом разделе для действия даётся цитата из кода и объяснение, что происходит и для чего;
• файлы исходников указаны в тексте;
• статья рассчитана на неподготовленного читателя: все термины объясняются в глоссарии в начале статьи, все шаги снабжены цитатами кода и пояснениями.

Глоссарий терминов

Батч (batch) — набор токенов (или эмбеддингов), позиций и флагов логитов, обрабатываемых за один вызов decode. При Prefill в батче много токенов промпта; при Decode — один новый токен.

Бэкенд (backend) — «движок» вычислений: CPU или видеокарта (GPU). Планировщик распределяет узлы графа по бэкендам.

Decode — этап генерации по одному токену: в батче один новый токен, граф вычисляет логиты для этой позиции, K и V дописываются в KV-cache.

Эмбеддинг (embedding) — вектор чисел, в который превращается токен перед подачей в слои модели; одна строка матрицы эмбеддингов модели.

EOS (end of sequence) — специальный токен «конец вывода»; по нему приложение прекращает генерацию.

GGUF — формат файла модели: заголовок, метаданные (ключ–значение), данные тензоров. Поддерживается квантизация и mmap.

Гиперпараметры (hparams) — числа, задающие размеры модели: длина контекста, число слоёв, размер эмбеддинга, число голов внимания и т.д.

Инференс — процесс получения ответа от модели: подаётся промпт, модель по шагам выдаёт следующий токен.

KV-cache — кэш ключей и значений механизма внимания; хранит уже посчитанные K и V по всем предыдущим позициям, чтобы не пересчитывать их на каждом шаге.

Логиты (logits) — «сырые» оценки модели по каждому токену словаря перед softmax; по ним сэмплер выбирает следующий токен.

Prefill — этап обработки промпта: в батче все (или много) токенов промпта, для них считаются K и V и записываются в KV-cache.

Сэмплинг — выбор одного токена по логитам (жадный, случайный с temperature/top_p и т.д.).

Тензор — многомерный массив чисел (веса модели, эмбеддинги, ключи, значения, логиты и т.д.).

Токен — целое число (ID), соответствующее кусочку текста (слову или части слова); модель работает только с токенами.

Токенайзер — компонент словаря, превращающий текст в токены (SPM, BPE и т.д.) и обратно.

Вычислительный граф — список операций (матрицы, сложения, активации) и связей между ними; по нему движок выполняет все вычисления модели.

Подбатч (ubatch) — часть батча, которая обрабатывается за один вызов process_ubatch. Если промпт длиннее n_ubatch, батч разбивается на подбатчи по n_ubatch токенов; каждый подбатч прогоняется через модель по очереди.

Для чего:

• чтобы ограничить пиковое потребление памяти при длинном промпте.

Планировщик (sched) — компонент GGML, который распределяет узлы вычислительного графа по бэкендам (CPU, GPU) и выделяет под граф буферы на этих устройствах. При выполнении графа планировщик обходит узлы в топологическом порядке и запускает операции на выбранных устройствах.

Схема процесса: все шаги по порядку

Ниже — вся цепочка от запуска движка до появления очередного токена в ответе. Каждый пункт дальше в статье разбирается подробно, с цитатами кода и пояснениями.

Подготовка (один раз при старте или смене модели):

• шаг 1: инициализация бэкенда (llama_backend_init)
• шаг 2: загрузка модели из файла (llama_model_load_from_file → загрузчик GGUF)
• шаг 3: определение типа модели — архитектура, уже прочитанная загрузчиком из ключа GGUF general.architecture, определяет, какой класс модели создаётся (llama_model_create)
• шаг 4: загрузка гиперпараметров — размеры, контекст (load_hparams)
• шаг 5: загрузка словаря и токенайзера (load_vocab)
• шаг 6: загрузка весов в память или на GPU (load_tensors)
• шаг 7: создание контекста инференса — KV-cache, планировщик (llama_init_from_model).

Генерация (для каждого сообщения и каждого нового токена в ответе):

• шаг 8: приходит текст промпта от пользователя
• шаг 9: токенизация — текст превращается в последовательность токенов (llama_tokenize)
• шаг 10: формирование батча — токены упаковываются для одного вызова (llama_batch_get_one или common_batch_add), а внутри вызова батч проверяется и раскладывается (balloc->init)
• шаг 11: llama_decode — точка входа шага генерации: батч проверяется и передаётся во внутренний путь декодирования (llama_context::decode)
• шаг 12: батч при длинном промпте разбивается на подбатчи (memory->init_batch)
• шаг 13: каждый подбатч прогоняется через модель: построение графа → выполнение на CPU/GPU (process_ubatch → build_graph → graph_compute)
• шаг 14: логиты копируются с выхода графа в буфер контекста — по одной строке на каждую позицию, помеченную в батче на вывод; в цикле генерации это только последняя позиция
• шаг 15: сэмплинг — по логитам выбирается один следующий токен
• шаг 16: если токен завершает генерацию (llama_vocab_is_eog — сюда входят EOS, EOT и другие токены конца генерации), цикл завершается; иначе токен переводится в текст и выводится (llama_token_to_piece), из этого одного токена собирается новый батч, и управление возвращается к шагу 11.

Общий процесс инференса LLM

Выше дана схема: что за чем происходит. По смыслу процесс делится на два этапа. Первый — подготовка: инициализация бэкенда, загрузка модели из GGUF (архитектура, гиперпараметры, словарь, веса) и создание контекста. Он выполняется один раз при старте или при смене модели. Второй этап — генерация: при каждом сообщении пользователя текст превращается в токены, упаковывается в батч, прогоняется через модель (llama_decode), из логитов выбирается следующий токен, он переводится в текст и выводится; цикл повторяется до токена «конец вывода» (EOS) или лимита. Этот цикл повторяется для каждого нового сообщения и для каждого нового токена в ответе. Ниже каждый шаг из схемы разбирается по отдельности: что именно вызывается в коде, что происходит и что может быть неочевидно неподготовленному читателю.

Структура репозитория и основные файлы

В репозитории llama.cpp основные части движка разнесены по папкам и файлам.

Для чего так сделано:

• чтобы разнести ответственность: загрузка файла, модель, словарь, контекст и батч — в разных файлах;
• так проще искать код и отлаживать.

Ниже перечислены файлы, которые прямо относятся к загрузке модели и инференсу; для каждого указано, что в нём лежит и зачем это нужно.

Точка входа и загрузка модели:

• src/llama.cpp — здесь живут функции llama_backend_init, llama_model_load_from_file, llama_model_load (статическая).

  Для чего: это «входная дверь» в движок: приложение вызывает эти функции, чтобы инициализировать библиотеку и загрузить модель; здесь же создаётся загрузчик и запрашивается объект модели под архитектуру, прочитанную из файла. Саму фабрику llama_model_create (она спрашивает архитектуру у загрузчика через get_arch) этот файл только вызывает — живёт она в src/llama-model.cpp. Затем по очереди вызываются load_hparams, load_vocab и load_tensors.

• src/llama-model-loader.cpp — класс llama_model_loader: открытие GGUF-файла, построение индекса тензоров (weights_map), методы get_weight и get_tensor_meta для поиска тензора по имени и load_all_data для чтения самих данных тензоров.

  Для чего: загрузчик нужен, чтобы по имени тензора знать, где в файле лежат его данные и как их прочитать или отобразить в память (mmap); без него нельзя по шагам загружать архитектуру, гиперпараметры, словарь и веса.

Модель и словарь:

• src/llama-model.cpp — класс llama_model и его базовая реализация llama_model_base: методы load_hparams, load_vocab, load_tensors, создание тензоров и назначение буферов. То, что различается от архитектуры к архитектуре, вынесено в load_arch_hparams и load_arch_tensors, которые каждое семейство моделей реализует в своём файле в src/models/.

  Для чего: объект модели хранит всё, что прочитано из файла: тип архитектуры, гиперпараметры, словарь и сами веса (тензоры); методы load_* по очереди заполняют эти данные из загрузчика. Саму архитектуру определяют раньше, при создании объекта модели: llama_model_create спрашивает её у загрузчика (get_arch) и строит класс подходящего семейства.

• src/llama-vocab.cpp — класс llama_vocab, реализация llama_vocab::impl::load (загрузка словаря из GGUF), токенизация и обратный перевод токенов в текст (tokenize, token_to_piece, detokenize).

  Для чего: словарь нужен, чтобы превращать текст в числа (токены) при вводе и числа обратно в текст при выводе; без него модель не сможет ни принять промпт, ни выдать читаемый ответ.

Контекст и decode:

• src/llama-context.cpp — класс llama_context: создание контекста (память, планировщик, резерв графов), метод decode, process_ubatch, llama_get_logits_ith.

  Для чего: контекст — это «рабочая среда» одного сеанса генерации: в нём задаётся размер контекста, KV-cache, планировщик вычислений; метод decode прогоняет батч через модель и возвращает логиты.

• src/llama-graph.cpp — построение вычислительного графа: класс llm_graph_context с build_inp_embd (поиск эмбеддингов по таблице) и результат графа llm_graph_result с методами set_inputs и can_reuse.

  Для чего: граф — это то, что реально считается на decode: здесь собираются его входные узлы, перед запуском заполняются данными подбатча и решается, можно ли переиспользовать прошлый граф вместо того, чтобы строить его заново.

• src/llama-batch.cpp — класс llama_batch_allocr и его метод init (заполнение позиций и флагов логитов); сама структура llama_batch объявлена в include/llama.h.

  Для чего: батч — это «пакет» токенов для одного вызова decode; аллокатор проверяет батч и при отсутствии полей заполняет их (позиции из памяти, логиты только для последнего токена), чтобы вызывающему коду не нужно было вручную всё выставлять.

• src/llama-kv-cache.cpp — выделение и обновление KV-cache и его init_batch (разбиение на подбатчи и резервирование под них мест в кэше). Сам интерфейс объявлен отдельно, в src/llama-memory.h, потому что модель может использовать память другого рода — рекуррентное состояние или гибрид, — и каждый вариант реализует тот же init_batch в своём файле.

  Для чего: KV-cache хранит уже посчитанные ключи и значения по всем предыдущим позициям, чтобы не пересчитывать их на каждом шаге; init_batch разбивает большой батч на подбатчи ограниченного размера, чтобы не переполнить память.

• src/llama-sampler.cpp — сэмплеры и цепочка из них: llama_sampler_chain_init, llama_sampler_chain_add, llama_sampler_sample.

  Для чего: после decode логиты ещё нужно превратить в один токен: цепочка по очереди прогоняет сэмплеры и возвращает выбранный токен.

Библиотеки и бэкенды:

• ggml/ (каталог внутри репозитория — библиотека лежит прямо здесь, а не подключена подмодулем) — вычислительный граф (GGML), типы тензоров, планировщик (ggml_backend_sched) и бэкенды CPU/GPU; публичные заголовки — в ggml/include/, бэкенды — в подкаталогах ggml/src/.

  Для чего: граф описывает, какие операции (умножения матриц, активации и т.д.) выполнить и в каком порядке; планировщик решает, на каком устройстве (CPU или GPU) считать каждый узел графа.

• gguf (ggml/include/gguf.h и ggml/src/gguf.cpp — часть ggml, а не отдельная библиотека) — чтение и запись формата GGUF: заголовок, метаданные и тензоры.

  Для чего: формат GGUF задаёт, как в файле лежат заголовок, метаданные и данные тензоров; эти функции читают их без ручного разбора байтов.

• include/llama.h — заголовок API для приложений: объявления llama_model_load_from_file, llama_context, llama_decode, llama_tokenize, llama_get_logits_ith, сэмплеры и т.д.

  Для чего: приложение подключает этот заголовок и вызывает объявленные функции, не заходя во внутренние файлы движка.

Основные типы и структуры (справочно)

Для ориентирования в коде полезно знать основные типы. Ниже — что хранит каждый тип и для чего он нужен.

Основные структуры:

• llama_model — объект загруженной модели. В нём хранятся: гиперпараметры (hparams), словарь (vocab), тензоры весов, список устройств (devices), разбиение слоёв по CPU/GPU.

  Для чего: модель — это всё, что прочитано из файла и нужно для вычислений; один объект модели можно использовать для нескольких контекстов (несколько сеансов генерации).

• llama_context — контекст инференса. В нём: ссылка на модель, параметры контекста (cparams: n_ctx, n_batch, n_ubatch, n_threads и т.д.), аллокатор батча (balloc), память KV-cache (memory), планировщик (sched), последний построенный граф, сохранённый для переиспользования (gf_res_prev), буфер логитов.

  Для чего: контекст — «рабочая среда» одного сеанса: размер контекста, кэш ключей и значений, планировщик и графы для decode; при каждом запросе вызывается decode именно для этого контекста.

• llama_batch — массив токенов (или эмбеддингов), позиций, идентификаторов последовательностей и флагов логитов.

  Для чего: один вызов llama_decode принимает один батч; в нём передаётся, какие токены обработать, на каких позициях и для каких позиций вернуть логиты (обычно только для последней).

• llama_model_loader — загрузчик GGUF. В нём: метаданные, прочитанные из файла (metadata), карта тензоров (weights_map), открытые файлы (files) и их отображения в память (mappings).

  Для чего: загрузчик живёт только во время загрузки модели; по нему по очереди читаются архитектура, гиперпараметры, словарь и тензоры; после загрузки он не нужен.

• ggml_context — контекст графа GGML: в нём создаются узлы и тензоры графа.

  Для чего: граф описывает последовательность операций (умножения, активации и т.д.); все узлы графа создаются в одном таком контексте.

• ggml_backend_sched — планировщик: список бэкендов и логика распределения узлов графа по устройствам.

  Для чего: планировщик решает, на каком устройстве (CPU или GPU) выполнять каждый узел графа, и выделяет под граф буферы на этих устройствах.

Что возвращают основные функции:

• llama_model_load_from_file возвращает llama_model* или nullptr при ошибке.

  Для чего: приложение проверяет указатель: если не nullptr, модель загружена и можно создавать контекст.

• llama_model_load — вспомогательная функция внутри src/llama.cpp, в публичном заголовке её нет — возвращает пару из статуса и модели: 0 при успехе, -1 при ошибке, -2 при отмене по колбэку прогресса.

  Для чего: при отрицательном статусе указатель на модель возвращается уже нулевым, так что вызывающий код только пишет в лог причину и возвращает приложению nullptr.

• llama_decode возвращает 0 при успехе. Положительное значение — это предупреждение, а не фатальная ошибка: 1 означает, что для этого батча не нашлось свободного места в KV-cache (нужно уменьшить батч или увеличить контекст), 2 — что вызов был прерван. -1 означает, что некорректен сам батч, всё, что меньше -1, — фатальная ошибка.

  Для чего: приложение по возврату понимает, удалось ли выполнить decode и можно ли читать логиты; при 1 можно повторить с батчем поменьше, а после 2 или фатальной ошибки часть батча уже попала в память контекста, так что докуда он дошёл, приходится спрашивать у контекста отдельно.

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

  Для чего: чтобы знать, сколько элементов массива токенов заполнено и какого размера должен быть массив.

• llama_get_logits_ith возвращает указатель на массив float размером n_vocab — логиты i-го токена последнего decode; при неотрицательном i аргумент — это индекс токена внутри батча, который контекст переводит в строку выходов через output_ids, так что для токена, логиты которого не запрашивали, вернётся NULL; отрицательный индекс отсчитывается по строкам выходов, то есть -1 — последняя. При некорректном индексе возвращается NULL.

  Для чего: по этому массиву сэмплер выбирает следующий токен (по одному числу на каждый токен словаря); в цикле это почти всегда индекс -1, только что посчитанная позиция.

Шаг 1: Инициализация бэкенда

Шаг 1 в схеме процесса — инициализация бэкенда. Перед загрузкой модели и инференсом приложение один раз вызывает llama_backend_init(). Вызов делает три вещи: запускает точный таймер, по которому потом замеряют время загрузки и decode, создаёт и тут же освобождает пустой контекст GGML и — это главное — заполняет реестр бэкендов, если тот ещё пуст, чтобы движку было на чём считать: процессор, а если для видеокарты есть бэкенд, то и она. Без зарегистрированного бэкенда загрузка не деградирует молча, а падает: движок возвращает nullptr и пишет, что бэкенды не загружены. Ниже — цитата целиком и по фрагментам (файл src/llama.cpp).

// Шаг 1: единственная точка входа инициализации движка; вызывается один раз при старте приложения
void llama_backend_init(void) {
    ggml_time_init();  // точный таймер; на Windows его нужно инициализировать явно

    // нужно для инициализации таблиц f16
    {
        struct ggml_init_params params = { 0, NULL, false };
        struct ggml_context * ctx = ggml_init(params);
        ggml_free(ctx);
    }

    // если ещё ничего не зарегистрировано — подтянуть бэкенды (CPU, CUDA, Metal, Vulkan ...);
    // именно это даёт движку устройства, на которых он будет считать
    if (!ggml_backend_reg_count()) {
        ggml_backend_load_all();
    }
}

Что в коде происходит по шагам:

// Фрагмент 1: таймер нужен, чтобы потом замерить время загрузки модели и время decode
ggml_time_init();

// Фрагмент 2: временный контекст с нулевым буфером — создаётся и тут же освобождается.
// Комментарий в исходниках называет это «инициализацией таблиц f16», но в нынешнем ggml первый
// вызов ggml_init() только запускает таймер — блок остался как рудимент и ничего не стоит
struct ggml_init_params params = { 0, NULL, false };
struct ggml_context * ctx = ggml_init(params);
ggml_free(ctx);

// Фрагмент 3: содержательная часть — если реестр пуст, загрузить библиотеки бэкендов
// (CPU, CUDA, Metal, Vulkan и так далее); без них считать не на чем
if (!ggml_backend_reg_count()) {
    ggml_backend_load_all();
}

Сначала включается таймер — потом по нему замеряют время загрузки и время decode. Затем создаётся и сразу освобождается временный контекст GGML с нулевым буфером; комментарий рядом с ним в исходниках по-прежнему говорит, что так инициализируются таблицы f16, но в нынешнем ggml первый вызов ggml_init только запускает таймер, а таблицы для половинной точности строятся позже, когда регистрируется бэкенд CPU. Настоящую работу делает последний блок: если ни один бэкенд ещё не зарегистрирован, ggml_backend_load_all ищет библиотеки бэкендов и регистрирует те, что нашлись. После этого движок знает, на каких устройствах он может считать, и готов к загрузке модели и построению графа.

Шаг 2а: Загрузка модели из файла (точка входа)

Шаг 2 — загрузка модели из файла. Она начинается с вызова llama_model_load_from_file: приложение передаёт путь к .gguf и параметры, движок возвращает готовый объект модели или nullptr при ошибке.

Для чего эта функция:

• она — единственная точка входа для загрузки модели из файла;
• приложение передаёт путь к файлу и параметры, движок возвращает готовый объект модели или nullptr при ошибке.

Цитата из кода (файл src/llama.cpp):

// Точка входа загрузки модели (шаг 2): путь к .gguf и параметры загрузки
struct llama_model * llama_model_load_from_file(
        const char * path_model,
        struct llama_model_params params) {
    // splits — пути к частям разбитой модели; здесь пусто, загрузчик выведет их сам
    std::vector<std::string> splits = {};
    // три nullptr и FILE * — это остальные возможные источники модели
    // (подготовленные в памяти метаданные GGUF и уже открытый файл); задан может быть только один
    return llama_model_load_from_file_impl(nullptr, nullptr, nullptr, path_model, splits, /*file*/ nullptr, params);
}

Функция принимает путь к файлу модели (обычно .gguf) и параметры загрузки — приложение указывает, откуда читать модель, как её читать и сколько слоёв положить на видеокарту. splits здесь всегда пустой: если в метаданных сказано, что модель разбита на несколько файлов, пути к частям загрузчик выводит из имени файла сам — поэтому это имя и должно следовать шаблону <name>-00001-of-00003.gguf. Явный список частей передают через отдельную точку входа — llama_model_load_from_splits. Всё остальное — проверка, что бэкенд зарегистрирован, колбэк прогресса по умолчанию, вызов llama_model_load и обработка его результата — происходит в llama_model_load_from_file_impl.

Параметры загрузки (llama_model_params), важные для понимания:

• load_mode — как читать файл: mmap, mlock, прямой ввод-вывод или обычное чтение в буфер.

  Для чего: mmap экономит RAM и ускоряет старт загрузки, потому что файл отображается, а не копируется; прямой ввод-вывод на некоторых дисках и системах даёт более предсказуемую скорость чтения. По умолчанию — auto: движок выбирает mmap и откатывается на обычное чтение, если какое-то из устройств не умеет работать с отображённой памятью. Внутри загрузчика это одно значение снова превращается в два флага — use_mmap и use_direct_io; именно в таком виде оно встречается дальше.

• n_gpu_layers — сколько слоёв загружать на GPU (остальные на CPU).

  Для чего: чтобы часть вычислений шла на видеокарте, часть на процессоре.

• progress_callback — колбэк прогресса загрузки.

  Для чего: приложение может показывать прогресс-бар или отменять загрузку (вернуть false).

• vocab_only — загрузить только словарь (без весов).

  Для чего: когда нужен только токенайзер, без тяжёлых весов. Полный список параметров — в include/llama.h в структуре llama_model_params.

Шаг 2б: Подготовка к чтению файла

Шаг 2 (продолжение) — внутри точки входа выполняется подготовка к чтению файла. В llama_model_load_from_file_impl выполняется основная подготовка перед чтением файла.

Для чего так:

• перед загрузкой нужно убедиться, что модель берётся ровно из одного источника, что есть бэкенд для вычислений, и настроить отображение прогресса;
• только после этого вызывается внутренняя функция llama_model_load, которая читает файл по шагам.

Цитата начала функции (файл src/llama.cpp):

static struct llama_model * llama_model_load_from_file_impl(
        struct gguf_context * metadata,
        llama_model_set_tensor_data_t set_tensor_data,
        void * set_tensor_data_ud,
        const std::string & path_model,
        std::vector<std::string> & splits,
        FILE * file,
        struct llama_model_params params) {
    // ... опущено: проверка, что задан ровно один источник — metadata, path_model или file
    ggml_time_init();  // таймер для замеров времени загрузки

    // Если загружаем не только словарь — проверяем, что зарегистрирован хотя бы один бэкенд
    if (!params.vocab_only && ggml_backend_reg_count() == 0) {
        LLAMA_LOG_ERROR("%s: no backends are loaded. hint: use ggml_backend_load() or ggml_backend_load_all() to load a backend before calling this function\n", __func__);
        return nullptr;
    }

    unsigned cur_percentage = 0;
    // Если колбэк прогресса не передан — подставляем свой: выводим точки до 100%
    if (params.progress_callback == NULL) {
        params.progress_callback_user_data = &cur_percentage;
        params.progress_callback = [](float progress, void * ctx) {
            unsigned * cur_percentage_p = (unsigned *) ctx;
            unsigned percentage = (unsigned) (100 * progress);
            while (percentage > *cur_percentage_p) {
                *cur_percentage_p = percentage;
                LLAMA_LOG_CONT(".");
                if (percentage >= 100) {
                    LLAMA_LOG_CONT("\n");
                }
            }
            return true;  // не отменяем загрузку
        };
    }

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

Что происходит в этом фрагменте и для чего:

• ggml_time_init() — включается таймер.

  Для чего: чтобы потом замерить, сколько заняла загрузка.

• Проверка ggml_backend_reg_count() == 0 — есть ли хотя бы один бэкенд (CPU или GPU).

  Для чего: без бэкенда нельзя будет выполнять вычисления модели; при загрузке только словаря (vocab_only) бэкенд не обязателен.

• Настройка колбэка прогресса — если приложение не передало свой, подставляется колбэк по умолчанию, который выводит точки.

  Для чего: пользователь видит, что загрузка идёт; при желании можно передать свой колбэк и показывать прогресс-бар или отменять загрузку (вернуть false).

• Сам объект модели здесь не создаётся. Он появляется уровнем ниже, внутри llama_model_load, в вызове llama_model_create — и только после того, как открыт загрузчик GGUF.

  Для чего: класс объекта зависит от архитектуры, записанной в файле (LLaMA, Gemma, Qwen и так далее), поэтому сначала нужно прочитать архитектуру из GGUF; гиперпараметры, словарь и тензоры записываются уже в этот объект.

Остальная часть функции — это только вызов внутреннего загрузчика и обработка его результата (тот же файл, конец llama_model_load_from_file_impl):

    // Внутренняя загрузка: читает файл и собирает модель (arch, hparams, vocab, tensors)
    const auto [status, model] = llama_model_load(metadata, set_tensor_data, set_tensor_data_ud, path_model, splits, file, params);
    GGML_ASSERT(status <= 0);
    if (status < 0) {
        if (status == -1) {
            LLAMA_LOG_ERROR("%s: failed to load model\n", __func__);
        } else if (status == -2) {
            LLAMA_LOG_INFO("%s: cancelled model load\n", __func__);
        }

        if (model) {
            llama_model_free(model);
        }
        return nullptr;
    }

    return model;
}

• Список устройств тоже строится уровнем ниже, в llama_prepare_model_devices, которую llama_model_load вызывает сразу после создания объекта модели; результат попадает в model->devices.

  Для чего: от него зависит, по каким ускорителям будут распределены слои модели (см. load_tensors). В этот список попадают только графические устройства — сначала удалённые RPC-серверы, затем дискретные видеокарты, а встроенные — только если дискретной не нашлось; CPU обрабатывается отдельно и в него не входит.

• llama_model_load — читает файл и по шагам заполняет модель: создаёт загрузчик GGUF, определяет архитектуру и создаёт под неё объект модели, выбирает устройства, а затем по очереди вызывает load_hparams, load_vocab и load_tensors.

  Для чего: вся логика чтения GGUF и заполнения модели сосредоточена в одной функции.

• При отрицательном статусе в лог пишется причина (-1 — ошибка загрузки, -2 — отмена колбэком прогресса) и возвращается nullptr. Вызов llama_model_free в этой ветке — только страховка: llama_model_load сама уничтожает недостроенную модель и при неудаче никогда не отдаёт указатель наружу.

  Для чего: приложение по nullptr понимает, что загрузка не удалась, и не использует неполную модель.

Колбэк прогресса вызывается внутри load_tensors при чтении каждого тензора: ему передаётся число от 0.0 до 1.0 (доля загруженных данных). Если колбэк возвращает false, загрузка прерывается и llama_model_load возвращает -2 (отмена).

Для чего:

• приложение может отменить долгую загрузку или показывать прогресс-бар.

Шаги со 2 по 6 вместе: Пошаговая загрузка модели из файла

Шаги 2–6 выполняются внутри одной функции llama_model_load: создаётся загрузчик (шаг 2), затем создаётся объект модели для архитектуры, которую прочитал загрузчик (llama_model_create, шаг 3), а после него по очереди вызываются load_hparams (шаг 4), load_vocab (шаг 5) и load_tensors (шаг 6).

Для чего нужна функция llama_model_load: она выполняет пошаговую загрузку модели из файла: создаёт загрузчик GGUF (открывает файл и строит карту тензоров), создаёт объект модели нужной архитектуры, а затем по очереди загружает гиперпараметры, словарь и тензоры. Порядок важен: архитектура задаёт набор ключей в GGUF; гиперпараметры читаются по этим ключам; словарь загружается с учётом архитектуры; тензоры создаются по известным размерам и заполняются из файла.

Сокращённая цитата функции (файл src/llama.cpp, функция llama_model_load):

// src/llama.cpp — llama_model_load(); пустые строки и две обёртки try/catch убраны для краткости
// Возвращает 0 при успехе, -1 при ошибке и -2 при отмене через llama_progress_callback
static std::pair<int, llama_model *> llama_model_load(struct gguf_context * metadata, llama_model_set_tensor_data_t set_tensor_data, void * set_tensor_data_ud,
        const std::string & fname, std::vector<std::string> & splits, FILE * file, llama_model_params & params) {
    try {
        // Шаг 2: загрузчик открывает GGUF, читает заголовок и метаданные, строит карту тензоров (weights_map)
        llama_model_loader ml(metadata, set_tensor_data, set_tensor_data_ud, fname, splits, file, params.load_mode,
            params.check_tensors, params.no_alloc, params.load_mtp, params.kv_overrides, params.tensor_buft_overrides);
        ml.lazy.mode = params.lazy_mode;  // ленивое чтение тензоров: часть весов остаётся на диске и читается по требованию
        ml.print_info();
        // Шаг 3: архитектура, прочитанная загрузчиком, выбирает C++-класс модели
        std::unique_ptr<llama_model> model_ptr(llama_model_create(ml, params));
        // список устройств (CPU, GPU), по которым будет разложена именно эта модель
        bool ok = llama_prepare_model_devices(params, model_ptr.get());
        if (!ok) {
            return {-1, nullptr};
        }
        auto * model = dynamic_cast<llama_model_base *>(model_ptr.get());
        // ... опущено: проверка на null, прерывающая работу, если модель не реализует llama_model_base
        model->t_load_us = 0;
        time_meas tm(model->t_load_us);  // время загрузки будет пересчитано после первого eval, чтобы учесть промахи страниц, отложенные mmap
        model->t_start_us = tm.t_start_us;
        model->hparams.vocab_only = params.vocab_only;
        model->hparams.no_alloc   = params.no_alloc;
        // ... опущено: каждый из двух вызовов ниже обёрнут в try/catch, перебрасывающий ошибку с префиксом
        model->load_hparams(ml);  // Шаг 4: размеры модели, длина контекста, число слоёв
        if (model->arch == LLM_ARCH_CLIP) {
            throw std::runtime_error("CLIP cannot be used as main model, use it with --mmproj instead");
        }
        model->load_vocab(ml);    // Шаг 5: словарь и токенайзер — текст <-> токены
        model->load_stats(ml);
        model->print_info();
        if (params.vocab_only) {
            LLAMA_LOG_INFO("%s: vocab only - skipping tensors\n", __func__);
            return {0, model_ptr.release()};
        }
        // Шаг 6: веса модели из файла в память (или mmap) на CPU/GPU
        if (!model->load_tensors(ml)) {
            return {-2, nullptr};
        }
        return {0, model_ptr.release()};
    } catch (const std::exception & err) {
        LLAMA_LOG_ERROR("%s: error loading model: %s\n", __func__, err.what());
        return {-1, nullptr};
    }
}

Ошибки и отмена загрузки:

• при ошибке в любом из шагов (создание загрузчика, llama_model_create, load_hparams, load_vocab, load_tensors) выбрасывается исключение; в блоке catch логируется сообщение и возвращается -1;
• при отмене по колбэку прогресса (колбэк возвращает false внутри load_tensors) load_tensors возвращает false, исключение не выбрасывается, но llama_model_load возвращает -2 (отмена);
• при любой неудаче недостроенная модель уничтожается тут же: она живёт в unique_ptr, который отдаётся вызывающему коду только при успехе, поэтому llama_model_load_from_file_impl получает нулевой указатель, логирует причину и возвращает nullptr;
• таким образом, приложение может отменить долгую загрузку через колбэк и корректно освободить ресурсы.

По шагам (что происходит и для чего):

• создаётся загрузчик llama_model_loader ml(...) — он открывает GGUF-файл, читает метаданные и строит weights_map.

  Для чего:

• без загрузчика нельзя прочитать архитектуру, гиперпараметры, словарь и тензоры из файла.

• вызывается ml.print_info() — выводит в лог формат файла, тип файла (квантование) и размер файла вместе с числом бит на вес.

  Для чего:

• чтобы пользователь видел, какой именно файл открывается.

• вызывается llama_model_create(ml, params) — архитектура, прочитанная загрузчиком (LLaMA, Gemma, Qwen и т.д.), выбирает C++-класс модели, и объект создаётся.

  Для чего:

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

• вызывается llama_prepare_model_devices — строится и выводится в лог список устройств (CPU и видеокарты) для этой модели.

  Для чего:

• он определяет, по каким устройствам потом будут разложены слои в load_tensors.

• только теперь сбрасывается время загрузки и запускается таймер.

  Для чего:

• измеренное здесь значение — не окончательное: при первом eval llama_context пересчитывает время загрузки от сохранённого t_start_us, поэтому в отсчёт попадают и промахи страниц, отложенные mmap, — они случаются только тогда, когда до весов реально доберутся.

• вызывается model->load_hparams(ml) — читаем размерности и параметры (длина контекста, число слоёв и т.п.).

  Для чего:

• чтобы знать «форму» модели и выделить под неё память.

• для CLIP выбросится ошибка — его используют отдельно как проектор, не как основную модель.

• вызывается model->load_vocab(ml) — загружаем словарь токенов.

  Для чего:

• чтобы потом превращать текст в числа (токены) и обратно при генерации.

• load_stats(ml) копирует из загрузчика в модель число элементов и размер в байтах, а print_info() выводит в лог архитектуру и все гиперпараметры. Если загружаем только словарь (vocab_only == true), на этом выход. Иначе вызывается model->load_tensors(ml) — читаются и раскладываются по памяти веса модели. При успехе возвращается 0, при отмене (колбэк прогресса вернул false) — -2, при ошибке — -1.

Порядок вызовов при загрузке модели (сводка):

• llama_model_load_from_file → llama_model_load_from_file_impl;
• в impl: проверка, что источник модели задан ровно один раз, проверка бэкенда, колбэк прогресса по умолчанию и вызов llama_model_load(metadata, set_tensor_data, set_tensor_data_ud, path_model, splits, file, params);
• внутри llama_model_load: создание llama_model_loader, ml.print_info, llama_model_create, llama_prepare_model_devices, load_hparams, load_vocab, load_stats, print_info, при необходимости load_tensors. Все эти шаги выполняются последовательно; при ошибке в любом из них загрузка прерывается.

Порядок вызовов llama_model_create → load_hparams → load_vocab важен: архитектура задаёт набор ключей GGUF; гиперпараметры читаются по этим ключам; словарь загружается с учётом архитектуры (например, имена ключей для токенайзера). Поэтому vocab.load(ml, kv) вызывается именно после load_hparams(ml) — к этому моменту и архитектура, и гиперпараметры уже известны, и загрузчик может корректно прочитать тип токенайзера, списки токенов и слияния.

Шаг 2в: Загрузчик GGUF — открытие файла и карта тензоров

Шаг 2 (завершение) (внутри llama_model_load) — создаётся загрузчик GGUF: открывается файл, читаются заголовок и метаданные, строится карта тензоров.

Для чего нужен загрузчик GGUF: чтобы открыть файл модели, прочитать заголовок и метаданные (без самих весов) и построить «карту» — по имени тензора знать, где в файле лежат его данные и какого он размера. Без этой карты нельзя потом загружать веса по одному тензору. Тензоры здесь — многомерные массивы чисел (матрицы и векторы), в которых хранятся веса нейросети; каждый слой модели — это несколько тензоров, и загрузчик должен знать для каждого имя, размер и смещение в файле.

Создание загрузчика — вызов конструктора llama_model_loader. Сам конструктор находится в src/llama-model-loader.cpp; llama_model_load только вызывает его. Сокращённо он выглядит так:

// src/llama-model-loader.cpp - конструктор (шаг 2): открывает GGUF, читает заголовок и метаданные, строит карту тензоров
llama_model_loader::llama_model_loader(
        struct gguf_context * meta,
        llama_model_set_tensor_data_t set_tensor_data,
        void * set_tensor_data_ud,
        const std::string & fname,
        std::vector<std::string> & splits,
        FILE * file,
        llama_load_mode load_mode,
        bool check_tensors,
        bool no_alloc,
        bool load_mtp,
        const llama_model_kv_override * param_overrides_p,
        const llama_model_tensor_buft_override * param_tensor_buft_overrides_p)
        : metadata(meta), set_tensor_data(set_tensor_data), set_tensor_data_ud(set_tensor_data_ud) {
    // ... переопределения KV и превращение load_mode в use_mmap / use_direct_io ...
    if (!fname.empty()) {
        struct ggml_context * ctx = NULL;
        struct gguf_init_params params = {
            /*.no_alloc = */ true,  // создать только пустые тензоры, не читать блок данных
            /*.ctx      = */ &ctx,
        };
        metadata_ptr.reset(gguf_init_from_file(fname.c_str(), params));
        metadata = metadata_ptr.get();
        if (metadata == nullptr) {
            throw std::runtime_error(format("%s: failed to load model from %s", __func__, fname.c_str()));
        }
        // Имя архитектуры (llama, qwen2 ...) задаёт имена всех остальных ключей GGUF
        get_key(llm_kv(LLM_KV_GENERAL_ARCHITECTURE), arch_name, false);
        llm_kv = LLM_KV(llm_arch_from_string(arch_name));
        files.emplace_back(new llama_file(fname.c_str(), "rb", use_direct_io));
        contexts.emplace_back(ctx);
        for (ggml_tensor * cur = ggml_get_first_tensor(ctx); cur; cur = ggml_get_next_tensor(ctx, cur)) {
            std::string tensor_name = std::string(cur->name);
            if (weights_map.find(tensor_name) != weights_map.end()) {
                throw std::runtime_error(format("invalid model: tensor '%s' is duplicated", ggml_get_name(cur)));
            }
            n_elements += ggml_nelements(cur);
            n_bytes    += ggml_nbytes(cur);
            weights_map.emplace(tensor_name, llama_tensor_weight(files.back().get(), 0, metadata, cur));
        }
        // ... тот же цикл по файлам-частям, когда модель разбита на несколько ...
    }
    // ... ветки для уже открытого FILE * и для метаданных, переданных извне ...
    n_kv      = gguf_get_n_kv(metadata);
    n_tensors = weights_map.size();
    fver = (enum llama_fver) gguf_get_version(metadata);
    // ... угадывание типа файла и вывод пар KV в лог ...
}

В конструкторе gguf_init_from_file читает заголовок GGUF и метаданные (без самих весов) — так получают список тензоров и пары ключ–значение (архитектура, гиперпараметры) без чтения тяжёлых данных в память. Из метаданных берётся имя архитектуры (general.architecture) — от него зависят имена остальных полей в GGUF (у разных моделей разные ключи). Файл открывается для чтения; потом по смещениям из weights_map будут читаться или маппиться данные тензоров. По списку тензоров из GGUF для каждого в weights_map записывается имя, размер и смещение в файле — потом get_weight(name) находит запись в карте, а load_all_data читает байты по этому смещению (или, при mmap, сразу указывает на них).

Структура llama_tensor_weight (элемент weights_map) хранит три вещи: индекс исходного файла (модель может быть разбита на несколько частей GGUF), абсолютное смещение данных тензора в этом файле и указатель на тензор в контексте GGUF. Смещение вычисляется один раз, при создании записи, как начало секции данных плюс смещение тензора внутри неё — и тот же конструктор проверяет, что тензор целиком помещается в файл, так что обрезанная модель отсекается здесь, а не во время генерации. Метод ml.get_key(...) читает из метаданных GGUF значение по ключу (имя ключа зависит от архитектуры — его возвращает kv(...)). Так загрузчик получает, например, имя архитектуры, тип токенайзера, гиперпараметры.

После создания загрузчика в llama_model_load вызывается ml.print_info(). Цитата из кода:

// src/llama.cpp, внутри llama_model_load, сразу после создания загрузчика:
ml.print_info();  // пишет в лог версию GGUF, угаданный тип файла и общий размер весов

Функция gguf_init_from_file (библиотека GGUF) открывает файл и читает заголовок:

• версию формата;
• число ключей метаданных;
• число тензоров.

Метаданные читаются в контекст gguf_context (пары ключ–значение); сами данные тензоров на этом шаге не загружаются — только имена, типы и смещения в файле. Сам конструктор уже пишет в лог число пар ключ–значение, число тензоров, имя файла и версию GGUF. Метод print_info (src/llama-model-loader.cpp) добавляет ещё три строки:

• версию формата GGUF;
• тип файла — Q4_K - Medium и подобные, угаданный по самому частому типу тензоров, если метаданные не говорят его напрямую;
• общий размер весов в MiB или GiB вместе со средним числом бит на вес.

Формат GGUF (справочно)

GGUF (GPT-Generated Unified Format) — бинарный формат для хранения моделей машинного обучения.

Для чего он нужен:

• чтобы в одном файле хранить и веса модели, и метаданные (размеры, тип архитектуры), и словарь;
• загрузчик по заголовку и метаданным строит «карту» и потом по запросу читает нужные куски файла или маппит их в память (mmap).

Структура заголовка GGUF:

• магическое число, четыре байта GGUF (идентификация формата — по нему понимают, что это GGUF);
• версия формата (для совместимости при изменениях формата);
• число тензоров (n_tensors);
• число ключей метаданных (n_kv).

Метаданные хранятся как массив пар «ключ — значение». Для каждой пары записаны:

• имя ключа (строка с длиной, записанной перед ней);
• тип значения (строка, число, булево, массив и т.д.);
• само значение (имя архитектуры, размерности, параметры RoPE, тип токенайзера, списки токенов и т.д.); для массива сначала идут тип элементов и их количество, потом сами элементы.

Тензоры в файле идут после метаданных. Для каждого тензора записаны:

• имя;
• число размерностей и размер по каждой из них (не больше четырёх; например, [n_embd, n_ff] для весов полносвязного блока одного слоя — каждый слой это отдельный набор тензоров, поэтому номер слоя входит в имя, blk.0.ffn_up.weight, и никогда не бывает размерностью);
• тип элемента (F32, F16, Q8_0, Q4_K и т.д. — от полной точности до квантизованных форматов);
• смещение, по которому начинаются данные, — от начала блока данных тензоров, идущего после метаданных.

Имена вроде Q4_K_M описывают файл целиком, а не отдельный тензор: это рецепт, который кладёт разные тензоры в разные типы.

Зачем это загрузчику: по этой информации он строит weights_map (карту «имя тензора → где в файле лежат данные»), и когда веса действительно понадобятся, load_all_data читает или маппит соответствующий участок файла.

Версия формата и типы элементов:

• версия формата задаётся в заголовке GGUF.

  Для чего:

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

• по типу элемента тензора (F32, F16, Q8_0, Q4_K и т.д.) загрузчик знает, сколько байт занимает блок элементов — квантизованные типы хранят элементы блоками фиксированного размера с общим масштабом, а не по одному, — и как интерпретировать данные при копировании в буфер или при mmap.

  Для чего:

• без этого нельзя корректно прочитать или отобразить в память данные тензора; разные типы имеют разный размер и разную интерпретацию байтов.

Типы данных тензоров в GGUF задают, как интерпретировать байты: F32, F16, Q8_0, Q4_K и т.д. — от полной точности до квантизованных форматов. Квантизация уменьшает размер модели и ускоряет вычисления за счёт приближённого представления весов. Движок при загрузке создаёт тензоры в нужном формате и копирует или маппит данные из файла в буферы на CPU или GPU.

Чтение метаданных GGUF выполняется через функции библиотеки gguf:

• gguf_get_n_kv — число ключей;
• gguf_get_key — имя ключа по индексу;
• gguf_get_kv_type — тип значения (строка, число, массив и т.д.);
• gguf_find_key — индекс ключа по его имени или -1, если такого нет;
• gguf_get_val_* — значение по этому индексу, по функции на каждый тип.

Загрузчик модели оборачивает это в метод get_key(key, value) с учётом архитектуры: ключ преобразуется в имя поля в GGUF (например, llama.embedding_length для LLaMA).

Шаг 3: Определение типа модели (архитектура)

Шаг 3 — определение типа модели (LLaMA, Gemma, Qwen и т.д.) по имени архитектуры из GGUF. Работу делает фабричная функция llama_model_create в src/llama-model.cpp. Для чего это нужно: от архитектуры зависят имена ключей, которые читаются из метаданных GGUF, набор тензоров, создаваемых при загрузке весов, и построение вычислительного графа; без этого нельзя корректно прочитать гиперпараметры и словарь. В llama.cpp это не просто флаг: каждая архитектура — отдельный класс C++, и фабрика выбирает, какой из них создать. Цитата (файл src/llama-model.cpp, функция llama_model_mapping и две перегрузки llama_model_create):

// src/llama-model.cpp — архитектура из GGUF решает, какой класс C++ представляет эту модель
static llama_model * llama_model_mapping(llm_arch arch, const llama_model_params & params) {
    switch (arch) {
        case LLM_ARCH_LLAMA:
            return new llama_model_llama(params);
        // ... по одному case на каждую поддерживаемую архитектуру ...
        default:
            throw std::runtime_error(std::string("unsupported model architecture: '") + llm_arch_name(arch) + "'");
    }
}

llama_model * llama_model_create(llm_arch arch, const llama_model_params & params) {
    llama_model * model = llama_model_mapping(arch, params);

    if (model != nullptr) {
        model->arch = arch;
        // ... проверка, что запрошенный режим разбиения тензоров реализован для этой архитектуры ...
    }

    return model;
}

llama_model * llama_model_create(llama_model_loader & ml, const llama_model_params & params) {
    llm_arch arch = ml.get_arch();
    if (arch == LLM_ARCH_UNKNOWN) {
        throw std::runtime_error("unknown model architecture: '" + ml.get_arch_name() + "'");
    }

    return llama_model_create(arch, params);
}

Что происходит и для чего:

• ml.get_arch() возвращает enum llm_arch, который загрузчик уже определил по ключу general.architecture из метаданных GGUF.

  Для чего: дальше по этому enum выбираются имена полей для гиперпараметров и словаря (у разных архитектур — разные ключи в GGUF).

• Если тип неизвестен (LLM_ARCH_UNKNOWN), выбрасывается ошибка.

  Для чего: движок не умеет работать с неизвестной архитектурой; приложение получит сообщение об ошибке и сможет сообщить пользователю.

Где архитектура читается на самом деле (файл src/llama-model-loader.cpp): конструктор загрузчика делает это один раз, сразу после открытия GGUF и до индексации тензоров, чтобы всё остальное в загрузчике уже пользовалось готовым значением. get_arch() и get_arch_name() после этого — простые геттеры:

// src/llama-model-loader.cpp — конструктор определяет архитектуру один раз, сразу после открытия GGUF
llama_model_loader::llama_model_loader(/* ... */) : metadata(meta), /* ... */ {
    // ... файл GGUF только что открыт в `metadata` ...

    get_key(llm_kv(LLM_KV_GENERAL_ARCHITECTURE), arch_name, false);  // строка "general.architecture"
    llm_kv = LLM_KV(llm_arch_from_string(arch_name));                // "llama" -> LLM_ARCH_LLAMA, "qwen2" -> LLM_ARCH_QWEN2

    // ... дальше строится индекс тензоров (weights_map) ...
}

// к моменту запроса enum уже определён — оба геттера тривиальны
std::string llama_model_loader::get_arch_name() const {
    return arch_name;
}

enum llm_arch llama_model_loader::get_arch() const {
    return llm_kv.arch;
}

Что делают эти вызовы:

• get_key(llm_kv(LLM_KV_GENERAL_ARCHITECTURE), arch_name, false) — из метаданных GGUF читается значение по ключу «общая архитектура» (например, llama, qwen2) и записывается в arch_name.

  Для чего: без имени архитектуры нельзя выбрать набор ключей для гиперпараметров и словаря.

• llm_arch_from_string(arch_name) — строка превращается в enum llm_arch (llama → LLM_ARCH_LLAMA, qwen2 → LLM_ARCH_QWEN2).

  Для чего: по enum дальше выбираются имена полей в GGUF для load_hparams и load_vocab, а также класс модели в llama_model_create. Чтение необязательное (false), поэтому файл без ключа архитектуры даёт LLM_ARCH_UNKNOWN, и ошибка возникает там, где создаётся модель, а не здесь.

• Примеры значений enum: LLM_ARCH_LLAMA, LLM_ARCH_GEMMA, LLM_ARCH_QWEN, LLM_ARCH_PHI3, LLM_ARCH_MISTRAL3, LLM_ARCH_CLIP и т.д. — сейчас в таблице около 150 именованных архитектур. Сами идентификаторы ключей GGUF (LLM_KV) — один общий набор: те, что относятся к гиперпараметрам, — шаблоны вида %s.context_length, куда вместо %s подставляется имя архитектуры, поэтому один и тот же ключ читается как llama.context_length у одной модели и как qwen3.context_length у другой; общие ключи, среди них general.architecture и general.name, — обычные строки, подставлять в них нечего.

  Для чего: без правильной архитектуры имена ключей получаются неверными, и гиперпараметры со словарём из GGUF не прочитать. По-настоящему своими у архитектуры остаются лишь несколько дополнительных гиперпараметров — их читает её собственный load_arch_hparams в src/models/.

• Имена тензоров в GGUF зависят от архитектуры: для LLaMA — blk.N.attn_q.weight, blk.N.attn_k.weight и т.д.; для других моделей — свои префиксы и суффиксы. Добавить поддержку новой архитектуры — значит добавить значение в enum и его имя в таблицу имён, написать новый класс в src/models/, который говорит, какие гиперпараметры читать, какие тензоры создавать и как строить граф, и зарегистрировать его в фабрике; новые ключи GGUF добавляются только тогда, когда архитектуре нужен параметр, которого нет ни в одном из существующих ключей. Гиперпараметры используются при создании тензоров в load_tensors (размеры матриц, число слоёв) и при создании контекста (n_ctx, n_batch, параметры RoPE и т.д.).

Шаг 4: Загрузка гиперпараметров — размеры и контекст

Шаг 4 — загрузка гиперпараметров (размеры модели, длина контекста, число слоёв и т.д.) из метаданных GGUF. Метод llama_model_base::load_hparams заполняет структуру hparams (гиперпараметры) из метаданных GGUF. Для чего это нужно: гиперпараметры задают «форму» модели — длину контекста, число слоёв, размер эмбеддинга, число голов внимания и т.п.; без них нельзя выделить память под тензоры и построить вычислительный граф. Здесь читаются ключи, общие для всех архитектур; затем метод вызывает load_arch_hparams, хук, который каждая архитектура реализует в своём файле в src/models/ и который читает параметры, свойственные только этому семейству. После возврата из хука ставится ещё несколько полей, среди них тип RoPE, — его можно вычислить только тогда, когда архитектура уже определила свои параметры. Цитата с основными ключами (файл src/llama-model.cpp, метод llama_model_base::load_hparams):

// src/llama-model.cpp — llama_model_base::load_hparams(): «форма» модели, прочитанная из метаданных GGUF
void llama_model_base::load_hparams(llama_model_loader & ml) {
    const gguf_context * ctx = ml.metadata;

    // сохраняем все пары ключ-значение (кроме массивов) как строки, для справки
    for (int i = 0; i < gguf_get_n_kv(ctx); i++) {
        gguf_type type = gguf_get_kv_type(ctx, i);
        if (type == GGUF_TYPE_ARRAY) {
            continue;
        }
        const char * name = gguf_get_key(ctx, i);
        const std::string value = gguf_kv_to_str(ctx, i);
        gguf_kv.emplace(name, value);
    }

    ml.get_key(LLM_KV_GENERAL_NAME, name, false);

    // всё дальше уже не относится к словарю
    if (hparams.vocab_only || ml.get_arch() == LLM_ARCH_CLIP) {
        return;
    }

    // архитектура — префикс каждого ключа ниже: llama.context_length, qwen3.context_length, ...
    ml.get_key(LLM_KV_CONTEXT_LENGTH,   hparams.n_ctx_train);   // длина контекста при обучении
    ml.get_key(LLM_KV_EMBEDDING_LENGTH, hparams.n_embd);        // размер эмбеддинга (скрытого состояния)
    ml.get_key(LLM_KV_BLOCK_COUNT,      hparams.n_layer_all);   // число слоёв трансформера
    GGML_ASSERT(hparams.n_layer_all > 0 && hparams.n_layer_all <= LLAMA_MAX_LAYERS);
    ml.get_key(LLM_KV_EXPERT_COUNT,     hparams.n_expert, false);  // только для MoE-моделей

    // ... здесь массивы по слоям заполняются нулями ...

    ml.get_key_or_arr(LLM_KV_FEED_FORWARD_LENGTH,  hparams.n_ff_arr,   hparams.n_layer(), false);  // размер FF по слоям
    ml.get_key_or_arr(LLM_KV_ATTENTION_HEAD_COUNT, hparams.n_head_arr, hparams.n_layer(), false);  // число голов внимания по слоям

    // n_head_kv необязателен, по умолчанию равен n_head
    hparams.n_head_kv_arr = hparams.n_head_arr;
    ml.get_key_or_arr(LLM_KV_ATTENTION_HEAD_COUNT_KV, hparams.n_head_kv_arr, hparams.n_layer(), false);  // число KV-голов (GQA)

    // rope_freq_base (необязательный)
    hparams.rope_freq_base_train = 10000.0f;
    ml.get_key(LLM_KV_ROPE_FREQ_BASE, hparams.rope_freq_base_train, false);

    // ... масштабирование RoPE, размеры голов, варианты со скользящим окном ...

    load_arch_hparams(ml);  // всё, что нужно только этой архитектуре — src/models/<arch>.cpp

    // ... после хука ставится ещё несколько полей, среди них hparams.rope_type ...
}

Что происходит и для чего:

• В цикле читаются все пары ключ–значение из GGUF (кроме массивов) и сохраняются в gguf_kv.

  Для чего:

• чтобы потом при необходимости можно было обратиться к любому полю по имени.

• Затем по ключам, зависящим от архитектуры, заполняются поля hparams:

• n_ctx_train — длина контекста при обучении.

  Для чего:

• от неё зависит размер KV-cache и максимальная длина ввода.

• n_embd — размер эмбеддинга (скрытого слоя).

  Для чего:

• от него зависят размеры матриц весов.

• n_layer_all — число блоков трансформера, записанное в файле.

  Для чего:

• от него зависит, сколько тензоров создавать в load_tensors; реально строится hparams.n_layer() — оно вычитает дополнительные блоки multi-token prediction, которые есть у некоторых моделей.

• n_ff_arr, n_head_arr, n_head_kv_arr — размеры feed-forward и число голов внимания по слоям.

  Для чего:

• от них зависят размеры матриц Q, K, V и feed-forward.

• rope_freq_base_train и др. — параметры RoPE (позиционного кодирования).

  Для чего:

• они задают, как в графе применяются позиционные кодировки. В итоге hparams полностью описывает размеры модели — этого достаточно, чтобы выделить память под тензоры и построить вычислительный граф.

Часть ключей GGUF для гиперпараметров (в зависимости от архитектуры):

• llama.context_length — длина контекста при обучении;
• llama.embedding_length — размер скрытого слоя (эмбеддинга);
• llama.block_count — число слоёв трансформера;
• llama.attention.head_count — число голов внимания;
• llama.attention.head_count_kv — число KV-голов (для GQA);
• llama.feed_forward_length — размер промежуточного слоя feed-forward;
• llama.rope.freq_base — базовая частота RoPE.

Для MoE-моделей добавляются ключи числа экспертов и т.д. Метод get_key_or_arr читает либо одно значение, либо массив по слоям (когда размеры различаются по слоям). После загрузки гиперпараметров модель знает «форму» всех тензоров — этого достаточно для выделения буферов и построения графа при load_tensors и при создании контекста.

Шаг 5: Загрузка словаря и токенайзера

Шаг 5 — загрузка словаря и токенайзера: по словарю текст превращается в токены при вводе и обратно в текст при выводе. Словарь токенов — таблица соответствия между кусочками текста и целыми числами (токенами); по нему текст режется на токены при вводе и обратно собирается в текст при выводе. Загрузка словаря выполняется после того, как определена архитектура и прочитаны гиперпараметры: в llama_model_load архитектура определяется при создании объекта модели (llama_model_create запрашивает её у загрузчика через ml.get_arch()), затем вызывается load_hparams(ml) и только потом load_vocab(ml). Внутри load_vocab вызывается vocab.load(ml, kv). Он загружается в llama_model_base::load_vocab (src/llama-model.cpp):

void llama_model_base::load_vocab(llama_model_loader & ml) {
    const auto kv = LLM_KV(arch);

    vocab.load(ml, kv);
}

Для текущей архитектуры берётся набор ключей словаря, после чего вызывается vocab.load(ml, kv). Реализация — метод llama_vocab::impl::load в src/llama-vocab.cpp. Из GGUF читаются:

• тип токенайзера (SPM, BPE, WPM и т.д.);
• списки токенов;
• типы токенов;
• слияния BPE (если есть);
• специальные токены — всё, что нужно, чтобы превращать текст в последовательность чисел (токенов) и обратно.

После этого модель умеет токенизировать промпт и переводить сгенерированные токены обратно в текст.

Вызов vocab.load(ml, kv) выполняется внутри llama_model_base::load_vocab после того, как для текущей архитектуры получен набор ключей kv (через LLM_KV(arch)). Загрузчик ml уже открыл GGUF и прочитал метаданные; архитектура известна из загрузчика (ml.get_arch()), а гиперпараметры прочитаны в load_hparams. Начало реализации llama_vocab::impl::load (файл src/llama-vocab.cpp):

void llama_vocab::impl::load(llama_model_loader & ml, const LLM_KV & kv) {
    struct gguf_context * ctx = ml.metadata;

    // Определяем тип словаря
    {
        ml.get_key(LLM_KV_TOKENIZER_MODEL, tokenizer_model);
        ml.get_key(LLM_KV_TOKENIZER_PRE,   tokenizer_pre, false);
        // ... "no_vocab" / "none" -> LLAMA_VOCAB_TYPE_NONE и ранний выход ...
        if (tokenizer_model == "llama") {
            type = LLAMA_VOCAB_TYPE_SPM;
            // Специальные токены по умолчанию
            special_bos_id  = 1;
            special_eos_id  = 2;
            special_unk_id  = 0;
        } else if (tokenizer_model == "gpt2" || tokenizer_model == "hybriddna" || tokenizer_model == "whitespace") {
            type = LLAMA_VOCAB_TYPE_BPE;
            // Читаем слияния BPE и заполняем ранги BPE
            const int merges_keyidx = gguf_find_key(ctx, kv(LLM_KV_TOKENIZER_MERGES).c_str());
            // ... неверно типизированный массив слияний — ошибка; отсутствующий — тоже, кроме
            //     случая tokenizer_pre == "kimi-k2"; элемент "first second" -> bpe_ranks[{first, second}] = i ...
        }
        // ... "bert" -> WPM, "t5" -> UGM, "rwkv", "plamo2", "gemma4"; всё остальное — ошибка ...
    }
    const int token_idx = gguf_find_key(ctx, kv(LLM_KV_TOKENIZER_LIST).c_str());
    if (token_idx == -1) {
        throw std::runtime_error("cannot find tokenizer vocab in model file\n");
    }
    // ... здесь находятся массивы оценок и типов токенов и проверяется, что их хватает на все токены ...
    const uint32_t n_tokens = gguf_get_arr_n(ctx, token_idx);
    id_to_token.resize(n_tokens);
    for (uint32_t i = 0; i < n_tokens; i++) {
        std::string word = gguf_get_arr_str(ctx, token_idx, i);
        // ... пустая строка заменяется заглушкой "[EMPTY_<i>]" ...
        token_to_id[word] = i;
        max_token_len = std::max(max_token_len, (int) word.size());
        auto & token_data = id_to_token[i];
        token_data.text = std::move(word);
        token_data.attr = LLAMA_TOKEN_ATTR_NORMAL;
        // ... score и attr затем берутся из массивов GGUF, если они есть в файле ...
    }
    init_tokenizer(type);
    // ... далее идут токен перевода строки, ID специальных токенов и флаги add_bos / add_eos ...
}

В коде видно: определение типа словаря по tokenizer_model (llama → SPM, gpt2 → BPE с чтением слияний), поиск массива токенов в GGUF, цикл по всем токенам — заполнение id_to_token и token_to_id, вызов init_tokenizer(type) для инициализации токенайзера (SPM, BPE и т.д.). Всё, что скрыто за строками // ..., — это проверки: массив слияний и массив токенов должны присутствовать и иметь правильный тип GGUF, а массивы оценок и типов токенов должны покрывать все токены — иначе загрузка прерывается исключением. Единственное послабление сделано для пре-токенайзера kimi-k2: он токенизирует без обычных слияний BPE, поэтому отсутствие массива слияний там не ошибка — загрузчик просто пишет об этом в лог. Далее в той же функции читаются специальные токены (BOS, EOS, UNK и т.п.) и настраиваются флаги add_bos, add_eos.

Специальные токены:

• BOS (begin of sequence) — токен начала последовательности, при необходимости добавляется перед промптом.
• EOS (end of sequence) — токен конца вывода, по нему приложение прекращает генерацию.
• UNK (unknown) — токен для неизвестных или не входящих в словарь символов.

Их ID хранятся в special_bos_id, special_eos_id, special_unk_id. В GGUF для словаря могут быть ключи вроде tokenizer.ggml.bos_token_id, tokenizer.ggml.eos_token_id и т.д. — они читаются в конце llama_vocab::impl::load и записываются в соответствующие поля. Флаги add_bos и add_eos задают, добавлять ли эти токены автоматически при токенизации (зависит от модели и формата чата). После init_tokenizer(type) словарь готов к токенизации и обратному переводу токенов в текст; эти операции используются при каждом запросе пользователя.

Шаг 6: Загрузка весов в память или на GPU

Шаг 6 — веса модели (тензоры) загружаются из файла в память или на GPU. Метод llama_model_base::load_tensors (src/llama-model.cpp) создаёт тензоры модели, назначает им буферы — участки памяти на CPU или видеокарте — и заполняет их данными из GGUF-файла. Ниже — начало метода, сокращённо.

// src/llama-model.cpp — llama_model_base::load_tensors()
bool llama_model_base::load_tensors(llama_model_loader & ml) {
    const auto & split_mode   = params.split_mode;
    const bool use_mlock      = params.load_mode == LLAMA_LOAD_MODE_MLOCK || params.load_mode == LLAMA_LOAD_MODE_MMAP_MLOCK;
    const auto & tensor_split = params.tensor_split;
    const int n_layer_all  = hparams.n_layer_all;
    const int n_gpu_layers = this->n_gpu_layers();   // отрицательное значение в параметрах означает «все слои»
    // ... при LLAMA_LOAD_MODE_AUTO ml.use_mmap отключается, если какое-то устройство не умеет mmap
    // строим списки типов буферов для CPU и для устройств GPU
    pimpl->cpu_buft_list = make_cpu_buft_list(devices, params.use_extra_bufts, params.no_host);
    for (const auto & dev : devices) {
        buft_list_t buft_list = make_gpu_buft_list(dev.dev, split_mode, tensor_split);
        // добавляем типы буферов CPU как запасной вариант
        buft_list.insert(buft_list.end(), pimpl->cpu_buft_list.begin(), pimpl->cpu_buft_list.end());
        pimpl->gpu_buft_list.emplace(dev.dev, std::move(buft_list));
    }

    ggml_backend_dev_t cpu_dev = ggml_backend_dev_by_type(GGML_BACKEND_DEVICE_TYPE_CPU);
    // ... splits[] заполняется из tensor_split или по свободной памяти каждого устройства и нормируется

    const int i_gpu_start = std::max(n_layer_all + 1 - n_gpu_layers, 0);
    const int act_gpu_layers = devices.empty() ? 0 : std::min(n_gpu_layers, n_layer_all + 1);
    auto get_layer_buft_list = [&](int il) -> llama_model::impl::layer_dev {
        // ... строка LLAMA_LOG_DEBUG по каждому слою опущена
        if (il < i_gpu_start || (il - i_gpu_start) >= act_gpu_layers) {
            return {cpu_dev, &pimpl->cpu_buft_list};
        }
        const int layer_gpu = std::upper_bound(splits.begin(), splits.begin() + n_devices(), float(il - i_gpu_start)/act_gpu_layers) - splits.begin();
        auto * dev = devices.at(layer_gpu).dev;
        return {dev, &pimpl->gpu_buft_list.at(dev)};
    };

    // от выгрузки входного слоя пользы почти нет, поэтому он всегда остаётся на CPU
    pimpl->dev_input = { cpu_dev, &pimpl->cpu_buft_list };

    // раскладываем повторяющиеся слои по устройствам согласно splits
    pimpl->dev_layer.resize(n_layer_all);
    for (int il = 0; il < n_layer_all; ++il) {
        pimpl->dev_layer[il] = get_layer_buft_list(il);
    }
    // назначаем выходной слой
    pimpl->dev_output = get_layer_buft_list(n_layer_all);

Что происходит в начале load_tensors и для чего:

• формируются списки типов буферов для CPU и для каждой видеокарты

  Для чего: от них зависит, на какие устройства будут размещены тензоры модели — входные обычно на CPU, слои по разбиению на CPU/GPU;

• по настройкам (tensor_split) или по свободной памяти решается, какие слои считать на CPU, какие на GPU

  Для чего: чтобы равномерно загрузить устройства и не переполнить память одной видеокарты.

Обратите внимание: mmap и mlock больше не отдельные булевы параметры — в llama_model_params есть одно поле load_mode (auto, none, mmap, mlock, mmap+mlock, dio), а из командной строки оно задаётся ключом -lm / --load-mode; прежние ключи --mmap, --no-mmap и --mlock отображаются на него.

Функция get_layer_buft_list(il) для номера слоя возвращает устройство и список буферов: вход всегда на CPU, повторяющиеся слои могут быть на CPU или GPU, выход — по разбиению. Далее в цикле создаются тензоры: эмбеддинги, выход, для каждого слоя — матрицы внимания (Q/K/V/O), нормализации, feed-forward. Создание тензора на этом этапе только фиксирует его форму и выбирает буфер, в котором он будет жить, — байты пока не двигаются. Данные приходят вторым проходом, когда все тензоры уже объявлены, а буферы бэкендов выделены: load_tensors вызывает ml.load_all_data(...) по одному разу на каждый буферный контекст, и уже внутри этого вызова выбирается mmap или обычное чтение. В итоге веса модели оказываются в памяти (и при необходимости на видеокарте), модель готова к генерации текста.

Сам загрузчик (src/llama-model-loader.cpp) раскладывает это на две половины. create_tensor объявляет один тензор: сверяет форму с метаданными GGUF, выбирает тип буфера по разбиению устройств, посчитанному выше, и создаёт тензор в соответствующем ggml-контексте. load_all_data затем проходит по всем тензорам контекста, по имени находит их запись в weights_map — оттуда берутся индекс файла и смещение в байтах — и либо направляет тензор на отображение файла в память, либо читает байты в его буфер. Для больших моделей используется mmap, чтобы не дублировать данные в оперативной памяти.

Проход объявления тензоров, для семейства llama — метод load_arch_tensors в файле src/models/llama.cpp:

// src/models/llama.cpp — llama_model_llama::load_arch_tensors(), вызывается из load_tensors()
void llama_model_llama::load_arch_tensors(llama_model_loader &) {
    LLAMA_LOAD_LOCALS;   // вводит в область видимости n_embd, n_layer, n_ff, n_vocab и остальные

    tok_embd = create_tensor(tn(LLM_TENSOR_TOKEN_EMBD, "weight"), {n_embd, n_vocab}, 0);

    // выход
    output_norm = create_tensor(tn(LLM_TENSOR_OUTPUT_NORM, "weight"), {n_embd}, 0);
    output      = create_tensor(tn(LLM_TENSOR_OUTPUT,      "weight"), {n_embd, n_vocab}, TENSOR_NOT_REQUIRED);

    // если output пустой, инициализируем его из входных эмбеддингов токенов
    if (output == NULL) {
        output = create_tensor(tn(LLM_TENSOR_TOKEN_EMBD, "weight"), {n_embd, n_vocab}, TENSOR_DUPLICATED);
    }

    for (int i = 0; i < n_layer; ++i) {
        auto & layer = layers[i];

        layer.attn_norm = create_tensor(tn(LLM_TENSOR_ATTN_NORM, "weight", i), {n_embd}, 0);

        create_tensor_qkv(layer, i, n_embd, n_embd_head_k * n_head, n_embd_k_gqa, n_embd_v_gqa, 0);
        layer.wo = create_tensor(tn(LLM_TENSOR_ATTN_OUT, "weight", i), {n_embd_head_k * n_head, n_embd}, 0);

        // ... необязательные тензоры смещений и тензоры коэффициентов RoPE опущены

        layer.ffn_norm = create_tensor(tn(LLM_TENSOR_FFN_NORM, "weight", i), {n_embd}, 0);

        if (n_expert == 0) {
            layer.ffn_gate = create_tensor(tn(LLM_TENSOR_FFN_GATE, "weight", i), {n_embd,   n_ff}, 0);
            layer.ffn_down = create_tensor(tn(LLM_TENSOR_FFN_DOWN, "weight", i), {  n_ff, n_embd}, 0);
            layer.ffn_up   = create_tensor(tn(LLM_TENSOR_FFN_UP,   "weight", i), {n_embd,   n_ff}, 0);
            // ... необязательные тензоры смещений MLP опущены
        }
        // ... ветка mixture-of-experts опущена
    }
}

Что здесь происходит и для чего:

• каждый вес модели именуется через tn(...), который строит имя тензора в GGUF — token_embd.weight, blk.0.attn_norm.weight, blk.0.ffn_down.weight и так далее.

  Для чего: имя — это ключ, по которому загрузчик потом найдёт смещение этого тензора в файле.

• create_tensor сверяет объявленную форму с метаданными, выбирает тип буфера по посчитанному ранее разбиению слоёв и создаёт тензор в ggml-контексте этого типа буфера.

  Для чего: именно здесь решается, что слой живёт на CPU или на конкретной видеокарте, — ещё до того, как тронуты данные.

• тензоры с флагом TENSOR_NOT_REQUIRED могут законно отсутствовать, а TENSOR_DUPLICATED переиспользует уже созданный тензор — так модель без отдельной выходной матрицы связывает свой выход с эмбеддингами токенов.

  Для чего: одна процедура загрузки должна покрывать много вариантов одной и той же архитектуры.

Сам проход с данными — это цикл по тензорам одного буферного контекста внутри ml.load_all_data (src/llama-model-loader.cpp). Для каждого тензора его запись ищется в weights_map по имени в GGUF — blk.0.attn_q.weight, blk.0.attn_k.weight и так далее, — и оттуда берутся индекс файла и смещение в байтах. Дальше возможны два варианта. При отображении файла в память тензор направляется прямо на отображённые страницы, если над ними удаётся построить буфер, — это и есть случай без копирования, и именно так получается для памяти хоста; иначе байты копируются из отображения в буфер тензора. Без отображения байты читаются из файла в этот буфер, а для буфера на видеокарте — отправляются на устройство. После этого прохода веса модели полностью находятся в памяти (и при необходимости на GPU).

// src/llama-model-loader.cpp — цикл по тензорам в llama_model_loader::load_all_data()
for (struct ggml_tensor * cur = ggml_get_first_tensor(ctx); cur != NULL; cur = ggml_get_next_tensor(ctx, cur)) {
    const auto * weight = get_weight(ggml_get_name(cur));
    if (weight == nullptr) {
        // такое бывает у моделей с разделёнными экспертами
        continue;
    }
    // ... здесь вызывается progress_callback; возврат false прерывает загрузку
    size_t n_size = ggml_nbytes(cur);
    const bool from_mapping = use_mmap || lazy.has(cur);

    if (from_mapping) {
        const auto & mapping = mappings.at(weight->idx);
        ggml_backend_buffer_t buf_mmap = nullptr;
        if (bufs.count(weight->idx)) {
            buf_mmap = bufs.at(weight->idx);
        }
        uint8_t * data = (uint8_t *) mapping->addr() + weight->offs;
        // ... необязательная проверка check_tensors опущена
        GGML_ASSERT(buf_mmap || cur->data); // либо есть буфер под тензор, либо он уже размещён
        if (buf_mmap && cur->data == nullptr) {
            // копирования нет вообще: тензор направляется прямо на отображённые страницы
            ggml_backend_tensor_alloc(buf_mmap, cur, data);
            // ... расширение mlock и учёт использованного диапазона опущены
        } else {
            ggml_backend_tensor_set(cur, data, 0, n_size);
        }
    } else {
        const auto & file = files.at(weight->idx);
        if (ggml_backend_buffer_is_host(cur->buffer)) {
            file->seek(weight->offs, SEEK_SET);
            file->read_raw(cur->data, n_size);
        } else {
            // ... в буфер на GPU: асинхронная отправка кусками через закреплённую память хоста,
            // ... если устройство это умеет, иначе чтение в read_buf + ggml_backend_tensor_set()
        }
    }
    size_done += n_size;
}

Так два прохода вместе покрывают всё: create_tensor решает, где будет жить каждый вес — эмбеддинги, матрицы Q/K/V/O, нормализации и feed-forward каждого слоя, — а load_all_data кладёт туда байты или подставляет отображение файла.

При использовании mmap данные тензоров не копируются в оперативную память — отображается участок файла, и тензор указывает прямо в него, — но только там, где устройство умеет построить буфер поверх памяти хоста. Процессор умеет всегда; на единой памяти вроде Apple Silicon умеет и графическое устройство. Дискретная карта не умеет: её байты копируются из отображения в видеопамять, и там mmap экономит RAM только на слоях, оставшихся на процессоре. Это уменьшает потребление RAM и ускоряет старт загрузки, но файл должен оставаться на диске на прежнем месте и без изменений всё время, пока модель загружена: отображение живёт дольше загрузчика и освобождается только при уничтожении модели. Режим прямого ввода-вывода (--load-mode dio) открывает файл без буферизации и округляет каждое чтение до размера блока, о котором сообщает файловая система; он реализован только на Linux, а если открыть файл без буферизации не удалось — происходит откат на обычное буферизованное чтение. Разбиение по слоям (tensor_split или по свободной памяти GPU) задаёт, какие слои загружать на какое устройство — так можно распределить большую модель по нескольким видеокартам. После завершения load_tensors модель полностью готова к инференсу: все веса находятся в памяти (и при необходимости на GPU), и можно создавать контекст и вызывать llama_decode.

Шаг 7: Создание контекста инференса

Шаг 7 — создание контекста инференса (KV-cache, планировщик, зарезервированные графы). Загруженная модель хранит только веса (тензоры). Чтобы генерировать текст, нужен контекст инференса — объект llama_context.

Для чего он нужен:

• контекст — это «рабочая среда» одного сеанса генерации: в нём задаётся, сколько токенов модель может «помнить» (размер контекста), как большими порциями подавать данные (размер батча), параметры RoPE и тип внимания;
• без контекста нельзя вызвать llama_decode — именно контекст хранит KV-cache, планировщик и зарезервированные графы.

Реализация — в файле src/llama-context.cpp.

Что создаётся при создании контекста и для чего:

• Планировщик (sched) — решает, на каком устройстве (CPU или видеокарта) выполнять каждый узел вычислительного графа.

  Для чего: чтобы распределить вычисления по CPU и GPU и выделить под граф буферы на нужных устройствах.

• Память KV-cache (memory) — буферы под ключи и значения механизма внимания.

  Для чего: в них хранятся уже посчитанные ключи и значения по всем предыдущим позициям; без кэша при каждом новом токене пришлось бы заново считать K и V для всей истории, что очень медленно (подробнее в разделе «KV-cache»).

• Аллокатор батча (balloc) — заполняет позиции и флаги логитов в батче при необходимости.

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

• Зарезервированные графы (Prefill и Decode) — временные графы и буферы под них.

  Для чего: при первом вызове decode память под граф не выделяется «на лету» — буферы уже зарезервированы под худший случай, и это уменьшает задержку первого ответа (сам граф при первом decode всё равно строится заново).

Начало конструктора llama_context::llama_context в src/llama-context.cpp (сокращённо — пропуски отмечены):

// src/llama-context.cpp — llama_context::llama_context (сокращённо)
llama_context::llama_context(
        const llama_model & model,
              llama_context_params params) :
    model(model),
    cvec(std::make_unique<llama_adapter_cvec>()),
    loras(std::make_unique<llama_adapter_loras>()),
    balloc(std::make_unique<llama_batch_allocr>(model.hparams.n_pos_per_embd())) {
    LLAMA_LOG_INFO("%s: constructing llama_context\n", __func__);

    t_start_us = model.t_start_us;
    t_load_us  = model.t_load_us;

    const auto & hparams = model.hparams;

    cparams.n_seq_max = std::max(1u, params.n_seq_max);
    if (cparams.n_seq_max > LLAMA_MAX_SEQ) {
        throw std::runtime_error("n_seq_max must be <= " + std::to_string(LLAMA_MAX_SEQ));
    }

    // ... n_rs_seq и его сброс в 0 для архитектур без отката recurrent-состояния
    cparams.n_threads               = params.n_threads;
    cparams.n_threads_batch         = params.n_threads_batch;
    cparams.yarn_ext_factor         = params.yarn_ext_factor  >= 0.0f ? params.yarn_ext_factor  : hparams.yarn_ext_factor;
    // ... остальные параметры YaRN, пулинга и Flash Attention
    cparams.n_ctx            = params.n_ctx           == 0    ? hparams.n_ctx_train           : params.n_ctx;
    cparams.rope_freq_base   = params.rope_freq_base  == 0.0f ? hparams.rope_freq_base_train  : params.rope_freq_base;
    cparams.rope_freq_scale  = params.rope_freq_scale == 0.0f ? hparams.rope_freq_scale_train : params.rope_freq_scale;
    // ...
    if (params.attention_type == LLAMA_ATTENTION_TYPE_UNSPECIFIED) {
        cparams.causal_attn = hparams.causal_attn;
    } else {
        cparams.causal_attn = params.attention_type == LLAMA_ATTENTION_TYPE_CAUSAL;
    }

    // при causal attention размер батча ограничен размером контекста
    cparams.n_batch = cparams.causal_attn ? std::min(cparams.n_ctx, params.n_batch) : params.n_batch;
    cparams.n_ubatch = std::min(cparams.n_batch, params.n_ubatch == 0 ? params.n_batch : params.n_ubatch);
    // ... n_ctx дополняется до кратного 256 и, если KV-cache не общий для всех
    //     последовательностей, делится между ними на лимит n_ctx_seq
    LLAMA_LOG_INFO("%s: n_ctx                 = %u\n",   __func__, cparams.n_ctx);
    LLAMA_LOG_INFO("%s: n_ctx_seq             = %u\n",   __func__, cparams.n_ctx_seq);
    LLAMA_LOG_INFO("%s: n_batch               = %u\n",   __func__, cparams.n_batch);
    LLAMA_LOG_INFO("%s: n_ubatch              = %u\n",   __func__, cparams.n_ubatch);
    // ... создаются бэкенды (GPU, CPU) и буфер выходов, затем модуль памяти
    //     (KV-cache), и последним sched_reserve() строит планировщик и графы
}

Что задаётся в конструкторе контекста:

• сохраняются ссылка на модель и время загрузки;

• задаются максимальное число последовательностей (n_seq_max), число потоков, параметры YaRN/RoPE, размер контекста (n_ctx), размер батча (n_batch, n_ubatch), тип внимания (causal).

  Для чего:

• от этих параметров зависят размер KV-cache, максимальная длина промпта и то, как большими порциями обрабатывается батч.

Запрошенный n_ctx округляется вверх до кратного 256, и, если KV-cache не общий для всех последовательностей, делится между ними: реальным ограничением одного диалога оказывается лимит на одну последовательность n_ctx_seq — именно его лог печатает рядом с n_ctx.

Далее инициализируются бэкенды (CPU и видеокарты), создаётся объект памяти memory (KV-cache и служебные буферы), планировщик sched (распределяет узлы графа по устройствам), резервируются графы для Prefill и Decode — чтобы к первому decode буферы под них были уже выделены. После этого можно вызывать llama_decode с батчами токенов.

Параметры n_batch и n_ubatch:

• n_batch — максимальное число токенов в одном батче (при Prefill в батче может быть до n_batch токенов промпта);
• n_ubatch — максимальный размер подбатча, который обрабатывается за один вызов process_ubatch;
• если промпт длиннее n_ubatch, он разбивается на подбатчи по n_ubatch токенов, каждый прогоняется через модель по очереди;
• логиты нужны только для последней позиции в батче, поэтому копируются только они;
• уменьшение n_ubatch снижает пиковое потребление памяти за счёт большего числа проходов.

Контекст создаётся один раз на сеанс (или при смене параметров); один контекст может использоваться для множества запросов подряд без пересоздания.

Память и планировщик настраиваются из конструктора llama_context (файл src/llama-context.cpp), но не прямо в нём. Сначала конструктор собирает собственный список бэкендов — по одному на устройство модели, плюс бэкенды ускорителей и CPU, — затем создаёт объект памяти через model.create_memory и последним вызывает вспомогательную функцию sched_reserve. Именно в ней ggml_backend_sched_new строит планировщик по этому списку бэкендов и резервируются графы, так что при первом реальном decode граф строится заново, но размещается в уже зарезервированной памяти. Сам KV-cache живёт не в src/llama-memory.cpp — в этом файле лежат только две небольшие вспомогательные функции для статуса памяти. Буферы выделяются в конструкторе llama_kv_cache в файле src/llama-kv-cache.cpp: для каждого слоя он создаёт тензор ключей и тензор значений размером на весь контекст, а затем запрашивает у бэкенда по одному буферу на устройство.

Функция graph_reserve (в src/llama-context.cpp) резервирует по одному графу за вызов: она делает фиктивный батч нужной формы, вызывает для него model.build_graph и передаёт результат в ggml_backend_sched_reserve — планировщик разбивает граф по бэкендам и резервирует буферы. sched_reserve вызывает её трижды: сначала для Prefill (целый подбатч токенов за раз), затем для Decode (по одному токену на последовательность), затем снова для Prefill — чтобы буферы остались размером под худший случай и не перевыделялись во время инференса. Позже, при настоящем вызове process_ubatch, предыдущий граф переиспользуется, если это позволяют его параметры (can_reuse), иначе строится заново и размещается через ggml_backend_sched_alloc_graph; в любом случае выделение под большие графы уже сделано при создании контекста — именно это и убирает всплеск задержки на первом decode.

Шаг 8: Приходит текст промпта от пользователя

Шаг 8 — к движку приходит текст промпта от пользователя. После создания контекста пользователь отправляет сообщение (промпт). Модель работает только с числами — токенами. Поэтому текст сначала превращают в токены (шаг 9), упаковывают в батч (шаг 10), прогоняют через модель вызовом llama_decode (шаги 11–14): при первом запросе в батче все токены промпта (Prefill заполняет KV-cache), при генерации — один новый токен (Decode). Из логитов сэмплер выбирает один следующий токен (шаг 15), он переводится в текст и выводится (шаг 16); токен снова добавляется в батч, и цикл повторяется до токена «конец вывода» (EOS) или лимита. Ниже каждый из этих шагов разобран по коду: что вызывается, что происходит и что может быть неочевидно.

Prefill и Decode — в чём разница и для чего:

• При первом вызове llama_decode с полным промптом (Prefill) модель обрабатывает все токены промпта за один или несколько подбатчей; для них считаются K и V и записываются в KV-cache; логиты запрашиваются только для последней позиции — по ним выбирается первый токен ответа.

  Для чего: один раз «прогнать» весь промпт и заполнить кэш ключей и значений, чтобы дальше генерировать по одному токену, не пересчитывая историю.

• При следующих вызовах в батче один новый токен (Decode); проходятся по-прежнему все слои модели, но только для этой одной позиции: Q, K и V считаются лишь для неё, а K и V всей предыдущей истории читаются из кэша; логиты снова только для последней позиции.

  Для чего: эффективная генерация по одному токену без пересчёта всей истории — старые K и V уже в кэше.

Весь цикл умещается в пару десятков строк. Ниже — цикл генерации из минимального примера examples/simple-chat/simple-chat.cpp (функция generate), сокращённо, с добавленными в комментарии номерами шагов этой статьи.

// Цикл генерации, сокращённо из examples/simple-chat/simple-chat.cpp (лямбда "generate").
// Номера шагов — из этой статьи, остальное — код самого примера.
// BOS добавляется только для самого первого промпта в диалоге
const bool is_first = llama_memory_seq_pos_max(llama_get_memory(ctx), 0) == -1;
// Шаг 9: текст промпта -> массив токенов. При вызове с tokens == NULL
// llama_tokenize возвращает минус число токенов — так и узнают размер буфера.
const int n_prompt_tokens = -llama_tokenize(vocab, prompt.c_str(), prompt.size(), NULL, 0, is_first, true);
std::vector<llama_token> prompt_tokens(n_prompt_tokens);
if (llama_tokenize(vocab, prompt.c_str(), prompt.size(), prompt_tokens.data(), prompt_tokens.size(), is_first, true) < 0) {
    GGML_ABORT("failed to tokenize the prompt\n");
}
// Шаг 10: токены упаковываются в батч — одна последовательность, позиции ведёт llama_decode
llama_batch batch = llama_batch_get_one(prompt_tokens.data(), prompt_tokens.size());
llama_token new_token_id;
while (true) {
    // ... здесь пример ещё проверяет, что батч влезает в контекст
    // Шаги 11–14: decode, подбатчи, process_ubatch; логиты попадают в буфер контекста
    int ret = llama_decode(ctx, batch);
    if (ret != 0) {
        GGML_ABORT("failed to decode, ret = %d\n", ret);
    }
    // Шаг 15: сэмплинг; -1 означает «логиты последней позиции»
    new_token_id = llama_sampler_sample(smpl, ctx, -1);
    // это конец генерации?
    if (llama_vocab_is_eog(vocab, new_token_id)) {
        break;
    }
    // Шаг 16: токен -> текст; отрицательное n значит, что буфер оказался мал
    char buf[256];
    int n = llama_token_to_piece(vocab, new_token_id, buf, sizeof(buf), 0, true);
    if (n < 0) {
        GGML_ABORT("failed to convert token to piece\n");
    }
    std::string piece(buf, n);
    printf("%s", piece.c_str());
    fflush(stdout);
    // следующий батч — один засэмплированный токен, дальше проход Decode
    batch = llama_batch_get_one(&new_token_id, 1);
}

Шаг 9: Токенизация — от текста к последовательности токенов

Шаг 9 — текст промпта превращается в последовательность токенов (целых чисел). Текст нужно превратить в последовательность целых чисел — токенов.

Для чего это нужно:

• модель (слои трансформера) принимает на вход не строки, а векторы чисел фиксированной длины;
• каждому токену соответствует одна строка в эмбеддинг-таблице модели.

Токенизация — это первый шаг:

• по словарю текст режется на кусочки (токены), каждому кусочку ставится в соответствие число (ID);
• дальше по этим ID берутся эмбеддинги и подаются в модель.

Что такое токен:

• токен — это ID (целое число), который соответствует кусочку текста: целому слову, части слова или служебному символу;
• словарь модели задаёт соответствие «текст ↔ токены»: по тексту можно получить массив токенов (токенизация), по токену — текст (token_to_piece).

В API (заголовок include/llama.h) объявлена функция llama_tokenize; реализация делегирует вызов словарю модели.

Реализация в src/llama-vocab.cpp:

// Шаг 9: текст промпта превращается в массив токенов (ID); словарь модели задаёт соответствие «текст ↔ токены»
int32_t llama_tokenize(
    const struct llama_vocab * vocab,
                  const char * text,
                     int32_t   text_len,
                 llama_token * tokens,
                     int32_t   n_tokens_max,
                        bool   add_special,
                        bool   parse_special) {
    return vocab->tokenize(text, text_len, tokens, n_tokens_max, add_special, parse_special);
}

Параметры:

• vocab — словарь модели;
• text и text_len — строка промпта;
• tokens — массив для записи токенов;
• n_tokens_max — его размер;
• add_special — добавлять ли служебные токены BOS и EOS, и только если сама модель на них настроена;
• parse_special — обрабатывать ли специальные теги.

Реальная логика (BPE, SentencePiece и т.д.) в методе vocab->tokenize в src/llama-vocab.cpp. Результат — число записанных токенов; если буфер оказался мал, функция возвращает минус нужное число токенов — именно так приложение сначала вызывает её с пустым буфером, чтобы узнать размер, и только потом выделяет массив. Токенизация выполняется при каждом новом сообщении пользователя; словарь при этом не меняется и уже загружен при загрузке модели.

Реализация токенизации — метод llama_vocab::impl::tokenize в src/llama-vocab.cpp. Внутри по типу словаря (SPM, BPE, WPM и т.д.) создаётся сессия токенайзера и вызывается её tokenize; для BPE, например, используется llm_tokenizer_bpe_session, который разбивает текст по регулярным выражениям и собирает токены по слияниям (merges).

Типы токенайзеров в словаре:

• LLAMA_VOCAB_TYPE_SPM — SentencePiece-подобный (модели LLaMA и др.), разбиение по правилам и словарю SPM;
• LLAMA_VOCAB_TYPE_BPE — Byte Pair Encoding (GPT-2 и др.), слияния пар байт/подстрок хранятся в GGUF, токенизация — жадное слияние;
• LLAMA_VOCAB_TYPE_WPM — WordPiece, токенайзер в стиле BERT;
• LLAMA_VOCAB_TYPE_UGM — Unigram, токенайзер в стиле T5;
• LLAMA_VOCAB_TYPE_RWKV — жадная токенизация по префиксному дереву (trie);
• LLAMA_VOCAB_TYPE_PLAMO2 — алгоритм Ахо — Корасик с динамическим программированием;
• LLAMA_VOCAB_TYPE_NONE — модель опубликована вообще без словаря; токенизировать нечем, и попытка токенизации просто аварийно завершается. Функция tokenizer_st_partition разбивает входной текст на фрагменты: обычный текст и специальные токены — специальный токен становится одним токеном на выходе, остальное идёт в токенайзер по типу словаря. Флаг parse_special управляет только управляющими и служебными токенами; токены, объявленные в модели как пользовательские, выделяются всегда. Фрагмент llama_vocab::impl::tokenize — общая часть и ветка BPE; остальные ветки устроены так же:

// Шаг 9: текст разбивается на фрагменты (обычный текст и специальные токены),
// и каждый фрагмент токенизируется по типу словаря
std::vector<llama_token> llama_vocab::impl::tokenize(
        const std::string & raw_text,
        bool add_special,
        bool parse_special) const {
    GGML_ASSERT(tokenizer && "Tokenizer not initialized. Call llama_vocab::init_tokenizer() first.");
    std::vector<llama_token> output;
    std::forward_list<fragment_buffer_variant> fragment_buffer;
    if (!raw_text.empty()) {
        fragment_buffer.emplace_front(raw_text, 0, raw_text.length());
        tokenizer_st_partition(fragment_buffer, parse_special);
    }
    switch (get_type()) {
        // ... ветки SPM, WPM, UGM, RWKV и PLAMO2 устроены так же
        case LLAMA_VOCAB_TYPE_BPE:
            {
                const llm_tokenizer_bpe * tok_bpe = static_cast<const llm_tokenizer_bpe *>(tokenizer.get());
                std::unique_ptr<llm_tokenizer_bpe_session> session;
                // ... для моделей токенайзера "hybriddna" и "whitespace" берётся свой подкласс сессии
                session = std::make_unique<llm_tokenizer_bpe_session>(vocab, *tok_bpe);
                if (add_special) {
                    session->append_bos(output);
                }
                for (const auto & fragment : fragment_buffer) {
                    if (fragment.type == FRAGMENT_BUFFER_VARIANT_TYPE_RAW_TEXT) {
                        std::string text = fragment.raw_text.substr(fragment.offset, fragment.length);
                        // ... экранирование пробелов, если словарь этого требует
                        session->tokenize(text, output);
                    } else { // FRAGMENT_BUFFER_VARIANT_TYPE_TOKEN
                        session->append(fragment.token, output);
                    }
                }
                if (add_special) {
                    session->append_eos(output);
                    session->check_double_bos_eos(output);
                }
            } break;
        case LLAMA_VOCAB_TYPE_NONE:
            GGML_ABORT("fatal error");
    }
    return output;
}

Шаг 10: Формирование батча для одного вызова

Шаг 10 — токены упаковываются в батч для одного вызова к модели. Один вызов к модели передаётся через структуру llama_batch (в include/llama.h).

Для чего нужен батч:

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

// Шаг 10: батч — «пакет» токенов для одного вызова llama_decode; token[], pos[], seq_id[], logits[] заполняются приложением или balloc->init
typedef struct llama_batch {
    int32_t n_tokens;
    llama_token  *  token;
    float        *  embd;
    llama_pos    *  pos;
    int32_t      *  n_seq_id;
    llama_seq_id ** seq_id;
    int8_t       *  logits;
} llama_batch;

Структура батча:

• массивы имеют размер n_tokens;
• либо передаются ID токенов (token), либо готовые эмбеддинги (embd) — векторы чисел, в которые уже превращены токены (обычно передают токены, а эмбеддинги считаются внутри);
• pos — позиция каждого токена; seq_id и n_seq_id — к какой последовательности относится токен;
• logits[i] != 0 означает, что для позиции i нужно вернуть логиты (обычно только для последней — чтобы выбрать следующий токен). Внутри llama_decode батч сначала обрабатывается классом llama_batch_allocr (файл src/llama-batch.cpp): метод init проверяет батч и при отсутствии полей заполняет их автоматически (позиции из памяти, логиты только для последнего токена).

Поля seq_id и n_seq_id используются при батчинге нескольких последовательностей (например, несколько запросов в одном батче): каждый токен может относиться к одной или нескольким последовательностям; позиции (pos) считаются отдельно для каждой последовательности по memory->seq_pos_max(seq_id). В типичном случае одна последовательность — все токены имеют один и тот же seq_id (например, 0), и позиции идут по порядку 0, 1, 2, ... . Заполнить батч для следующего шага приложение может двумя способами. Минимальный — llama_batch_get_one: он оборачивает один только что выбранный токен и оставляет равными NULL и pos, и seq_id, чтобы llama_decode сам продолжил позицию и отнёс токен к последовательности 0 — так делают examples/simple и examples/simple-chat. Второй — один раз выделить батч через llama_batch_init, а перед каждым вызовом очищать его через common_batch_clear и добавлять токены через common_batch_add, явно передавая позицию и идентификаторы последовательностей — именно так приходится делать любому коду, который обслуживает несколько последовательностей сразу.

Метод init класса llama_batch_allocr (файл src/llama-batch.cpp), который llama_context::decode вызывает для входящего батча раньше всего остального:

// src/llama-batch.cpp, llama_batch_allocr::init(): проверяет входной батч, затем заполняет
// все массивы, которые приложение оставило NULL — прежде всего позиции и флаги вывода
bool llama_batch_allocr::init(
        const llama_batch & batch_inp,
        const llama_vocab & vocab,
        const llama_memory_i * memory,
        uint32_t n_embd,
        uint32_t n_seq_max,
        bool output_all) {
    clear();
    batch = batch_inp;
    this->vocab = &vocab;
    GGML_ASSERT(batch.n_tokens > 0);
    // ... опущено: n_seq_max должен помещаться в LLAMA_MAX_SEQ, каждый seq_id должен быть меньше n_seq_max,
    //     и каждый batch.token[i] должен быть допустимым id (< vocab.n_tokens()) — иначе return false ...
    // ... опущено: если n_seq_id или seq_id равны NULL, каждый токен относится к последовательности 0 ...
    if (!batch.pos) {
        pos.resize(batch.n_tokens);

        // начальная позиция каждой последовательности берётся из позиций в памяти
        llama_pos p0[LLAMA_MAX_SEQ];
        for (uint32_t s = 0; s < n_seq_max; ++s) {
            if (!memory) {
                // если памяти нет -> начинаем с 0
                p0[s] = 0;
            } else {
                p0[s] = memory->seq_pos_max(s) + 1;
            }
        }

        for (int32_t i = 0; i < batch.n_tokens; i++) {
            const llama_seq_id seq_id = batch.seq_id[i][0];
            pos[i] = p0[seq_id];
            // ... опущено: p0 сдвигается за эту позицию для каждой последовательности токена ...
        }
        batch.pos = pos.data();
    }
    if (!batch.logits) {
        if (output_all) {
            output.resize(batch.n_tokens, true);   // вывод для каждого токена
        } else {
            output.resize(batch.n_tokens, false);  // вывод только для последнего токена
            output[output.size() - 1] = true;
        }
        batch.logits = output.data();
    }
    // ... опущено: если logits заданы, но выставлен output_all, недостающие выводы включаются принудительно;
    //     затем статистика позиций по последовательностям, связанные последовательности и проверки согласованности ...
    return true;
}

В коде:

• проверка токенов на допустимость;
• при отсутствии n_seq_id и seq_id каждый токен относится ровно к одной последовательности с номером 0;
• при отсутствии pos каждая последовательность продолжается с того места, где она остановилась в памяти (memory->seq_pos_max(s) + 1), и позиции проставляются по порядку; если памяти нет вовсе, отсчёт начинается с 0;
• при отсутствии logits логиты запрашиваются только для последнего токена (или для всех, если output_all).

От токенов к эмбеддингам (происходит внутри шага 13)

Внутри шага 13 токены батча превращаются в эмбеддинги. В батче можно передать либо ID токенов (token), либо готовые эмбеддинги (embd), и в типичном случае приложение передаёт токены. Превращение — это не отдельный проход перед обработкой батча: это самый первый узел графа вычислений, который decode строит для каждого ubatch.

Для чего нужно это превращение:

• модель (слои трансформера) работает не с номерами токенов, а с векторами чисел фиксированной длины — эмбеддингами;
• выборка берёт каждый ID токена и читает соответствующую строку эмбеддинг-таблицы модели, и эта строка становится входом первого слоя;
• без него графу было бы не над чем считать.

Что такое эмбеддинг-таблица:

• это матрица весов модели размером «размер словаря × размер эмбеддинга»; одна строка — вектор чисел для одного токена;
• в коде на C++ это поле модели tok_embd, а в файле GGUF — тензор token_embd.weight; имена embed_tokens и tok_embeddings пришли из исходных чекпоинтов PyTorch — скрипт конвертации отображает их в token_embd, так что искать что-то под этими именами внутри llama.cpp бесполезно;
• она создаётся при загрузке модели, в списке тензоров конкретной архитектуры (load_arch_tensors, вызывается из load_tensors);
• при выполнении графа для каждого токена батча читается строка с индексом token[i] и попадает на позицию i входа графа;
• после этого граф считает уже по эмбеддингам (слои трансформера, внимание, feed-forward, логиты).

Где это в коде: эмбеддинг-таблица — это поле модели tok_embd, а выборку по ней строит llm_graph_context::build_inp_embd (файл src/llama-graph.cpp), который каждая архитектура вызывает первой же строкой своего графа. Он создаёт два входных тензора — вектор I32 под ID токенов и матрицу F32 под готовые эмбеддинги — и пропускает токенную ветку через ggml_get_rows по таблице; в граф попадают обе ветки, а ggml_build_forward_select помечает к вычислению только ту, что соответствует содержимому ubatch — токенам или готовым векторам. Ради этого он и нужен: топология графа остаётся одинаковой от ubatch к ubatch, и граф можно переиспользовать. Сами ID записывает во входной тензор llm_graph_input_embd::set_input, которую process_ubatch (файл src/llama-context.cpp) вызывает уже после того, как граф построен и размещён, прямо перед его выполнением. То есть строку копирует не decode на CPU: она читается на бэкенде, во время вычисления графа, вместе со всем остальным — а поскольку эмбеддинг-таблица обычно хранится квантизованной, ggml_get_rows попутно распаковывает каждую строку во float. При decode по одному токену читается ровно одна строка таблицы.

Выборка, как она строится в графе (src/llama-graph.cpp, llm_graph_context::build_inp_embd):

// src/llama-graph.cpp, llm_graph_context::build_inp_embd() — сокращённо: убраны отладочные
// колбэки и проверки. Превращение токена в вектор — это не memcpy внутри decode, а узел
// графа вычислений, который выполняется на бэкенде вместе со всей остальной моделью.
ggml_tensor * llm_graph_context::build_inp_embd(ggml_tensor * tok_embd) const {
    const int64_t n_embd_inp = hparams.n_embd_inp();

    auto inp = std::make_unique<llm_graph_input_embd>(n_embd_inp);

    inp->tokens = ggml_new_tensor_1d(ctx0, GGML_TYPE_I32, ubatch.n_tokens);
    ggml_set_input(inp->tokens);

    inp->embd = ggml_new_tensor_2d(ctx0, GGML_TYPE_F32, n_embd_inp, ubatch.n_tokens);
    ggml_set_input(inp->embd);

    // выбираем один из 2 входов, исходя из содержимого батча
    std::array<ggml_tensor *, 2> inps;

    // ветка с эмбеддингами токенов (ubatch.token != nullptr)
    {
        auto & cur = inps[0];

        cur = ggml_get_rows(ctx0, tok_embd, inp->tokens);

        // ... сокращено: необязательная LoRA-поправка к эмбеддинг-таблице
        //     и паддинг, который нужен при n_embd_inp != n_embd
    }

    // ветка с готовыми векторами (ubatch.embd != nullptr)
    {
        auto & cur = inps[1];

        cur = inp->embd;
    }

    ggml_tensor * cur = ggml_build_forward_select(gf, inps.data(), inps.size(), ubatch.token ? 0 : 1);

    // ... сокращено: view при n_embd_inp != n_embd и умножение на f_embedding_scale

    res->add_input(std::move(inp));

    return cur;
}

Что происходит и для чего:

• для каждого индекса i в ubatch ID токена ubatch.token[i] записывается во входной тензор графа inp_tokens.

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

• ggml_get_rows читает из таблицы tok_embd строку с этим индексом — вектор длины n_embd, потому что сама таблица имеет ширину n_embd. Отдельным архитектурам нужен более широкий вход графа, n_embd_inp — это модели с deepstack-слоями и gemma4-assistant, которая задаёт своё значение; там строку добивают паддингом до этой ширины, а перед первым слоем снова сужают до n_embd.

  Для чего: эта строка и есть эмбеддинг токена — вход для первого слоя трансформера.

• строки для всех токенов ubatch складываются в матрицу, которую получает первый слой.

  Для чего: слои обрабатывают весь ubatch разом; без этого узла у графа вообще не было бы входа.

Шаги 11 и 12: Прогон батча через модель (вход в decode, подбатчи)

Шаги 11 и 12 — приложение вызывает llama_decode, передавая ему батч. Внутри батч проверяется и подготавливается (шаг 11), затем разбивается на подбатчи (шаг 12), и каждый подбатч прогоняется через модель (шаг 13). Превращение идентификаторов токенов в векторы-эмбеддинги — не отдельный шаг на стороне хоста: это первый узел вычислительного графа, поэтому оно происходит на шаге 13 вместе со всем остальным. Ниже — точка входа, цикл по подбатчам и разбиение батча.

Для чего нужна функция llama_decode:

• она прогоняет один батч токенов через модель и заполняет внутренний буфер контекста логитами — «сырыми» оценками по каждому возможному следующему токену;
• по этим логитам приложение (через сэмплер) выбирает один следующий токен и при необходимости снова вызывает decode с одним новым токеном в батче;
• так повторяется до конца ответа (EOS) или лимита.

Публичный API — llama_decode (в src/llama-context.cpp):

// Шаг 11: точка входа decode. Публичная C-функция только передаёт батч
// в C++-контекст; вся работа происходит в llama_context::decode.
int32_t llama_decode(
        llama_context * ctx,
          llama_batch   batch) {
    const int ret = ctx->decode(batch);
    // ret == 1 означает «нет свободного слота в KV-cache под этот батч» — это предупреждение,
    // а не сбой, поэтому оно не логируется как ошибка
    if (ret != 0 && ret != 1) {
        LLAMA_LOG_ERROR("%s: failed to decode, ret = %d\n", __func__, ret);
    }

    return ret;
}

Вот что происходит внутри llama_context::decode (src/llama-context.cpp). Сначала батч проверяется. Если у этого контекста вообще нет модуля памяти — например, это контекст только под эмбеддинги — decode просто передаёт батч в encode и возвращает результат. Иначе он вызывает balloc->init(...), резервирует планировщик и применяет отложенные обновления памяти (KV-cache). Затем один раз вызывается memory->init_batch: этот единственный вызов разбивает весь батч на подбатчи и возвращает контекст памяти, в котором лежат сразу все они. Дальше цикл идёт по этому контексту: берёт очередной подбатч через get_ubatch(), прогоняет его через process_ubatch, копирует полученные логиты во внутренний буфер контекста и переходит к следующему подбатчу через next().

Цикл по подбатчам внутри decode (сокращённо, из src/llama-context.cpp):

// src/llama-context.cpp, llama_context::decode — сокращённо
    memory_update(false);                   // применяем отложенные сдвиги/копирования
    llama_memory_context_ptr mctx;
    // разбиваем ВЕСЬ батч на подбатчи не больше n_ubatch токенов, за один вызов
    // ... при FAILED_PREPARE: один раз оптимизируем кэш, повторяем, иначе возвращаем 1
    mctx = memory->init_batch(*balloc, cparams.n_ubatch, output_all);
    if (!mctx) {
        return -2;
    }
    // ... резервируем выходной буфер под n_outputs_all строк логитов
    do {
        const auto & ubatch = mctx->get_ubatch();
        // ... n_outputs — сколько строк логитов даёт этот подбатч
        ggml_status status;
        // шаг 13: строим (или переиспользуем) граф и выполняем его на CPU/GPU
        const auto * res = process_ubatch(ubatch, ctx_type_to_graph_type(cparams.ctx_type), mctx.get(), status);
        if (!res) {
            // ... откатываем позиции этого подбатча из модуля памяти
            switch (status) {
                case GGML_STATUS_ABORTED:      return  2;
                case GGML_STATUS_ALLOC_FAILED: return -2;
                case GGML_STATUS_FAILED:       return -3;
                case GGML_STATUS_SUCCESS:      GGML_ABORT("should not happen");
            }
        }
        auto * t_logits = res->get_logits();
        // шаг 14: забираем логиты этого подбатча с бэкенда в буфер контекста —
        // пропускается, если у всех выходных последовательностей есть бэкенд-сэмплер
        if (logits.data && t_logits && n_outputs > 0 && needs_raw_logits(ubatch, sampling.samplers)) {
            ggml_backend_t backend_res = ggml_backend_sched_get_tensor_backend(sched.get(), t_logits);
            float * logits_out = logits.data + n_outputs_prev*n_vocab;
            // ... проверки, что эти строки помещаются в выходной буфер
            ggml_backend_tensor_get_async(backend_res, t_logits, logits_out, 0, n_outputs*n_vocab*sizeof(float));
        }
        // ... эмбеддинги и выходы бэкенд-сэмплера извлекаются так же
        n_outputs_prev += n_outputs;
    } while (mctx->next());
    // после цикла приложение читает логиты через llama_get_logits_ith

Сначала проверяется батч:

• что в нём переданы либо токены, либо готовые эмбеддинги;
• что у этого контекста действительно есть модуль памяти — если его нет, decode сразу передаёт батч в encode.

Затем батч инициализируется через balloc->init — это нужно, чтобы заполнить позиции токенов и решить, для каких позиций считать логиты (обычно только для последней). Резервируется планировщик и обновляется память (KV-cache).

Дальше memory->init_batch разбивает батч на подбатчи размером не больше n_ubatch токенов каждый и возвращает контекст памяти, в котором лежат все они, — так большой батч разбивается на части, которые по очереди прогоняются через модель. Цикл берёт их по одному и для каждого вызывает process_ubatch(...): внутри строится вычислительный граф (эмбеддинги, слои трансформера, выход в логиты) — или переиспользуется уже построенный, если форма прохода ничем не изменилась, — выполняется вычисление на CPU/GPU и возвращаются тензоры с логитами: «сырыми», ненормированными оценками по словарю.

init_batch — метод модуля памяти, поэтому у каждого типа памяти своя реализация; для обычного KV-cache это llama_kv_cache::init_batch в src/llama-kv-cache.cpp (сам интерфейс объявлен в src/llama-memory.h):

// src/llama-kv-cache.cpp, llama_kv_cache::init_batch — сокращённо
// Шаг 12: весь батч режется на подбатчи здесь, за один вызов, до запуска любого из них
llama_memory_context_ptr llama_kv_cache::init_batch(
            llama_batch_allocr & balloc,
            uint32_t n_ubatch,
            bool embd_all) {
    do {
        balloc.split_reset();

        std::vector<llama_ubatch> ubatches;
        while (true) {
            // каждый вызов берёт очередные (не больше) n_ubatch ещё не использованных токенов батча
            auto ubatch = n_stream == 1 ? balloc.split_simple(n_ubatch) : balloc.split_equal(n_ubatch, true, 0);
            if (ubatch.n_tokens == 0) {
                break;  // батч исчерпан
            }
            ubatches.push_back(std::move(ubatch));
        }

        if (balloc.get_n_used() < balloc.get_n_tokens()) {
            break;  // часть токенов не удалось разложить ни в один подбатч
        }

        // находим слот в KV-cache под каждый подбатч, прежде чем зафиксировать хоть один
        auto sinfos = prepare(ubatches);
        if (sinfos.empty()) {
            break;
        }

        return std::make_unique<llama_kv_cache_context>(
                this, std::move(sinfos), std::move(ubatches));
    } while (false);

    // места под этот батч нет — decode превращает это в код возврата 1
    return std::make_unique<llama_kv_cache_context>(LLAMA_MEMORY_STATUS_FAILED_PREPARE);
}

Что делает init_batch и для чего:

• за один проход режет весь батч на порции не больше n_ubatch токенов каждая.

  Для чего: один вызов process_ubatch обрабатывает ограниченное число токенов — так на длинном промпте не разрастается память под промежуточные тензоры графа.

• для каждой порции копирует в ubatch токены, позиции и флаги выходов.

  Для чего: process_ubatch получает готовый подбатч и строит граф ровно под него.

• перед возвратом резервирует слот в KV-cache под каждый подбатч и только потом фиксирует результат.

  Для чего: если кэш не вмещает весь батч, decode узнаёт об этом до того, как отработал хоть один подбатч, и может сообщить вызывающему вместо того, чтобы оставить в кэше половину батча.

• возвращённый контекст памяти хранит список подбатчей; цикл в decode идёт по нему через get_ubatch() и next().

  Для чего: длинный промпт обрабатывается за несколько проходов через модель, без единого огромного графа.

Цикл по подбатчам в llama_context::decode устроен так: контекст памяти, возвращённый memory->init_batch, выдаёт по одному подбатчу через get_ubatch(), для каждого вызывается process_ubatch(ubatch, gtype, mctx, status), а next() переводит на следующий, пока подбатчи не кончатся. Тип графа gtype не выбирается для каждого подбатча — он следует из типа контекста и одинаков для всех проходов этого контекста. Между проходом по длинному промпту и проходом с одним токеном различается кое-что попроще: батчевый проход берёт число потоков для батча, а не для генерации, и при создании контекста llama.cpp резервирует буферы вычислений по худшему случаю сразу под обе формы. После каждого process_ubatch логиты для позиций, помеченных как выходные, копируются с бэкенда во внутренний буфер контекста, откуда их читает llama_get_logits_ith, — но только если хотя бы одна из этих позиций принадлежит последовательности без своего бэкенд-сэмплера: когда сэмплеры навешаны на все, сырые логиты не копируются вовсе. Строить граф заново для каждого подбатча было бы расточительно, поэтому llama.cpp переиспользует предыдущий, если параметры, полностью определяющие его топологию, не изменились.

Порядок вызовов при одном decode (сводка):

• llama_decode(ctx, batch) → ctx->decode(batch);
• в decode: проверка батча (и, если у контекста нет модуля памяти, передача батча в encode и возврат), balloc->init(...), резервирование планировщика, применение отложенных обновлений памяти (KV-cache);
• memory->init_batch(...) — один вызов, который разбивает весь батч на подбатчи и резервирует слот в кэше под каждый; затем резервируется выходной буфер;
• цикл: get_ubatch() выдаёт очередной ubatch, вызывается process_ubatch(ubatch, ...) — внутри model.build_graph (или переиспользование предыдущего графа), res->set_inputs, graph_compute — логиты копируются в буфер контекста, а next() переходит к следующему подбатчу;
• после цикла приложение читает логиты через llama_get_logits_ith, сэмплер возвращает следующий токен.

Логиты копируются в выходной буфер контекста. Оттуда их читает llama_get_logits_ith — по этим числам сэмплер выбирает следующий токен (например, самый вероятный или по temperature/top_p).

Возвращаемое значение llama_decode: 0 — успех; 1 — в KV-cache не нашлось свободного слота под этот батч (уменьшить батч или увеличить контекст); 2 — вычисление прервано колбэком; -1 — сам батч некорректен; всё, что меньше -1, — фатальная ошибка, чаще всего неудачное выделение буфера. Положительный код — это предупреждение, а не сбой, но 2 тоже положительное, так что проверка только на отрицательное значение пропустит прерывание незамеченным — проверять надо на любое значение, кроме 0. После прерывания или фатальной ошибки уже отработавшие подбатчи остаются в памяти контекста; насколько далеко продвинулся батч, можно узнать через llama_memory_seq_pos_min и llama_memory_seq_pos_max. Минимальные примеры, которые идут в комплекте с llama.cpp, просто считают любой ненулевой код фатальным и останавливаются. Приложение должно проверять возвращаемое значение и при ошибке прекращать генерацию или выводить сообщение об ошибке.

Шаг 13а: Подготовка к прогону подбатча (память, параметры графа)

Шаг 13 разбит в статье на три части: подготовка к прогону подбатча, построение графа и аллокация буферов, запись входов и выполнение графа. Вся работа по одному подбатчу выполняется в методе llama_context::process_ubatch (файл src/llama-context.cpp). Его вызывают из llama_context::decode в цикле. Разбиение на подбатчи происходит раньше и только один раз: memory->init_batch вызывают со всем батчем, и он возвращает объект контекста памяти, в котором уже лежат все подбатчи вместе с нужным им состоянием кэша. Дальше цикл идёт по ним — mctx->get_ubatch() отдаёт текущий, mctx->next() переходит к следующему и возвращает false, когда они закончились, — и на каждый подбатч один раз вызывает process_ubatch. Внутри по шагам происходит: подготовка памяти, решение — переиспользовать ли уже построенный граф или строить заново, при необходимости построение графа и аллокация буферов, запись входных данных в граф, выполнение графа на CPU/GPU. Ниже — первая часть шага 13: точка входа и подготовка.

Для чего нужен вычислительный граф:

• модель (трансформер) — это цепочка операций: эмбеддинги, слои внимания (Q, K, V, softmax, взвешенная сумма), нормализации, feed-forward и т.д.;
• вместо того чтобы вызывать каждую операцию вручную, движок строит граф — список узлов (операций) и связей между ними;
• планировщик потом обходит граф в топологическом порядке и выполняет операции на CPU или GPU;
• так можно автоматически распределять узлы по устройствам и переиспользовать граф при одинаковых размерах батча.

Сигнатура и входные данные process_ubatch (цитата из src/llama-context.cpp):

// src/llama-context.cpp, llama_context::process_ubatch — один подбатч прогоняется через модель;
// вызывается из llama_context::decode в цикле по подбатчам
llm_graph_result * llama_context::process_ubatch(const llama_ubatch & ubatch, llm_graph_type gtype, llama_memory_context_i * mctx, ggml_status & ret) {
    // 1) фиксируем состояние памяти, подготовленное для этого подбатча (ячейки KV-cache), до построения графа
    if (mctx && !mctx->apply()) {
        LLAMA_LOG_ERROR("%s: failed to apply memory context\n", __func__);
        ret = GGML_STATUS_FAILED;
        return nullptr;
    }

    // 2) результат ПРЕДЫДУЩЕГО построения: в нём лежат граф и его входные тензоры
    auto * res = gf_res_prev.get();
    auto * gf  = res->get_gf();

    // 3) всё, от чего зависит топология графа; граф можно переиспользовать только тогда,
    //    когда эти параметры совпадают с теми, с которыми он был построен
    const auto gparams = graph_params(res, ubatch, mctx, gtype);

    // ... опущено: решение о переиспользовании, build_graph, set_inputs и graph_compute — см. ниже
}

Что происходит в начале process_ubatch и для чего:

• Вызывается mctx->apply(), если передан контекст памяти (mctx).

  Для чего:

• контекст памяти обновляет состояние KV-cache и служебных буферов (например, сдвигает указатели на следующие свободные позиции); перед построением графа граф будет обращаться к этим буферам — они должны быть в актуальном состоянии.

• gf_res_prev — это результат предыдущего построения графа: сам граф, его входные тензоры и параметры, с которыми он был построен. При самом первом вызове он пуст, поэтому граф строится с нуля; дальше он становится кандидатом на переиспользование.

  Для чего:

• именно хранение последнего графа и делает переиспользование возможным — если новые параметры совпадают с сохранёнными в нём, тот же граф можно выполнить снова с новыми значениями входов.

• в gparams собирается всё, от чего зависит форма графа: архитектура модели и её гиперпараметры, параметры контекста, копия текущего ubatch (сколько в нём токенов, как они сгруппированы по последовательностям, лежат в нём ID токенов или готовые эмбеддинги), тип графа, планировщик, загруженные LoRA-адаптеры и control vector, контекст памяти, сэмплеры по последовательностям и число позиций, для которых нужны выходы.

  Для чего:

• правило такое: два графа с одинаковыми gparams имеют одинаковую топологию; именно это и делает возможной проверку на переиспользование ниже, а те же значения потом задают размеры узлов и входных тензоров при построении графа.

Если mctx->apply() возвращает false, функция сразу возвращает nullptr и в ret записывается GGML_STATUS_FAILED — вызывающий код (decode) обработает ошибку и прекратит цикл по подбатчам.

Цитата по смыслу: что делает mctx->apply() и что входит в gparams (по коду src/llama-context.cpp и src/llama-kv-cache.cpp):

// mctx->apply() — фиксирует состояние памяти, подготовленное для этого подбатча. Для KV-cache это значит
// записать позицию и id последовательности каждого токена в отведённые ему ячейки и пересчитать,
// сколько ячеек графу придётся читать (src/llama-memory.h, src/llama-kv-cache.cpp)
if (mctx && !mctx->apply()) { ret = GGML_STATUS_FAILED; return nullptr; }

// graph_params() собирает всё, от чего зависит топология графа: архитектуру, параметры модели
// и контекста, копию подбатча, тип графа, планировщик, адаптеры, контекст памяти,
// сэмплеры и n_outputs — проверка на переиспользование сравнивает ровно этот набор
const auto gparams = graph_params(res, ubatch, mctx, gtype);

Шаг 13б: Построение вычислительного графа и аллокация буферов

Шаг 13 (продолжение) — построение графа и выделение под него буферов. После подготовки памяти и формирования gparams движок решает: можно ли переиспользовать уже построенный граф (та же форма подбатча и те же параметры построения), или нужно строить граф заново и выделять под него буферы. Если граф переиспользуется — сразу переходят к записи входов и выполнению. Если нет — вызываются res->reset(), ggml_backend_sched_reset(sched.get()), model.build_graph(gparams) и ggml_backend_sched_alloc_graph(sched.get(), gf). Ниже по шагам, что за чем происходит и для чего; несколько цитат из кода.

Цитата: решение о переиспользовании и построение графа (фрагмент process_ubatch, src/llama-context.cpp):

    // граф перестраиваем только когда изменились параметры; повторные decode с одним токеном переиспользуют его
    if (!graph_reuse_disable && res->can_reuse(gparams)) {
        // ... опущено: при pipeline parallelism здесь синхронизируется предыдущий, ещё идущий расчёт,
        //     иначе set_inputs перезаписал бы тензоры, которые он ещё читает
        n_reused++;  // счётчик переиспользований (профилировщик показывает его как "graphs reused")
    } else {
        res->reset();   // выбрасываем старый граф вместе с его входными тензорами

        ggml_backend_sched_reset(sched.get());  // сбрасываем разбиение планировщика и его аллокации
        ggml_backend_sched_set_eval_callback(sched.get(), cparams.cb_eval, cparams.cb_eval_user_data);

        gf = model.build_graph(gparams);  // эмбеддинги → слои трансформера → логиты

        if (!gf) {
            LLAMA_LOG_ERROR("%s: failed to initialize graph\n", __func__);
            ret = GGML_STATUS_FAILED;
            return nullptr;
        }

        // планировщик разбивает граф по устройствам и выделяет память под каждый тензор
        if (!ggml_backend_sched_alloc_graph(sched.get(), gf)) {
            LLAMA_LOG_ERROR("%s: failed to allocate graph\n", __func__);
            ret = GGML_STATUS_ALLOC_FAILED;
            return nullptr;
        }
    }