채팅 내 상호작용/미리보기 가능한 아티팩트 (Artifacts)

공개: 저는 Docker로 셀프 호스팅(self-host)할 수 있는 소스 공개형 (BUSL-1.1) AI 워크스페이스인 Bike4Mind를 개발하고 있습니다. 실행을 위해 구매해야 할 것은 아무것도 없습니다. 저는 일반적인 노트북에서 주로 로컬 Qwen을 사용하여 이를 실행합니다. 4GB 그래픽 카드로 로컬 채팅 모델을 실행하는 것은 새로운 뉴스도 아니지만, 제가 탐구하고 싶었던 것은 전체 에이전트 워크스페이스(도구를 호출하고, 개인 문서에 대해 RAG를 수행하며, 아티팩트, 비전 등을 사용하는 에이전트)가 4GB 환경에서 무엇을 할 수 있는지, 그리고 소형 모델이 단순 채팅 이상의 작업을 수행해야 할 때 어디에서 따라잡지 못하는지입니다. 저장소(Repo)는 첫 번째 댓글에 있습니다.

제 사양: i7-12700H, 32GB RAM, RTX 3050 Ti Laptop (4GB VRAM, 60W), Ubuntu 24.04. 클라우드 키 없이 스택에 포함된 Ollama를 통한 로컬 Qwen 사용.

4GB 한계에 부딪혔을 때의 속도 (Ollama /api/generate, Q4_K_M 적용, Q8_0 0.8b 모델 제외, num_ctx=4096, warm-up 포함, 3회 측정 중앙값, 한 번에 하나의 모델만 로드):

• qwen3.5:0.8b - 122 tok/s, 약 1.4GB, 모두 GPU 사용
• qwen3.5:2b-q4_K_M - 96 tok/s, 약 2.4GB, 모두 GPU 사용
• qwen3.5:4b - 25 tok/s, 약 3.4GB, 약 1/3이 CPU로 넘어감
• qwen3.5:9b - 8.6 tok/s, 대부분 CPU 사용, 약 8GB 필요

현재까지 저에게는 2b 모델이 최적의 지점(sweet spot)입니다. 4GB 안에 들어가면서 약 1.3GB의 여유 공간이 남고, 이전에 실행했던 qwen2.5-coder:3b(72 tok/s)보다 빠르면서도 더 최신이며 멀티모달(multimodal) 기능을 갖추고 있습니다. 그 이상의 모델에서는 한계에 부딪힙니다. 4b 모델의 가중치(weights) 약 3.4GB는 num_ctx=2048 설정에서도 완전히 들어가지 않으므로, 1/3이 CPU에 할당됩니다. 일반적인 qwen3.5:2b는 Q8_0 빌드(약 2.7GB)로 4GB 환경에서 용량이 넘치지만, qwen3.5:2b-q4_K_M은 들어갑니다. 이 경우 약 1.3GB의 여유가 남으므로, 옆에 두 번째 모델을 올릴 공간은 없습니다.

다양한 셀프 호스팅 모델을 보여주는 모델 선택기 (클라우드 제공업체 키를 구성하면 해당 업체들의 모델도 모두 표시됩니다)

채팅, 네이티브 도구 호출(tool-calls), 비전(vision)과 같은 명백한 기능들은 2b 모델에서 잘 작동합니다. qwen3.5는 멀티모달이며 도구를 네이티브하게 호출하므로 매우 훌륭합니다.

그 위에서 제가 가장 기대하고 있는 레이어는 완전히 키리스(keyless) 방식으로 본인의 문서에 대해 수행하는 RAG (Retrieval-Augmented Generation)입니다. 파일을 넣기만 하면, 워커(worker)가 로컬 Ollama 임베더 (embedder)를 사용하여 이를 청크 (chunk)로 나누고 임베딩 (embedding)하며, 클라우드 임베딩 API를 루프 어디에도 사용하지 않고 인용된 답변과 함께 쿼리 (query) 결과가 돌아옵니다. 4GB 환경에서는 임베더와 채팅 모델이 서로 자리를 바꿉니다. qwen3-embedding:0.6b는 약 1.2GB를 점유하고, 2b 모델은 약 2.4GB를 점유하므로 둘 다 동시에 들어갈 수 없습니다. 따라서 Ollama는 하나를 로드하기 위해 다른 하나를 언로드 (unload)합니다. 2b 모델이 VRAM에 있는 동안에는 임베더가 VRAM에 없기 때문에, 생성 (generation) 속도는 여전히 96 tok/s의 전체 속도를 유지합니다. 즉, 지불해야 하는 비용은 토큰 속도가 느려지는 것이 아니라 모델 로딩 시간입니다. 인제스션 (ingestion)은 워커에서 실행되므로, 문서 폴더 하나를 처리할 때 임베더를 한 번 로드한 후 채팅 경로를 방해하지 않고 많은 청크를 처리합니다. 쿼리가 들어오면 짧은 문자열 하나를 임베딩하고, 그 다음 2b 모델이 답변을 위해 다시 로드됩니다. 따라서 RAG 턴당 한 번의 재로드(reload)가 발생할 뿐, 토큰당 혹은 청크당 발생하는 것이 아닙니다. 만약 이 비용을 치르고 싶지 않다면, nomic-embed-text는 약 0.25GB (768-dim, 평판상 검색 성능은 더 약함)이므로 2b 모델을 밀어낼 필요가 없으며, 혹은 임베딩을 CPU에 두고 GPU는 생성에만 남겨둘 수도 있습니다. 어느 쪽이든, 전체 지식 베이스/데이터 레이크 (data lake)를 로드하기 전에 임베더 하나를 선택하여 그대로 유지하십시오 (그렇지 않으면 모든 것을 다시 임베딩해야 한다는 점을 인지해야 합니다). 벡터 (vector)는 모델 간에 공유되지 않기 때문입니다. RAG를 위한 채팅-임베더-스왑(swap) 상황은 차치하더라도, 소형 모델들은 다음과 같은 부분에서도 한계를 보입니다:

