# Sweep, 오픈 가중치 기반 1.5B 모델로 코드 ‘다음 편집’ 자동완성 지원 > Clean Markdown view of GeekNews topic #26047. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26047](https://news.hada.io/topic?id=26047) - GeekNews Markdown: [https://news.hada.io/topic/26047.md](https://news.hada.io/topic/26047.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-23T10:27:18+09:00 - Updated: 2026-01-23T10:27:18+09:00 - Original source: [huggingface.co](https://huggingface.co/sweepai/sweep-next-edit-1.5B) - Points: 19 - Comments: 2 ## Summary **Sweep Next-Edit 1.5B**는 사용자의 **다음 코드 수정**을 예측해 제안하는 오픈소스 자동완성 모델입니다. 1.5B 파라미터 규모임에도 **로컬 환경에서 500ms 이하의 응답 속도**를 보이며, 더 큰 모델보다 높은 정확도를 기록합니다. Q8_0 GGUF 양자화 형식으로 8192 토큰 컨텍스트를 지원하며, Apache 2.0 라이선스입니다. ## Topic Body - **1.5B 파라미터**를 가진 Sweep Next-Edit 모델은 사용자의 **다음 코드 수정**을 예측해 자동완성 기능을 제공 - **로컬 환경**에서 500ms 이하의 속도로 실행되며, **4배 이상 큰 모델보다 높은 성능**을 보임 - **Q8_0 GGUF 양자화 형식**으로 제공되어, 경량화된 상태에서도 긴 **8192 토큰 컨텍스트 길이**를 지원 - **Qwen2.5-Coder**를 기반으로 하며, JetBrains 플러그인과 연동 가능 - **Apache 2.0 라이선스**로 공개되어, 오픈소스 AI 개발자에게 실험과 통합에 유용한 모델임 --- ### 모델 개요 - **Sweep Next-Edit 1.5B**는 코드 자동완성을 위한 **next-edit 예측 모델** - 사용자가 코드를 수정하기 전에 다음 편집을 예측해 제안 - **로컬 노트북 환경**에서도 500ms 이하의 지연으로 실행 가능 - **Speculative decoding**을 활용해 빠른 응답 속도 제공 - **4배 이상 큰 모델보다 높은 성능**을 next-edit 벤치마크에서 기록 ### 모델 세부 정보 - **파라미터 수**: 1.5B - **형식**: GGUF (Q8_0 양자화) - **컨텍스트 길이**: 8192 토큰 - **기반 모델**: Qwen2.5-Coder - **라이선스**: Apache 2.0 ### 사용 방법 - `run_model.py`와 모델 파일을 다운로드 후 실행 - 설치 명령: ``` uv pip install llama-cpp-python huggingface_hub python run_model.py ``` - **로컬 실행 중심 구조**로, 별도의 클라우드 인퍼런스 제공자는 없음 ## Comments ### Comment 49758 - Author: minsuchae - Created: 2026-01-23T14:09:08+09:00 - Points: 1 최근 빅테크들이 파라미터 수를 높이며 성장했는데 방향성이 바뀔려나요? 제 개인적으로는 점점 파라미터 올리면서 성장하는게 사실 답이 없다라고 생각했어서요. 당장의 미래를 포기하고 성장한다는 느낌이라고 할까요? 특히 MoE가 가장 심할 때라고 보였어요. 구글의 Gemma 3 27b 정도 높은 편이였는데 이제는 LLM에서는 그 정도의 파라미터 수는 적은 것 처럼 보였었죠. 기술발전도 중요하지만 실제 그걸 서빙하는 단계를 고려한 무언가가 나와야 하지 않을까 싶은데 이번거는 괜찮은 시도인것 같네요. (파라미터 늘어나는거에 회의적인 이유는 성능 좋은건 알겠는데 그걸 서빙하는데 더 큰 비용이 들기 때문이였습니다.) ### Comment 49734 - Author: neo - Created: 2026-01-23T10:27:18+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46713106) - 모델을 직접 써봤는데 **성능과 품질**이 정말 인상적이었음 오픈소스로 공개해줘서 고마움 나는 Neovim용 **edit completion 플러그인**을 만든 사람인데, Sweep Edit 모델과 통합하는 데 성공했음 관심 있는 사람은 [cursortab.nvim](https://github.com/leonardcser/cursortab.nvim) 참고 바람 - Emacs용 포트나 gptel 통합 버전도 있는지 궁금함 - 흥미로워 보여서 바로 nvim 플러그인 써볼 예정임 - 멋짐. 나도 직접 시도해볼 생각임 - 예전에 Continue.dev에서 **Qwen 2.5 Coder**를 자동완성용으로 써봤는데 JetBrains IDE나 VS Code 모두에서 엉망이었음 이런 시도를 공유해주는 게 정말 반가움. 대부분의 IDE 플러그인들(Cline, RooCode, KiloCode 등)은 **자동완성 모델 설정**을 제대로 지원하지 않음 Copilot 구독을 유지하는 이유가 사실상 자동완성 때문이었는데, 이제 대안이 생긴 것 같아 기쁨 - llama.cpp의 VS Code 확장도 써봤는데 **설정 UX**가 정말 형편없었음 - 이런 플러그인을 쓸 때마다 **자동완성 AI** 없이 코딩하는 게 얼마나 비효율적인지 새삼 느껴짐 보일러플레이트 코드가 많을수록 Claude Code보다 훨씬 유용함 JetBrains를 오래 써서 VSCode로 옮기기 어려웠는데, JetBrains의 AI 기능은 너무 뒤처졌음 이제야 괜찮은 자동완성 도구가 나와서 Copilot 구독을 이걸로 바꿀 생각임 게다가 **오픈 가중치 공개**와 **프라이버시 모드** 제공도 마음에 듦 - 예전부터 자동완성의 효용성을 강조했는데, 이제야 두 가지 개발 문화가 있다는 걸 이해하게 됨 새 코드를 주로 작성하는 개발자는 자동완성의 **생산성 향상**을 크게 느끼지만, 유지보수 중심의 개발자는 Claude Code 같은 도구에서 더 많은 도움을 받음 - 나도 동의함. Emacs에서 로컬 모델과 gemini 3 flash를 통합해 쓰고 있음 하지만 평소엔 LLM을 꺼두고 필요할 때만 켬 **소형 특화 모델**의 잠재력이 과소평가되고 있다고 생각함 관련해서 ‘Winning Big With Small AI’라는 책을 쓰고 있음 - 약간 주제에서 벗어나지만, 왜 그렇게 **보일러플레이트 코드**가 많은지 궁금함 대부분은 유틸리티나 라이브러리로 리팩터링할 수 있다고 생각함 나는 연구용 파이프라인 코드를 주로 써서 그런지 다르게 느껴짐 참고로 [yasnippet](https://github.com/joaotavora/yasnippet), [ultisnips](https://github.com/SirVer/ultisnips), [VSCode snippets](https://code.visualstudio.com/docs/editing/userdefinedsnippets) 같은 도구로도 기본적인 자동완성을 구현할 수 있음 - Junie는 별로지만, 자동완성 불만이라면 IntelliJ에도 **로컬/클라우드 자동완성** 기능이 있음 - 보일러플레이트 문제의 해결책이 결국 **자동 생성**으로 귀결되는 게 좀 씁쓸함 - 이런 걸 정말 오래 기다렸음 Cursor가 자동완성만 쓰는데도 월 20달러를 요구해서 불만이었음 직접 만들까도 고민했는데, 로컬에서 돌릴 만큼 작은 모델이 쓸 만할지 확신이 없었음 그래서 VSCode 확장을 급히 만들어봤는데 모델은 꽤 괜찮음 과거 로컬 모델은 인라인 완성에서 형편없었는데 이번엔 훨씬 나음 **경쟁이 활발해지길 기대함** - 궁금한 점 있으면 알려달라 함 **token healing** 같은 기능으로 품질을 높였다고 함 — [관련 글](https://blog.sweep.dev/posts/token-healing-autocomplete) - 1.5B 모델이 로컬에서 돌아갈 만큼 작다고 들었는데, Sweep AI JetBrains 플러그인에서도 실제로 로컬 실행되는지 궁금함 설치하면 모델이 자동 다운로드되고 외부 통신이 없는지 알고 싶음 - 현재는 아니고, JetBrains 플러그인은 **호스팅된 대형 모델**을 사용함 - JetBrains 플러그인에서 로컬 엔드포인트를 설정하는 방법은 없는 것으로 보임 - JetBrains의 **AI 구현 수준이 너무 낮아서** 놀랐음 여러 해가 지났는데도 여전히 이런 수준이라니, 오히려 새로운 회사가 더 잘할 수 있을 정도임 기술적 글도 흥미로웠음 - 고마움. 피드백이나 질문 있으면 언제든 환영함 - GLM-4.7-Flash와 이번 발표를 보며, **소형 모델의 한계 돌파**가 진짜 흥미로움 이제 내가 가진 하드웨어에서도 충분히 돌아가는 모델들이 점점 좋아지고 있어서 기대됨 - 정말 멋짐 특히 **레포지토리에서 next edit 학습 데이터**를 어떻게 생성했는지가 궁금함 관련 통찰을 듣고 싶음 - 자세한 내용은 [공식 블로그 글](https://blog.sweep.dev/posts/oss-next-edit)에 있음 - 훌륭함. 관련 블로그 글도 매우 흥미로웠음 Neovim용 플러그인이 곧 나오길 바람 [관련 글](https://blog.sweep.dev/posts/oss-next-edit) - 이미 이 모델과 연결된 Neovim 플러그인을 만든 사람이 있다고 들음 - [llama.vim](https://github.com/ggml-org/llama.vim)도 있음 Qwen3 Coder와 함께 잘 작동했고, infill만 지원되면 문제없을 듯함 오늘 테스트해볼 예정임 - 이미 플러그인 작성자가 이 스레드에 댓글을 남겼음 - next-edit 모델과 FIM 모델의 차이를 잘 모르겠음 각각 언제 사용하는 게 좋은지 설명해줄 사람 있으면 좋겠음 가능하면 Sublime용 플러그인도 만들어서 직접 써보고 싶음 - 나도 궁금해서 Claude에게 플러그인을 만들어보라고 요청했음 기본 자동완성 기능을 활용하는 구조임 [AItoComplete](https://github.com/lumnn/AItoComplete)에서 확인 가능함 - 내 추측으로는 FIM이 **Fill-In-the-Middle**의 약자일 것 같음 기존 자동완성은 단순히 끝부분을 채우지만, FIM은 **코드 블록 사이를 채우는 방식**임 즉, 삽입 지점 전후의 문맥을 모두 보고 가장 자연스러운 중간 완성을 찾는 모델임