Обновить
3

Enterprise search

Отправить сообщение

Мини-отчет мак-чайника: поставил через brew mlx-serve, загрузил пару моделей через UI (text, stt/tts, image, video). Офигел - всё работает и быстро! tps > 100! prefill - 2000!

❯ tool-eval-bench --base-url http://192.168.2.76:11234  --hardmode --parallel 3
🏆 Benchmark Complete
│    Model:  ddalcu/Qwen3.8-Flash-Next-MLX-Serve-mixed-4-8bit                                                                            │
│    Score:  93 / 100                                                                                                                    │
│    Rating: ★★★★★ Excellent                                                                                                             │
│    Benchmark: tool-eval-bench v2.7.0                                                                                                   │
│    Max context:  524,288 tokens                                                                                                        │
│                                                                                                                                        │
│    ✅ 77 passed   ⚠️  8 partial   ❌ 3 failed                                                                                          │
│    Points: 162/174                                                                                                                     │
│    ⚠  1 scenario(s) excluded (infrastructure failure), completion rate 98.9%                                                           │
│         TC-45                                                                                                                          │
│                                                                                                                                        │
│    Quality:        93/100                                                                                                              │
│    Responsiveness: 42/100  (median turn: 3.7s)                                                                                         │
│    Deployability:  78/100  (α=0.7)                                                                                                     │
│    Weakest: O Structured Output (75%)                                                                                                  │
│                                                                                                                                        │
│    Completed in 473.9s                                                                                                                 │
│                                                                                                                                        │
│    📊 Token Usage:                                                                                                                     │
│    Total: 560,487 tokens  │  Efficiency: 0.3 pts/1K tokens

Похоже допилили этот фрейморк. Молодцы.

ГПТ не остановить:

Для AgentMux вашу связку нужно разложить так:

Pi             → непосредственно выполняет задачу
tmux           → держит процессы и терминалы живыми
Pi Intercom    → Pi-сессии находят друг друга, отправляют сообщения,
                 задают вопросы и ждут ответы

AgentMux пытается заменить tmux + Pi Intercom одной программой, а Pi оставить внутри.

Что именно он делает вместо них

1. Вместо tmux — собственные окна и запуск процессов

Вместо:

tmux new-window -n planner 'pi'
tmux new-window -n reviewer 'pi'

вы создаёте две панели AgentMux. Он сам запускает процессы Pi. По умолчанию используется:

pi --json

AgentMux читает машинный поток Pi и самостоятельно рисует сообщения, вызовы инструментов и изменения файлов. Это не обычный интерактивный интерфейс Pi, показанный внутри терминала. Аналогично он запускает Claude Code, Codex, Gemini и другие CLI. (AgentMux Docs)

То есть здесь:

tmux pane + обычный Pi TUI

заменяется на:

AgentMux pane + Pi в машинном режиме + интерфейс AgentMux

2. Вместо Pi Intercom — MuxBus

AgentMux регистрирует агентов по именам и позволяет отправлять им сообщения.

Есть два основных варианта:

inject

— немедленно записать текст в stdin чужого агента;

message

— оставить сообщение в почтовом ящике, чтобы агент забрал его асинхронно.

MuxBus может связывать разные AgentMux-процессы на одной машине, в локальной сети и через отдельно настроенный WAN-relay. (AgentMux Docs)

Например:

Pi-planner
    ↓ SendMessage
Codex-reviewer

В отличие от Pi Intercom, получателем может быть не только Pi.

3. Добавляет хранилище конфигураций

Для каждого именованного агента AgentMux может хранить:

  • используемый harness и модель;

  • инструкции;

  • MCP-серверы;

  • skills;

  • переменные окружения;

  • привязанные credentials;

  • историю и собственные memory-файлы.

После этого можно повторно открыть условного backend-reviewer с теми же настройками. (AgentMux Docs)

4. Добавляет очередь и расписание

AgentMux имеет встроенную очередь заданий:

положить задачу в очередь
→ свободный агент забирает её
→ продлевает lease во время работы
→ помечает выполненной

Также есть cron-задачи, которые периодически отправляют prompt определённому агенту. Агент может через API открыть редактор, запустить фоновый shell-процесс или создать новую панель. (AgentMux Docs)

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

Что ваша связка уже делает лучше

Общение Pi ↔ Pi

У Pi Intercom есть настоящий блокирующий протокол:

intercom({
  action: "ask",
  to: "reviewer",
  message: "Можно менять публичный API?"
})

