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 означает больше KV cache memory, более медленную prompt processing, больше attention work, более сложную evaluation и больше способов, которыми irrelevant text может отвлекать модель. Quality также может деградировать на расстоянии. Модель может хорошо обрабатывать конец длинного документа, но пропускать critical details, спрятанные ближе к началу.

Используйте длинный контекст для whole-document analysis, codebase slices, legal or technical review, transcript summarization, multi-file reasoning и RAG fallback, когда retrieval пропускает context.

Не относитесь к длинному контексту как к замене retrieval. Это complement. Используйте RAG для large corpora и long context для final selected evidence.

Практические привычки помогают:

Размещайте critical instructions near the beginning and near the end.
Используйте section headers и delimiters.
Просите citations, привязанные к source chunks.
Сжимайте irrelevant history.
Используйте summary memory вместо infinite chat history.

Думайте о long context как о дорогом attention, а не бесплатной записной книжке.

Multimodality

Multimodal local models принимают images, а иногда audio или video, в дополнение к text. Современные open-weight ecosystems всё чаще включают эти модели.

Скрытая стоимость в том, что non-text input тоже становится tokens. Vision encoders добавляют memory. Image patches потребляют context. Audio и video могут взорвать input budget. Multimodal templates также легче испортить, чем text-only templates.

Одна high-resolution image может потреблять тысячи токенов в context window. Если вы запускаете multimodal model локально, считайте image tokens так же, как text tokens. Они идут из того же бюджета.

Small VLMs могут hallucinate visual details. OCR reliability varies. Charts and tables всё ещё сложны. Для серьёзных document или image workflows оценивайте на real samples. Не доверяйте demo простой фотографии как доказательству качества invoice extraction.

Локальная сцена моделей в 2026 году

Сцена моделей меняется быстро. По состоянию на 21 мая 2026 года пользователям local LLM стоит думать в терминах families и ecosystems, а не одной лучшей модели.

Qwen 3.5 / Qwen 3.6 — крупное open-weight family, потому что покрывает весь stack: small models для laptops, dense mid-size models для workstations, MoE models для multi-GPU serving, FP8 variants, long context, multilingual work, coding, tools и agentic workflows. Практический вывод прост: Qwen — сильное default family, когда нужна одна ecosystem от laptop experiments до серьёзного local serving.

Gemma 4 важна, потому что Google DeepMind двигает семейство к полезному local deployment: efficient edge models, larger dense and MoE options, multimodality, long context на larger models, broad language support, stronger coding/agent behavior и Apache 2.0 licensing. Эта комбинация стоит тестирования, когда важны commercial use и device-side deployment.

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax и Mistral — тоже core families, за которыми стоит следить. Kimi релевантна для long-horizon coding, multimodal reasoning, tool use и agent workflows. GLM важна для coding agents, long-horizon tasks, MoE systems и deployment-oriented model releases. DeepSeek остаётся влиятельной благодаря large MoE systems, Multi-head Latent Attention, DeepSeekMoE, FP8 serving paths, sparse attention и high-throughput self-hosting. MiniMax стоит внимания для practical agent workloads и inference-efficient MoE models. Mistral всё ещё важна, потому что её lineup покрывает generalist, coding, reasoning, multimodal и specialist use cases с сильной deployment support.

Nemotron 3 — open model family NVIDIA для production-grade agent systems на NVIDIA hardware. Семейство включает Nano, Super и Ultra sizes, использует hybrid Mamba-Transformer MoE designs и тесно связано с TensorRT-LLM, NIM, Dynamo, Blackwell NVFP4/FP8 paths и enterprise agent deployment. Относитесь к нему меньше как к casual desktop-chat family и больше как к сигналу, куда NVIDIA хочет вести open-weight serving stacks.

Open-weight AI — это уже не просто Llama против всего остального. Вы выбираете ecosystem: weights, license, tokenizer, template, quantizations, runtime support, serving path, community tools и failure modes.

The Qwen 27B Dense Model

Qwen 3.5 / 3.6 27B (Dense) — один из самых практичных public-weight options для локальных пользователей, которым важны coding, multilingual work, tool use, thinking/non-thinking modes и long context. Model cards Qwen 3.5 27B и Qwen 3.6 27B описывают OpenAI-compatible serving paths, thinking mode defaults, tool use и context lengths до 262 144 tokens, с longer-context extension через YaRN в поддерживаемых frameworks.

