Как считать токены Qwen на своём сервере и у вендора

Токены Qwen у вендора складываются в счёт за вход и выход, а на своём сервере той же единице соответствуют время генерации, занятая память и место в очереди — счёта здесь нет вовсе. На практике важнее то, как эта единица влияет на скорость ответа и на объём разговора, который модель держит в контексте одновременно. Часть приёмов экономии общая для обоих путей, а вот способ мерить расход и набор приёмов на своём железе — свои.

Две единицы счёта

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

У вендора количество токенов на входе и на выходе — прямая переменная тарифа, и рост диалога в истории переписки напрямую увеличивает счёт за следующий запрос. На своём сервере тот же рост истории увеличивает время ответа и объём занятой памяти вместо денег — ограничение переезжает из бюджета в железо.

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

Счёт у вендора и его типичные подводные камни разбирает статья как считать токены DeepSeek и держать расход под контролем — там пример другого вендора, но логика счёта совпадает с тем, что видит команда в личном кабинете Qwen.

Скорость и контекст

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

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

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

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

Нагрузка команды

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

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

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

Практический разбор, как выбрать размер модели Qwen под конкретную нагрузку и проверить её на своих задачах, собран в статье Qwen через Ollama: как выбрать размер и проверить на своих задачах — вопрос нагрузки команды там разобран пошагово.

Оценка нагрузки команды напрямую подводит к следующему шагу — измерению реального расхода на практике.

Как мерить расход

1. Ведите журнал запросов — дата, отправитель, длина входа и выхода в токенах
2. Считайте среднюю длину запроса за неделю отдельно для входа и для выхода
3. Сравнивайте пиковые часы с обычными — очередь на своём сервере растёт именно в пике
4. Раз в месяц сверяйте журнал с реальной нагрузкой на железо вместо общего ощущения команды

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

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

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

Приёмы экономии

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

Приёмы, общие с вендорским счётом — короткий системный промпт, обрезка истории, кэш повторяющихся частей, — разобраны в статье как считать токены DeepSeek и держать расход под контролем; здесь собрано то, что работает только на своём железе.

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

Расчёт нагрузки и выбор железа под контур с Qwen на своём сервере разбираем на странице внедрения ИИ — вместе с планом миграции, если команда стартовала у вендора.

Частые вопросы