2코어 2GB 클라우드 서버에 OpenViking 구동한 실제 후기

최근 나는 내 AI Coding Agent의 메모리 기반을 자체 구축한 OpenViking으로 이전했다. 공식 문서는 꽤 겁이 나게 생겼고, 고사양 서버와 로컬 VRAM을 권장하지만, 실제로 써 보니 선택만 명확히 하면 몇십 위안짜리 입문급 클라우드 서버 한 대로도 충분히 빠르게 돌릴 수 있었다.

이 글은 명령어를 어떻게 입력하는지 알려주는 설치 튜토리얼이 아니라, 이번 작업을 거치면서 클라우드 호스트, 모델 조합, 연산 비용에 관해 얻은 실제 후기와 시행착오, 선택의 고민을 이야기하는 글이다.

1. 클라우드 호스트: 왜 나는 99위안의 2G를 선택하고, 경쟁사의 더 저렴한 4G를 선택하지 않았나?

클라우드 서버를 구매할 때 첫눈에 경쟁사들의 "몇십 위안으로 4G 심지어 8G" 신규 고객 프로모션에 끌리기 쉽다. 그러나 나는 결국 알리클라우드 99위안/년의 2코어 2G(ecs.e-c1m1.large)를 선택했다.

핵심 이유는 단 하나다: 장기적인 갱신 비용을 계산하고, "첫해 저가, 이듬해 폭등"이라는 수법을 피하는 것.

단지 무상태 개인 블로그를 만드는 것이라면 1년마다 바꾸고 이리저리 이사 다녀도 상관없다. 하지만 OpenViking은 너의 메모리 데이터베이스로, 그 안에는 일상의 모든 세션 트레이스, 축적된 프로젝트 아키텍처, 엔티티 그래프와 벡터 인덱스가 저장되며, 강한 상태 자산이다. 많은 경쟁사는 첫해 60위안이지만, 2년 차 갱신은 바로 600, 800 심지어 1000위안 이상으로 뛰어오르고, 1년 후 돈을 아끼려고 어쩔 수 없이 서비스를 중단하고 클라우드를 넘나들며 수천 메가바이트의 데이터를 복사하고 보안 그룹과 도메인 해석을 다시 설정해야 하는데, 이런 시행착오 비용은 그 차액을 훨씬 뛰어넘는다.

알리클라우드 이번 프로모션의 가장 큰 진심은 이듬해에도 여전히 99위안에 수법 없이 동일 가격으로 갱신할 수 있음을 보장한다는 점이다.

2G 메모리는 비록 빠듯하지만, Swap 안전장치를 잘 갖추고 컨테이너 메모리를 제한하며 연산을 전부 외부 API에 넘기고 기기 로컬에서는 저장과 검색만 하면, 일상적인 메모리 점유는 평시 몇백 메가바이트 정도다. 시스템을 약간 튜닝하는 대가로 매년 99위안만 들고 자주 이사할 필요 없는 안정적인 메모리 기반을 얻는다면, 이 계산은 어떻게 해도 더 이득이다.

2. 벡터 모델(Embedding): 돈이 많이 드는 핵심, 반드시 한 번에 제대로 가야 한다

전체 시스템을 돌리면 지속적으로 돈이 드는 핵심은 사실 벡터 모델이다. 그러나 나는 처음부터 "무료 모델 공짜로 쓰기"라는 생각을 버리고, 돈을 내고 상용 서비스를 사기로 확고히 선택했으며, 그것도 "한 번에 제대로" 하기로 했다.

왜 반드시 한 번에 제대로 해야 하나?

VLM, 의도 분석, 리랭킹 모델 등은 모두 즉시 추론이라, 오늘 쓰기 안 좋다고 느끼면 설정 한 줄 고치고 재시작하면 바로 바꿀 수 있다. 그러나 벡터 모델은 데이터베이스 저층의 공간 기하학적 특징을 결정한다. 나중에 벡터 모델을 바꾸고 싶어지면, 출력 차원이 완전히 같더라도 이전 벡터는 모두 폐기되며, 반드시 전체 데이터베이스의 전량 인덱스를 재구축(Re-index)해야 한다. 메모리가 쌓일수록 2차 재구성의 비용과 중단 위험은 매우 높아지므로, 벡터 모델 선정은 처음부터 가장 좋은 것을 선택해야 한다.

왜 SiliconFlow의 무료 BGE-M3를 포기했나?

많은 튜토리얼이 실리콘플로우의 무료 BGE-M3를 추천한다. 우리가 실제로 벡터 리콜 테스트를 할 때 발견한 것은, 그 리콜 품질이 신세대 모델에 의해 매우 뚜렷한 세대 격차로 벌어졌다는 점이다. BGE-M3는 2024년 1월의 모델이라 기반이 너무 오래되었고, 순수 텍스트 모델이라 이미지는 첨부 파일로만 저장할 수 있고 인덱스를 전혀 구축할 수 없어 "텍스트로 이미지 검색"을 할 수 없다.