Qwen — сильный default для setup 2x RTX 3090, когда runtime правильно настроен для coding, agents или multilingual coverage.

Inference Research

Фронтир 2026 года — это не только качество моделей. Это ещё и inference efficiency. PagedAttention атакует KV-cache memory waste в serving. FP8 KV cache теперь практическая runtime feature в системах вроде vLLM. DFlash и DDTree исследуют speculative decoding с block diffusion draft models и draft trees. NVFP4 тоже стоит отслеживать на NVIDIA hardware, потому что он меняет практический разговор о deployment для поддерживаемых stacks.

Часть этого production-ready. Часть всё ещё research. Часть имеет значение только если ваш runtime чисто это поддерживает. Не относитесь к paper speedups как к checkbox в desktop app.

Failure Modes и Fixes

Большинство сбоев local LLM не мистические. Обычно они происходят из memory fit, formatting, runtime support, decoding settings или retrieval quality.

Out of memory: weights, KV cache, runtime overhead или batch size не помещаются. Используйте smaller model, уменьшите context, снизьте batch/concurrency, выберите better quantization или оставьте больше headroom.

Gibberish or role confusion: chat template, tokenizer, BOS/EOS token, reasoning-mode switch или tool schema неправильны. Проверьте model card и runtime template, прежде чем винить model quality.

Slow first token: prefill дорогой. Укоротите prompt, используйте prefix caching, улучшите retrieval, уменьшите context или используйте faster runtime.

Slow streaming: decode — bottleneck. Проверьте memory bandwidth, quantization, CPU spill, attention backend, speculative decoding support и не слишком ли модель велика для железа.

Bad document answers: retrieval, вероятно, failed. Проверьте parsed text, chunk boundaries, metadata, top-k retrieval, reranking и citation grounding.

Bad JSON or tool calls: используйте lower temperature, constrained decoding, stricter schemas, better examples и модель, tuned for tool use.

Repeating loops: снизьте temperature или top-p, добавьте repetition penalties, проверьте stop tokens и убедитесь, что template не заставляет модель видеть собственный answer как новый prompt.

Начинайте со скучных проверок. Они чинят больше проблем, чем swapping models.

Как развивать stack

Beginner: Easiest Useful Setup

Используйте Harbor или LM Studio, свежую 4B–9B instruct model, Q4 quantization, 8K–32K context и built-in chat UI. Скачайте две-три модели в одном size class и сравните их на одних и тех же prompts.

Goal: научиться prompting, сравнить models, понять speed and memory и сначала избегать custom code.

Intermediate: Developer Setup

Используйте llama.cpp или Transformers, GGUF или safetensors, OpenAI-compatible local server, простой RAG pipeline и маленький eval set. Вызывайте local server из настоящего application или script, а не только из chat UI.

Goal: строить local apps, тестировать retrieval, измерять quality и serve from localhost.

Advanced: Private Serving Setup

Используйте vLLM или SGLang, one or more GPUs, OpenAI-compatible API, monitoring, prompt/version management, evaluation suite, RAG with reranking и tool sandboxing.

Goal: обслуживать real users или internal workflows, оптимизировать throughput and latency и поддерживать safety and observability.

Expert: Custom Optimization

Используйте TensorRT-LLM, custom kernels, specialized runtimes, quantization experiments, speculative decoding, multi-GPU parallelism, fine-tuning, distillation и production evals.

Goal: обменять engineering time на inference efficiency, lower cost и higher quality at scale.

Privacy не автоматическая

Local LLM улучшают privacy, потому что prompts и outputs могут оставаться на вашем железе. Но local не означает автоматически secure.

Threats включают malicious model files, pickle-based weight loading, untrusted trust_remote_code, prompt injection в retrieved documents, tool-call abuse, secret leakage through logs, telemetry from desktop apps, browser extensions или plugins, model hallucinations in high-stakes settings, license violations и data contamination during fine-tuning.

Рабочий baseline безопасности local AI имеет четыре привычки:

