200 lines
6.8 KiB
Markdown
200 lines
6.8 KiB
Markdown
# 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 자동(복잡도 판단)?
|