더 결정적인 것은, 공용 무료 풀이 이미 무임승차족들에 의해 망가졌다는 점이다. 우리는 무료 모델로 라우팅을 테스트할 때 패킷 손실, 높은 지연, 무응답을 빈번히 겪었다. 핵심 인프라의 기반으로서, 신상 자산을 무료 공공 풀에 묶어두는 것은 순전히 스스로에게 골칫거리를 만드는 일이다.

왜 화산방주의 도우바오 Vision(0.7위안)을 선택하고, 알리 치엔원을 선택하지 않았나?

최종적으로 나는 화산방주의 doubao-embedding-vision-251215를 사용했고, 공식 가격은 추론 입력 0.7위안/백만 tokens이다.

사실 알리 바이롄에도 멀티모달 벡터 모델(qwen3-vl-embedding)이 있고, 가격도 똑같이 0.7위안이지만, 둘 사이에는 치명적인 차이가 있다:

- 알리 치엔원의 컨텍스트 윈도는 겨우 32K이고,

- 화산 도우바오의 컨텍스트 윈도는 무려 128K이다.

Agent 시나리오에서는 장문의 개발 규범, 긴 컨텍스트 코드 슬라이스 또는 여러 장의 고해상도 스크린샷을 자주 넣어야 하는데, 128K는 무려 4배의 안전 여유를 주어 초장문 슬라이스 오버플로를 전혀 걱정할 필요가 없다. 게다가 OpenViking 자체가 바이트 화산엔진에서 오픈소스화한 것이어서 네이티브 Provider 호환이 가장 안정적이므로, 같은 가격이라면 당연히 128K의 도우바오를 선택한다.

참고: 만약 이미지, 스크린샷 검색 수요가 전혀 없고 순수 텍스트나 코드 노트만 한다면, 알리 바이롄의 순수 텍스트 벡터 qwen3.7-text-embedding이 비용을 아끼는 좋은 대안이며, 가격은 0.5위안/백만 tokens에 불과하다.

3. 의도 분석(Query Planner): 90%의 사람들이 놓치는 "숨은 스위치"

많은 사람이 OpenViking을 처음 쓸 때 공통된 혼란을 겪는다: "왜 이건 반응이 이렇게 둔하냐? IDE나 터미널에서 문장을 막 입력했는데 커서가 5~6초 멈춰야 반응이 시작된다?" 어떤 사람들은 이 때문에 기기 사양이 부족하거나 시스템 자체 설계가 둔중하다고 생각하기까지 한다.

사실 전혀 성능 문제가 아니라, 대다수 사람들이 설정 문서를 꼼꼼히 보지 않아 의도 분석 모델을 별도로 설정할 수 있다는 것을 모르기 때문이다.

공식 기본 예시에서는 보통 vlm과 embedding만 채운다. 그러나 설정에서 query_planner를 명시적으로 선언하지 않으면, OpenViking은 매 라운드 대화를 처리할 때 기본적으로 메인 모델 VLM으로 폴백해 이 대화가 잡담인지, 메모리를 검색해야 하는지, 키워드를 어떻게 추출할지를 분석한다. 만약 VLM으로 큰 모델이나 사고 사슬이 있는 모델(예: 즈푸 glm-5.3-flash)을 선택했다면, 단일 사전 분석만으로 6~7초를 잡아먹어 프론트엔드 상호작용이 자연히 PPT처럼 버벅인다.

이 사전 지연을 해결하기 위해, 처음에는 주류 범용 대형 모델에서 대안을 찾으려 했다. 그러나 한 바퀴 돌아보고 매우 낙담했다:

- 알리 바이롄 공식 Qwen3.7-Flash는 기본적으로 심층 사고를 포함해 한 번 실행에 10초를 생각해야 한다;

- 실리콘플로우의 Qwen/Qwen3.5-9B는 처리량이 느린 편(평시 30 tok/s)이라 매 질문마다 여전히 4초 멈춘다;

- 실리콘플로우의 Qwen/Qwen2.5-7B는 형식이 불안정해 날것 배열을 잘 토해낸다;

- 실리콘플로우 공용 무료 풀의 모델(예: Qwen3.5-4B)은 무임승차 스크립트에 더욱 밀려 패킷 손실과 타임아웃이 빈번하다.

우리가 범용 대형 모델 선정 병목에 막혀 있을 때, 나는 알리 바이롄 모델 광장에서 우연히 보물 같은 모델을 발견했다 — tongyi-xiaomi-analysis-flash(링췌-대화 분석-flash). 공식 소개는 매우 소박하게 적혀 있었다: 대화 정보 추출, 장면 분류와 저지연 분석을 전문으로 하는 도메인 모델.

