By Blip in AI — 23 мая 2026

LLM 101: практическое руководство (редакция 2026)

Начните с цикла. Текст превращается в токены. Токены проходят через трансформер. Attention решает, какие предыдущие токены важны. Среда выполнения хранит KV-кэш, чтобы модель не пересчитывала весь разговор каждый раз заново. Затем модель выбирает следующий токен и повторяет всё снова.

Источник: https://x.com/TheAhmadOsman/status/2057590224729911346

Автор: Ahmad

Практическое руководство о том, как работают LLM, как модели «думают» по одному токену за раз и как запускать их локально.

Когда этот цикл становится понятен, выбор железа и софта становится проще объяснять. VRAM, квантование, длина контекста, chat templates, decode, RAG, serving engines и выбор модели — всё вытекает из одной и той же механики.

Начните с цикла: токены на входе, вероятности на выходе, по одному следующему токену за раз. Веса говорят модели, какие паттерны она выучила. Контекст говорит ей, на что она смотрит прямо сейчас. KV-кэш — это рабочая память, которая делает цикл пригодным к использованию. Железо, runtime и выбор модели имеют смысл только после того, как вы понимаете правила памяти, контекста и форматирования, которым подчиняется модель.

Цель — сначала сделать механику локальных LLM интуитивной, а затем дать практический путь к железу, runtime, serving и современным исследованиям LLM по состоянию на 21 мая 2026 года.

Фокус

Это руководство сначала смотрит на модель. Оно начинается с механики: inference, токены, трансформеры, attention, KV-кэш, prefill, decode, параметры декодирования, пакеты моделей, chat templates, типы моделей, длинный контекст, RAG, агенты, fine-tuning и мультимодальные модели.

После этого оно переходит к слою локального развёртывания: что на самом деле значит «локально», квантование, расчёт VRAM, уровни железа, выбор runtime, режимы serving, лицензии, выбор модели, приватность, troubleshooting, benchmarks, пути настройки и практические сценарии.

Такой порядок важен. Нужно понимать, почему длинный prompt стоит памяти, прежде чем выбирать GPU. Нужно понимать, почему chat templates важны, прежде чем оценивать модель. Нужно понимать, почему decode последовательный, прежде чем заботиться о токенах в секунду.

Для более глубокого пути по железу и софту у меня есть серия из трёх частей о self-hosted LLM / local AI:

Часть 1: расчёт памяти GPU для LLM (редакция 2026).
Часть 2: пропускная способность памяти для локального AI-железа (редакция 2026).
Часть 3: inference engines для LLM и локального AI-железа (редакция 2026).

Первые две статьи объясняют математику ёмкости и пропускной способности железа. Третья объясняет программный слой, который превращает это железо в usable inference. Эта статья сначала даёт модельный фундамент, а затем возвращает вас к слоям развёртывания, когда механика уже понятна.

Что LLM на самом деле делает

Запуск модели называется inference. Для стандартной decoder-only LLM inference — это один и тот же цикл, повторяющийся снова и снова:

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

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

Математически модель — это выученная функция:

f(theta, sequence) -> распределение вероятностей по next_token

Где:

theta означает веса модели.
sequence означает prompt плюс уже сгенерированные токены.
Logits — это сырые scores до softmax.
Probabilities — нормализованные scores после softmax.
Decoding превращает эти вероятности в один выбранный токен.

Именно поэтому скорость локальной генерации измеряется в токенах в секунду. Ваша система снова и снова запускает forward pass, выбирает или сэмплирует токен, обновляет KV-кэш и продолжает.

Здесь важна воспринимаемая скорость. Длинный prefill означает долгую паузу до появления первого слова. Медленный decode означает, что ответ стримится медленно. Локальные сборщики часто зациклены на скорости decode, потому что именно её чувствуют пользователи, но время prefill болит, когда вы вставляете документ на 10K токенов.

Токены

LLM не видят сырой текст как слова. Они видят токены: маленькие куски текста, внутренне представленные как целочисленные ID.

Токеном может быть:

Целое слово: "hello"
Фрагмент слова: "inter", "national", "ization"
Знак пунктуации
Строка с начальным пробелом
Byte-level fallback
Специальный управляющий маркер, например <|user|>, <|assistant|>, , или