Load carefully: предпочитайте safetensors или GGUF из reputable sources, избегайте untrusted .bin files и не включайте trust_remote_code casually.
Run with boundaries: используйте unprivileged user, containers или sandboxes для agents и отключённый network access, когда важна offline privacy.
Protect secrets: держите credentials вне prompts и RAG indexes, проверяйте desktop app telemetry settings и валидируйте tool calls перед execution.
Version what matters: отслеживайте model, prompt, adapter, runtime и quantization versions, и логируйте достаточно для debugging, не создавая privacy disaster.

Local AI security — в основном скучная operational discipline. Именно так вы избегаете скачивания random checkpoint, запуска его as root и превращения local AI в local compromise.

Benchmarks, которые важны

Бенчмаркайте stack, который реально будете запускать. BF16 leaderboard score модели — не ваша Q4 local reality.

Измеряйте quality, latency, memory, reliability и operating fit:

Quality: correctness на ваших реальных tasks, не только generic benchmarks.
Latency: time to first token, decode tokens per second и end-to-end time.
Memory: weight memory, KV-cache growth, peak VRAM и headroom under load.
Formatting: chat template correctness, JSON/schema success, tool-call reliability и stop-token behavior.
Retrieval: citation faithfulness, answer grounding, missing-evidence behavior и reranker impact.
Operations: startup time, warmup behavior, crash recovery, logging, privacy и version tracking.

Создайте маленький eval set с 30–100 representative prompts. Включите expected answers или scoring criteria, latency and memory measurements, failure categories, RAG-specific grounding checks, JSON compliance checks, если relevant, и human review для ambiguous tasks.

Затем сравнивайте models. Не позволяйте leaderboard выбирать за вас local stack.

Кодинг с локальными моделями

Coding — один из лучших use cases для local LLM, потому что prompts часто включают private code, latency важна, iteration частая, API costs могут быстро расти, а local models могут интегрироваться с editors, shells, grep, test runners и patch workflows.

Самая сильная local coding setup — не naked chatbot. Это code-capable instruct model, подключённая к targeted repository context, retrieval over the codebase, file paths, relevant snippets, test execution и patch loop.

Держите decoding deterministic или low-temperature. Просите patches вместо vague advice. Запускайте tests automatically. Держите небольшой eval set реальных bugs и tasks, чтобы понимать, стала ли new model действительно лучше.

Не позволяйте local model переписывать large codebase without review. Local не делает coding agent мудрым. Оно только делает context private, loop cheaper и integration проще контролировать.

Local Agents требуют Guardrails

Local LLM становится гораздо полезнее, когда может использовать tools: file search, shell commands, browser automation, databases, code execution, calendars, ticket systems, internal APIs, vector databases, home automation, robotics или edge devices.

Tool use меняет safety model. Chatbot, который hallucinate, раздражает. Agent с filesystem access может удалять вещи. Agent с browser access может leak secrets. Agent с shell access может повредить машину быстрее, чем вы успеете прочитать logs.

Local agent safety имеет четыре слоя. Жёстко ограничьте scope agent, дав ему только directories, APIs, network access и credentials, которые реально нужны. Constrain execution через sandboxes, containers, least-privilege users, confirmations for destructive actions и schema-validated tool arguments. Treat inputs as hostile, потому что retrieved documents, web pages, tickets и emails могут содержать prompt injection. Keep an audit trail, логируя tool calls, model versions, prompts и approvals, не dumping secrets into logs.

Structured outputs помогают, но не являются security boundary. JSON schemas, constrained decoding и function signatures упрощают validation tool calls. Они не доказывают, что модель поняла request, выбрала safe action или избежала injected instructions.

Для серьёзного tool use ставьте policy checks outside the model.

RAG лучше гигантских prompts

RAG означает Retrieval-Augmented Generation. Вместо stuffing all information into the prompt вы извлекаете relevant chunks из knowledge base и даёте модели только эти chunks.

Хорошая local RAG system обычно имеет document ingestion, parsing, chunking, embeddings, vector index, retrieval, reranking, prompt construction, answer generation, grounding checks и evaluation. Каждый stage — failure point.

Bad parsing превращает tables в garbage. Bad chunking делит answer по boundaries. Bad retrieval возвращает irrelevant paragraphs. Bad reranking закапывает правильный answer на rank 20. Хорошая модель не может reliably answer from evidence, который она never received.

Большинство bad RAG systems плохи не из-за LLM. Они плохи из-за chunking, retrieval, reranking и evaluation.

