Вы когда-нибудь задумывались, сколько лишних токенов вы платите за то, чтобы Qwen нарисовал табличку в HTML, а не просто выплюнул строку текста? Я да. И однажды ночью, сидя с лопатой в руках и локальным инстансом Qwen 3.6 35B под капотом, я решил это выяснить. Результаты оказались настолько контринтуитивными, что я переписал половину своих промптов и сэкономил под 30% токенов на инференсе. Добро пожаловать под капот.
Почему формат вывода — это не просто эстетика?
Когда вы просите LLM: «Напиши отчёт в HTML», модель генерирует не только контент, но и обёртку: теги, атрибуты, стили. Каждый <div> или **жирный** — это дополнительный токен. А токены, как вы знаете, тянут за собой время и деньги (или лимиты, если вы на облаке).
Но есть нюанс: если вам нужно отдать результат человеку или в систему, которая парсит разметку, сырой TXT может обернуться ещё большими затратами на постобработку. Поэтому выбор формата — это всегда trade-off между стоимостью генерации и стоимостью потребления.
Ключевая метрика: общее количество токенов (prompt + completion). Но если промпт фиксирован, главное — длина completion. Именно её мы и будем измерять.
Экспериментальная установка
В качестве подопытного — Qwen 3.6 35B в 4-битном квантовании (GPTQ), запущенная через Hexllama — штука, которая, кстати, реально упрощает жизнь с флагами llama.cpp. Inferencing на одной NVIDIA A100 80GB (но можно и на 4090, просто будет чуть медленнее). KV cache включён, контекст 8K.
Промпт — один и тот же для всех форматов (меняется только инструкция о формате вывода):
Ты — ассистент, отвечающий на вопросы по RAG. Опиши архитектуру типичного RAG-пайплайна, перечислив 4 основных этапа.Вариации промпта:
- TXT — «Ответь обычным текстом, без разметки. Просто абзацы.»
- Markdown — «Ответь в формате Markdown, используй заголовки и списки.»
- HTML — «Ответь в виде HTML-кода, используй семантические теги (h2, ul, p и т.д.).»
- HTML+CSS — «Ответь в виде HTML-кода с встроенными CSS-стилями (цвета, отступы, шрифты).»
Каждый запрос повторялся 5 раз, усреднялись значения по completion токенам и времени до первого токена (TTFT).
Результаты: таблица убийц
| Формат | Среднее кол-во completion токенов | Относительно TXT | TTFT (мс) | Качество (субъективно) |
|---|---|---|---|---|
| TXT | 320 | 1x (база) | 120 | 5/10 — читаемо, но скучно |
| Markdown | 410 | +28% | 135 | 7/10 — структура, но нет цвета |
| HTML | 580 | +81% | 155 | 7/10 — структура, но пусто |
| HTML+CSS | 890 | +178% | 210 | 9/10 — красиво, но дорого |
Внимание: Markdown оказался самым эффективным «компромиссом» — даёт читаемую структуру всего за +28% токенов. HTML+CSS жрёт почти в 3 раза больше токенов, чем TXT, но если вы собираетесь отдавать результат в веб-интерфейс, экономия на фронтенде может перевесить.
Анатомия раздувания токенов
Давайте разберём, куда уходят токены в самом «жирном» варианте — HTML+CSS. Qwen 3.6 сгенерировала вот такой фрагмент (сокращён):
<!DOCTYPE html>
<html>
<head>
<style>
body { font-family: Arial; margin: 20px; }
h2 { color: #2c3e50; border-bottom: 2px solid #3498db; }
ul { list-style-type: square; color: #333; }
</style>
</head>
<body>
<h2>1. Ingestion</h2>
<p>Загрузка документов в базу знаний...</p>
...
</body>
</html>Каждый селектор, фигурная скобка, двоеточие — это отдельный токен. В среднем, одно CSS-правило «съедает» 15-20 токенов. А если модель решает добавить отступы и цвета для каждого элемента — сумма растёт как на дрожжах. При этом реальная информация (содержание этапов RAG) занимает лишь 30% от общего объёма.
Подводные камни: как НЕ надо делать
Первая ошибка, которую я совершил — попросил «выдай ответ в HTML» без указания степени детализации. Qwen 3.6 выдала полную HTML-страницу с <!DOCTYPE>, хотя мне нужен был только фрагмент. Это сразу +200 токенов.
Вторая ошибка — не указал, что CSS нужно минимизировать. Модель любит генерировать «красивые» стили с градиентами и тенями, что ещё сильнее раздувает ответ. Исправленный промпт:
Ответь в HTML. Используй только семантические теги, без стилей. Минимум обёрток. Только контент.Это снизило количество completion токенов для HTML почти в 2 раза (с 580 до 340).
Практический чек-лист оптимизации
- Определите, кто будет читать ответ. Человек — Markdown или TXT. Машина (API) — лучше TXT/JSON. Фронтенд — HTML+CSS только если вы не можете пост-обработать.
- Используйте минимально возможную разметку. Если нужны только заголовки и списки, Markdown достаточно.
- Экспериментируйте с указанием максимальной длины.
max_tokens=512без формата — модель может обрезать смысл, а с форматом — обрезать стили, оставив контент. - Кэшируйте KV cache при повторяющихся промптах. Если вы генерируете похожие отчёты, разница в TTFT между форматами сглаживается.
- Попробуйте RAG с предварительной разметкой. Иногда проще хранить документы уже в HTML, а LLM использовать только для извлечения — об этом я писал в гайде по RAG для документации.
Влияние квантования на «дороговизну» формата
Я запускал Qwen 3.6 35B в двух вариантах: полный float16 и 4-bit GPTQ. Результат предсказуем, но неочевиден: в квантованной модели разница между форматами чуть меньше в абсолютных токенах (из-за особенности токенизации в квантованных весах — модель чуть «жаднее»), но в относительном выражении — такая же. Зато TTFT в кванте был выше на 18-25% для всех форматов, что говорит о дополнительной нагрузке на декодирование.
Если вы используете локальные LLM на слабом железе (Mac M5 с 128 ГБ, как в сравнении для юристов), каждый лишний токен бьёт по времени генерации. Поэтому рекомендую придерживаться TXT или Markdown, а красоту навешивать уже после генерации.
Вердикт (без слова «заключение»)
Самый эффективный способ сэкономить токены — не просить модель делать то, что вы можете сделать сами. Если вам нужен HTML с бутстраповскими классами — лучше пусть модель выдаст Markdown, а вы конвертнёте его Pandoc'ом за микросекунду. Это сэкономит не только токены, но и нервы, когда Qwen вдруг решит, что цвет фона должен быть #ff69b4.
Но если вы всё-таки гонитесь за красивым выводом прямо из модели — помните, что HTML+CSS обходится в 2-3 раза дороже TXT. Зато можете смело показывать результат клиенту, не тратя время на вёрстку. Вопрос только в том, что дороже: ваше время или GPU-часы.