Вызывающий Pi останавливается, ждёт reply, получает ответ как результат tool call и продолжает текущий turn с этим ответом в контексте. Сообщения сохраняются в истории Pi. (GitHub)

В документированном API AgentMux есть SendMessage и непосредственный inject, но аналогичного встроенного блокирующего ask → reply → результат tool call я не вижу. Для такого поведения придётся самостоятельно договариваться о сообщениях-ответах или писать дополнительную логику.

Поэтому для Pi ↔ Pi Pi Intercom выглядит более специализированным и удобным.

Переживание SSH-разрыва

tmux специально построен как отдельный сервер: клиент отключается, а сессия и процессы продолжают работать; позже к ним можно подключиться снова. (GitHub)

AgentMux документирован как desktop-приложение, запускающее CLI как собственные дочерние процессы. Это не та же архитектура, что отделяемый сервер tmux. Поэтому не следует считать, что закрытие AgentMux эквивалентно tmux detach: гарантии сохранения живого процесса после полного закрытия приложения в документации нет. (AgentMux Docs)

Простота

Ваша система:

tmux
Pi
маленький локальный broker Pi Intercom

AgentMux — приложение с launcher, backend-sidecar, Chromium/CEF-интерфейсом, базой данных, собственным RPC, адаптерами harness-программ и MuxBus. Сам проект предупреждает, что находится в ранней alpha-стадии, возможны поломки, потеря состояния и несовместимые изменения. (AgentMux Docs)

Что AgentMux действительно даёт сверх вашей связки

Он имеет смысл при таких требованиях:

Pi-planner
Claude-implementer
Codex-reviewer
Gemini-researcher

И вы хотите:

  • адресовать их через один канал сообщений;

  • видеть tool calls и diff в одном GUI;

  • использовать единый API open / send / stop / status / output;

  • хранить профили, инструкции, MCP и credentials централизованно;

  • отправлять сообщения между машинами;

  • иметь встроенную очередь и cron.

Pi Intercom ограничен Pi-сессиями на одной машине. (GitHub)

Итог

Для вашего случая:

несколько локальных Pi
+ tmux
+ Pi Intercom

AgentMux не закрывает важную отсутствующую функцию. Он преимущественно заменяет вашу простую терминальную систему более тяжёлым графическим приложением.

Он становится полезным, когда главная задача уже другая:

связать разные CLI-агенты общим интерфейсом, каналом сообщений, конфигурацией, очередью и расписанием.

Поэтому AgentMux можно назвать meta-harness в техническом смысле: он приводит разные CLI к общим операциям запустить / отправить сообщение / показать вывод / остановить.

Но он не является «AI-руководителем»: он не решает самостоятельно, кому поручить задачу, как проверить результат и когда переделывать. Его документация прямо говорит, что панели независимы и контекст между агентами не передаётся, пока вы сами их явно не свяжете. (AgentMux Docs)

ГПТ сравнил:

В вашем сценарии Herdr, скорее всего, не нужен.

Связка уже закрывает основные задачи:

tmux          → процессы Pi не умирают, есть окна и панели
Pi Intercom   → сессии находят друг друга и обмениваются сообщениями
Pi            → выполняет задачи
вы/инструкции → определяете, кто кому что поручает

Pi Intercom умеет не просто печатать текст в чужой терминал. У него есть локальный broker, список активных Pi-сессий, их состояния, адресные send, блокирующие ask/reply, доставка сообщений в контекст получателя и возможность автоматически запустить новый turn. (GitHub)

Например:

Pi-planner:
  intercom.ask(worker, "Реализуй retry и сообщи результат")

Pi-worker:
  выполняет работу
  intercom.reply(planner, "Готово, тесты проходят")

Это уже гораздо ближе к реальному взаимодействию агентов, чем возможности Herdr.

Что изменится при установке Herdr

Herdr заменит эту часть:

tmux

на:

Herdr server

И добавит внешний API:

herdr agent start ...
herdr agent prompt ...
herdr agent wait ...
herdr agent read ...

То есть внешний скрипт сможет сказать:

запусти Pi
отправь ему текст
дождись idle или blocked
прочитай экран

Также Herdr собирает состояния агентов в одном интерфейсе: какой работает, какой ждёт подтверждения, какой закончил. (Herdr)

Но для общения Pi ↔ Pi вам всё равно полезнее Pi Intercom. Herdr сам по себе не предоставляет такой же нормальный протокол send / ask / reply с доставкой непосредственно в контекст Pi.

Сравнение без абстрактных слов

(ппц, таблицу приходится как скриншот вставлять)

Где Herdr всё же может пригодиться

Допустим, у вас одновременно работают:

