Локальный RAG для документов: как выбрать железо для скорости 30-40 токенов/сек на TXT, DOC, PDF

Зачем вообще гоняться за 30-40 токенов в секунду?

Представьте. Вы задаёте вопрос по 200-страничному PDF. И ждёте. 5 секунд. 10. 20. Мысли убегают, контекст теряется. 30-40 токенов в секунду — это магический порог, где диалог с локальной моделью перестаёт быть пыткой и становится работой. Это скорость, при которой вы читаете ответ быстрее, чем успеваете отвлечься на кофе.

Но здесь кроется ловушка. Все бенчмарки в интернете измеряют чистую генерацию на идеальных промптах. В реальном RAG-пайплайне всё сложнее: загрузка чанков из векторизованной базы, их вставка в контекст, парсинг PDF (проклятие всех разработчиков), и только потом — генерация. Ваша цель — не просто 40 токенов/сек на чистой модели, а 40 токенов/сек в конце всей этой цепочки, когда вы загрузили документ через неидеальный парсер вроде Unstructured или LlamaParse.

Архитектура, которая съедает ваши токены

Прежде чем выбирать железо, поймите, куда уходит время. Типичный пайплайн локального RAG для документа выглядит так:

1. Загрузка и парсинг (PDF/DOC/TXT) — CPU-intensive, зависит от библиотек.
2. Чанкинг и эмбеддинг — здесь можно использовать маленькую модель эмбеддингов на CPU или переложить на GPU.
3. Поиск по векторной базе (FAISS, Chroma) — операция в памяти, зависит от скорости RAM и размера индекса.
4. Формирование финального промпта — простая конкатенация строк, но с большими контекстами начинает нагружать CPU.
5. Генерация ответа LLM — та самая часть, где нужны мощные GPU или NPU.

Если вы оптимизируете только пункт 5, но у вас старый HDD и 8 ГБ ОЗУ для векторной базы на 60 ГБ документов (как в случае из этой статьи), то 40 токенов/сек вы не увидите никогда. Система будет простаивать, ожидая загрузки данных с диска.

Выбор платформы: битва архитектур

Здесь не бывает универсального ответа. Ваш выбор зависит от бюджета, шума, потребления энергии и того, готовы ли вы возиться с драйверами.

Вариант 1: Элегантная тюрьма Apple Silicon

MacBook Pro с M3 Max или Mac Studio с M2 Ultra.

• Плюсы: Тишина, энергоэффективность, единая память (никаких проблем с переносом данных CPU-GPU), идеально для офиса.
• Минусы: Цена. Ограниченный выбор моделей (не всё работает через Metal). Апгрейд — купить новый компьютер.
• На что смотреть: Объём unified memory. Для 30-40 токенов/сек на моделях типа Llama 3.1 8B или Qwen2.5 7B нужно минимум 32 ГБ. 16 ГБ — будет больно.

Вариант 2: Старая добрая ферма Nvidia

ПК с RTX 3090, 4080, 4090 или серверная карта типа A2000 12GB.

• Плюсы: Полный контроль. Поддержка всех фреймворков (Ollama, llama.cpp, vLLM, ExLlama). Возможность тонкой оптимизации. Апгрейд по частям.
• Минусы: Шум, тепло, потребление энергии (4090 может брать 450Вт), возня с драйверами и CUDA.
• На что смотреть: Объём VRAM (минимум 12 ГБ, комфортно 16-24 ГБ) и пропускная способность памяти (от 600 ГБ/с). И не забудьте про мощный CPU (Ryzen 7/Intel i7) и быстрый NVMe SSD для парсинга документов.

Вариант 3: Экзотика и компромиссы

• Nvidia Jetson Orin: Интересно для embedded-решений. Но 40 токенов/сек? Только на крошечных моделях. Для серьёзного RAG с документами — маловато.
• Intel ARC: Цена привлекательная, производительность растёт. Но поддержка в llama.cpp и Ollama ещё сыровата. Если любите эксперименты — ваш выбор.
• Чистый CPU с llama.cpp: Современные Ryzen 7/9 с DDR5 и AVX2. Удивительно, но на 7B-моделях можно выжать 15-20 токенов/сек. Для 40 — нужно чудо или очень умные маленькие модели.

Пошаговый план: от коробки до 40 токенов/сек

1 Определите модель-работягу

Не гонитесь за размером. Для работы с документами через RAG часто хватает 7B-8B параметров. Качество ответа определяет не размер модели, а качество релевантных чанков, которые вы ей подаёте. Используйте гибридный поиск, чтобы найти лучшее. Кандидаты на 2024 год: Qwen2.5 7B, Llama 3.1 8B, DeepSeek-V2 Lite 16B (более требовательна).

