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

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

---

## 🐛 Проблема

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

### Діагностика

1. **Router працює коректно**:
   ```
   Request successful via llm_local_qwen3_8b
   Tokens: 416
   Response: "Я — GREENFOOD, AI-ERP для крафтових виробників..."
   ```

2. **Запит займає 18 секунд**:
   ```bash
   $ curl -v http://144.76.224.179:9102/route ...
   # Transfer time: 18 seconds
   HTTP/1.1 200 OK
   ```

3. **Таймаут frontend: 15 секунд**:
   ```typescript
   const timeoutId = setTimeout(() => controller.abort(), 15000); // ❌ Занадто короткий
   ```

### Причина

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

---

## ✅ Рішення

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

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

```typescript
// До виправлення
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 сек |

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

1. **Модель qwen3:8b** працює на CPU (без GPU acceleration на повну):
   - GPU layers: 35 (частково)
   - Частина шарів на CPU

2. **Ollama keep_alive**: 24h
   - Модель завантажена в пам'ять
   - Але перший запит може бути повільнішим

3. **Мережні затримки**:
   - Docker network overhead
   - Router → Ollama комунікація

---

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

### 1. GPU Acceleration (якщо доступний)
```bash
# Переконатися, що Ollama використовує GPU повністю
Environment="OLLAMA_NUM_GPU=1"
Environment="OLLAMA_GPU_LAYERS=99"  # Всі шари на GPU
```

### 2. Streaming Responses
```typescript
// Замість чекання повної відповіді - 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. Кешування промптів
```yaml
# Router config
cache:
  enabled: true
  ttl: 300  # 5 хвилин
```

### 4. Lighter Model для простих запитів
```yaml
# Швидша модель для простих питань
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 секунд вирішує проблему для всіх агентів-оркестраторів.

Якщо потрібно прискорити відповіді - рекомендується:
1. Повне GPU acceleration для Ollama
2. Streaming responses у frontend
3. Легші моделі для простих запитів