Локальные LLM для суммаризации документов: выбор модели и софта

Документ не отправляется стороннему облачному провайдеру, а содержание запроса не зависит от его политики хранения, журналирования и лимитов. Для договоров, внутренних отчётов, расшифровок встреч и рабочих архивов это не абстрактное преимущество, а иногда главное условие использования ИИ.

Цена приватности — не только видеокарта. Локальный запуск требует разобраться в памяти, формате модели, длине контекста, интерфейсе и способе загрузки документов. На одном компьютере модель будет работать целиком в VRAM, на другом часть весов уйдёт в оперативную память, а на третьем тот же файл окажется слишком большим не из-за самой модели, а из-за контекстного окна. Поэтому универсальной связки «модель X — видеокарта Y» здесь нет. Есть компромисс между скоростью, качеством, объёмом документа и удобством.

Аппаратные требования: сколько памяти нужно для локальной обработки

При выборе локальной модели обычно сначала смотрят на VRAM, но считать её единственным жёстким ограничением неправильно. Важны как минимум четыре величины: размер квантованной модели, длина контекста, объём оперативной памяти и способ запуска.

Если модель помещается в видеопамять вместе с необходимым контекстом, генерация обычно получается быстрее. Если места не хватает, часть весов можно выгрузить в RAM. Такой режим поддерживается не всеми конфигурациями одинаково хорошо, а его скорость зависит от процессора, пропускной способности памяти и того, какая именно часть модели осталась на CPU. Это не означает, что компьютер превращается в бесполезный терминал: для коротких запросов и нерегулярной работы CPU-инференс может быть приемлемым. Но при обработке длинных документов задержки становятся заметнее.

На компьютерах с Apple Silicon нужно отдельно учитывать Unified Memory. Там память не разделена на классическую оперативную и видеопамять: процессор и графический ускоритель используют общий пул. Поэтому сравнивать, например, 32 ГБ Unified Memory и 32 ГБ выделенной VRAM напрямую нельзя. Доступный объём зависит от операционной системы, фоновых приложений, выбранного бэкенда и того, сколько памяти уже занято самим компьютером.

Есть и ещё один расход — KV-cache, то есть структура, в которой движок хранит состояние текущего контекста. Чем длиннее входной документ и чем больше одновременно обрабатываемых токенов, тем больше памяти требуется помимо самих весов модели. Именно поэтому модель, которая запускается на коротком запросе, может начать выгружать часть данных в RAM при работе с большим PDF.

Практически аппаратную конфигурацию удобно оценивать так:

• 8 ГБ VRAM часто позволяют запускать квантованные модели класса 7B–8B, но реальный запас зависит от формата квантования, контекстного окна и конкретного движка. Для коротких и средних документов это наиболее понятная отправная точка.
• 12–16 ГБ VRAM дают больше свободы для увеличения контекста, использования более крупных моделей и снижения вероятности агрессивной выгрузки в RAM. Это не универсальный порог для длинных документов, а скорее комфортный диапазон для части конфигураций.
• 24 ГБ VRAM и больше полезны, когда нужно сочетать крупную модель, длинный контекст и приемлемую скорость. Но сама по себе большая видеопамять не гарантирует, что модель хорошо обработает сложный документ.
• Только оперативная память остаётся рабочим вариантом для CPU-инференса. Он может подходить для экспериментов, пакетной обработки небольших файлов и компьютеров без дискретной видеокарты, однако скорость на длинных запросах часто становится главным ограничением.
• Unified Memory на компьютерах Apple Silicon нужно считать отдельным классом конфигураций. Запас памяти там используется совместно системой и моделью, поэтому номинальный объём нельзя без поправок трактовать как доступную VRAM.

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

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

Почему квантование не сводится к выбору «самого маленького файла»

Для суммаризации чаще всего выбирают GGUF-сборки с квантованием уровня Q4, включая варианты вроде Q4_K_M. Это популярный компромисс между размером, скоростью и сохранением способности модели следовать инструкции. Но «Q4» не является гарантией одинакового качества: результат зависит от исходной модели, набора данных, качества конвертации и характера документа.

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

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

