Почему llm (на примере работы и тарифов openai gpt и той же llama и llama2) обрабатывают запрос со скоростью от количества токенов в нем?

Работа llm на основе gpt в общем случае простая - в пределах входного окна (размер контекста) мы подаем токены входящего запроса (точнее как я понимаю там токены с помощью токенизера разворачиваются в вектора но операция линейная и очень быстрая), полученный вектор пропускается через слои llm и получается один новый токен, он добавляется к предыдущим и операция повторяется циклически до условия конца (лимит на количество токенов или финишный токен).

Получается стартовый запрос llm должен обрабатываться со скоростью генерации одного токена.

Но почему входящие токены в принципе тарифицируются у той же openai (в 2 раза меньше чем сгенерированные токены) - input/output tokens?

Если смотреть на работу llama/llama2 на основе llama.cpp (там хорошо покрыто все бенчмарками, можно даже развернуть в логи временные затраты на внутренних типы слоев llm и типы операций) то там входящий запрос обрабатывается какое то время, линейно зависящее от количества токенов в нем (в 2-3 раза быстрее чем генерация новых).

Так вот, что же происходит в это время? Входящий запрос вместо разовой подачи в сеть как то обрабатывается по токенам? Отсюда еще одно следствие - в llama.cpp есть поддержка сохранения состояния на диске (так же по логам видно сколько мегабайт оперативной памяти отводится под его хранение), так вот загрузка этого состояния происходит фактически мгновенно (на скорости диска). Так вот что это за состояние, описывающее входящий запрос (как я понимаю не зависит от количества токенов в нем), ведь в логике работы llm состоянием является сам запрос?

p.s. исходники читаются не легко, хотелось бы сначала понимание идеи
  • Вопрос задан
  • 181 просмотр
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы