chore: initial project setup with agent guide
This commit is contained in:
Variet-Worker
199
docs/ai_assistant_architecture.md
Normal file
199
docs/ai_assistant_architecture.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# AI 비서 시스템 아키텍처 논의 기록
|
||||
|
||||
> 작성일: 2026-04-05
|
||||
> 상태: 논의 중
|
||||
|
||||
---
|
||||
|
||||
## 1. 하드웨어 조건
|
||||
|
||||
- **GPU: RTX 3060 12GB × 2장 (총)**
|
||||
- Machine A: 현재 머신 (Modern CPU, 96GB RAM) → API 서버 전용
|
||||
- Machine B: i7-7700, 64GB RAM → 워크스테이션 (코딩, Discord 등)
|
||||
- Machine B는 내장그래픽(HD 630)으로 디스플레이 사용
|
||||
- Machine A에서 7700+64GB RAM+3060 조합으로 유사한 결과 확인 완료
|
||||
|
||||
## 2. GPU 배치 결정: 1+1 vs 2+0
|
||||
|
||||
### 2+0 (Machine A에 2장 집중) — 추천
|
||||
|
||||
| 장점 | 설명 |
|
||||
|------|------|
|
||||
| 코딩 속도 2.5배 향상 | 35B 모델: 30 t/s → 50-80 t/s |
|
||||
| 모델 완전 VRAM 수용 | 35B (20.5GB) → 24GB에 수용, cpu-moe 불필요 |
|
||||
| 비서도 오히려 빠름 | API 호출해도 50-80 t/s > 로컬 42 t/s |
|
||||
| 아키텍처 단순 | LLM 엔드포인트 1곳만 관리 |
|
||||
|
||||
| 단점 | 설명 |
|
||||
|------|------|
|
||||
| Machine A 의존 | 장애 시 추론 전체 중단 |
|
||||
| 동시 처리 제한 | 솔로유저라 실질적 문제 적음 |
|
||||
| 122B 핫스왑 중 비서 중단 (~3-5분) | 빈도 낮으면 수용 가능 |
|
||||
|
||||
### 1+1 (각 1장씩)
|
||||
|
||||
| 장점 | 설명 |
|
||||
|------|------|
|
||||
| 병렬 처리 가능 | 양쪽 동시 추론 |
|
||||
| 장애 시 독립 동작 | Machine B가 자체 LLM 보유 |
|
||||
| 122B 핫스왑 중에도 비서 유지 | Machine B가 대체 |
|
||||
|
||||
| 단점 | 설명 |
|
||||
|------|------|
|
||||
| 코딩 속도 30 t/s (2+0 대비 절반) | 메인 작업 속도 희생 |
|
||||
| 35B 모델 cpu-moe 의존 | RAM 대역폭 제한 |
|
||||
| 관리 복잡 | LLM 2곳 관리 |
|
||||
|
||||
### 결론: 솔로 유저 + 메인 코딩 → 2+0 추천
|
||||
|
||||
---
|
||||
|
||||
## 3. Machine A 모델 후보 비교 (2x 3060, 24GB VRAM)
|
||||
|
||||
### 모델 스펙 비교
|
||||
|
||||
| 모델 | 크기 | 활성 파라미터 | 1x 3060 속도 | **2x 3060 예상** | VRAM 여유 |
|
||||
|------|:----:|:----------:|:----------:|:-----------:|:---------:|
|
||||
| **Gemma4 26B-A4B** | 15.6 GB | 4B | 42 t/s | **70-100+ t/s** | 8.4 GB |
|
||||
| **Qwen3.5 35B-A3B** | 20.5 GB | 3B | 30 t/s | **50-80 t/s** | 3.5 GB |
|
||||
| Qwen3.5 122B-A10B | 71.3 GB | 10B | 11 t/s | 11 t/s (cpu-moe) | N/A |
|
||||
|
||||
### Gemma4 26B-A4B 장점
|
||||
|
||||
- **속도**: 15.6 GB로 작아서 VRAM에 여유롭게 수용 → 2x GPU에서 70-100+ t/s 가능
|
||||
- **도구 호출**: function calling / tool use에 안정적 (구글 설계)
|
||||
- **VRAM 여유**: 8.4 GB 남음 → 더 큰 컨텍스트, 더 높은 양자화(Q5/Q6), 멀티슬롯 가능
|
||||
- **로딩 시간**: 15.6 GB → ~20초 (핫스왑 빠름)
|
||||
- **범용성**: 코딩 + 도구 호출 + 일반 대화 균형
|
||||
|
||||
### Qwen3.5 35B-A3B 장점
|
||||
|
||||
- **코딩 품질**: Qwen3.5 시리즈가 코딩 벤치마크에서 Gemma4보다 강세
|
||||
- **추론 능력**: 35B 전체 파라미터 → 더 깊은 지식/추론
|
||||
- **한국어**: Qwen 시리즈가 한국어 성능 우수
|
||||
- **3B 활성**: 4B보다 적어 토큰당 읽기 데이터 적음 (그러나 모델 크기가 더 커서 상쇄)
|
||||
|
||||
### Qwen3.5 122B-A10B 장점
|
||||
|
||||
- **최고 품질**: 122B 파라미터 → 가장 정확하고 깊은 추론
|
||||
- **복잡한 설계**: 아키텍처 리뷰, 수학, 어려운 디버깅에 탁월
|
||||
- **단점**: 11 t/s → 일상 사용에는 느림
|
||||
|
||||
### 제안: 3단계 핫스왑 전략
|
||||
|
||||
```
|
||||
Fast (기본): Gemma4 26B-A4B → 70-100+ t/s
|
||||
└── 빠른 대화, 도구 호출, 간단한 코딩, 비서 업무
|
||||
└── 로딩: ~20초
|
||||
|
||||
Balanced: Qwen3.5 35B-A3B → 50-80 t/s
|
||||
└── 본격적 코딩, 리팩토링, 복잡한 작업
|
||||
└── 로딩: ~30-40초
|
||||
|
||||
Deep: Qwen3.5 122B-A10B → ~11 t/s
|
||||
└── 아키텍처 설계, 고난도 추론, 심층 분석
|
||||
└── 로딩: ~3-5분
|
||||
```
|
||||
|
||||
또는 **자주 쓰는 2개만 유지**:
|
||||
|
||||
| 전략 | 기본 모델 | 온디맨드 | 적합한 경우 |
|
||||
|------|----------|---------|-----------|
|
||||
| A) 코딩 중심 | Qwen 35B (50-80 t/s) | 122B (11 t/s) | 코딩이 압도적 다수일 때 |
|
||||
| B) 균형형 | Gemma4 26B (70-100+ t/s) | Qwen 35B (50-80 t/s) | 비서+코딩 혼합일 때 |
|
||||
| C) 속도형 | Gemma4 26B (70-100+ t/s) | 122B (11 t/s) | 빠른 일상 + 가끔 딥 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 시스템 구조 (2+0 기준)
|
||||
|
||||
```
|
||||
Machine A (API 서버, 2x 3060, 헤드리스)
|
||||
┌─────────────────────────┐
|
||||
│ llama-server │
|
||||
│ (포트 8000, OpenAI API) │
|
||||
│ │
|
||||
│ 모델: Gemma4/Qwen35B/122B│
|
||||
│ 핫스왑 API (포트 8001?) │
|
||||
└────────────┬─────────────┘
|
||||
│ REST API (LAN)
|
||||
│
|
||||
Machine B (워크스테이션, GPU 없음)
|
||||
┌────────────┴─────────────┐
|
||||
│ VS Code Extension │ → Machine A API 호출 (코딩)
|
||||
│ Discord Bot │ → Machine A API 호출 (비서)
|
||||
│ MCP/도구 서버: │
|
||||
│ · 캘린더 (Google API) │
|
||||
│ · 이메일 (Gmail API) │
|
||||
│ · 웹 검색 (SearXNG) │
|
||||
│ · 쉘/파일 (subprocess) │
|
||||
│ · 서버 관리 (Machine A) │
|
||||
└──────────────────────────┘
|
||||
```
|
||||
|
||||
### 에이전트 루프 구조
|
||||
|
||||
```python
|
||||
MACHINE_A = "http://192.168.x.x:8000/v1/chat/completions"
|
||||
|
||||
while not done:
|
||||
response = call_llm(MACHINE_A, messages, tools=local_tools)
|
||||
if response.has_tool_calls:
|
||||
results = execute_tools_locally(response.tool_calls)
|
||||
messages.append(results)
|
||||
else:
|
||||
show_to_user(response.content)
|
||||
done = True
|
||||
```
|
||||
|
||||
- LLM은 Machine A에서 "생각"
|
||||
- 도구는 Machine B에서 "실행"
|
||||
- 이 분리가 깔끔하고 확장 용이
|
||||
|
||||
---
|
||||
|
||||
## 5. 기술 스택
|
||||
|
||||
| 컴포넌트 | 기술 | 위치 |
|
||||
|---------|------|:----:|
|
||||
| LLM 서버 | llama-server (OpenAI API) | Machine A |
|
||||
| VS Code Extension | TypeScript + VS Code API | Machine B |
|
||||
| Discord Bot | discord.py | Machine B |
|
||||
| 도구 프레임워크 | 직접 구현 (function calling 기반) | Machine B |
|
||||
| 웹 검색 | SearXNG (Docker) | Machine B |
|
||||
| 코드/쉘 실행 | subprocess (직접) | Machine B |
|
||||
| 에이전트 루프 | 직접 구현 (LangChain 등 불필요) | Machine B |
|
||||
|
||||
---
|
||||
|
||||
## 6. 구현 로드맵
|
||||
|
||||
### Phase 1: 인프라 (1-2일)
|
||||
- Machine A: 2x 3060 설치, llama-server 자동 시작
|
||||
- LAN API 통신 확인
|
||||
- 핫스왑 스크립트 (모델 전환 자동화)
|
||||
|
||||
### Phase 2: VS Code Extension (3-5일)
|
||||
- Extension 기본 구조
|
||||
- Machine A API 연동 (에이전트 루프)
|
||||
- 로컬 도구: 파일 R/W, 터미널, 프로젝트 탐색
|
||||
|
||||
### Phase 3: Discord Bot (2-3일)
|
||||
- 기본 봇 구조
|
||||
- Machine A API 연동
|
||||
- 슬래시 명령어
|
||||
|
||||
### Phase 4: 도구 통합 (3-5일)
|
||||
- SearXNG 자체 호스팅
|
||||
- Google Calendar/Gmail API
|
||||
- 서버 관리 도구
|
||||
|
||||
---
|
||||
|
||||
## 7. 미결 사항
|
||||
|
||||
1. VS Code Extension 먼저 vs Discord Bot 먼저?
|
||||
2. Machine A 기본 모델: Gemma4 26B vs Qwen 35B?
|
||||
3. SearXNG 위치: Machine A vs Machine B?
|
||||
4. Machine A 자동 시작: Windows 서비스 vs 작업 스케줄러?
|
||||
5. 핫스왑 트리거 방식: 수동(명령어) vs 자동(복잡도 판단)?
|
||||
Reference in New Issue
Block a user