Выбор архитектуры: модели 7B–8B против систем с длинным контекстом

Модели класса 7B–8B остаются удобной отправной точкой для локального суммаризатора документов на ПК. Они сравнительно нетребовательны, быстро загружаются и поддерживаются большим числом инструментов. На них удобно отлаживать промпты, проверять разные форматы вывода и строить автоматизацию через локальный API.

Llama 3.1 8B и Qwen 2.5 7B — примеры распространённых семейств, для которых доступны локальные квантованные сборки. Они могут справляться с пересказом отдельных статей, рабочих инструкций, договоров и расшифровок, если документ помещается в рабочее окно или предварительно разбивается на части. Это не означает, что любая модель такого размера одинаково хорошо решает любую задачу. На техническом тексте одна сборка лучше удерживает термины, другая аккуратнее работает с многоязычным материалом, третья требует более строгой инструкции.

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

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

Кроме того, на практический лимит влияют:

• токенизация конкретного языка и документа;
• наличие таблиц, списков, колонтитулов и служебного текста;
• формат извлечения содержимого из PDF;
• резерв памяти под KV-cache;
• настройки движка и фактический режим размещения слоёв;
• необходимость одновременно держать системную инструкцию, документ и шаблон ответа.

Поэтому файл на «50 тысяч токенов» не следует автоматически связывать с определённым объёмом VRAM. Одна модель обработает его в полном контексте, другая потребует разбивки, третья формально примет вход, но будет хуже удерживать детали. Корректнее сначала выяснить, как конкретная сборка ведёт себя на нужном окне, а затем подбирать память и стратегию обработки.

Для длинных материалов часто надёжнее не передавать модели весь документ одним сообщением, а использовать иерархическую схему. Сначала система делает краткие выжимки отдельных разделов, затем объединяет их в промежуточное резюме и только после этого формирует итог. Такой подход увеличивает число проходов, зато позволяет явно контролировать, какие части исходника уже обработаны. Он особенно полезен, когда в документе много повторов, приложений или плохо извлечённого текста.

Экосистема инструментов: от Ollama до Open WebUI и AnythingLLM

Запуск локальной модели — это не одна программа, а несколько уровней. Их можно объединить в готовый пакет, а можно собрать отдельно под собственный сценарий.

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

LM Studio предлагает графический сценарий. В нём проще скачивать модели, просматривать доступные варианты, запускать локальный сервер и экспериментировать с параметрами без терминала. Для разовой работы с документами и первичного сравнения сборок это часто более дружелюбный вариант. При этом графический интерфейс не отменяет технических ограничений: длинный контекст и крупная модель всё равно требуют памяти.

Open WebUI — веб-интерфейс для чатов и работы с моделями через совместимые локальные серверы. В зависимости от конфигурации он может подключаться к Ollama и другим бэкендам. Это важная оговорка: Open WebUI не следует считать оболочкой, построенной только вокруг одного движка. Его роль — предоставить интерфейс, историю запросов, управление моделями и дополнительные сценарии поверх подключённого исполнения.

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

llama.cpp — один из распространённых движков локального инференса, особенно заметный в экосистеме GGUF. Многие приложения умеют работать с ним прямо или косвенно, но не все перечисленные инструменты построены исключительно вокруг него. На практике пользователь может встретить разные бэкенды, режимы ускорения и способы загрузки одной и той же модели. От этого меняются поддерживаемые форматы, скорость и требования к памяти.

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

Сравнение Ollama и LM Studio для суммаризации документов на практике сводится не к вопросу, какая программа «лучше», а к режиму работы:

Для простой выжимки одного файла можно начать с LM Studio или связки Ollama с Open WebUI. Для регулярного разбора папки документов логичнее смотреть в сторону AnythingLLM или собственного пайплайна с RAG. При этом интерфейс не исправит плохое извлечение текста и не устранит ошибки модели. Если PDF состоит из сканов, сначала понадобится OCR; если в нём сложные таблицы, их структура может потеряться ещё до этапа суммаризации.

