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. Я же говорю – получил кучу удовольствия за свои деньги 😊