Токенизатор отображает текст в token IDs и token IDs обратно в текст. Распространённые семейства токенизаторов включают BPE-style tokenizers и SentencePiece-style tokenizers. Разные семейства моделей используют разные токенизаторы, и это важно. Документ на 4 000 слов может быть 5 000 токенов в одном токенизаторе и 7 500 токенов в другом.

Размер словаря тоже важен. Токенизатор с большим словарём может сжимать некоторый текст в меньшее число токенов, но он также меняет размер embeddings и output projection. Это одна из причин, почему токены в секунду нельзя идеально сравнивать между семействами моделей.

Токены важны, потому что они определяют:

Сколько текста помещается в context window.
Насколько большим становится KV-кэш.
Какую latency вы платите во время обработки prompt.
Насколько эффективен multilingual или code-heavy текст.
Правильно ли модель видит специальные chat markers.

Context window модели — это максимальное число токенов, к которым она может attend одновременно. В 2026 году распространённые локально пригодные модели варьируются от контекстов 8K и 32K до 128K, 256K и даже 1M-token contexts в server-class системах.

Но поддерживаемая длина контекста — не то же самое, что дешёвый, быстрый или одинаково точный контекст. Модель, которая технически может обрабатывать 128K токенов, может замедлиться до ползания на 64K и терять связность на 100K. Всегда тестируйте те длины контекста, которые реально планируете использовать.

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

Полезное упражнение: попробуйте моё демо-приложение Tokenizer, чтобы увидеть, как текст разбивается на токены в реальном времени.

Трансформеры

Большинство современных LLM основаны на архитектуре Transformer. Большинство локальных chat LLM — decoder-only Transformers: они предсказывают следующий токен, глядя назад на предыдущие токены.

Всё выше этого места, включая токены, веса, config и chat templates, — подготовка для настоящего движка под капотом. Transformer — это скелет, который перемещает числа.

Упрощённый слой Transformer содержит:

Token embeddings: token IDs становятся векторами.
Positional information: модели нужен порядок токенов. Многие современные LLM используют RoPE (Rotary Position Embeddings), который кодирует позицию через вращение представлений.
Self-attention: представление каждого токена смотрит назад на представления предыдущих токенов и решает, что важно.
MLP / feed-forward block: плотное нелинейное вычисление, которое расширяет и сжимает представления. Большая доля параметров живёт здесь.
Layer normalization и residual connections: они стабилизируют глубокие сети и помогают информации проходить через множество слоёв.
Output projection: финальное hidden state становится logits по словарю.

Сложите этот рецепт десятки или сотни раз — и получите языковую модель.

Кратко о Transformer: токены становятся векторами, attention связывает последовательность, MLP меняют представление, RoPE удерживает позиции в порядке, а финальная projection превращает последний hidden state в logits следующего токена.

Attention

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

Классический MHA (multi-head attention) хранит отдельное key/value state для многих heads. Это даёт модели гибкость, но делает KV-кэш большим.

Современные локальные модели часто используют более эффективные attention designs:

MQA: несколько query heads делят один key/value head. Это эффективно по памяти, но может быть менее выразительным.
GQA: группы query heads делят key/value heads. Это распространённая золотая середина во многих текущих локальных моделях.
MHA: полный multi-head attention. Он может быть сильным, но длинный контекст быстро становится дорогим.

Современные kernels, такие как FlashAttention и SDPA-style реализации, уменьшают memory traffic attention и лучше загружают GPU. Runtime с хорошими attention kernels может быть драматически быстрее runtime без них даже на той же модели и железе.

Именно поэтому две 7B модели могут вести себя очень по-разному на длинном контексте. Число параметров — не вся история. 7B MHA модель на 128K context может исчерпать 24 GB GPU, а 7B GQA модель с тем же заявленным контекстом может поместиться с запасом.

Сравнивая модели, смотрите на тип attention, KV heads, длину контекста и поддержку runtime, а не только на число параметров.

KV-кэш

KV-кэш — это рабочая память модели во время генерации. Он хранит key/value attention states для предыдущих токенов, чтобы модель не пересчитывала всю историю с нуля на каждом сгенерированном токене.

