StuffyAl, супер — хороший вопрос — после покупки второго GPU — экспериментальным путем выяснилось, что мой мини-PC имеет только один разъем USB4 — второй идентичный разьем (они оба выглядят как USB-C) — оказался обычным, не скоростным USB
Пришлось купить небольшой адаптер интерфейса Oculink, воткнуть его в свободный M2 — слот внутри, и аккуратно вывести шлейф с коннектором наружу через щель в корпусе — это на моей заглавной фотке в посте видно — черный GPU  подключен как раз через Oculink. 

Petr S, тут есть несколько моментов
Во-первых, у самого мини-компа, как выяснилось, есть своя собственная GPU Radeon 780M — и она может распоряжаться всей его памятью — всеми 64 GB (плюс, мне повезло, что в этом компе стоит 2 модуля по 32 — то есть скорость увеличивается вдвое). То есть, только на самом компе, безо всяких энвидий — мне удалось запустить довольно большую Gemma 4 31B c 8-мибитной квантизацией — и она выдает токенов 7-10 в секунду

Что касается  qwen 3.5-35B-A3B — там часть слоев и параметров запущена на Энвидии, часть работает на CPU — выдает 30-35 токенов в секунду.

Vyacheslav Ivanenkov, RAG, конечно же, в этой системе тоже предусмотрен. Как и векторная, как и обычная реляционная БД, конечно

Вообще, в процессе разработки всей этой системы — я понял, что полагаться на интеллект одной только LLM-ки в разговоре с клиентом, и ожидать, что она будет следовать своим инструкциям — это дохлый номер, особенно — с относительно небольшими LLM-ками, у которых отключен режим Reasoning (потому что — если его включать, то скорость ответа сразу падает до недопустимых задержек)

LLL-м должна еще и tool calling делать — то есть вызывать инструменты — проверка адреса клиента, тот же RAG вызвать например, вызвать код, который будет предлагать время визита и т д — если на нее еще и это навалить, то она сходит с ума. Чем длиннее системная инструкция, тем тупее нейронная сеть будет ей следовать.

Поэтому у меня сейчас основная и самая умная LLM (qwen3.5:9b-q8_0)  отвечает только за поддержание разговора с клиентом, и при каждом turn — транскрипт разговора читает другая LLM-ка (granite3.3:2b) , которая отвечает ТОЛЬКО за извлечение структурной информации (те данные, которые надо обязательно собрать — имя клиента, адрес, тип проблемы), и иногда говорит основной LLM — что спросить у клиента в следующем turn (такие инструкции впрыскиваются прямо в конец системного промпта)

Но и этого оказалось недостаточно, чтобы приструнить этих двух чуваков, и заставить их делать то, что надо. Я подсмотрел, как сделаны коммерческие системы, и понял, что надо строить еще более менее строгий алгоритмический harness, который основан на flow

И все эти системы — они основаны на Intent (намерение) звонящего. Главной целью основной LLM – является определить Intent (чего вообще звонящий хочет) – пожаловаться на проблему, вызвать мастера, спросить, делаем ли мы какой то сервис, или спросить сколько он стоит

Поэтому — мне пришлось сделать еще и редактор для этих flow. Где для каждого Intent-а – описана своя последовательность шагов – смотрите скриншот, которыя я гружу сюда – это именно мой редактор для одного из Intent
Сейчас, собственно и занимаюсь отладкой всего этого
Там еще выяснилось куча ОЧЕНЬ ОЧЕНЬ интересных моментов, я здесь описал наверное только процентов 30. Я же говорю – получил кучу удовольствия за свои деньги 😊

Маркиз Лафайет, почему же, раз он еще жив — значит, дождался! Буквально два дня назад слушал интервью с ним на подкасте MFM ( My first million)
не уверен, что миру нужен еще один такой зануда

Сергей Викторович, RAG — это совсем другая история. Там тоже нужна нейронная сеть для генерации Embeddings, но их надо генерить только один раз, для конкретного запроса, если что то опрашивать в real time (Для начального наполнения векторной базы данных — эти embeddings тоже надо вызывать, и вызывать много, но это надо делать один раз, и можно подождать -  там время некритично)

Короче — RAG — это та штука, которая, наверное, могла бы работать на обычном PC без проблем (для прототипирования — сгодится)

Забыл упомянуть еще момент — при наполнении векторной базы данных — хорошо еще сделать правильный Chunking (разбиение на куски) — и — возможно — суммирование знаний / сжатие текстов, чтобы убрать из них всю «воду» — для этого тоже желательно использовать отдельную LLM-ку, но она не обязательно должна быть слишком умной (разбиение на куски и суммирование — не сложные задачи). Тут размер контекста важней «умности» модели.  Какая нибудь небольшая Gemma или Granite — подойдет. И тут уже надо — вместе с embedding — моделью, которая будет работать на том же железе — наверное как минимум 32 гига памяти, и чтобы проц не слишком медленный. Все это без правильных GPU будет тошнить с скоростью улитки, но заполнение векторной БД — это надо сделать всего один раз, можно и подождать.

Блин!!! забыл упомянуть еще один момент — если база знаний в разных форматах типа pdf / word или упаси господь отсканированные документы, которые еще надо в текст перевести, или диаграммы какие нибудь — вот тут вы попали. Потому что — чтобы перевести все эти разные форматы в удобноваримые логичные chunks — тут никакой локальной модели не хватит, конечно же. Тут нужна приличная коммерческая модель, мульти-модальная, чтобы понимала все форматы. Готовьтесь платить за токены, если этот сценарий описывает Ваш случай !

когда был в Лондоне года три назад, специально зашел в магазин Чичваркина.
Дорого, богато. Большой магазин, на 2-х этажах. Посетителей — кроме меня — было немного. Ничего не купил ессно. Как сертифицированный нищеброд — я вина дороже 10 долл за бутылку не покупаю.