Как запустить 176B‑класс Qwen3.8-Flash‑Next в DeepSeek Harness на GTX 1080 Ti

Введение: как запустить модель на 100+ GB веса на видеокарте с 11 GB VRAM

Когда смотришь на характеристики современных MoE‑моделей, иногда возникает странная мысль: а что будет, если взять модель с сотнями миллиардов параметров и попробовать запустить её на старом игровом GPU?

С Qwen3.8-Flash‑Next этот эксперимент оказался особенно интересным.

Qwen3.8-Flash‑Next — мультимодальная MoE‑модель, которую сама команда Qwen называет ранним предпросмотром архитектуры, лежащей в основе Qwen4. В основной части модели 125 млрд параметров, дополнительно используется около 51 млрд параметров n‑gram embedding‑таблиц, а на один токен активируется около 6 млрд параметров. Поэтому в сообществе модель часто называют 176B‑классом: 125B + 51B. В model card отдельно также указан 4B MTP‑компонент.

Модель использует гибридную архитектуру Gated DeltaNet (GDN) и Qwen Sparse Attention (QSA). Всего в ней 48 слоёв: три из четырёх используют GDN, а каждый четвёртый — QSA. Кроме того, здесь используется 512 экспертов MoE, из которых на каждом токене выбираются 10 маршрутизируемых экспертов плюс shared expert.

Нативный контекст модели составляет 262 144 токена, то есть 256K в обычном обозначении.

На бумаге всё это выглядит впечатляюще. На практике возникает главный вопрос: куда поместить более 100 GB модели, если видеокарта располагает всего 11 GB VRAM?

В моём случае ответ оказался неожиданным: GTX 1080 Ti действительно достаточно, чтобы запустить такую модель, если использовать llama.cpp и правильно распределить вычисления между GPU и оперативной памятью.

Моя конфигурация:

• NVIDIA GeForce GTX 1080 Ti — 11 GB VRAM;

• Intel Core i9-9900K;

• 64 GB RAM;

• Ubuntu Linux;

• llama.cpp с поддержкой qwen4exp;

• GGUF UD-Q4_K_XL;

• DeepSeek Harness (DSH) в качестве агентной оболочки.

Полученная скорость генерации составила около 11 токенов/с. Для обычного интерактивного чата это немного, но для пакетной обработки и сложных агентных задач уже представляет практический интерес.

Почему я вообще занялся этим экспериментом, ведь есть Qwen3.8–27B

У Qwen есть гораздо меньшая Qwen3.8–27B. Она существенно проще с точки зрения требований к памяти и для многих задач выглядит более рациональным выбором.

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

Это важно подчеркнуть: речь идёт именно о моём опыте, а не о том, что Qwen3.8–27B в целом «не умеет следовать инструкциям». Официальные результаты Qwen показывают, что 27B вполне конкурентоспособна на coding и agentic‑бенчмарках.

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

До Qwen3.8-Flash‑Next я уже запускал локально gpt‑oss-120b через Ollama — тоже MoE‑модель большого размера.

Она показала, что на системе с ограниченной VRAM большой sparse‑модели вполне могут работать за счёт того, что далеко не все параметры участвуют в вычислении каждого токена.

Это навело меня на мысль: если удаётся запустить 120B‑класс, можно попробовать ещё более крупную MoE‑модель — при условии, что её архитектура хорошо подходит для CPU/GPU offload.

Qwen3.8-Flash‑Next оказалась именно таким случаем.

Часть 1. Почему нельзя просто использовать Ollama

На момент проведения эксперимента основной официальный тег Qwen3.8-Flash‑Next в библиотеке Ollama был представлен как MLX‑вариант:

ollama run qwen3.8-flash-next:125b-mlx

MLX предназначен для экосистемы Apple Silicon, поэтому это не тот путь, который нужен пользователю Linux + NVIDIA.

Ситуация с Ollama несколько сложнее, чем просто «Ollama вообще не поддерживает модель». Поддержка MLX у Qwen3.8-Flash‑Next появилась в Ollama 0.33.1, а попытки импортировать сторонний GGUF в актуальной ветке Ollama сталкивались с ошибками при внутренней проверке GGUF. Например, для UD‑Q4_K_XL в Ollama 0.33.2 была зафиксирована ошибка failed to validate GGUF...; та же модель при этом нормально запускалась напрямую через llama.cpp.