Без KV-кэша генерация была бы зверски неэффективной. С KV-кэшем генерация usable, но кэш потребляет память пропорционально:

tokens x layers x kv_heads x head_dim x precision x 2

x 2 — это для keys и values.

Полезное правило для старых Llama-like 7B MHA моделей — примерно 0.5 MiB на токен в FP16 KV-кэше. Это означает, что 4K токенов могут стоить около 2 GiB только на KV-кэш. На 32K токенов вы можете смотреть уже на 16 GiB одного KV-кэша.

Новые GQA/MQA модели существенно это уменьшают. Некоторые runtime также поддерживают FP8 или INT8 KV-кэш. В 2026 году это часто практический нижний предел сжатия, который я бы рекомендовал локальным пользователям.

Не относитесь к sub-8-bit KV-кэшу как к дефолту. Исследовательские системы вроде KIVI, KVQuant и новых compressed-cache kernels показывают, что 2-bit–4-bit KV может работать с аккуратными алгоритмами, калибровкой и custom kernels. Это не то же самое, что небрежно включить Q4 KV toggle в desktop runtime. Ниже 8-bit — жёстко бенчмаркайте, особенно для кода, tool calls, JSON, long-context retrieval и задач, где важны точные предыдущие токены.

Также не путайте KV-cache quantization со speculative decoding. DFlash и DDTree, часто неформально сокращаемый до DTree, атакуют decode latency, черновым образом предлагая будущие токены и проверяя их. Они могут повышать скорость, но не стирают счёт памяти KV-кэша.

Именно поэтому модель может помещаться на пустом prompt, но падать при загрузке длинного документа. Веса поместились. Рабочая память — нет.

Prefill и Decode

LLM inference имеет два разных режима производительности: prefill и decode.

Prefill обрабатывает prompt, который вы дали модели. Если вы вставляете документ на 20 000 токенов, модель должна обработать эти 20 000 токенов, прежде чем сможет выдать первый токен ответа. Prefill относительно хорошо параллелится, поэтому GPU могут эффективно его обрабатывать, но он всё равно может быть дорогим.

Время ожидания появления первого токена обычно является временем prefill.

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

Длинные prompts наказывают prefill. Длинные ответы наказывают decode. Длинные разговоры наказывают оба, потому что KV-кэш растёт.

В chat session каждый turn добавляется в кэш. Если вы позволяете разговору вырасти до 16K токенов, вы платите memory cost за все 16K токенов на каждом новом генерируемом токене. Именно поэтому chat UI с бесконечной историей рано или поздно замедляются или падают.

Decoding

После того как модель выдаёт logits, она ещё ничего не написала. Она только оценила каждый возможный следующий токен. Decoding — это политика, которая превращает эти scores в один реальный токен, добавляет этот токен к контексту и повторяет цикл.

Runtime, или inference engine, может выбирать токены разными способами. Он может каждый раз брать токен с максимальной вероятностью. Может сэмплировать из суженного множества вероятных токенов. Может штрафовать повторы. Может остановиться на delimiter. Может использовать фиксированный seed, чтобы один и тот же prompt воспроизводился одинаково.

Эти choices не меняют веса модели, но меняют её голос, детерминизм, креативность, risk profile и склонность зацикливаться.

Важные knobs отвечают на три практических вопроса:

Randomness: сколько вариативности разрешено?
Tail reach: насколько глубоко в низковероятные токены может заходить sampler?
Boundaries: что предотвращает loops, rambling, schema breaks или runaway output?

Для точной работы начинайте узко: низкая temperature, короткие max-token limits, явные stop sequences и constrained decoding, когда output должен соответствовать JSON или schema. Для творческой работы дайте sampler больше пространства с higher temperature, top-p и несколькими candidates с последующим ранжированием. Для кода держите первый проход консервативным, а alternatives сэмплируйте только когда вы намеренно исследуете варианты.

Greedy decoding не всегда точнее. Часто он хрупок. Greedy decoder может застрять в loops или давать generic answers, потому что никогда не исследует alternatives. Для evals используйте deterministic settings. Для ideation дайте модели дышать.

