OpenClaw 120B на трёх ноутбуках: как размазать гиганта по домашнему железу

Когда один компьютер плачет, а три — уже думают

OpenClaw-120B — это не просто очередная большая языковая модель. Это инструмент для автономных агентов, который умеет вызывать функции, работать с API и выполнять сложные цепочки действий. Проблема в том, что 120 миллиардов параметров требуют примерно 240 ГБ памяти в FP16. Даже если у вас есть RTX 4090 с 24 ГБ VRAM, этого катастрофически мало.

Типичная ситуация: у вас есть основной ПК с RTX 3090 (24 ГБ), ноутбук с RTX 4060 (8 ГБ) и старый сервер с 128 ГБ RAM. По отдельности каждый из них беспомощен против 120B модели. Но вместе они могут запустить OpenClaw с приличной скоростью генерации.

Три подхода к распределению: что выбрать?

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

1 Chunking через llama.cpp: когда слои летают по сети

Это самый прямой способ. Вы буквально делите модель на куски и загружаете каждый кусок на отдельное устройство. llama.cpp с версии 0.3.0 (актуальной на февраль 2026) поддерживает распределённую загрузку через параметр --split.

Сначала подготовьте модель в формате GGUF. OpenClaw обычно поставляется в формате Safetensors, так что конвертация обязательна:

# Конвертация в GGUF (делается один раз на главном ПК)
python convert.py openclaw-120b/ --outtype q4_0 --outfile openclaw-120b-q4_0.gguf

# Проверка размера
ls -lh openclaw-120b-q4_0.gguf
# ~60 ГБ для квантования Q4_0

Теперь самое интересное — запуск распределённо. Предположим, у вас три машины:

• Главная (192.168.1.100) — RTX 3090 24 ГБ
• Вторая (192.168.1.101) — RTX 4060 8 ГБ + 32 ГБ RAM
• Третья (192.168.1.102) — только CPU с 64 ГБ RAM

На главной машине запускаем сервер:

# На главной (192.168.1.100)
./llama-server \
  --model openclaw-120b-q4_0.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  --split 0:24  # Первые 24 слоя на GPU0 (RTX 3090)
  --ctx-size 8192

На второй машине подключаемся к главной и добавляем свои слои:

# На второй (192.168.1.101)
./llama-worker \
  --host 192.168.1.100 \
  --port 8080 \
  --split 24:40  # Слои 24-40 на этой машине
  --gpu-layers 16  # 16 слоёв на GPU (остальные в RAM)

На третьей машине забираем оставшиеся слои:

# На третьей (192.168.1.102)
./llama-worker \
  --host 192.168.1.100 \
  --port 8080 \
  --split 40:80  # Слои 40-80 на CPU
  --threads 16

2 Sliding window: когда контекст не помещается

А вот это уже хитрее. Sliding window не делит модель, а делит контекст. Представьте, что у вас есть документ на 50 тысяч токенов, но каждая из ваших машин может обрабатывать только 8 тысяч. Вы разбиваете документ на перекрывающиеся окна и отправляете каждое окно на отдельную машину.

Для OpenClaw это особенно актуально, потому что агентные рабочие процессы часто включают длинные истории взаимодействий. Один только лог переписки с пользователем может занимать 20-30 тысяч токенов.

Реализация через vLLM (версия 0.4.2 на февраль 2026):

# orchestrator.py
from vllm import SamplingParams
import asyncio
from typing import List

class SlidingWindowDistributor:
    def __init__(self, workers: List[str], window_size: int = 8000, overlap: int = 200):
        self.workers = workers  # Список URL: ["http://192.168.1.100:8000", ...]
        self.window_size = window_size
        self.overlap = overlap  # Перекрытие для контекста
    
    async def process_long_context(self, prompt: str) -> str:
        tokens = self.tokenize(prompt)
        windows = []
        
        # Разбиваем на окна
        for i in range(0, len(tokens), window_size - overlap):
            window = tokens[i:i + window_size]
            windows.append(window)
        
        # Распределяем окна по воркерам
        tasks = []
        for idx, window in enumerate(windows):
            worker_idx = idx % len(self.workers)
            task = self.send_to_worker(self.workers[worker_idx], window)
            tasks.append(task)
        
        results = await asyncio.gather(*tasks)
        
        # Собираем результаты (здесь нужна логика агрегации)
        return self.aggregate_results(results, overlap)

# На каждом воркере запускаем отдельный vLLM инстанс
# vllm serve openclaw-120b --port 8000 --gpu-memory-utilization 0.9

Проблема sliding window в том, что OpenClaw может терять контекст между окнами. Особенно критично для tool calling — если описание функции разорвано между окнами, модель не поймёт, как её вызывать. Поэтому overlap (перекрытие) должно быть достаточно большим — минимум 200-500 токенов.

3 MCP-оркестрация: когда каждый инструмент живёт отдельно

А вот это самый элегантный способ для OpenClaw. Model Context Protocol (MCP) — это стандарт, который позволяет моделям вызывать инструменты. OpenClaw из коробки умеет работать с MCP-серверами.

Идея простая: вместо того чтобы гонять всю модель по сети, мы запускаем несколько инстансов OpenClaw поменьше (например, 7B или 13B версии) на разных машинах, и каждый специализируется на своём типе инструментов.

