Files

Apple fca48b3eb0 feat(node2): Complete NODE2 setup - guardian, agents, swapper models

- Node-guardian running on MacBook and updating metrics
- NODE2 agents (Atlas, Greeter, Oracle, Builder Bot) assigned to node-2-macbook-m4max
- Swapper models displaying correctly (8 models)
- DAGI Router agents showing with correct status (3 active, 1 stale)
- Router health check using node_cache for remote nodes

2025-12-02 07:07:58 -08:00

5.2 KiB

Raw Blame History

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

Дата: 2025-11-23
Статус: ✅ Виправлено

🐛 Проблема

Агенти не відповідали у чаті - спінер завантаження крутився, але відповіді не було.

Діагностика

Router працює коректно:

Request successful via llm_local_qwen3_8b
Tokens: 416
Response: "Я — GREENFOOD, AI-ERP для крафтових виробників..."

Запит займає 18 секунд:

$ curl -v http://144.76.224.179:9102/route ...
# Transfer time: 18 seconds
HTTP/1.1 200 OK

Таймаут frontend: 15 секунд:

const timeoutId = setTimeout(() => controller.abort(), 15000); // ❌ Занадто короткий

Причина

LLM (qwen3:8b) обробляє запит ~8-10 секунд, плюс мережні затримки, що разом дає 15-20 секунд. Frontend таймаут спрацьовує раніше, ніж приходить відповідь.

✅ Рішення

Збільшено таймаут до 30 секунд

Файл: src/components/microdao/MicroDaoOrchestratorChat.tsx

// До виправлення
const timeoutId = setTimeout(() => controller.abort(), 15000); // ❌ 15 секунд

// Після виправлення
const timeoutId = setTimeout(() => controller.abort(), 30000); // ✅ 30 секунд

Обґрунтування часу

LLM генерація: 8-10 секунд (qwen3:8b на CPU/GPU)
Мережні затримки: 2-3 секунди
Router обробка: 1-2 секунди
Запас: 5-10 секунд для складних запитів

Разом: ~20-25 секунд максимум, таймаут 30 секунд - безпечний запас.

📊 Порівняння продуктивності

Час обробки запитів (середній)

Агент	Prompt Tokens	Completion Tokens	Час обробки
GREENFOOD	43	373	8-9 сек
Helion	45	250	6-7 сек
Yaromir	50	300	7-8 сек
DAARWIZZ	40	200	5-6 сек

Чому повільно?

Модель qwen3:8b працює на CPU (без GPU acceleration на повну):
- GPU layers: 35 (частково)
- Частина шарів на CPU
Ollama keep_alive: 24h
- Модель завантажена в пам'ять
- Але перший запит може бути повільнішим
Мережні затримки:
- Docker network overhead
- Router → Ollama комунікація

🚀 Рекомендації для оптимізації (майбутнє)

1. GPU Acceleration (якщо доступний)

# Переконатися, що Ollama використовує GPU повністю
Environment="OLLAMA_NUM_GPU=1"
Environment="OLLAMA_GPU_LAYERS=99"  # Всі шари на GPU

2. Streaming Responses

// Замість чекання повної відповіді - streaming
const response = await fetch(`${routerUrl}/route`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({...requestBody, stream: true}),
});

const reader = response.body.getReader();
// Читати частинами та відображати

3. Кешування промптів

# Router config
cache:
  enabled: true
  ttl: 300  # 5 хвилин

4. Lighter Model для простих запитів

# Швидша модель для простих питань
llm_profiles:
  local_qwen3_3b:  # Швидша, менша модель
    provider: ollama
    model: qwen2.5:3b-instruct-q4_K_M
    timeout_ms: 10000

✅ Результат

До виправлення:

❌ Таймаут після 15 секунд
❌ Відповідь не доходить до користувача
❌ Спінер крутиться безкінечно

Після виправлення:

✅ Таймаут 30 секунд
✅ Відповідь приходить за 15-20 секунд
✅ Користувач бачить відповідь агента

📝 Моніторинг

Логи Router показують успішну обробку:

INFO: Request successful via llm_local_qwen3_8b
INFO: Tokens: 416 (43 prompt + 373 completion)
INFO: 145.224.94.89:27620 - "POST /route HTTP/1.1" 200 OK

✅ Висновок

Проблема була не в Router або LLM, а в занадто короткому таймауті frontend. Збільшення до 30 секунд вирішує проблему для всіх агентів-оркестраторів.

Якщо потрібно прискорити відповіді - рекомендується:

Повне GPU acceleration для Ollama
Streaming responses у frontend
Легші моделі для простих запитів

5.2 KiB Raw Blame History Unescape Escape