Что содержит пакет модели

Runnable local LLM — это больше, чем один большой файл весов. Пакет модели обычно включает:

Architecture/config: число слоёв, hidden size, тип attention, настройки RoPE, vocabulary size, special tokens и context length.
Weights: выученные параметры, часто сохранённые как safetensors, GGUF, GPTQ, AWQ, EXL2 или другой runtime-specific format.
Tokenizer: правила, которые превращают текст в token IDs и token IDs обратно в текст.
Chat template: точная разметка для system, user, assistant, tool и reasoning messages.
Generation config: дефолты для temperature, top-p, stop tokens, repetition penalties и max tokens.
License and model card: юридические и операционные инструкции о том, как можно использовать модель.

Веса — самый большой файл, но это не вся модель. Если tokenizer, config или chat template неправильные, те же самые веса могут казаться сломанными.

Раздел про package говорит, что должно путешествовать вместе. Следующий раздел объясняет, почему chat template — часть, которую люди ломают чаще всего.

Chat Templates

Chat model обучалась на конкретном формате разговора. Например, она может ожидать что-то вроде:

Другая модель может ожидать:

[BOS] [INST] Explain KV cache. [/INST]

Другая может использовать ChatML-style markers. Ещё одной могут требоваться специальные reasoning tokens. Ещё одной могут быть нужны tool-call XML или JSON wrappers.

Использование неправильного формата может вызвать gibberish, role confusion, ignored system prompts, repeated prompts, странные refusals, broken tool calls, плохие benchmark results и выводы, что модель тупая, хотя настоящая ошибка — template.

Best practice:

Используйте tokenizer's apply_chat_template при работе с Transformers.
Используйте model-specific templates во фронтендах на Harbor, llama.cpp, LM Studio, vLLM или SGLang.
Проверяйте, модель base, instruct, chat, reasoning или tool-tuned.
Убедитесь, что BOS/EOS tokens корректны.
Держите system prompts короткими, если им не нужно быть длинными.
Для tool use следуйте точной schema, которую ожидает model/runtime.

Если вы строите приложение, где пользователи могут переключать модели, вам нужно и переключение templates. Hardcoding одного template format и последующая загрузка модели, ожидающей другой, — частый источник плохих local-model evals.

Относитесь к template как к API contract. Если вы ошиблись, вы на самом деле не тестируете ту модель, которую думаете тестировать.

Типы моделей

Не все LLM настроены на одно и то же поведение.

Для большинства пользователей дефолтной отправной точкой должна быть свежая instruct/chat-tuned модель в размере, который комфортно помещается в память.

Не начинайте с base model, если не знаете зачем. Base models продолжают ваш prompt, а не отвечают на него. Они полезны исследователям, fine-tuners и людям, строящим custom pipelines. Для всех остальных они раздражающие.

Если спросить base model: What is the capital of France?, она может продолжить: and what is the population of Paris? вместо ответа Paris.

Практическое разделение простое:

Base model: хороша для pretraining research, fine-tuning и custom pipelines.
Instruct model: хороша для прямого следования инструкциям.
Chat model: хороша для multi-turn dialogue с role formatting.
Reasoning model: хороша, когда задача выигрывает от дополнительных thinking tokens и verification.
Tool-tuned model: хороша, когда важны structured calls, JSON или function use.

Что на самом деле значит Local

Local LLM — это модель, чьи веса и inference runtime находятся под вашим контролем. Вы решаете, какая модель запускается, как она запускается, какие данные видит и что происходит с outputs.

Эта свобода приходит с работой. Теперь вы ops team. Вы управляете downloads, updates, compatibility, memory limits и security. Когда что-то ломается, некуда отправить support ticket. Есть только вы, logs и documentation.

Local может означать:

Модель с 2B параметров, работающую на телефоне.
Модель 7B–14B, работающую на consumer GPU.
Модель 30B–70B, работающую на high-end workstation.
Sparse MoE model, работающую на одной или нескольких datacenter GPUs.
Private deployment с vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio или custom PyTorch stack.