Поэтому для этой конкретной конфигурации я выбрал более прямую схему:

Qwen3.8-Flash-Next GGUF        
         ↓    
     llama.cpp        
         ↓   
     llama-server        
         ↓
    DeepSeek Harness

Это позволяет полностью контролировать размещение модели и параметры llama.cpp.

Часть 2. Подготовка модели

Что понадобится

Аппаратная часть

Минимальная конфигурация для описанного эксперимента:

• GPU с примерно 10–12 GB VRAM;

• не менее 64 GB RAM;

• быстрый SSD/NVMe;

• примерно 150–250 GB свободного места.

Почему так много?

Потому что сам GGUF занимает около 111 GB, а во время объединения шардов временно приходится хранить как исходные файлы, так и итоговый файл.

Программная часть

Потребуются:

• Linux;

• Git;

• CMake;

• GCC;

• CUDA toolkit, совместимый с вашей видеокартой;

• llama.cpp;

• Node.js для DeepSeek Harness.

Для DSH актуальная ветка требует современный Node.js; исходный репозиторий сейчас указывает Node.js 22.19+ либо 24+.

Шаг 1. Скачиваем GGUF

Для эксперимента использовался UD-Q4_K_XL от Unsloth.

Модель разбита на четыре файла:

Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf   10.9 MB
Qwen3.8-Flash-Next-UD-Q4_K_XL-00002-of-00004.gguf   49.9 GB
Qwen3.8-Flash-Next-UD-Q4_K_XL-00003-of-00004.gguf   49.4 GB
Qwen3.8-Flash-Next-UD-Q4_K_XL-00004-of-00004.gguf   12.1 GB

Суммарный размер получается примерно 111 GB. Эти размеры соответствуют текущим файлам на Hugging Face.

Создадим каталог:

mkdir -p ~/GGUF/qwen-flash-next
cd ~/GGUF/qwen-flash-next