나는 즉시 이 모델을 테스트 매트릭스에 끌어들여, 앞서의 후보 모델들과 같은 무대에서 겨루게 했다. 특별히 밝혀둘 점은, 공정한 비교를 위해 우리는 모든 후보 모델을 부하 테스트할 때 전부 명시적으로 사고 모드를 껐다는 것이다(비사고 연쇄 모드를 켜서 순수 직접 출력만 하도록).

실제 평가에서 우리는 세 가지 핵심 차원에 집중해 철저하게 파고들었다: 응답 소요 시간, 생성 구조, 계획 성능. 세 가지 엄격한 검증 아래, 이렇게 우연히 건진 보물 같은 모델은 교과서급 성능을 보여주었다.

차원 1: 응답 소요 시간(시간 예산은 반드시 1초 이내로 사수해야 한다)

query_planner는 사용자가 엔터를 누르고 모델이 실제로 답하기 전의 **핵심 차단 경로(Critical Path)** 상에 있다. 소요 시간이 단 1초만 늘어도 체감상 극히 뚜렷한 끊김으로 느껴진다.

- 알리바바 바이롄 Qwen3.7-Flash: 사고 모드를 꺼도(enable_thinking: false), 단일 분석에 여전히 1.1~1.4초가 걸린다(70~90 tok/s). 고빈도 프런트 단계 차단 용도로는 여전히 다소 무겁다.

- 실리콘플로우 Qwen/Qwen3.5-9B: 사고를 끈 뒤에도 공급사의 30 tok/s 생성 처리량 병목에 묶여, 한 차례 다중 턴 분석을 끝내는 데 여전히 3.8~4.2초가 걸린다.

- 실리콘플로우 무료 풀(예: Qwen3.5-4B): 공용 무료 풀은 연중내내 이득을 노린 스크립트에 밀려 지연이 심하게 요동치거나 아예 타임아웃되기 일쑤다.

- 통이링취에(Flash): 첫 토큰 지연(TTFT)이 단 0.31초이고, 생성 처리량은 무려 200+ tok/s에 달해, 한 라운드 계획에 걸리는 시간이 곧바로 0.8초 안팎까지 내려갔다. 초 단위 이하 예산 안에 완벽히 들어맞는다.

차원 2: 생성 구조(OpenViking이 요구하는 JSON 프로토콜을 엄격히 준수)

OpenViking 기반의 의도 파서는 출력 형식에 명확한 계약 요구가 있다. 모델은 반드시 {"queries": [...]} 형태의 표준 JSON 객체 구조를 반환해야 한다(내부 코드가 직접 역직렬화해 검색 의도를 추출한다). 형식에 조금의 편차도 있어서는 안 된다.

- 범용 대형 모델의 고질병: 쓸데없이 예의를 붙여("네, 다음과 같이 계획해 드립니다") 덧붙이거나, 바깥에 json ... 울타리를 한 겹 덧씌워, 본래 깔끔해야 할 출력을 지저분하게 만들어 전적으로 시스템이 정규식으로 뒷수습해 세척해야 한다.

- 실리콘플로우 Qwen/Qwen2.5-7B의 치명적 결함: 속도는 1.8초까지 압축되었지만, 형식이 규범을 극도로 따르지 않아 자주 OpenViking이 요구하는 최상위 Key를 빠뜨리고 곧바로 날것의 배열 [...]을 토해낸다. 객체 구조를 잃는 순간 파싱 예외를 촉발해 검색 실패로 이어지기 십상이다.

- 통이링취에(Flash): 공식 기능이 "사용자 정의 분석 표준 준수"를 앞세우는데, 실측 결과 OpenViking이 요구하는 JSON 프로토콜을 100% 엄격히 실행했다. 순수한 날것의 JSON을 출력하며, 마크다운 울타리도 없고 앞뒤 군더더기도 없어, OpenViking의 역직렬화 계약과 빈틈없이 맞아떨어졌다.

차원 3: 계획 성능 평가(비즈니스 의도의 결단 품질)

의도 분석 모델은 결코 맹목적으로 검색어를 생성하는 존재가 아니다. 명확한 비즈니스 시나리오 결단력을 갖추어야 한다.

- 잡담 검색 거부율: "안녕", "고마워", "버블 정렬 짜 줘"처럼 장기 기억 개입이 필요 없는 입력에 직면했을 때, 통이링취에는 방화벽처럼 0.4초 안에 과감히 검색이 필요 없다고 단정하고 빈 배열 {"queries": []}을 출력해, 무의미한 벡터 DB 조회와 컨텍스트 오염을 피한다.