Главная мысль: local не означает автоматически offline, private, safe, cheap или opensource. Это значит только, что вы запускаете модель сами. Local app всё ещё может phone home. Модель может быть open-weight, но не opensource. Модель может быть local, но небезопасной для загрузки. Quantized model может помещаться в память, но плохо отвечать.

Компромисс стоит того, когда вам нужны privacy, low latency, custom behavior, offline operation или cost control at scale. Он не стоит того, когда вам нужно абсолютное лучшее качество моделей и у вас нет соответствующего железа. В таком случае hosted API — правильный инструмент.

Local LLM практичны, когда вы понимаете одно уравнение:

Local LLM success = model fit + correct prompt format + good runtime + realistic evals.

Всё остальное — детали. Детали важны.

Квантование

Квантование хранит веса в меньшей precision, чтобы уменьшить память и иногда повысить throughput.

Правило 2026 года для локальных пользователей:

FP16/BF16: лучшее качество, когда памяти много. Используйте как baseline для evaluation.
Q8 / INT8: почти без потерь для многих задач, но всё ещё крупно. Хорошо, когда у вас есть VRAM и вы хотите минимальную потерю качества.
Q6 / Q5: отличное качество при умеренной экономии. Сильная золотая середина.
Q4: дефолтная consumer sweet spot для многих chat и document workflows.
Q3 / Q2: только когда нужно уместить более крупную модель. Math, code, structured output и tool use деградируют первыми.

Weight quantization — не то же самое, что KV-cache quantization. Weight quantization сжимает модель. KV-cache quantization сжимает живую память контекста.

Для KV-кэша относитесь к FP16/BF16 как к чистому baseline, а к FP8/INT8 — как к практическому нижнему пределу локального сжатия. Ниже 8-bit — много research и высокая зависимость от workload. Используйте только после измерения качества на ваших реальных prompts.

Сбой квантования сначала проявляется в math, multi-step reasoning, code correctness, tool-use reliability, JSON/schema adherence, subtle instruction following и long-context retrieval.

Меньшая модель с более высокой precision может побить большую модель, раздавленную в слишком малое число bits. Не поклоняйтесь числу параметров. 7B модель в Q6 может обойти 13B модель в Q2 на reasoning tasks, используя меньше памяти и работая быстрее.

File Formats и безопасность загрузки

safetensors — безопасный формат сериализации tensors, созданный для хранения tensors без поведения Python pickle. Используйте safetensors, когда возможно, особенно для PyTorch/Transformers models.

Избегайте случайных .bin файлов из ненадёжных источников. PyTorch pickle-based loading может выполнять произвольный код во время deserialization. Правило номер один безопасности local AI: не позволяйте чужому model file становиться чужим code execution.

GGUF — binary model format экосистемы llama.cpp. Используйте GGUF, когда вам нужны llama.cpp, CPU inference, Apple Silicon inference, simple local servers, portable quantized models или desktop tools вроде LM Studio.

ONNX полезен для стандартизированного deployment и hardware-specific acceleration, особенно вне обычного PyTorch stack. Если вы развёртываете на Intel NPUs, ARM devices или custom accelerators, ONNX часто является путём наименьшего сопротивления.

TensorRT-LLM — высокопроизводительный inference path NVIDIA для production GPU deployments. Он мощный, но сложнее llama.cpp или Harbor. Обычно вы конвертируете checkpoint в TensorRT engines, что занимает время и GPU memory, но даёт отличный throughput после сборки.

EXL2 / GPTQ / AWQ formats распространены в GPU-focused local inference communities, особенно для размещения более крупных моделей на single GPUs.

Выбор file format не косметический. Он определяет, какие runtime смогут загрузить модель, какое quantization можно использовать и как быстро она будет работать.

Runtimes и режимы Serving

Runtime — это software, который загружает модель и выполняет inference. В 2026 году экосистема local LLM runtime зрелая, полезная и фрагментированная.

Для одного человека, экспериментирующего локально, начните с Harbor, LM Studio или llama.cpp. Harbor лучше всего подходит, когда нужен полный local stack с frontends, backends и supporting services, уже связанными вместе. LM Studio — самый простой desktop-first путь. llama.cpp — portable low-level workhorse.