• 아티팩트 (Artifacts). 일반적인 qwen3.5 모델들은 이 정도 크기에서는 닫히지 않은 태그나 페이지로 스크립트가 새어 나가는 등 미완성된 HTML을 작성합니다. 실제 상호작용이 가능한 아티팩트를 위해서는 코딩에 튜닝된 qwen2.5-coder로 전환해야 하며, 이 모델은 완전하게 작동하는 페이지를 작성합니다. 따라서 작업별로 모델을 사용하는 방식(model-per-task)이 필요합니다: 채팅/비전/도구에는 qwen3.5를, 코딩에는 coder를 사용하며 노트북 중간에 전환합니다. 대부분의 경우, 이것이 4GB 환경에서의 삶인 것 같습니다!

• 도구 선택 (Tool selection). 많은 도구를 켜두면 소형 모델들은 경로를 잘못 지정합니다. 모든 도구를 활성화했을 때, 제 7b 모델은 한 번

따라서 또 다른 명백한 점은, 소형 로컬 모델(small local models)에서는 훨씬 더 적은 수의 도구(tools)만 활성화해야 한다는 것입니다. 이는 사용자의 컨텍스트(context)에 따라 가장 관련성이 높은 몇 가지(설정 가능한 N개?) 도구만을 자동으로 활성화해 주는 멋진 레이어(layer)가 있으면 좋겠다는 생각을 들게 합니다. - 이미지 생성(Image gen)은 로컬(자체 호스팅되는 SD.Next)에서 수행되지만, CPU로 스필오버(spilling)가 발생하면서 이미지당 1~3분이 소요되며, 채팅 모델과 VRAM을 두고 경쟁합니다. 따라서 여전히 실행해 두고 기다려야 하는 상황이며, 여기에는 딱히 좋은 해결책이 없습니다. 그저 더 많은 VRAM을 구매하는 수밖에 없습니다 🙃 그렇다면 단순히 Ollama와 채팅 UI를 사용하는 것보다 이 방식이 가치가 있을까요? 제 생각에는 상단의 에이전트 레이어(agent layer)가 여러분에게 가치가 있을 때만 그렇습니다. 즉, 도구 처리(tool handling), 아티팩트(artifacts), 로컬 RAG, 그리고 자체 서버에 대한 CLI 기능 등이 말이죠. 만약 단순히 빠른 로컬 채팅만을 원한다면, 오버헤드(overhead)가 적은 llama.cpp 등을 그대로 사용하는 것이 좋습니다. 라이선스에 대해 짧게 언급하자면, BUSL-1.1 하의 소스 공개(source-available) 방식이며, 아직 완전한 오픈 소스(open source)는 아닙니다. 자체 호스팅하고, 프로덕션에서 실행하고, 포크(fork)하여 이를 기반으로 제품을 구축하고 판매할 수 있습니다. 다만, 직접적으로 경쟁하는 호스팅 서비스(hosted service)로 재판매할 수는 없습니다. 각 릴리스는 2년 후에 Apache-2.0으로 전환됩니다 (AWS가 MongoDB에 했던 것처럼 즉시 우리에게 하지 못하도록 타이머를 설정한 것입니다 ㅎㅎ). 저장소(Repo) 및 자체 호스팅에 대한 자세한 내용은 첫 번째 댓글에 있습니다. 이 설정에서 저에게 진짜 마찰(friction)이 되는 부분은 두 개의 모델이 필요하다는 점입니다. 채팅, 비전(vision), 도구 사용을 위한 qwen3.5 모델과, 코드 형태의 모든 작업을 위한 코더(coder) 모델이 필요합니다. 왜냐하면 이 정도 크기의 모델들은 일반 모델(general models)이 깨진 HTML/아티팩트를 작성하기 때문인데, 이는 새로운 문제는 아닙니다. 이를 위해 저는 여전히 이 설정을 최적화하려고 노력 중입니다. 따라서 저보다 제한된 로컬 빌드 환경에 대해 더 강력한 경험을 가진 여러분(인간 LLM들)께 몇 가지 프롬프트(prompts)를 드립니다: - 전용 코딩 모델을 병행할 필요 없이, 완전하고 유효한 아티팩트를 작성할 수 있는 4GB 환경용 단일 범용 모델을 찾으셨거나, 혹은 단순히 더 나은 구성 방법을 알고 계신가요? 알려주세요! - 저는 기본적으로 다른 사람들의 채팅+코드+이미지+임베딩(embeddings) 등이 모두 포함된 올인원(all-at-once) 설정에 대해 궁금합니다. 잘 작동하는 모델들의 훌륭한 테트리스 조합(Tetris wombo)을 찾으셨다면, 혹은 이처럼 모든 것을 자체 호스팅하려고 시도하면서 어떤 트레이드오프(trade-offs)를 경험하고 수용하셨는지 공유해 주세요.

/u/maikerukonare 님이 게시함 [link] [comments]