- 다중 턴 지시 대명사 해소와 엔티티 추출: 다중 턴 대화에서(예컨대 사용자가 "방금 말한 그 서비스 포트 나한테 보내줘"라고 되물을 때), 이 모델은 역사적 컨텍스트에서 대명사를 구체적 엔티티어로 정확히 환원해(예: "OpenViking 1933 포트 설정"으로 전개), 추출해 낸 Query가 극히 정밀하고 간결하며 결코 발산하거나 과잉 상상하지 않는다.

사실로 증명되었듯, 이렇게 무심코 건진 보물 같은 모델은 요행으로 이긴 것이 아니라, "대화 추출, 시나리오 분류, 형식 준수"에 특화된 수직 파인튜닝 포지셔닝이 OpenViking의 프런트 라우팅 엔지니어링 요구와 교과서적으로 정확히 맞아떨어진 결과다(게다가 관건은 이게 가장 싸다, 범용 대형 모델보다 훨씬 싸다).

4. 재정렬(Rerank)과 VLM: 실용적인 경제성 계산과 재해 대비

마지막으로 남은 두 컴포넌트를 짚어보자.

- 재정렬(Rerank): 나는 여전히 실리콘플로우에 올렸고, Qwen/Qwen3-Reranker-4B를 쓴다. 이걸 쓴 이유는, 경량 상용 과금 채널을 타기 때문이다(무료 풀의 대기를 피한다). 호출 한 번에 몇 리(厘) 수준의 돈만 든다. 관건은 내 계정에 증정된 16위안 상품권이 아직 남아 있어, 안 쓰면 손해라는 점이다. 실측으로 4개 문서 채점에 0.26초, 30개 문서 채점에 0.57초로 빠르고 채점도 정확해 가성비가 극대화된다.

- VLM(멀티모달 시맨틱 추출): 즈푸 Coding 요금제의 glm-5.3-flash를 쓰고, 겸사겸사 이중 Key 주/예비 재해 대비도 갖췄다. 여기에는 극히 관건적인 실전 경험이 하나 있다. 설정에서 반드시 사고 모드를 명시적으로 reasoning_effort: "low"로 바꿔야 한다. 우리는 별도로 여러 조의 A/B 실측을 진행했는데, 기본적으로 파라미터를 전달하지 않거나 high로 설정하면 모델이 먼저 수십 초 깊게 사고하며(20~48초 소요, 수천 개의 무의미한 사고 연쇄 토큰 생성), 최종적으로 추출되는 엔티티와 개요 내용은 low와 거의 아무런 차이가 없었다. 기억 추출은 본질적으로 정보 추출과 구조화 아카이빙이라, 복잡한 수학 논리 추론이 전혀 필요 없으며, high를 켜는 것은 순전히 시간과 연산을 헛되이 낭비하는 짓이다. 심지어 low로 설정해도 단일 추출에 여전히 4~6초가 걸린다(하부 기초 사고와 20~30 tok/s의 처리량 상한이 있어서). 이 또한 현재 시스템의 유일한 소요 지점이다. 그러나 VLM은 백그라운드에서 비동기로 세션 아카이빙과 개요 생성을 할 뿐이라, **프런트엔드의 질의 상호작용을 전혀 차단하지 않고**, 게다가 Coding 요금제는 연간 결제라 극히 저렴하고, 이중 Key 재해 대비와 맞물려 매우 안정적이어서, 현 단계에서는 돈을 들여 바꿀 필요가 전혀 없다.

5. 마지막으로 남기는 몇 가지 솔직한 소회

이 설정을 다 짜내고 나서 가장 크게 느낀 몇 가지 깨달음:

- 상태형 서비스라면 서버를 살 때 먼저 갱신 요금을 보라: 장기 기억 라이브러리를 만들 때는 차라리 초기에 2G에서 시간을 들여 튜닝할지언정, 첫해 몇 푼 아끼려고 갱신 요금이 폭등하는 머신을 사지 마라. 이사하는 게 정말 힘들다.

- 핵심 자산은 단번에 확정하고, 무상태 노드는 수시로 최적화하라: 벡터 모델은 당신의 하부 공간을 결정하니 무료만 탐하지 말고, 멀티모달 + 대용량 컨텍스트(128K)를 곧바로 고정해 향후 재구축을 피하라. 반면 VLM과 Rerank 같은 순수 추론 노드는 더 빠르고 더 싼 쪽이 있으면 바꾸면 된다.

- 전용 소형 모델은 수직 시나리오에서 범용 대형 모델을 압도한다: 의도 분석처럼 "분류, 추출, 엄격한 JSON 형식, 극속"을 중시하는 작업에는, 파인튜닝된 대화 분석 소형 모델이 걸핏하면 장문을 쓰고 사고 연쇄를 켜는 범용 대형 모델보다 몇 배나 더 쓸 만하다.

limuyang2

Android 개발? iOS 개발? @한 작은 회사

26

글

90k

조회수

291

팔로워