Fathom ускорил инференс ИИ с контекстом в миллион токенов на 67%

Когда агентные сессии ИИ разрастаются до миллиона токенов контекста и в памяти одновременно держат много таких сессий, KV-кэш и индекс, который его ранжирует для отбора top-k (наиболее релевантных) ключей на каждом шаге, выносятся в память хоста, а не хранятся в памяти видеокарты. Именно чтение этой памяти при сканировании всех ключей и становится узким местом, которое ограничивает скорость декодирования.

Авторы предлагают метод Fathom, разреженное сканирование ключей, в котором каждый запрос сам решает, сколько бит из каждого канала ключа прочитать. 4-битный K-кэш хранится с группировкой по каналам в виде битовых плоскостей, поэтому первые t таких плоскостей, это ровно t-битный квантователь данного канала. Запрос тратит свой бюджет бит по каналам не поровну, а по правилу, обратному классическому распределению «заливкой водой» (water-filling): больше бит уходит на каналы с более высокой важностью, взвешенной по дисперсии.

На контексте в миллион токенов на модели Qwen3-8B шаг декодирования с Fathom выполняется в 1.67 раза быстрее по времени GPU, чем при использовании 136-битных сканирований методов Double Sparsity, Loki и SparQ (вариант r=32). При равном времени GPU, что и у SparQ с 68-битным чтением (r=16), Fathom читает на 18% меньше байт и одновременно даёт более низкую ошибку внимания в шести из семи протестированных сочетаний модели и длины контекста. На задачах в стиле RULER любой вариант потокенного (per-token) сканирования, включая Fathom, совпадает по качеству с точным top-k-декодированием. А на реальных сессиях ИИ-агентов, работающих с кодом, Fathom достигает такой же согласованности решений, как самое точное 136-битное сканирование, уже при чтении всего 92 бит.

Важное ограничение: Fathom работает поверх той же 4-битной копии K-кэша, которую уже держит квантованный serving-стек, новое хранилище не требуется. Но выигрыша нет, если индекс кэша целиком помещается в памяти видеокарты: метод ускоряет ситуацию именно тогда, когда данные вынесены в память хоста.

Ключевые факты

Fathom, метод разреженного сканирования KV-кэша, где каждый запрос сам решает, сколько бит каждого канала ключа прочитать, вместо фиксированной битовой глубины у всех предыдущих подходов.
На контексте в миллион токенов на Qwen3-8B шаг декодирования выполняется в 1.67 раза (на 67%) быстрее, чем при 136-битных сканированиях Double Sparsity, Loki и SparQ (r=32).
При равном времени GPU с SparQ (r=16, 68 бит) Fathom читает на 18% меньше байт и даёт более низкую ошибку внимания в шести из семи протестированных настроек модели и контекста.
На реальных сессиях ИИ-агентов для работы с кодом Fathom достигает точности самого качественного 136-битного сканирования уже при 92 битах; на задачах в стиле RULER все потокенные варианты сканирования совпадают с точным top-k-декодированием.
Метод использует уже существующую 4-битную копию K-кэша квантованного serving-стека и ускоряет только случай, когда KV-кэш и его индекс вынесены в память хоста, а не хранятся в памяти видеокарты.

Почему это важно

Контексты ИИ-агентов растут до миллиона токенов, и когда в памяти одновременно держат много таких сессий, KV-кэш и его индекс переносят в память хоста. Сканирование этой памяти ради отбора top-k ключей на каждом шаге декодирования становится тем, что ограничивает скорость всего вывода. Fathom снимает это ограничение не новым железом, а тем, что каждый запрос сам подбирает глубину чтения под свои ключи, это даёт заметное ускорение и снижение трафика без потери точности относительно уже используемых методов разреженного сканирования.

Кому это важно

Инженерам, которые строят или поддерживают инференс-стеки для длинных агентных сессий с большим числом одновременных запросов и с KV-кэшем, вынесенным в память хоста; командам, уже применяющим методы разреженного сканирования вроде Double Sparsity, Loki или SparQ, для них Fathom прямая альтернатива с измеренным приростом скорости и снижением трафика.

Как это применить

Fathom не требует нового формата хранения: он читает переменную глубину бит из той же 4-битной копии K-кэша, которую квантованный serving-стек и так держит, это замена алгоритма сканирования индекса, а не новая инфраструктура. Но выигрыш проявляется только тогда, когда KV-кэш и его индекс вынесены в память хоста; если индекс целиком помещается в памяти видеокарты, метод ускорения не даёт.

Можно ли доверять

Текст источника не называет ни авторов, ни их организацию, ни дату публикации, это карточка на HuggingFace Papers, и указанное там имя относится к тому, кто разместил публикацию в списке, а не обязательно к автору работы. Цифры о скорости и трафике памяти, результаты, заявленные самими авторами; независимой проверки на момент публикации нет: у карточки всего 2 отметки и 2 комментария, то есть заметного обсуждения сообществом ещё не было. Из текста также не ясно, что именно входит в бенчмарки RULER-style и «реальные сессии ИИ-агентов для работы с кодом», источник называет их, но не описывает состав.

Риски и подводные камни

Ускорение и экономия трафика работают только в одном сценарии, когда KV-кэш и индекс вынесены в память хоста; при индексе, полностью помещающемся в памяти видеокарты, преимущества нет. Сравнение приведено против конкретных базовых методов (Double Sparsity, Loki, SparQ), как Fathom соотносится с другими подходами, из текста не видно. Не указано, как метод ведёт себя при росте числа одновременных сессий сверх протестированных условий, и на момент публикации нет независимого воспроизведения результатов.