Для команды или private service смотрите на vLLM или SGLang. Для максимальной NVIDIA production performance изучите TensorRT-LLM. Для browser или mobile deployment смотрите на MLC или WebLLM.

Выбор runtime часто привязывает вас к format ecosystem. llama.cpp означает GGUF. vLLM и SGLang обычно означают safetensors или Hugging Face checkpoints. TensorRT-LLM означает ONNX или optimized engines. Сначала выберите runtime, затем ищите модели в правильном формате.

Есть три практических режима serving.

Single-user local означает desktop app, CLI stack или command-line server для одного человека. Harbor, LM Studio, llama.cpp server, ExLlama/TabbyAPI и маленькие Transformers scripts подходят сюда. Цель — быстрая итерация: сравнить behavior, speed, memory use и prompt formats без построения ops platform.

Team or private API означает OpenAI-compatible endpoint на workstation или server. vLLM, SGLang, TensorRT-LLM и llama.cpp server появляются здесь в зависимости от model size и throughput needs. Когда несколько людей или jobs делят модель, нужны monitoring, prompt/version management, routing и realistic latency measurements.

Production serving — другая работа. Теперь разговор включает continuous batching, prefix caching, speculative decoding, paged attention, tensor parallelism, pipeline parallelism, quantized serving, structured outputs, load balancing, GPU utilization, latency percentiles, prompt caching, admission control, logging, failover, privacy и cost controls.

На production scale вопрос «могу ли я загрузить модель?» — лёгкий. Сложный вопрос: «могу ли я reliably serve it under real traffic?»

Расчёт VRAM для локальных моделей

Есть три основных потребителя памяти:

Model weights
KV cache
Runtime overhead

Грубая формула памяти весов:

weight_memory ~= parameters x bytes_per_parameter

Полезные приближения:

FP16/BF16: около 2 bytes per parameter.
INT8/Q8: около 1 byte per parameter.
Q4: около 0.5 bytes per parameter плюс format overhead.

Затем добавьте:

Runtime overhead: framework buffers, CUDA overhead, memory fragmentation и temporary tensors.
KV cache: растёт с каждым токеном в active context.
Batch/concurrency memory: каждому concurrent request нужен собственный cache.
Vision encoder memory: images тоже становятся токенами.
Speculative decoding memory: draft models, draft heads или extra verification structures не бесплатны.
Adapter memory: LoRA adapters маленькие, но всё равно реальные.

MoE models добавляют ещё одну тонкость. Модель может активировать только часть своих параметров на токен, но inactive experts обычно всё равно должны где-то жить в памяти. Active parameters влияют на compute cost. Total parameters всё ещё влияют на loading и capacity planning.

Реалистичная оценка выглядит так:

total_memory = quantized_weightsKV_cache_for_context runtime_overhead batch_or_concurrency_overhead safety_margin

Вот ловушка: 13B модель в Q4 может легко помещаться на 8K context, а затем падать на 32K, потому что KV-кэш вырос в четыре раза. Веса не изменились. Контекст изменился.

Оставляйте 10–20 процентов headroom. Работа на 99 процентах VRAM utilization — просьба об out-of-memory errors и fragmentation failures.

Уровни железа на практике

Это практические правила 2026 года, предполагающие quantized inference и sane context lengths. Точные результаты зависят от runtime, quantization, model architecture, attention type, context length и OS/driver overhead.

Для большинства серьёзных локальных пользователей в 2026 году 16 GB — минимальный комфортный GPU tier, 24 GB — лучший value enthusiast tier, а 48 GB+ — место, где открывается более сильный локальный мир.

Performance зависит от memory bandwidth, GPU FLOPs, VRAM capacity, KV-cache size, attention implementation, quantization, batch size, prompt length, generated length и runtime maturity.

Decode часто memory-bandwidth-bound: GPU снова и снова stream weights, выполняя относительно мало compute per byte. Prefill более compute-bound, потому что может обрабатывать prompt параллельно. Именно поэтому две карты с одинаковой VRAM capacity могут иметь очень разную token speed, если у одной much higher memory bandwidth.

Самая болезненная локальная setup — та, где модель почти помещается и spills layers to CPU. Она может технически работать, но token speed может обрушиться. CPU offload приемлем для экспериментов. Это не performance strategy.