Pi
Claude Code
Codex
Gemini CLI
OpenCode

Pi Intercom связывает только Pi-сессии. Herdr может показать все эти процессы в одном списке и дать внешнему скрипту одинаковые команды:

запустить
отправить prompt
дождаться остановки
прочитать результат

То есть его преимущество — унифицированное внешнее управление разными CLI, а не более качественное общение агентов.

Итог

Для вашей конфигурации:

несколько Pi + tmux + Pi Intercom

Herdr преимущественно дублирует tmux и часть отображения состояний.

Он нужен только при конкретной дополнительной потребности:

«Я хочу управлять Pi, Claude Code, Codex и другими CLI одним внешним API и видеть их состояния в единой панели».

Без этой потребности переходить с tmux на Herdr особого смысла нет. Более того, документация Pi Intercom прямо рассматривает Herdr лишь как опциональный способ открыть новую Pi-панель, когда подходящей сессии ещё нет; сама связь между Pi-сессиями от Herdr не зависит. (GitHub)

Было бы интересно, если бы вы сравнили этот “харнес харнесов” Herd со связкой tmux + Pi+pi-intercom

Попробуйте тот самый read-запрос к панели

С удовольствием! А какой end-point? )

Вот это меня и останавливает пока от Агента. Чую одним местом в какое “допиливание” это выйдет.

Купить Mac Studio на 512 ГБ за 15 тысяч долларов

Вообще-то подержанная ультра м3 на 512к уже давно за 20к перевалила. Если найти вообще.

Теперь у меня небольшие приложения на Go

Харнесы, прости хоспади, для харнеса. И сколько времени понадобилось для вайб-кодинга / вайб-дебагинга? Вы же не ручками писали эти приложения?

Да более-менее бесполезно. В реальной жизни, не на тестах, прибавка - 2-3 т/с. That was a nice try :(

Я забыл замерить, но кажется, тут почему-то быстрее нашлось решение. Но не намного. Хотя, по замерам бенчей, этот Призма-квант быстрее всех токены генерит: до 30 в сек доходит.

Update: приношу королю свои извинения.

— Не виноватая я! Это всё корявый квант!..

Запустил модель с порядочным квантом: Qwen/Qwen3.8-27B-FP8, ответ стал нормальным:

Evidence chain:

  1. pstore/ramoops (/var/lib/systemd/pstore/console-ramoops-0) — the crashed boot’s last kernel console ends in an OOM storm at T+9.7h:

    • pi invoked oom-killer, Out of memory: Kill process 3721 (MainThread) score 510, victims: telegraph-mcp-p, MainThread (1.2GB vms), V8Worker

    • the memory hogs were the AI agent stack itself: pi sessions + MCP servers + litellm + docker on a 4GB box

В своё оправдание: этот призма-квант мне самый красивый двойной, горизонтальный (и рабочий) тетрис сгенерировал. Как говорится: не тот порядочный квант, что блестит. Хотя… кто его знает - может этот FP8 запуск что-то в прошлой сессиии Sol подглядел. Я, правда, постарался почистить. Но он не признаётся, пишет, что “всё сам!” 😄

Поиграл с “королём” в troubleshooting: микро-PC (типа Расбери) ребутнулся. Я озадачил rdtand/Qwen3.8-27B-PrismaAQUA-5.5bit-vllm (xhigh) и gpt-5.6-sol провести разбор полётов.

  • “Король” после 40 минут:

Prime suspect (moderate confidence) Kernel-side wedge under full-memory LLM load: 27B-class models (MixedInt4 / NVFP4 evals, PrismaQuant) ran on this 4 GB Nano last 2 days — 5–20 GB of model vs 4 GB DRAM + 2 GB zram swap…

  • Sol (5 мин):

Jetson перезагрузился из-за исчерпания оперативной памяти. Ядро трижды запустило OOM killer (Out Of Memory killer — механизм Linux, завершающий процессы при нехватке памяти), но Pi и его дочерние роцессы имели oom_score_adj=-1000 и не могли быть выбраны жертвой. Система перестала отвечать, после чего аппаратный watchdog перезапустил плату.

Король, превед! 😂 Но удалять пока не буду… Может пригодится.

Он нас опередил: сам музон встроил в Тетрис, только я пока не понял откуда звуки берутся :)

А я попросил модельку, как профессионального UI дизайнера и художника, нарисовать качественного Чебурашку (мой любимый ЧебурБЕНЧ).

Результат через полчаса

не за что! Вот, только что тест закончился на 512к:

90% контекста проверено:

 - 471 858 токенов
 - заполнение ровно 90.0%
 - exact retrieval: pass
 - prefill: 736.2 с
 - весь запрос: 741.8 с
 - эффективная скорость: 636 ток/с
monitoring 500k prefill
Заполнение и генерация
Заполнение и генерация

Вот тут обсуждаем потихоньку: https://habr.com/ru/articles/1070694/

А промпт, где нормальный ответ был: Be concise, dude

Да уже все на 3.8 переходят :)

qwen-3.8-27b-unsloth-nvfp4

Рассуждение заняло 52 секунд(ы)

Поедем на машине. Мойка — для машины, а не для твоих кроссовок. Пойдёшь пешком — через 50 метров огонит осознание, что рыхлая железная тварь стоит дома и требует, потом ещё 50 метров назад. На авто эти 50 метров — полминуты и одно свободное место у въезда. Сел, завёл, поехал.

Читал ИИ, долго думал…

П.С. Квин - для кода, для “пофилосовствовать” - Гемма-4

П.П.С. с более адекватным system-prompt:

Рассуждение заняло 32 секунд(ы)

На машине — моется же машина, а не ты. 🚗

recipe
---
recipe_version: "1"
name: Qwen3.8-27B-Unsloth-NVFP4-TP2-Service
summary: Unsloth Qwen 3.8 27B Dynamic V3 NVFP4 with 512K YaRN context
model: unsloth/Qwen3.8-27B-NVFP4
container: vllm/vllm-openai:v0.27.1
cluster_only: true
solo_only: false

defaults:
  port: 8040
  host: 0.0.0.0
  tensor_parallel: 2
  gpu_memory_utilization: 0.55
  max_model_len: 524288
  max_num_batched_tokens: 16384
  max_num_seqs: 5

env:
  VLLM_ALLOW_LONG_MAX_MODEL_LEN: "1"
  VLLM_BLOCKSCALE_FP8_GEMM_FLASHINFER: "0"

command: |
  model_root=/root/.cache/huggingface/safetensors/unsloth
  model_name=Qwen3.8-27B-NVFP4
  served_name=qwen3.8-27b-unsloth-nvfp4
  chat_template="$model_root/$model_name/chat_template.jinja"
  chat_kwargs='{{"enable_thinking":false}}'
  mm_limits='{{"image":1,"video":0}}'
  spec_config='{{"method":"mtp","num_speculative_tokens":2}}'
  hf_overrides='{{"text_config":{{"rope_parameters":{{"mrope_interleaved":true,'\
  '"mrope_section":[11,11,10],"rope_type":"yarn","rope_theta":10000000,'\
  '"partial_rotary_factor":0.25,"factor":2.0,'\
  '"original_max_position_embeddings":262144}}}}}}'
  kernel_config='{{"enable_flashinfer_autotune":false,'\
  '"enable_cutedsl_warmup":false,"enable_jit_warmup":false}}'
  vllm serve "$model_root/$model_name" \
    --served-model-name "$served_name" \
    --host {host} \
    --port {port} \
    --tensor-parallel-size {tensor_parallel} \
    --gpu-memory-utilization {gpu_memory_utilization} \
    --max-model-len {max_model_len} \
    --hf-overrides "$hf_overrides" \
    --max-num-batched-tokens {max_num_batched_tokens} \
    --max-num-seqs {max_num_seqs} \
    --kv-cache-dtype fp8 \
    --kv-cache-memory-bytes 20G \
    --max-parallel-loading-workers 1 \
    --mm-processor-cache-gb 0 \
    --skip-mm-profiling \
    --mm-encoder-tp-mode data \
    --kernel-config "$kernel_config" \
    --load-format safetensors \
    --attention-backend flashinfer \
    --enable-prefix-caching \
    --enable-chunked-prefill \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3_xml \
    --reasoning-parser qwen3 \
    --chat-template "$chat_template" \
    --default-chat-template-kwargs "$chat_kwargs" \
    --trust-remote-code \
    --limit-mm-per-prompt "$mm_limits" \
    --speculative-config "$spec_config" \
    -O3 \
    --no-enable-log-requests

Log:

Using max model len 524288
GPU KV cache size: 1,188,900 tokens
Maximum concurrency for 524,288 tokens per request: 2.27x

VRAM - 35,5Gb на каждой ноде (всего 2).

У меня первое впечатление как раз “вау”. Такого красивого тетриса мне еще ни одна модель локальная не генерила:

скриншот
Двойной тетрис
Двойной тетрис
1
23 ...

Информация

В рейтинге
5 457-й
Зарегистрирован
Активность