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단계 핫스왑 전략
또는 자주 쓰는 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 기준)
에이전트 루프 구조
- 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. 미결 사항
- VS Code Extension 먼저 vs Discord Bot 먼저?
- Machine A 기본 모델: Gemma4 26B vs Qwen 35B?
- SearXNG 위치: Machine A vs Machine B?
- Machine A 자동 시작: Windows 서비스 vs 작업 스케줄러?
- 핫스왑 트리거 방식: 수동(명령어) vs 자동(복잡도 판단)?