Архитектура выглядит так:

# mcp-orchestration.yaml
services:
  orchestrator:
    image: openclaw-13b:latest  # Лёгкая модель для роутинга
    gpu: "device=0"  # Главный ПК
    environment:
      - MCP_SERVERS=code_worker,web_worker,db_worker
  
  code_worker:
    image: openclaw-7b-coder:latest  # Специализированная на коде
    gpu: "device=0"  # Второй ПК
    command: ["mcp-server", "--tools", "python,javascript,bash"]
  
  web_worker:
    image: openclaw-7b-web:latest  # Для веб-запросов
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    command: ["mcp-server", "--tools", "fetch,scrape,parse"]
  
  db_worker:
    image: openclaw-7b-db:latest  # Для работы с базами
    gpu: "device=1"  # Третий ПК
    command: ["mcp-server", "--tools", "sqlite,postgres,redis"]

Когда пользователь просит: "Найди информацию о X, проанализируй код и сохрани в БД", orchestrator разбивает запрос на части:

1. web_worker ищет информацию
2. code_worker анализирует найденные примеры кода
3. db_worker сохраняет результаты

Преимущество в том, что каждая модель загружена только на одном устройстве и не требует синхронизации слоёв через сеть. Недостаток — нужны специализированные версии OpenClaw (или fine-tuning).

Что выбрать для своего железа?

Давайте на чистоту. Если у вас:

• Однородные видеокарты (3x RTX 3090) — chunking через llama.cpp даст максимальную скорость
• Разное железо (GPU + CPU + мало RAM) — sliding window более гибкий
• Агентные рабочие процессы с чёткими этапами — MCP-оркестрация идеальна

Я в своей практике чаще комбинирую подходы. Например, основной инстанс OpenClaw-120B запускаю через chunking на двух мощных ПК, а для специфичных инструментов поднимаю MCP-сервера с маленькими моделями на остальных машинах.

Типичные грабли, на которые все наступают

1. Разное квантование на разных устройствах

Самая дурацкая ошибка. Вы квантуете модель в Q4_0 для первого ПК, в Q4_K для второго, а потом удивляетесь, почему inference падает. Все устройства должны использовать одинаковую схему квантования. Золотой стандарт на 2026 год — Q4_K_M для баланса скорости и качества.

2. Забыли про overlap в sliding window

Берут window_size 8000, overlap 50. Результат — модель теряет контекст между сегментами, tool calling ломается. Для OpenClaw минимальный overlap — 200 токенов. А лучше 500, если в контексте есть описания функций.

3. Сетевые задержки убивают chunking

Запустили распределённый inference через Wi-Fi с пингом 50 мс. Каждый токен теперь проходит через 3 устройства, добавляя 150 мс задержки. Скорость падает с 5 токенов в секунду до 1.5. Проводной Ethernet обязателен. Или Wi-Fi 6E с пингом <10 мс.

4. MCP-сервера без health check

Запустили 5 MCP-серверов на разных машинах. Один упал, а orchestrator продолжает слать ему запросы. Результат — таймауты и сломанные цепочки. Всегда добавляйте health check эндпоинты и механизмы ретраев.

Мой стек для продакшена

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

• Основная модель: OpenClaw-120B-Q4_K_M.gguf
• Orchestrator: FastAPI + Redis для кеширования промежуточных результатов
• Транспорт: gRPC вместо HTTP для chunking (меньше оверхеда)
• Мониторинг: Prometheus + Grafana для отслеживания загрузки каждого устройства
• Фолбэк: OpenClaw-13B на одной машине на случай сбоя распределённого режима

Скрипт запуска выглядит так:

#!/bin/bash
# start_openclaw_cluster.sh

# Запускаем основной сервер на главной машине
ssh user@192.168.1.100 "./llama-server --model openclaw-120b-q4_k_m.gguf --host 0.0.0.0 --port 50051 --split 0:40 --grpc" &

# Воркер на второй машине
ssh user@192.168.1.101 "./llama-worker --host 192.168.1.100 --port 50051 --split 40:70 --gpu-layers 20" &

# Воркер на третьей машине (CPU only)
ssh user@192.168.1.102 "./llama-worker --host 192.168.1.100 --port 50051 --split 70:80 --threads 32" &

# MCP-сервера для специализированных инструментов
ssh user@192.168.1.101 "docker run --gpus all mcp/code-server" &
ssh user@192.168.1.102 "docker run mcp/db-server" &

# Оркестратор
python orchestrator.py --mode hybrid  # Использует и chunking, и MCP

Что будет дальше?

К концу 2026 года ожидаю появления нативных решений для распределённого запуска OpenClaw. Anthropic уже экспериментирует с протоколом, где разные слои модели могут мигрировать между устройствами в реальном времени в зависимости от нагрузки.

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

Главный совет напоследок: начните с малого. Возьмите OpenClaw-7B, распределите её между двумя ноутбуками, поймите принципы. Потом переходите к 120B. Иначе рискуете потратить неделю на настройку, только чтобы обнаружить, что сеть между ПК — узкое горлышко.

А если хочется экзотики — попробуйте запустить OpenClaw частично на GPU, частично на NPU (как в AMD Strix Halo). Об этом есть отдельная статья про Strix Halo. Но это уже для тех, кто любит боль и страдания.