И поместим туда все четыре shard‑файла (которые можно скачать по https://huggingface.co/unsloth/Qwen3.8-Flash‑Next‑GGUF/tree/main/UD‑Q4_K_XL.

Шаг 2. Объединяем GGUF

Современный llama.cpp умеет непосредственно работать с разбитыми GGUF‑файлами, поэтому технически объединение не обязательно. Однако единый файл удобнее для некоторых сценариев и плагинов. Тем более, я планирую использовать данную модель в своей программе https://github.com/SkalaSkalolaz/gogitor. Сам llama-gguf-split официально умеет объединять shards в один GGUF и автоматически находит остальные части по имени первого файла.

Если llama.cpp ещё не установлен, клонируем репозиторий:

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

Для GTX 1080 Ti используется compute capability 6.1:

cmake -B build   -DGGML_CUDA=ON   -DCMAKE_CUDA_ARCHITECTURES=61
cmake --build build --config Release -j $(nproc)

После этого объединяем файлы:

./build/bin/llama-gguf-split --merge   ~/GGUF/qwen-flash-next/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf   ~/GGUF/qwen-flash-next/Qwen3.8-Flash-Next-merged.gguf

Официальная документация llama-gguf-split подтверждает именно такую схему: достаточно указать первый shard и имя выходного файла.

После успешного объединения можно удалить исходные shards и вернуть себе около 111 GB дискового пространства.

Часть 3. Какая версия llama.cpp нужна

Поддержка Qwen3.8-Flash‑Next появилась в llama.cpp благодаря PR #27742, который был объединён 27 августа 2026 года. Новая архитектура получила внутреннее имя qwen4exp.

На момент первых экспериментов это означало необходимость собирать свежий master.

Сейчас ситуация изменилась: 14 сентября 2026 года вышел стабильный llama.cpp 0.4.1, поэтому для новой установки уже нет необходимости принципиально привязываться к какой‑либо ночной сборке. Тем не менее важно использовать версию, в которой присутствует поддержка qwen4exp.

Проверить версию можно:

llama-server --version

Если вы собираете llama.cpp самостоятельно, а для GTX 1080 Ti пришлось это делать, то имеет смысл использовать CUDA 12.x и архитектуру 61.

Часть 4. Первый запуск llama‑server

После сборки можно попробовать запустить модель непосредственно через llama.cpp.

В моём случае использовалась такая конфигурация:

llama-server   -m ~/GGUF/qwen-flash-next/Qwen3.8-Flash-Next-merged.gguf   -c 16384   -b 2048   -ub 1024   -np 1   --cache-type-k q8_0   --cache-type-v q8_0   --host 127.0.0.1   --port 55555

Параметры здесь означают:

• -c 16384 — начальный контекст 16K;

• -b 2048 — batch size;

• -ub 1024 — ubatch size;

• -np 1 — один параллельный слот;

• q8_0 для K/V‑кэша — компромисс между качеством и потреблением памяти;

• 127.0.0.1:55555 — локальный OpenAI‑compatible API.

Главное здесь — не пытаться автоматически ставить -ngl 999 или -ngl all только потому, что это обычно используется для небольших моделей.

Современный llama.cpp поддерживает автоматический подбор количества GPU‑слоёв (-ngl auto, являющийся значением по умолчанию), а также отдельные параметры для CPU‑offload MoE‑экспертов.

Для конкретной 11-гигабайтной GTX 1080 Ti автоматическое размещение оказалось более удобным, чем попытка вручную поместить весь граф на GPU.

При успешном запуске сервер сообщает, что модель загружена и слушает указанный порт.

Часть 5. Проверяем модель без DeepSeek Harness

Сначала лучше убедиться, что llama.cpp работает независимо от DSH.

Проверяем список моделей:

curl -s http://127.0.0.1:55555/v1/models | jq

Затем отправляем простой запрос:

curl -s http://127.0.0.1:55555/v1/chat/completions   -H "Content-Type: application/json"   -d '{    "model": "slot-a",    "messages": [      {        "role": "user",        "content": "2+2"      }    ],    "max_tokens": 50  }' | jq

Название модели в запросе зависит от того, какое значение сообщает ваш сервер. Не следует жёстко рассчитывать, что оно всегда будет slot-a.

Если сервер вернул корректный ответ, значит самое сложное уже позади: GGUF загружен, qwen4exp поддерживается, CPU/GPU offload работает, а OpenAI‑compatible API доступен.

Часть 6. DeepSeek Harness

DeepSeek Harness, или DSH, — локально запускаемая агентная среда DeepSeek. Сам проект сейчас распространяется как developer preview и построен вокруг плагинной архитектуры: модели, инструменты, sandbox, storage, workflows и другие возможности представлены как плагины.

Запустить Web‑интерфейс можно:

npx @deepseek-ai/dsh web

или после глобальной установки:

npm install -g @deepseek-ai/dsh
dsh web

По умолчанию Web UI доступен по адресу:

http://127.0.0.1:3080

При необходимости порт можно изменить:

dsh web --port 8080

Это официально предусмотрено CLI DSH.

Часть 7. Подключаем llama.cpp к DSH

Для этого существует сторонний плагин:

dsh-local-llm-controller

Он предназначен именно для запуска и остановки llama-server из интерфейса DeepSeek Harness.

Установка:

dsh plugin --profile web add dsh-local-llm-controller

Если dsh не находится в PATH:

npx @deepseek-ai/dsh plugin --profile web add dsh-local-llm-controller

После установки необходимо перезапустить Web UI DSH. Плагин появится в:

Settings → Plugins → Local LLM Controller

Плагин позволяет задать каталог llama.cpp, порт, каталог модели и набор параметров запуска. В текущей версии также используются два слота моделей A/B.

Важный нюанс Linux

Текущая документация dsh-local-llm-controller ожидает исполняемый файл с именем:

llama-server.exe

Это явно указано в настройках плагина.

На Linux нормальный файл называется:

llama-server

В моём случае проблему решило создание символической ссылки:

ln -s ~/.local/bin/llama-server ~/.local/bin/llama-server.exe

После этого плагин мог находить нужный executable.

Это именно workaround для текущего плагина, а не особенность llama.cpp: сам llama.cpp на Linux штатно использует обычный llama-server.

Настройка плагина

В Local LLM Controller необходимо указать:

llama.cpp directory

Каталог, в котором расположен сервер:

/home/user/.local/bin

или соответствующий путь вашей установки.

Port

Например: 5555

Плагин использует этот порт при добавлении локальной модели в список DSH.

Slot A / Slot B

В качестве каталога модели удобно использовать (по крайней мере, я так сделал):

/home/user/GGUF/qwen-flash-next/

Я рекомендую использовать абсолютный путь, а не ~/GGUF/.... Это избавляет от лишних проблем с различиями в обработке путей GUI‑плагинами.

После сохранения конфигурации плагин обнаруживает GGUF‑файлы внутри каталога и позволяет выбрать нужный файл.

Launch args

Для моей конфигурации базовый набор выглядел так:

-c 16384
-b 2048
-ub 1024
-np 1
--cache-type-k q8_0
--cache-type-v q8_0

Параметры -m, --host, --port и некоторые служебные параметры добавляются самим плагином, поэтому вручную их задавать не нужно.

А что насчёт ‑ngl и ‑n-cpu‑moe?

Здесь есть важное уточнение.

В первоначальном эксперименте я сознательно отказался от ручной настройки:

-ngl 999

и:

--n-cpu-moe ...

потому что именно с конкретной комбинацией этих параметров получал ошибки нехватки VRAM.

Но это не означает, что данные параметры несовместимы с Qwen3.8-Flash‑Next или вообще не должны использоваться.

Наоборот, современный llama.cpp прямо предоставляет:

-ngl

для управления количеством offload‑слоёв и:

--n-cpu-moe N

для размещения MoE‑экспертов первых N слоёв на CPU.

На более мощных системах ручная настройка --n-cpu-moe может быть полезна. Для GTX 1080 Ti в моей исходной конфигурации, я предпочёл начать с автоматического размещения и уже от него проводить эксперименты.

Это важное практическое правило: не переносите значения -ngl и --n-cpu-moe с другой видеокарты один в один.

Часть 8. Производительность

На моей системе:

Это результаты конкретной конфигурации, а не универсальные характеристики Qwen3.8-Flash‑Next.

На скорость очень сильно влияют процессор, пропускная способность RAM, VRAM, выбранная квантовка, число CPU‑offloaded experts, контекст и параметры llama.cpp.

Например, современные эксперименты (по описанию их авторов) на RTX 4090 показывают уже существенно более высокие значения, а конфигурации с 24 GB VRAM и 64 GB RAM позволяют использовать --n-cpu-moe для гибридного размещения.

Поэтому цифра «11 tok/s» интересна прежде всего как доказательство того, что сама схема работает на GTX 1080 Ti. Да и меня, такая скорость устраивает, а покупать новую видеокарту, как доказано некоторыми авторами здесь на Хабре, не рентабельно, если у Вас не стоит задача обеспечить конфиденцальность данных (лучше потратить «ваши денежки» на токены у облачных провайдеров LLM).

Часть 9. Почему 256K контекст не означает, что нужно сразу ставить 256K

Qwen3.8-Flash‑Next имеет нативный контекст 262 144 токена.

Но это вовсе не означает, что на любой системе стоит сразу запускать:

-c 262144

В архитектуре модели действительно большая часть слоёв использует GDN, которое эффективно поддерживает состояние истории, а QSA ограничивает объём используемого контекста с помощью sparse‑индейсера. Но память и производительность всё равно зависят от состояния модели, KV/cache‑структур и конкретной реализации backend.

Кроме того, в текущей реализации llama.cpp уже обнаруживались проблемы на границе полного 262144-контекстного окна, причём на некоторых конфигурациях это не OOM, а ошибки CUDA/kernel или деградация поведения.

Поэтому для старой 11-гигабайтной видеокарты разумнее начинать с:

16K

затем экспериментировать с:

32K
64K
128K

и только после этого пытаться использовать весь заявленный контекст. На моей видеокарте нормально «тянет» 64k, больше устанавливать не стал, потому что чем больше контекст, тем больше время работы LLM....

Часть 10. Почему модель может долго «думать»

Qwen3.8-Flash‑Next поддерживает reasoning. Это означает, что даже простой вопрос может приводить к генерации внутреннего рассуждения.

При этом важно различать две совершенно разные вещи:

thinking/reasoning

и

preserving reasoning in conversation history

Параметр:

--no-reasoning-preserve

относится именно ко второму. Он не выключает reasoning как таковой. В текущей документации llama.cpp он описывается как управление сохранением reasoning‑трассы в полной истории.

Поэтому первоначальное утверждение, что:

--no-reasoning-preserve отключает reasoning и в 2–3 раза ускоряет модель

следует считать некорректным.

На практике нужно отдельно управлять самим reasoning и отдельно решать, сохранять ли результат рассуждения в истории.

В DeepSeek Harness для модели Qwen3.8-Flash‑Next есть настройка требуемого уровня размышления (прямо в меню выбора модели)

Часть 11. Переключение reasoning

В старых и некоторых промежуточных сборках llama.cpp использовался такой механизм:

"chat_template_kwargs": {    "enable_thinking": false
}

Например:

curl -s http://127.0.0.1:55555/v1/chat/completions   -H "Content-Type: application/json"   -d '{    "model": "slot-a",    "messages": [      {        "role": "user",        "content": "2+2"      }    ],    "max_tokens": 50,    "chat_template_kwargs": {      "enable_thinking": false    }  }'

Однако для современной ветки llama.cpp это уже нельзя считать стабильным универсальным API: в новых сборках данный способ управления enable_thinking переводится в deprecated‑состояние, а сервер предлагает использовать собственные reasoning‑параметры, включая --reasoning, --reasoning-effort и --reasoning-budget.

Поэтому при написании собственного клиента или ассистента вроде Gogitor лучше не зашивать единственный вариант управления reasoning, а ориентироваться на конкретную версию llama.cpp и её /v1 API.

Часть 12. Что получилось в итоге

После настройки схема выглядит так:

    ┌─────────────────────┐ 
    │ Qwen3.8-Flash-Next  │ 
    │      ≈176B class    │ 
    │   UD-Q4_K_XL ≈111GB │ 
    └──────────┬──────────┘ 
               │            
           llama.cpp
               │ 
 ┌──────────────┴──────────────┐
 │                             │ 
 |          GTX 1080 Ti        |
 |           RAM / CPU         |
 |             11 GB           |
 |             64 GB           |
 │                             │
 └──────────────┬──────────────┘
                │                
           llama-server 
                │
      OpenAI-compatible API
                │        
                ▼
     DeepSeek Harness (DSH)

И самое интересное здесь — то, что для запуска модели совершенно не требуется помещать все 111 GB весов в VRAM.

MoE‑архитектура и hybrid CPU/GPU execution позволяют использовать видеокарту в качестве ускорителя, а основную массу модели хранить в оперативной памяти и использовать по мере необходимости.

Что работает

В моей конфигурации удалось получить:

• запуск Qwen3.8-Flash‑Next;

• работу модели через OpenAI‑compatible API;

• сохранение контекста между запросами;

• работу с DSH;

• агентные сценарии;

• tool calls;

• reasoning;

• локальный запуск без Ollama;

• работу на GTX 1080 Ti с 11 GB VRAM.

Что работает неидеально

Скорость

Около 11 tok/s для decode — это далеко от комфортного интерактивного чата.

Ответ на несколько сотен токенов может занимать десятки секунд, при первом обращении и минут.

Первый запрос

Большой системный prompt обрабатывается заметно дольше обычной небольшой локальной модели.

CPU/RAM становятся частью вычислительной системы

В такой конфигурации производительность зависит не только от GPU.

Фактически в работу модели входят:

GPU bandwidth
      +
CPU performance
      +
RAM bandwidth
      +
    VRAM
      +
SSD performance

Последнее особенно важно для новых способов offload и lazy loading больших n‑gram/PLE таблиц.

Что можно улучшить

1. Более мощная видеокарта

На GPU с 24 GB VRAM появляется значительно больше пространства для размещения экспертов и других частей модели.

Тесты сообщества показывают, что 24 GB GPU вместе с достаточным объёмом RAM уже позволяет получать значительно более высокую производительность, чем в конфигурации с GTX 1080 Ti.

Но конкретные значения сильно зависят от квантовки и параметров offload.

2. Настройка ‑n-cpu‑moe

Это один из основных инструментов тонкой настройки современных MoE‑моделей в llama.cpp.

Например, для одной конфигурации может быть оптимально:

--n-cpu-moe 40

а для другой:

--n-cpu-moe 30

и это будет зависеть от количества VRAM, RAM и пропускной способности памяти.

3. Более компактная квантовка

UD-Q4_K_XL — довольно крупная квантовка, но она одновременно предоставляет лостаточный уровень «ума» и скорости (по этому рекомендую....). Для машин с ограниченной RAM можно рассматривать более компактные варианты:

UD-Q3_K_XL
UD-IQ3_XXS
UD-IQ2_K_XL
UD-IQ1_M
UD-IQ1_S

Существуют варианты заметно меньше 111 GB. Например, опубликованные GGUF‑кванты доходят примерно до 72–75 GB для самых компактных вариантов.

Цена за это, как сказано выше — снижение качества.

А нужен ли вообще DeepSeek Harness?

Если задача состоит просто в том, чтобы поговорить с моделью, DSH здесь необязателен.

Достаточно:

Qwen3.8-Flash-Next 
       ↓   
   llama.cpp   
       ↓  
  llama-server
       ↓ 
OpenAI-compatible API

DSH или иная программа (как пример: OpenCode или аналоги), интересны уже на следующем уровне — когда нужна агентная среда, инструменты, работа с файлами, shell, workflow и многошаговое выполнение задач. Сам DeepSeek описывает Harness именно как extensible agent runtime, где модель, инструменты и другие возможности являются плагинами.

Именно поэтому комбинация:

Qwen3.8-Flash-Next
       +
  llama.cpp
       +
DeepSeek Harness

получается интереснее, чем просто запуск модели в локальном чате и эту связку я уже тестирую на своих задачах.

Несколько практических выводов

1. Большой MoE ≠ необходимость иметь столько же VRAM

176B‑класс модели не означает, что вам требуется 176 GB VRAM.

В данном случае основная модель — 125B, ещё около 51B параметров приходится на n‑gram embedding‑таблицы, а активируется около 6B параметров на токен. Архитектура специально рассчитана на значительное снижение вычислительной стоимости относительно полного dense‑моделя такого размера.

2. 11 GB VRAM действительно могут быть достаточны

Но слово «достаточны» здесь означает:

«модель можно запустить»

а не:

«модель будет работать быстро».

Это две совершенно разные задачи.

3. RAM становится второй памятью модели

При конфигурации 11 GB VRAM + 64 GB RAM модель уже нельзя рассматривать как «GPU‑модель».

Это скорее гибридный вычислительный комплекс:

GPU
 +
CPU
 +
RAM
 +
SSD

4. llama.cpp здесь оказался важнее Ollama

Для необычных архитектур ранняя поддержка часто появляется сначала непосредственно в llama.cpp.

В случае Qwen3.8-Flash‑Next поддержка qwen4exp была добавлена непосредственно в llama.cpp 27 августа 2026 года.

Ollama при этом могла использовать собственные backend'ы и собственную версию интегрированного llama.cpp, поэтому появление модели в каталоге Ollama вовсе не означает автоматическую поддержку того же GGUF на Linux/NVIDIA.

Итог

Запустить Qwen3.8-Flash‑Next на GTX 1080 Ti оказалось возможно.

Причём речь идёт не о какой‑то специально урезанной версии, а о GGUF‑кванте размером около 111 GB, который содержит модель 176B‑класса:

125B main model
      +
51B n-gram embeddings
    ≈176B

при примерно 6B активных параметрах на токен.

Конфигурация:

GTX 1080 Ti 11 GB
      +
Core i9-9900K
      +
64 GB RAM

оказалась способна запустить модель примерно на:

11 tok/s decode
19 tok/s prefill

Это не тот результат, ради которого стоит выбрасывать современную видеокарту и срочно покупать GTX 1080 Ti, это для тех, кто не хочет обновлять свой компьютер ради «попробовать ИИ у себя дома».

Но это отличный пример того, насколько далеко ушли современные MoE‑архитектуры и runtime'ы вроде llama.cpp.

Ещё несколько лет назад идея запустить модель такого класса на 11-гигабайтной видеокарте выглядела бы практически абсурдной. Сейчас это уже вопрос правильного offload, квантовки и терпения.

А если поверх llama.cpp добавить DeepSeek Harness, получается уже не просто локальная LLM, а полноценная агентная среда, где огромная модель может использоваться для многошаговой работы, программирования и инструментальных задач.

И всё это — на видеокарте, которая появилась на рынке почти десять лет назад.