Расчеты количества токенов¶
128 000 токенов — это не совсем 128 000 слов, потому что токен ≈ 3–4 символа на английском (или ≈ 0.75–1 слова в среднем), а на русском обычно чуть меньше (токен делится чаще, т.к. больше морфем).
Можно прикинуть:
- В словах (средний случай):
128 000 токенов × ~0.75 слова/токен ≈ 96 000 слов - В страницах текста (при 300 слов на страницу):
96 000 ÷ 300 ≈ 320 страниц стандартного документа A4. - В символах (с пробелами, при 4 символа/токен):
128 000 × 4 ≈ 512 000 символов ≈ 0.5 млн знаков.
Иными словами: 128k токенов — это примерно книга на 300+ страниц, или сотня средних новостных статей, объединённых в один запрос.
Если хотите, могу сделать таблицу с пересчётом токенов в страницы/слова/символы для разных размеров контекста (32k, 128k, 1M). Это удобно для планирования, сколько текста реально влезет в модель.
Вот таблица пересчёта токенов → слова → страницы → символы
(для английского и русского примерно усреднено по корпусам текста; формат А4 ~300 слов на страницу).
| Контекст (токены) | Слова (≈0.75 слова/токен) | Страницы (≈300 слов) | Символы (≈4 символа/токен) |
|---|---|---|---|
| 32 000 | ~24 000 | ~80 | ~128 000 |
| 64 000 | ~48 000 | ~160 | ~256 000 |
| 128 000 | ~96 000 | ~320 | ~512 000 |
| 256 000 | ~192 000 | ~640 | ~1 024 000 |
| 1 000 000 | ~750 000 | ~2 500 | ~4 000 000 |
Пояснения:
-
Слова: усреднённый коэффициент 0.75 слова/токен (на русском часто чуть меньше, ~0.7).
-
Страницы: при 300 слов на страницу (шрифт 12pt, интервал 1.5).
-
Символы: пробелы включены, усреднённо 4 символа/токен.
Ниже — «на пальцах», сколько VRAM уйдёт на KV-кэш у Qwen2.5-14B при разных настройках на A100 40 GB. Это поможет понять реальный предел длины контекста.
Как считать (коротко)¶
KV-кэш ≈ 2 × n_layers × hidden_size × bytes_per_elem × tokens.
Для 14B (параметры порядка Llama-13B): примем n_layers ≈ 40, hidden_size ≈ 5120.
Тогда при FP16: ~0.781 MB на токен (включает K и V).
Это расход на все токены контекста + сгенерированные токены в батче.
В расчётах я закладываю ~2 GB на «прочие накладные расходы**» (фреймворк, графы, буферы). Реальные цифры могут плавать ±10–20%.
Сколько токенов влезет (batch=1)¶
Допустим, вы запускаете модель на одном GPU и храните веса в VRAM:
| Формат весов | Размер весов (оценка) | Доступно под KV (из 40 GB, минус 2 GB оверхед) | Макс. токенов (ввод+вывод) |
|---|---|---|---|
| FP16 | ~28 GB | ~10 GB | ≈ 13 100 |
| INT8 | ~14 GB | ~24 GB | ≈ 31 500 |
| INT4 (GPTQ/AWQ) | ~10 GB | ~28 GB | ≈ 36 700 |
| INT4 (агрессивнее) | ~8 GB | ~30 GB | ≈ 39 300 |
Вывод: с FP16 весами на 40 GB реальная «безболезненная» длина запроса — ~12–13k токенов при batch=1.
Хотите 32k+ токенов — квантовать веса (INT8/INT4) или снизить параллелизм.
Как влияет батч (batch>1)¶
Общий лимит распределяется на все одновременные запросы: - Пример (INT8 веса, ~31 500 токенов суммарно): - batch=1 → ~31.5k токенов на запрос - batch=2 → ~15.7k токенов на запрос - batch=4 → ~7.9k токенов на запрос
В vLLM это регулируется через --max-num-batched-tokens: ставьте этот лимит ≈ суммарному числу токенов, которое у вас реально помещается (из таблицы выше).
Рекомендованные пресеты под A100 40 GB¶
Вариант A — максимум качества без квантовки¶
- Модель: Qwen2.5-14B-Instruct (FP16)
- Окно по факту: до ~13k токенов на запрос (batch=1)
-
Запуск (vLLM):
python3 -m vllm.entrypoints.api_server \ --model Qwen/Qwen2.5-14B-Instruct \ --dtype float16 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-seq-len 13000 \ --max-num-batched-tokens 13000
Вариант B — длиннее контекст (компромисс)¶
- Модель: та же, но INT8 веса
- Окно по факту: ~31k токенов (batch=1), либо 2× по ~15k
- Запуск (идея): аналогично, но
--max-seq-lenи--max-num-batched-tokens≈ 30000
Вариант C — ещё длиннее (агрессивно)¶
- Модель: INT4 (GPTQ/AWQ)
- Окно по факту: ~36–39k токенов (batch=1)
- Требует совместимых рантаймов (vLLM/TGI с GPTQ/AWQ), качество чуть проседает.
Полезные замечания¶
- Paged Attention (vLLM) экономит/уплотняет память и даёт стабильный батчинг, но формулу расхода KV это не отменяет — просто снижает фрагментацию и повышает пропускную способность.
- KV-кэш можно ужать (8-бит/FP8) в некоторых стеках — это почти ×2 к длине, но надо следить за поддержкой в вашей версии рантайма/железа и метриками качества.
- Chunking всё ещё рулит: для документов в десятки/сотни тысяч токенов надёжнее нарезать на 8–16k куски с перекрытием, делать локальные сводки и финальный консолидирующий прогон.
--max-seq-lenи--max-num-batched-tokensдержите согласованными с расчётами выше, иначе упрётесь в OOM.