Chunking strategy — silent killer. Fixed-size chunks без overlap могут split sentences и терять context. Semantic chunking или hierarchical chunking с parent-document retrieval часто работают лучше, но универсального ответа нет. Нужно evaluate chunk size, overlap и splitting rules на ваших реальных documents.

Хороший reranker может спасти mediocre retrieval. Никакой reranker не исправит chunks, которые потеряли answer during ingestion.

Документы и knowledge work

Для private documents local LLM shine: meeting transcript summaries, contract review, technical documentation Q&A, research note synthesis, email drafting, policy search, internal support assistants и compliance workflows выигрывают от того, что source material остаётся рядом с machine или organization, которому он принадлежит.

Workflow простой, но unforgiving. Аккуратно parse documents, сохраняйте page and section metadata, chunk semantically, используйте embeddings and rerankers, просите citations, отделяйте answer from sources от general reasoning и оценивайте citation faithfulness.

Не предполагайте, что модель знает, что в ваших documents. Она знает только то, что вы положили в prompt или retrieved into context.

Для meeting transcripts сохраняйте speaker labels и timestamps. Для contract review chunk by clause or section, а не arbitrary token count. Для technical documentation Q&A включайте page numbers или section anchors в retrieved chunks, чтобы модель могла точно cite sources.

Для document work ваш parser и retriever важны не меньше модели.

Edge Deployment

Small models всё полезнее на phones, laptops, robots, IoT gateways, factory devices, vehicles, medical devices, offline field equipment и browser apps. Edge — это не просто smaller version of the workstation. У него другой набор constraints.

Edge deployment управляется low memory, low power, thermal limits, intermittent connectivity, privacy requirements, real-time latency, small context windows и predictable fallback behavior. На таких устройствах small reliable model лучше large fragile one.

Практический edge setup часто использует 0.5B–4B model, aggressive weight quantization, tiny prompts, fixed schemas, tool-assisted workflows, local embeddings, caching и no unnecessary chat history.

Когда connectivity drops, local model, которая продолжает работать, ценнее larger model, которая fails. Будущее local AI — не только giant workstation models. Это также small models, выполняющие полезную работу близко к data.

Runbook локальной LLM

Используйте это как final gate перед доверием local model для real work.

Choose and fit: выберите model family, подходящую задаче, прочитайте license, подтвердите hardware requirements, выберите quantization level и оцените полный memory bill. Не останавливайтесь на weight size. Включите KV cache, runtime overhead, batch/concurrency и safety margin.

Load and format: предпочитайте safetensors или GGUF из reputable sources, избегайте untrusted pickle-based files, проверяйте tokenizer and chat template, задавайте context length осознанно и выбирайте decoding parameters под задачу. Если template неправильный, eval invalid.

Evaluate and operate: тестируйте representative prompts, измеряйте time to first token и decode speed, отслеживайте peak memory, оценивайте retrieval до добавления RAG, sandbox tools до добавления agents и fine-tune только после провала более простых методов.

Version everything that matters: model, quantization, runtime, prompt, chat template, adapter, embedding model, reranker, eval set и hardware profile. Local systems проще контролировать только тогда, когда можно reproduce what you ran.

Fine-Tuning

Fine-tuning меняет behavior модели через training on additional data. Для локальных пользователей самые важные методы — LoRA и QLoRA.

LoRA freezes base model и обучает маленькие low-rank adapter weights. Это уменьшает trainable parameters и позволяет поддерживать multiple lightweight adapters. QLoRA расширяет это, fine-tuning through a frozen 4-bit quantized model into LoRA adapters.

Fine-tune, когда нужен consistent writing style, domain-specific output format, repetitive classification or extraction behavior, tool-call format reliability, specialized assistant persona, domain adaptation, которую RAG не решает, или лучшая small-model performance on a narrow task.

Не fine-tune first. Попробуйте порядок: correct chat template, better prompting, better model, better decoding, RAG, reranking, few-shot examples, затем fine-tuning.

Большинство проблем, похожих на «model does not understand my domain», на самом деле являются «my prompt is vague», «my template is wrong» или «my retrieval is broken».

Хороший fine-tuning plan включает clean data, train/validation/test splits, baseline evals, clear target behavior, safety review, overfitting checks, regression evals, adapter versioning, license review и rollback plan.

