Прокси «для экономии токенов» перед LLM API
Появился целый класс инструментов, которые встают между твоим приложением и Claude/OpenAI и обещают резать счёт за токены. Этот документ объясняет с нуля: что это, какие бывают, чем отличаются, какие есть доказательства пользы — и где спрятаны реальные риски.
НАЧАЛОС чего всё начинается: почему вообще хотят «экономить токены»
Когда твоё приложение обращается к LLM (Claude, GPT и т.п.), оно отправляет промпт — текст запроса вместе со всем контекстом (инструкции, документы, история диалога). Модель видит этот текст не как буквы, а как токены — кусочки слов. Примерно 1 токен ≈ 4 символа английского текста.
Главное, что нужно понять про деньги: провайдеры берут плату за токены — отдельно за то, что ты отправил (input), и за то, что модель сгенерировала (output). Чем длиннее промпт и чем больше таких вызовов — тем больше счёт. У больших систем (RAG, агенты, длинные диалоги) промпт может быть огромным и повторяться тысячи раз в день.
Идея у всех одна: поставить middleware (прослойку) между приложением и API, которая что-то делает с запросом или ответом, чтобы итоговый счёт был меньше. Вот где она физически стоит в потоке запроса:
Дальше всё зависит от того, что именно делает эта прослойка. И вот здесь начинаются различия — потому что «сэкономить» можно четырьмя принципиально разными способами, с очень разными последствиями.
РАЗДЕЛ 1Карта: какие бывают и как делятся
Сначала — каркас, чтобы не потеряться. Все эти инструменты делятся по двум осям. Первая ось — теряют ли они информацию:
- lossy — с потерями. Что-то выкидывают или подменяют (сжатие промпта, отправка на модель попроще). Дёшево, но качество может пострадать.
- lossless — без потерь. Переиспользуют то, что уже посчитали (кэш). Если сработало корректно — ответ тот же.
Вторая ось — что именно они трогают: вход (промпт), сами вызовы (нужно ли вообще обращаться к API) или внутреннее состояние модели. Вот четыре семейства, которые мы разберём по очереди:
| Семейство | Тип | Что делает в одну строку | Примеры |
|---|---|---|---|
| Сжатие промпта | lossy | Выкидывает «лишние» токены из запроса до отправки | LLMLingua, LLMLingua-2 |
| Семантический кэш | условно lossless | На похожий запрос отдаёт старый ответ, не дёргая API | GPTCache, semantic-router |
| KV-кэш (reuse/offload) | lossless | Переиспользует внутренние вычисления для общих кусков текста | vLLM, LMCache |
| Прокси / роутинг | смешанный | Шлюз: учёт, кэш, отправка на модель подешевле | LiteLLM, Helicone, Portkey, Cloudflare AI Gateway |
Теперь — каждое по очереди, по одной схеме: что это → как работает → пример → пруф пользы → главный минус.
① Сжатие промпта (prompt compression)
Что это. Прослойка берёт твой длинный промпт и с помощью маленькой, дешёвой языковой модели решает, какие слова можно выкинуть без большой потери смысла, — и отправляет в дорогую модель уже укороченный текст.
Как работает. Маленькая модель (например, на базе GPT-2 или LLaMA-7B) оценивает «важность» каждого токена и удаляет наименее информативные. Это lossy — выкинутые слова не вернуть.
Цифры ниже — это то, что заявляют сами авторы в лабораторных условиях (на бенчмарк-датасетах), а не гарантия для произвольного прод-промпта.
LLMLingua (EMNLP 2023, Microsoft): до 20× сжатия («up to 20×») с минимальной потерей качества — замерено на 4 датасетах: GSM8K, BBH, ShareGPT, Arxiv.
LLMLingua-2 (ACL Findings 2024): сжатие 2–5×, при этом ускоряет полный цикл запроса в 1.6–2.9× и сама работает в 3–6× быстрее старых методов сжатия.
🟢 arXiv:2310.05736 · arXiv:2403.12968 · github.com/microsoft/LLMLingua
«До 20×» — это оптимистичный потолок на одной задаче, а не гарантия для любого промпта. Реальные коэффициенты из таблиц самой статьи, при которых качество не падает, гораздо скромнее:
- GSM8K (рассуждения) — ~5× (точность 79.1 против 78.9 у несжатого — даже чуть выше)
- BBH (рассуждения) — ~3× (70.1 против 70.1)
- Диалоги (ShareGPT) — ~9×; суммаризация (Arxiv) — ~3.3×
Хвалёные «20×» достигаются только на GSM8K при сильнейшем сжатии примеров — и уже с потерей ~1.5 балла; на BBH те же 5× стоят −8.5 балла, а 7× — уже −13.2. То есть рабочий ориентир для прода — 3–9× в зависимости от задачи, а не 20×.
Главный минус разберём подробно в разделе про риски — если коротко, сжатие теряет детали, и на части задач это катастрофа.
② Семантический кэш (semantic caching)
Что это. Прослойка запоминает пары «запрос → ответ». Когда приходит новый запрос, она проверяет: нет ли в памяти похожего по смыслу? Если есть — отдаёт сохранённый ответ, вообще не обращаясь к LLM. Ноль токенов, мгновенный ответ.
Как работает. Запрос превращается в эмбеддинг (вектор чисел, отражающий смысл). Если новый вектор близок к уже сохранённому — это «попадание в кэш» (cache hit). Слово «семантический» означает «по смыслу, а не по точному совпадению букв».
Почему в таблице стоит условно lossless, а не честный lossless: кэш считается lossless, только если «похожий» запрос действительно требует того же ответа. Но «похоже по смыслу» ≠ «нужен тот же ответ» — порог похожести настраивается, и слишком агрессивный порог начинает отдавать неверные ответы. Отсюда — отдельный класс проблем.
Классический семантический кэш (GPTCache — самый типичный пример) по умолчанию хранит запросы и ответы всех пользователей в одном общем хранилище, без разделения по пользователю. Это и про приватность, и про корректность: из-за этого один пользователь получил закэшированный баланс счёта другого — реальный баг в vLLM semantic-router (март 2026), ключ кэша был без UserID.
🟢 arXiv:2403.02694 — MeanCache (Cisco/Virginia Tech/UMN): научный разбор приватности стандартных кэшей, включая GPTCache · 🟢 semantic-router #1448 — сам баг с балансом счёта
Та же статья (arXiv:2403.02694) не только критикует GPTCache, но и предлагает MeanCache — кэш с federated learning и локальным хранилищем на устройстве каждого пользователя, без общего сервера. По замерам авторов он обходит GPTCache: +17% F-score, +20% precision, −83% объёма хранилища. То есть приватность тут — by design.
Но не «серебряная пуля»: (1) все цифры — заявления авторов, независимых проверок мало; (2) это исследовательский прототип, не зрелый продукт уровня GPTCache; (3) приватность ценой экономии — локальный кэш ловит только твои прошлые запросы, без шеринга между пользователями hit rate ниже; (4) это всё ещё семантический кэш, базовый риск «похоже по смыслу ≠ нужен тот же ответ» остаётся. «Нет громких атак на MeanCache» — это во многом следствие того, что её мало где развернули, а не доказанная безопасность.
③ Переиспользование KV-кэша (KV-cache reuse / offloading)
Что это. Это уже не про текст запроса, а про внутреннюю «черновую работу» модели. Когда LLM читает промпт, она для каждого токена вычисляет промежуточные данные (так называемые ключи и значения — Key/Value). Если два запроса начинаются с одинакового куска (например, общая системная инструкция), эту черновую работу можно посчитать один раз и переиспользовать.
vLLM.Где подвох. Чтобы переиспользовать KV-кэш между запросами и серверами, его часто выгружают наружу — из памяти GPU в обычную RAM, на диск или в общее хранилище. Здесь размен «производительность ↔ безопасность»: пока кэш заперт в изолированном процессе на GPU, дотянуться до него трудно; как только он выгружен в менее защищённый слой — его может прочитать тот, кто взломал хранилище или сам провайдер. А KV-кэш не зашифрован — это числовые «слепки» токенов, из которых исходный текст реконструируется почти дословно (см. риск B3).
④ Прокси / шлюз с роутингом (proxy / gateway)
Что это. Это «диспетчер» перед всеми LLM-провайдерами сразу. Через него идёт весь трафик; он умеет считать расходы, логировать, кэшировать и — главное для экономии — маршрутизировать (роутить): отправлять простой запрос на дешёвую модель, а сложный — на дорогую.
Экономия здесь смешанная: если запрос ушёл на модель попроще — это lossy (качество может упасть); если отдан из кэша — lossless. Отдельный, неочевидный риск прокси: через него проходят все твои промпты в открытом виде — это новая точка, где данные логируются, кэшируются и могут утечь, плюс это звено цепочки поставок (см. риски — у LiteLLM уже была реальная компрометация).
РАЗДЕЛ 2Сквозные риски: цельная картина опасностей
Польза доказана, но за неё платят. Риски здесь сквозные: один и тот же риск часто касается нескольких методов (например, утечка кэша — это и про семантический кэш, и про KV-кэш). Поэтому они сгруппированы по типу (A–D), а не по методу. Вот карта соответствия — какой метод какие риски несёт:
| Метод (из раздела 1) | Его риски (ниже) |
|---|---|
| ① Сжатие промпта | A — деградация качества · C — мнимое ускорение · D1 — атака на модуль сжатия |
| ② Семантический кэш | B — утечки между пользователями, кража по таймингу |
| ③ KV-кэш | B — реконструкция PII из выгруженного кэша |
| ④ Прокси / роутинг | A — падение качества при роутинге на слабую модель · D2 — supply-chain |
Риск A — деградация качества (методы ① сжатие и ④ роутинг)
Сжатие и роутинг теряют информацию — и на части задач это оборачивается не небольшим ухудшением качества, а полностью неверным результатом.
Исследование «Prompt Compression in the Wild» (TU Dresden / ScaDS.AI) — 30 000+ прогонов на GPT-4o, LLaMA 3.1 70B и Mistral 7B:
• на few-shot классификации (TREC, LSHT-ZH) — просадка до 52%;
• точность подсчёта пассажей рухнула с ~20% до <4.5%;
• метод прямо назван «непригодным для structured / synthetic данных».
Независимое подтверждение — AWS AI Labs (Amazon Science, EMNLP 2025). Построили фреймворк, который мерит не только степень сжатия, но и сохранность информации и опору ответа на контекст (grounding). На multi-hop вопросах (это когда ответ нельзя дать из одного факта — нужно связать несколько в цепочку; например «в каком городе родился автор теории относительности?» = сначала «Эйнштейн», потом «Ульм»; бенчмарки HotpotQA, TriviaQA, модель Mistral-7B) «мягкие» методы (xRAG и др.) не сохраняют ключевые факты исходного промпта — а потеря одного звена рвёт всю цепочку, отсюда падение на сложных задачах. Контроль «гранулярности» сжатия вернул +23% качества и сохранил в 2.7× больше сущностей — значит, базовые методы ровно столько и выбрасывали.
Вывод по A: главный фактор вреда — выживают ли при обрезке критичные для задачи части промпта. Суммаризация и обычный QA терпят сжатие неплохо; код, reasoning, few-shot, структурированные данные — зона высокого риска.
Риск B — утечки данных (методы ② семантический кэш и ③ KV-кэш)
Самая серьёзная группа для энтерпрайза. Здесь три разных, независимо доказанных механизма.
Семантический кэш по умолчанию складывает запросы всех пользователей вместе. Реальный баг (vLLM semantic-router, март 2026): ключ кэша был (модель, эмбеддинг запроса) без UserID — и пользователь B получил баланс счёта пользователя A.
Раз ответ из кэша приходит заметно быстрее, атакующий по времени отклика может понять, что его пробный запрос «попал в кэш», — то есть кто-то уже спрашивал то же самое, и восстановить чужой запрос.
«The Early Bird Catches the Leak»: атака Peeping Neighbour даёт 85.3% с одной попытки и >95% после трёх. Прямо названы уязвимыми GPTCache, LangChain, SGLang. Похожие тайминговые атаки продемонстрированы даже против прод-Claude и ChatGPT.
Работа Carlini & Nasr показала это даже на боевых Claude и ChatGPT. Логика:
1. Время ответа зависит от текста. Модели ускоряются трюком speculative decoding: мелкая модель угадывает токены наперёд, большая разом проверяет. Предсказуемый текст («1 + 2 =») угадывается → быстро; сложный («log(53.5) =») → откат и пересчёт → медленно. Замерено: GPT-4-turbo отвечает на «лёгкие» запросы в 2× быстрее, чем на «сложные».
2. У каждой темы/языка свой ритм. Медицина и код генерируются с разным паттерном «быстрее-медленнее» — получается уникальная временна́я подпись.
3. Атакующий видит только зашифрованные пакеты, но замеряет тайминг между ними (каждый токен ≈ отдельный ~150-байтный пакет). Заранее обучает классификатор на известных запросах, потом сопоставляет ритм жертвы с образцами. Результат: медицина vs код — 79–82% с одного сообщения на ChatGPT; язык из 10 — top-1 ≈49% (немецкий/русский/китайский «текут» сильнее).
Важно: это не риск именно KV-кэша, а сетевой сайд-канал от ускорения генерации в целом — он есть у любого провайдера. Полное вытаскивание PII (телефоны, карты) показано пока только на open-source, не на прод-API.
🟢 arXiv:2410.17175 «Remote Timing Attacks on Efficient LM Inference» (Carlini, Nasr)
Из выгруженного наружу KV-кэша (раздел ③) можно восстановить исходный текст — точные креды, PII, проприетарную логику — почти дословно.
Как это работает (кратко). KV-кэш — это числовые векторы (Key/Value), которые модель посчитала из каждого токена. Преобразование «токен → вектор» почти обратимо: имея на руках сами векторы, атакующий обратным расчётом восстанавливает, какие токены их породили (в работе — три способа: Inversion, Collision, Injection). Это не взлом шифра — кэш не зашифрован, — а инверсия по открытым числам.
Честная оговорка по модели угроз: чтобы запустить инверсию, нужен доступ к самим данным кэша (white/gray-box). То есть это модель «скомпрометированный провайдер или взломанный storage-слой», а не удалённый анонимный злоумышленник по сети. Но для энтерпрайза и этого хватает: тот, кто получил доступ к кэшу, видит ваши пароли и PII в нём почти открытым текстом.
🟢 NDSS 2026 «Shadow in the Cache» / KVCloak · arXiv:2508.09442
Риск C — обещанное ускорение часто исчезает (метод ① сжатие)
Это самый систематичный замер: 30 000+ end-to-end экспериментов на Mistral 7B, LLaMA 3.1 70B, GPT-3.5 Turbo, GPT-4o mini; железо A100 / GTX 1080 Ti / M1 Pro; фреймворки HuggingFace, vLLM, TGI. Время сжатия мерили отдельно от декодинга (по Time-To-First-Token).
Главный вывод — ускорение есть только в «узком окне»: неоптимизированный стек (HuggingFace), длинные промпты (>10k токенов), сжатие >4×, короткий ответ — тогда до 3–4×. Вне этого окна оверхед на сжатие побеждает: на vLLM коротким запросам становится хуже, а на коммерческих API (GPT-3.5/4o mini) на длинных промптах ускорение падает ниже 0.5× — то есть ~вдвое медленнее базового. Причина: сжатие ускоряет только чтение промпта (prefill), а у оптимизированных API оно и так быстрое.
Это значит: экономия по биллингу входных токенов реальна, а вот ускорение — нет. Это две разные метрики, и их постоянно путают.
🟢 arXiv:2604.02985 «Prompt Compression in the Wild» (§4.2, дословно: «with vLLM or commercial APIs the compression overhead outweighs any benefits»)
Риск D — новые поверхности атаки (D1 → метод ① сжатие · D2 → метод ④ прокси)
Что это. Сжатие промпта решает, какие токены выкинуть, а какие оставить (или как «ужать» представление в латентном пространстве). Этот модуль оптимизирован под эффективность, а не безопасность — и его вход можно подобрать так, чтобы после сжатия смысл промпта поплыл («смысловой дрейф»), и итоговая модель выполнила уже искажённую инструкцию.
Как это работает. Атакующий подаёт безобидный на вид текст, в котором сжатие выбросит или сохранит «не те» куски — например, потеряется отрицание, и «не возвращать платёж» превратится в «возвращать». Человек подвоха не видит (атака скрытная), и один и тот же приём переносится между моделями.
CompressionAttack (HKUST, окт 2025) покрывает оба вида сжатия. «Жёсткое» сжатие просто выбрасывает часть слов, оставляя укороченный, но всё ещё читаемый текст — против него работает HardCom (подбор слов на входе так, чтобы сжатие выкинуло именно нужные). «Мягкое» сжатие сворачивает промпт в числовые векторы вместо слов — против него SoftCom (вносит помехи прямо в эти векторы).
Уверенность средняя: сами авторы заявляют успех (ASR) до 83% и 87% на двух задачах и отмечают, что существующие защиты не помогают.
Суть. Прокси стоит на пути всех запросов и, чтобы роутить / логировать / кэшировать, видит весь трафик в открытом виде (он расшифровывает TLS у себя). То есть это одна точка, где все промпты и ключи лежат незашифрованными. И вдобавок это чужой код, от которого ты зависишь.
Почему это опасно. Бьёт двумя способами: (1) одна успешная атака на прокси — и утекает всё, что через него прошло; (2) supply-chain — ломать тебя не нужно: достаточно скомпрометировать сам пакет/сервис прокси (вредоносное обновление, подмена зависимости), и атакующий получает то самое «всевидящее» место, не трогая твою инфраструктуру. Именно так и вышло с LiteLLM — у популярного open-source шлюза была реальная компрометация цепочки поставок (разбор Trend Micro, 2026). Cloud Security Alliance выпустила отдельную заметку о рисках LLM-прокси/роутеров.
РАЗДЕЛ 3Чем они отличаются — одной таблицей
Свод всего вышесказанного. Это та самая «цельная картина»: что экономит, что теряет, чего бояться и когда вообще уместно.
| Семейство | Экономит | Что теряет / риск | Главная опасность | Когда уместно |
|---|---|---|---|---|
| Сжатие промпта lossy |
входные токены (до 20×, реально 2–7×) | детали промпта | деградация до −52% на нек. задачах; ускорение часто мнимое | суммаризация, длинный неструктурный контекст |
| Семантический кэш усл. lossless |
целые вызовы API (повторяющиеся вопросы) | точность при широком пороге похожести | утечка между пользователями; тайминг-атаки >95% | публичный FAQ, неперсональные ответы |
| KV-кэш lossless |
вычисления на общих префиксах | ничего по качеству | реконструкция PII из выгруженного кэша | общие системные промпты; предпочтительно нативный у провайдера |
| Прокси / роутинг смешанный |
деньги (модель подешевле) + учёт | качество при роутинге на слабую модель | supply-chain; все промпты в открытом виде в одной точке | централизация учёта/лимитов; роутинг — осторожно |
РАЗДЕЛ 4Вердикт: безопасно ли в корпоративной разработке
Экономишь токены — платишь чем-то другим. У каждого инструмента своя цена: расплачиваешься либо качеством, либо скоростью, либо безопасностью.
ПРУФЫИсточники
- LLMLingua — сжатие промпта (EMNLP 2023, Microsoft) peer-reviewed
arXiv:2310.05736 · github.com/microsoft/LLMLingua - LLMLingua-2 — быстрое сжатие (ACL Findings 2024) peer-reviewed
arXiv:2403.12968 - Prompt Compression in the Wild — 30k+ прогонов, деградация и мнимое ускорение (TU Dresden/ScaDS.AI) первоисточник
arXiv:2604.02985 - AWS AI Labs / Amazon Science (EMNLP 2025) — фреймворк оценки сохранности информации; xRAG теряет факты на HotpotQA/TriviaQA (Mistral-7B), +23% при контроле гранулярности peer-reviewed
arXiv:2503.19114 - MeanCache — приватность семантических кэшей (Cisco/Virginia Tech/UMN) первоисточник
arXiv:2403.02694 - vLLM semantic-router #1448 — реальный баг межпользовательской утечки первоисточник
github issue #1448 - The Early Bird Catches the Leak — тайминговые атаки на кэши (GPTCache/LangChain/SGLang) первоисточник
arXiv:2409.20002 - InputSnatch — восстановление точного ввода первоисточник
arXiv:2411.18191 - Remote timing attacks vs прод-Claude/ChatGPT первоисточник
arXiv:2410.17175 - Shadow in the Cache / KVCloak — реконструкция PII из KV-кэша (NDSS 2026) первоисточник
NDSS 2026 PDF · arXiv:2508.09442 - CompressionAttack — атака на модуль сжатия (HKUST, 2025) первоисточник, не реплицирован
arXiv:2510.22963 - LiteLLM supply-chain compromise вторичный
Trend Micro · Security Boulevard - CSA Research Note — риски LLM proxy/router первоисточник
cloudsecurityalliance.org
Методология: 5 поисковых углов → 25 источников → 113 утверждений → состязательная проверка (3 голоса на утверждение, нужно 2/3 на опровержение) → 21 подтверждено, 4 отклонено. Поле быстро меняется — часть security-находок 2025–2026 ещё не реплицирована независимо.