Выберите модель, которая помещается

Практический вопрос не «какая модель лучшая?», а «какая самая маленькая модель побеждает на вашем реальном workload на вашем железе?»

Начните со свежей instruct/chat model, которая комфортно помещается с длиной контекста, реально нужной вам. Если у вас 8–12 GB VRAM или unified memory, начинайте с малого. Если 16–24 GB, сначала тестируйте модели класса 7B–14B. Если у вас 48 GB или больше, larger dense models и MoE models становятся реалистичными.

Используйте этот memory gate, прежде чем влюбиться в checkpoint:

weights + KV cache + runtime overhead <= 80 to 90 percent of available memory

Затем прогоните одни и те же 20–50 prompts по кандидатам. Включите реальные tasks: coding edits, document Q&A, JSON output, summaries, tool calls, long context или всё, что вам действительно нужно. Измеряйте answer quality, latency, memory use, template reliability и failure modes.

Практический выбор модели обычно сводится к пяти проверкам:

Task fit: chat, coding, documents, agents, multimodal, edge или fine-tuning.
Memory fit: weights, KV cache, runtime overhead и safety margin.
Interface fit: tokenizer, chat template, stop tokens, tool schema и reasoning mode.
Runtime fit: хорошо ли ваш runtime поддерживает эту architecture, quantization, context length и serving mode?
License fit: можете ли вы реально использовать её там, где планируете?

Leaderboards полезны для discovery. Они не заменяют ваши собственные evals. Ваш workload — benchmark, который важен.

Для простого local assistant выберите свежую 7B–14B instruct model, Q4/Q5 quantization, правильный chat template, 8K–32K context и Harbor, LM Studio или llama.cpp. Приоритизируйте responsiveness, а не гигантский size.

Для local coding assistant выберите code-capable 14B–32B model, если хватает VRAM. Используйте low temperature, repository retrieval, test execution и patch-based workflow. Code model без tools — половина продукта.

Для private document assistant выберите сильную instruct model, local embedding model, reranker, RAG pipeline, citation enforcement и moderate-to-long context. Не вставляйте PDF на 200 страниц и не надейтесь.

Для reasoning setup выберите reasoning-tuned model, заложите extra tokens, используйте low-to-medium temperature, добавьте verification и tools для math, code или search. Reasoning models тратят больше токенов. Планируйте бюджет соответственно.

Для low-resource setup выберите 1B–4B model, Q4/Q5, short prompts, structured tasks, retrieval или tools и tight output schema. Малые модели становятся полезными, когда задача ограничена.

Что управляет скоростью

Tokens per second не контролируются одной вещью. Это результат model size, memory bandwidth, compute, attention kernels, context length, quantization, batching и runtime quality.

Главные рычаги:

Memory bandwidth: decode часто снова и снова стримит model weights, поэтому bandwidth доминирует single-user token speed.
GPU FLOPs: prefill и large batches используют больше parallel compute, поэтому FLOPs важнее там.
VRAM capacity: если model или KV cache spills to CPU, performance может обрушиться.
Attention implementation: FlashAttention, SDPA, paged attention и runtime-specific kernels меняют и speed, и memory behavior.
Quantization: меньшие weights уменьшают memory movement, но aggressive quantization может вредить quality и иногда добавлять dequantization overhead.
Batch size and concurrency: batching улучшает throughput, но каждой active sequence нужен KV cache.
Prompt length: длинные prompts увеличивают prefill time.
Generated length: длинные ответы раскрывают decode speed.
Speculative decoding: EAGLE-style methods, MTP, DFlash и DDTree могут проверять больше одного drafted token за target pass при поддержке.

Болезненная setup — almost-fit setup. Модель, которая spills layers или cache to CPU, может технически работать, но token speed может упасть с usable до miserable.

Бенчмаркайте именно тот runtime, quantization, context length, prompt shape и workload, которые планируете использовать. BF16 leaderboard number не говорит, как будет ощущаться ваш Q4 local stack.

Длинный контекст

Длинный контекст звучит магически: 128K, 256K или даже 1M tokens в одном prompt. Он полезен, но имеет реальные costs.

Больше context означае