Open-Weight не означает Opensource

В 2026 году фразу open model часто используют небрежно. Следует различать open-weight, source-available, opensource и local-compatible.

Open-weight обычно означает, что вы можете скачать weights. Это не означает автоматически, что можно commercially use модель, freely modify it, train on its outputs, deploy it at any scale или игнорировать attribution requirements.

Source-available означает, что code или weights visible. Это не обязательно значит, что license opensource.

Opensource AI model — более сильное утверждение. OSI's Opensource AI Definition рассматривает AI system как включающую architecture, parameters/weights, inference code и enough data information and code used to derive the parameters. Это гораздо более высокая планка, чем weights are on Hugging Face.

Некоторые licenses выглядят permissive, но содержат restrictions: no competitive use, no training on outputs, no deployment above a certain scale, geographic exclusions, attribution requirements, patent clauses или copyleft-like obligations on derivatives.

Правило: читайте model card и license перед коммерческим использованием любой модели. Модель может быть отличной, downloadable и locally runnable, но всё равно плохо подходить под ваши legal or deployment constraints.

Glossary

Model And Tuning Terms

Active Parameters: в MoE model только часть parameters используется для данного token. Модель может иметь hundreds of billions total parameters, но намного меньше active parameters per token.
Adapter: маленький trainable module, добавляемый к base model, часто через LoRA.
Base Model: pretrained model, не настроенная специально для chat или instruction following.
Fine-Tuning: additional training, меняющий model behavior для target domain или output style.
Instruct Model: model, tuned to follow instructions.
LoRA / QLoRA: efficient fine-tuning methods, использующие low-rank adapters; QLoRA обучает через quantized base models.
MoE: Mixture of Experts. Sparse architecture, где только выбранные expert subnetworks активируются на token.
Weights / Parameters: выученные numerical values внутри модели.

Inference Mechanics

BOS / EOS: beginning-of-sequence и end-of-sequence tokens.
Chat Template: formatting, используемый для представления system, user, assistant и tool messages.
Context Window: максимальное число tokens, которое модель может обработать одновременно.
Decode: фаза, где модель генерирует новые tokens один за другим.
DFlash: speculative decoding approach 2026 года, использующий block diffusion для parallel drafting.
DDTree / DTree: speculative decoding method, который строит draft tree из block diffusion distributions и эффективно его verifies.
GQA / MQA: attention variants, уменьшающие KV-cache size и повышающие inference efficiency.
Inference: запуск модели для producing outputs.
KV Cache: сохранённые key/value attention states для previous tokens.
Prefill: фаза, где модель обрабатывает input prompt перед generation.
RoPE: Rotary Position Embeddings, positional encoding method, распространённый в modern LLM.
Speculative Decoding: speed technique, где cheaper drafter proposes tokens, а target model verifies them.
Tokenizer: component, который converts text into token IDs and back.
Top-p / Top-k / Temperature: sampling controls for token generation.

Retrieval, Files, And Serving

AWQ: Activation-aware weight quantization.
Embedding Model: model, converting text into vectors for search/retrieval.
FP8 KV Cache: practical 8-bit KV-cache compression mode, supported in some runtimes.
GGUF: model file format, heavily used by llama.cpp.
PagedAttention: KV-cache memory-management technique, used by vLLM-style serving.
Quantization: reduction of numeric precision to save memory and improve efficiency.
RAG: Retrieval-Augmented Generation. Retrieve relevant external context and give it to the model.
Reranker: model, reordering retrieved passages by relevance.
Safetensors: safer tensor serialization format, avoiding pickle-based execution risks.

Final Words

Экосистема local LLM включает compact edge models, strong 7B–32B consumer models, large MoE open-weight systems, multimodal models, long-context models, local reasoning models, mature inference runtimes и всё более capable private serving stacks.

Но fundamentals не изменились: модель предсказывает по одному токену за раз, tokens are not words, weights are not the whole model, chat templates matter, KV cache is the hidden memory bill, quantization is a tradeoff, long context is not free, RAG quality depends on retrieval, fine-tuning needs evals, and local privacy still requires security discipline.

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

Local LLMs — это в основном memory math плюс formatting плюс evaluation. Сделайте это правильно, и остальной stack станет гораздо проще осмыслять.

До следующего раза.

-Ahmad