Ollama удобен как локальный исполнитель и API, LM Studio — как графическая среда для ручного запуска, Open WebUI — как универсальный веб-интерфейс, а AnythingLLM — как оболочка для рабочих пространств и RAG. Это разные роли, а не взаимоисключающие продукты.

Настройка параметров генерации для точной суммаризации

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

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

Для начала можно использовать такую логику:

• Temperature — низкое значение подходит для воспроизводимой выжимки. Конкретный диапазон лучше подбирать на собственных документах: слишком низкая температура не превращает модель в проверяющий модуль, а иногда делает ответ механическим.
• Top-P — обычно нет необходимости одновременно агрессивно ограничивать и Temperature, и Top-P. Если оба параметра сильно зажаты, текст может стать однообразным или начать пропускать важные формулировки.
• Repetition Penalty — умеренная настройка помогает при зацикливании, но чрезмерное значение способно повредить повторяющимся терминам. Для договоров и технических текстов это особенно заметно: одинаковое слово не всегда является стилистическим повтором, иногда это ключевой термин.
• Context Window — его нужно выставлять с запасом под инструкцию, исходный текст и ожидаемый ответ. Формальное увеличение окна не заменяет тестирование: модель и движок должны поддерживать выбранный режим, а память компьютера — его выдерживать.
• Max Tokens — ограничение длины ответа полезно для контроля формата, но слишком короткий лимит обрежет вывод в середине списка или заставит модель чрезмерно сжимать содержание.
• Seed, если параметр доступен, помогает сравнивать настройки в более стабильных условиях. Он не делает ответ истинным, но упрощает повторный прогон.

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

Хорошая схема промпта для суммаризации выглядит как последовательность требований:

1. Указать, что источником являются только переданные фрагменты.

2. Попросить не добавлять сведения, которых нет в тексте.

3. Разделить результат на факты, решения, риски и открытые вопросы.

4. Сохранить числа, названия, сроки и отрицательные формулировки без вольного пересказа.

5. Если данных не хватает, явно обозначить это.

6. Привести ссылку на раздел или заголовок исходного документа, если такая разметка доступна.

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

Как проверять итог без превращения текста в ручную экспертизу

У суммаризатора должна быть собственная процедура контроля. Это не обязательный формальный чек-лист, а нормальная часть рабочего процесса. Для чувствительных материалов полезно сравнить с исходником хотя бы:

• все числа, проценты, даты и сроки;
• имена организаций, продуктов и участников;
• формулировки с «не», «только», «если», «кроме» и другими ограничениями;
• выводы, которые выглядят как причинно-следственные связи;
• упоминания приложений, таблиц и исключений.

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

Интеграция RAG: как работать с локальными базами документов

Если нужно суммаризировать один файл, его можно передать модели напрямую или разбить на части. Когда речь идёт о папке, архиве или постоянно пополняемой базе, возникает другая задача: сначала нужно найти нужные фрагменты, а уже потом передать их в контекст. Здесь применяется Retrieval-Augmented Generation, или RAG.

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

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

На качество RAG влияют несколько этапов:

• Извлечение текста. Сканированный PDF без OCR для системы почти бесполезен. Даже текстовый PDF может содержать колонки, таблицы и заголовки в порядке, который ломает смысл.
• Разбиение на фрагменты. Слишком маленькие куски теряют контекст, слишком большие хуже находятся и занимают больше окна. Универсального размера нет: структура договора отличается от расшифровки или технической документации.
• Перекрытие частей. Небольшое пересечение помогает не обрывать определения и списки на границах, но увеличивает объём повторяющегося текста.
• Модель эмбеддингов. Поисковая модель должна хорошо работать с языком и типом документов. Качество генератора не компенсирует слабый поиск.
• Количество retrieved-фрагментов. Если передать слишком мало источников, ответ окажется неполным. Если слишком много — контекст переполнится шумом, а модель начнёт смешивать похожие положения.
• Метаданные. Название файла, раздел, страница и дата помогают понять происхождение найденного фрагмента и упрощают проверку.

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