2 Протестируйте на том, что есть

Прежде чем тратить деньги, установите Ollama на свой текущий компьютер. Загрузите модель в формате Q4_K_M (хороший баланс качества и скорости). Запустите не абстрактный бенчмарк, а свой реальный пайплайн: загрузите типичный PDF, сделайте индексацию, задайте вопрос. Замерьте скорость. Упираетесь в CPU при парсинге? В IO при загрузке модели? Это даст понимание, что улучшать в первую очередь.

3 Соберите системный бутылочный горлышко

Железо — это система. Самый слабый компонент определяет всё.

• Для Nvidia-системы: GPU (минимум 12 ГБ быстрой VRAM) + CPU с 8+ ядрами (для парсинга) + 32 ГБ ОЗУ DDR4/5 + NVMe SSD (чтение 3+ ГБ/с). Блок питания с запасом 30%.
• Для Apple-системы: Выбирайте по объёму Unified Memory. 32 ГБ — необходимый минимум для комфортной работы. 64 ГБ — если планируете держать в памяти несколько моделей или огромную векторную базу.

4 Настройте софт под железо

Купили железо — работа только началась.

• Ollama: Используйте флаги --num-gpu (для слоёв на GPU) и --num-thread (для CPU). Экспериментируйте, какая часть модели на GPU даёт максимальный прирост.
• llama.cpp: Тонкая настройка через количество потоков, размещение слоёв. Для продвинутых.
• Парсеры документов: Настройте кэширование. Не парсьте один и тот же PDF каждый раз. Сохраняйте результат чанкинга и эмбеддингов на диск.

5 Оптимизируйте сам RAG-пайплайн

Железо можно не апгрейдить, если умнее работать.

• Используйте умные форматы вроде CommerceTXT для структурированных данных, чтобы сократить контекст.
• Применяйте техники самосборки и обновления индекса.
• Выбирайте меньший размер чанка. Часто 512 токенов работает лучше, чем 1024, и быстрее обрабатывается.

Распространённые ошибки, которые крадут вашу скорость

• Запуск без квантования. Загружаете модель в формате FP16 (оригинальные веса) и удивляетесь, что она не влезает в память и тормозит. Всегда используйте квантованные версии (Q4_K_M, Q5_K_M). Потери качества минимальны, выигрыш в скорости и памяти — колоссальный.
• Игнорирование парсинга PDF. Вы купили RTX 4090, но парсите PDF через pdfminer на одном ядре. Это станет бутылочным горлышком. Используйте многопоточные парсеры или выносите парсинг в отдельный процесс.
• Векторная база на диске. Запускаете Chroma с persist_directory на HDD. Каждый поиск — ожидание дисковых операций. Держите индекс в оперативной памяти. Если не помещается — используйте специальные оптимизации для FAISS или гибридный поиск с BM25, который менее требователен к памяти.
• Слишком длинный контекст. Подаёте в модель 10 чанков по 1024 токена «на всякий случай». Модель тратит 90% времени на обработку нерелевантного контекста. Улучшайте поиск, чтобы находить 2-3 самых точных чанка.

Что в итоге? Простой чеклист

1. Цель: 30-40 токенов/сек в конце-to-end пайплайна (парсинг + поиск + генерация), а не в синтетическом тесте.
2. Модель: Начинайте с квантованной 7B-8B модели (Qwen2.5, Llama 3.1). Этого достаточно для большинства задач по документам.
3. Платформа:
   — Хотите «работает из коробки» и тишину → Mac Studio с M2 Max/M2 Ultra и 32+ ГБ памяти.
   — Хотите максимальную производительность и контроль → PC с RTX 3090/4080/4090 (16+ ГБ VRAM), быстрым 8-ядерным CPU и 32 ГБ ОЗУ.
   — Бюджет ограничен → PC с RTX 4070 Ti Super 16GB или даже мощный CPU (Ryzen 9) с llama.cpp.
4. Оптимизация: Настройте софт, кэшируйте результаты парсинга, используйте гибридный поиск, следите за бутылочными горлышками (диск, память).

И последнее. Самый важный компонент в локальном RAG — не видеокарта и не процессор. Это ваш patience threshold (порог терпения). 40 токенов в секунду — это примерно скорость чтения вслух. Если система отвечает медленнее, вы начнёте ненавидеть её и вернётесь к ручному поиску в PDF. Правильно подобранное и настроенное железо — это не роскошь, а инструмент, который сохраняет ваше внимание и время для действительно важных задач. А там, глядишь, и до сборки своей экспериментальной модели рукой подать.