AnythingLLM и Open WebUI могут предоставлять RAG-сценарии через свои настройки и подключаемые компоненты, но конкретные возможности зависят от версии и выбранного бэкенда. В более контролируемом варианте можно собрать отдельный локальный пайплайн: инструмент извлечения текста, индекс, модель эмбеддингов, локальный сервер LLM и интерфейс для запросов. Это сложнее, зато позволяет отдельно менять каждый элемент и понимать, на каком этапе появилась ошибка.

Как собрать рабочую конфигурацию под разные задачи

Для первого знакомства не обязательно сразу строить сложную систему с базой документов. Разумнее разделить сценарии.

Если требуется иногда пересказывать статьи, небольшие отчёты или расшифровки, достаточно настольного приложения с поддержкой нужного формата модели. Важно проверить, как оно открывает PDF, умеет ли ограничивать контекст и позволяет ли менять параметры генерации. При слабой видеокарте можно начать с квантованной модели меньшего размера или разрешить частичную выгрузку в RAM, приняв снижение скорости.

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

Для команды, которой нужен браузерный интерфейс, подойдёт связка локального исполнителя с Open WebUI. Пользователи получают историю диалогов и привычный чат, а модель продолжает работать на внутреннем компьютере или сервере. Но здесь особенно важно заранее определить права доступа: локальность не решает вопрос, кто может открыть историю запросов и загруженные файлы.

Для архива с постоянным поиском по документам стоит рассматривать AnythingLLM или другой RAG-инструмент. Он полезен, когда нужно задавать вопросы по нескольким источникам, находить связанные фрагменты и получать краткие выжимки по выбранным материалам. Полное резюме крупного отчёта всё равно лучше строить по этапам, а не полагаться только на выборку нескольких фрагментов.

Выбор модели можно свести к нескольким практическим вопросам:

• Нужно ли обрабатывать один документ целиком или искать сведения в коллекции?
• Важнее скорость ответа или аккуратность сложного анализа?
• Есть ли таблицы, сканы, колонтитулы и другие элементы, которые могут потеряться при импорте?
• Должна ли система работать полностью без сети или допустим локальный сервер с отдельными обновлениями?
• Можно ли повторить обработку нескольких частей и затем проверить итог?
• Какой объём памяти останется после запуска операционной системы и интерфейса?
• Нужен ли API для автоматизации или достаточно графического окна?

Ответы на эти вопросы обычно полезнее, чем сравнение моделей по числу параметров. Размер 7B–8B может быть разумным выбором для одного сценария и слабым — для другого. Модель с большим контекстом может принять длинный файл, но потребовать больше памяти и не обязательно лучше выделить главное. RAG может сократить объём входа, но ошибиться на этапе поиска. У каждого ускорения есть цена, и её нужно видеть до внедрения.

Вердикт

Локальные LLM для суммаризации документов на ПК уже подходят для регулярной работы, если задача сформулирована реалистично. Квантованная модель класса 7B–8B — удобная отправная точка для коротких и средних документов. Более крупные модели имеют смысл, когда важны сложное сопоставление, терминологическая точность и устойчивость на неоднозначных материалах. Для больших файлов нужно выбирать не только модель с расширенным контекстом, но и способ обработки: полный проход, разбивку на части или иерархическую суммаризацию.

Аппаратные требования зависят от модели, квантования, размера контекстного окна и режима запуска. VRAM важна, но оперативная память тоже может использоваться при частичной выгрузке, а на системах с Unified Memory граница между этими ресурсами устроена иначе. Поэтому правильнее тестировать связку целиком, а не считать абсолютный объём видеопамяти гарантией работоспособности.

В качестве первого стека можно рассматривать Ollama или LM Studio для запуска, Open WebUI для браузерного интерфейса и AnythingLLM для базы документов с RAG. llama.cpp остаётся одним из поддерживаемых вариантов движка, но экосистема не сводится к нему одному. Итоговое качество определяется тем, как извлечён документ, какой контекст попал в запрос, насколько строго задан формат ответа и проверяются ли критичные детали.

Для тех, кто подходит к выбору локальных решений с тем же фильтром маркетинговой воды, рабочий пример структурированного отбора — подборка Лучшие бары на Рубинштейна: критерии выбора и главные локации. Та же логика отсечения внешней шелухи, только в другой предметной области.

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