▲

로컬 LLM과 오프라인 위키피디아 비교

 (evanhahn.com)
4P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 최근 MIT Technology Review 기사에서 로컬 LLM을 오프라인 백업 위키피디아와 비교하는 아이디어가 소개됨
  • Ollama 라이브러리의 주요 LLM 모델 파일 크기와 Kiwix에서 제공하는 오프라인 위키피디아 번들의 용량을 직접 비교함
  • LLM 파일과 위키피디아 데이터는 목적, 강점, 약점이 달라 단순 비교는 어렵지만, 용량 기준으로 흥미로운 차이가 있음
  • 일부 LLM(1~4GB 모델) 은 단순 영어 위키피디아(약 1GB)보다 크고, 전체 위키피디아(57GB)는 대형 LLM(20~32GB)보다 큼
  • 파일 크기 외에 메모리, CPU 요구사항 등 현실적 고려가 필요하며, 실제 사용 목적에 따라 선택이 달라질 수 있음

로컬 LLM과 오프라인 위키피디아 비교

서론 및 비교 계기

  • MIT Technology Review에서 최근 "How to run an LLM on your laptop"이라는 기사가 소개되었음
  • 기사에서는 로컬에서 LLM을 실행해 오프라인 환경에서도 지식 활용이 가능하다는 점을 강조함
  • Simon Willison의 "'"오프라인 LLM은 위키피디아의 요약, 불완전 버전 같아 아포칼립스 상황에서 USB만 있으면 사회 재부팅에 도움이 된다'는 비유**가 인상적임

모델 및 데이터 크기 비교

  • Ollama 라이브러리의 여러 LLM 모델과 Kiwix에서 제공하는 오프라인 위키피디아 번들 파일 크기를 비교함
  • 비교를 위해 일반적인 소비자용 하드웨어에서 실행 가능한 모델과, 이미지가 없는 위키피디아 데이터로 한정함
  • 주요 비교 결과는 아래와 같음:
    • 가장 작은 요약본
      • Best of Wikipedia (상위 5만개, 요약본): 356.9MB
      • Simple English Wikipedia (요약본): 417.5MB
    • 대표 LLM 모델 (소형)
      • Qwen 3 0.6B: 523MB
      • Deepseek-R1 1.5B: 1.1GB
      • Llama 3.2 1B: 1.3GB
    • 대표 LLM 모델 (중대형)
      • Deepseek-R1 8B / Qwen 3 8B: 5.2GB
      • Gemma3n e4B: 7.5GB
      • Deepseek-R1 14B: 9GB
      • Qwen 3 14B: 9.3GB
    • 위키피디아 전체
      • Wikipedia (전체): 57.18GB
  • 위키피디아 상위 5만개 기사는 356.9MB로 매우 작음
  • 최소 LLM(0.6B, Qwen) 은 523MB로 단순 위키피디아 요약본보다 큼
  • 전체 위키피디아(57.18GB) 는 최대 LLM(20GB) 보다 훨씬 큼

비교의 한계 및 고려사항

  • 직접적인 비교가 어려움: 백과사전(데이터)과 LLM(생성형 모델)은 본질적으로 목적과 구조가 다름
  • 파일 크기만이 중요하지 않음: LLM은 파일 크기 외에도 실행 시 메모리와 CPU 자원을 많이 필요로 함. 오프라인 위키피디아는 저사양 기기에서 구동이 더 쉬움
  • 실제 사용 목적별 유용성: 예를 들어, 화학 분야만 다운로드할 수도 있고, 특정 하드웨어에 최적화된 LLM을 쓸 수도 있음
  • 선정 기준의 주관성: 비교에 사용한 항목 선정이 주관적임

결론 및 시사점

  • 위키피디아 상위 5만개 기사와 Llama 3.2 3B 모델이 파일 크기로 비슷한 수준임
  • 가장 작은 위키피디아 번들은 최소 LLM보다도 작고, 전체 위키피디아 파일은 가장 큰 LLM보다 큼
  • 충분한 스토리지를 가진 환경에서는 LLM과 위키피디아 데이터를 모두 다운로드해 활용하는 것도 고려할 만함
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • LLM의 강점은 단순히 지식 저장이나 검색이 아니라 이해력에 있음, 위키피디아처럼 단순 데이터가 아니라, 모호하거나 부정확한 질문도 파악해서 사용자 수준에 맞춰 설명해주고 여러 분야를 연결함, 사회를 재시작하는 상황에서는 이런 상호작용적 이해가 더 값질 수 있음, 단순히 지식 스냅샷이 아니라, 사람들이 그걸 활용하고 배울 수 있는 도구가 된다고 봄
    • 신뢰할 수 없는 컴퓨터가 정보화 이전 사회에서 신처럼 숭배받는 것, 스타트렉 에피소드 연상됨
    • LLM이 “더” 값진지는 모르겠지만 확실히 유용함, 현 AI 사용 방식은 별로 좋아하지 않음, 근본적으로 강화된 자동완성 같음, 그래도 검색엔진으로서는 훌륭하게 동작함, Copilot에게 짧은 질문을 하면 종종 괜찮은 답을 얻음, 그러나 아주 깊은 기술적 질문을 하면 헛소리를 많이 함, 항상 경계가 필요함, CentOS 저장소 파일 생성을 요청했는데 전반적으로 완벽했지만 gpgkey를 http로 지정해서 보안이 뚫려버린 경험 있음
    • 이상적으로라면 다른 사람 요약물보다 직접 정보원을 비판적으로 읽어야 함, 학교에서 다들 배우고 동의하지만 실제로 하는 이는 드묾, 졸업 후에는 삼차 정보원만 신뢰하는 경향 있음, LLM을 활용해 해당 주제의 최신 사학 흐름이나 참고할 만한 자료를 찾을 수 있었음, 반면에 위키피디아 편집자들이 위키피디아가 부정확하다고 말하면 적대적으로 구는 사례도 많았고, 실제로 참고문헌을 확인하지 않으면 오도되는 내용도 많이 경험함
    • 컴퓨터나 스마트폰이 남아있다는 전제임, 위키피디아나 책 몇 권을 인쇄 보관하는 게 안전한 백업이 될 수도 있음, 하지만 정말로 사회가 재부팅된다면 아예 완전히 다르게 시작해보는 것도 의미 있을 수 있음
    • 오프라인 위키피디아와 다른 정보원, 그리고 로컬 LLM 조합이 최선이라고 생각함, LLM이 간결하고 관련 링크 제공한다면 더 좋음, 검색기능이 들어간 LLM은 설명이 너무 장황하고, 더 많은 링크를 제공해 원하는 정보로 이동할 수 있게 해주는 게 더 좋음
  • “USB 스틱 하나로 사회를 재부팅한다”는 건 인터뷰 중에 그냥 던진 말이었고, 이게 기사에 쓰일 줄 몰랐음 기사 링크, 여러 사람이 위키피디아를 USB에 담는 게 합리적이라고 했고 동의함, 위키피디아 덤프는 MySQL이라 SQLite로 변환하고 FTS 쓰는 게 더 편할 것 같음, 1TB 이상 USB도 쉽게 구할 수 있어서 저장공간 걱정은 거의 없음
    • 이런 지식을 미리 탑재한 USB 스틱을 만들어 판매하는 회사를 누군가 차릴 법함, 전자기 충격 보호용 박스까지 포함해서 실제 재난 상황 때 큰 도움 줄 수 있음, 보존 가치 가장 높은 건 대규모 재난 리스크에 대한 정보라고 생각함, 저작권 문제로 ‘Global Catastrophic Risks’ 같은 책은 담을 수 없지만, 관련 웹페이지 등은 크롤링할 수 있을 것 같음
    • 10년 넘게 휴대전화나 PDA에 로컬 위키피디아 덤프를 담아 다녔음(최근 5년은 사진까지 포함), 재난 대비뿐만 아니라 오프라인 용도로도 자주 도움이 됨, 최근엔 LLM 등 모델이 정말 유용해져서, RAG 형식으로 로컬 모델과 위키피디아를 결합하면 시너지 있을 것으로 기대함
    • 예전 댓글 재인용함, 모든 디지털화된 책이 30TB 정도, 압축하면 5.5TB 정도로, 2TB 마이크로SD 카드 3장에 들어감, 대략 750달러면 전체 휴대 가능함
    • 굳이 SQL 쓸 필요 없이 Kiwix 쓰면 됨
    • 기사가 너무 거창하게 시작하는 게 약간 거슬림, 기자들이 항상 도구를 너무 웅장하게 프레이밍하는 느낌, 기분이 묘함
  • 지금 막 ‘wikipedia_en_all_maxi_2024-01.zim’을 다운로드 중임, libzim으로 페이지 추출해 LLM과 연동하려 함, zim 파일은 HTML로 페이지 저장되어 있고 약 100GB임, 이유는 HDD에 대량 저장된 게임 목록(제목뿐, 따로 카테고리X)을 위키피디아 기사와 매칭해 장르나 정보로 정리하려고 함, 실험해보니 LLM(Mistral Small 3.2 quantized)이 놀랍게도 혼돈을 잘 정리해줌, llama.cpp로 커스텀 스크립트에서 빠르게 구동할 수 있음
    • 사실 이런 게임-위키 연동 작업은 Wikidata 쿼리가 훨씬 쉬움, 심지어 영문 위키에 아직 없는 게임도 포함될 수 있음
    • 이런 기술적 경험담이 바로 HN을 보는 진짜 이유임, 개인적으로 고민하며 만든 무언가를 충분한 디테일로 공유해서 신선하게 느껴짐, 나도 LLM을 직접 만들어보고 있는데 이렇게 유용한 사례는 처음 봐서 더 배워야 할 것 같음, 좋은 정보 고맙게 생각함
  • 위키피디아, arXiv 덤프, 오픈소스 코드는 실행 가능한 코드와 신뢰도 있는 정보가 대부분이고, 값싸고 검색하기 쉬움, FOSS 앱은 바로 쓸 수 있고, 위키는 주제를 소개하거나 정리해줌, 반면 LLM은 특히 소형 모델일수록 결과를 지어내지만, 깔끔하지 않은 질문에도 대답을 해주려고 하고 (가끔은) 방대한 원자료 중에서 직접 읽고 정리도 할 수 있음, 오프라인 작업 상황에서는 존재하는 라이브러리를 최대한 활용하는 게 좋다고 느끼며, 코딩 도우미로서의 LLM도 실사용 예시가 생각나긴 함, 다만 로컬 모델 사용 경험은 없고, 벤치마크에서 Qwen3 32B는 코딩 보조가 된다고 하니 언젠가 활용 가능할 것으로 보임
  • LLM의 덜 언급된 강점 중 하나는 언어에 구애받지 않는 지식 활용임, 영어 위키는 대부분 내용이 잘 있지만 다른 언어는 그렇지 않음, 영문 위키에도 없는 정보가 타 언어 위키에 있는 등, LLM은 이 모든 걸 하나로 합쳐서 다양한 언어로 접근할 수 있음
  • AI 회사가 웹 전체를 LLM에 증류해서 똑똑한 컴퓨터를 만들었는데, 왜 인간은 저작권 있는 부분까지 넣어 새로운 초일류 위키피디아를 만들지 못하는지 의문이 듦, 왜 아이들은 AI 회사보다 못해서 이런 걸 못 만드는지 궁금함
    • 그건 우리가 실제로 해왔던 일임, 다만 요즘은 백과사전도 잘 안 팔림
    • 그게 도서관임
  • Wikipedia Monthly라는 위키피디아 월간 덤프를 언급하고 싶음, 341개 언어 총 205GB, 영어만 24GB임, MediaWiki 마크업에서 클린 텍스트로 변환돼서 로컬색 인덱스나 다양한 활용에 좋음, Simple English Wikipedia는 내용이 얕고 정확하지 않다고 느낌, Wikipedia Monthly 블로그 링크
  • LLM의 유용성 논의에서 늘 상황별 구체적인 활용도가 빠지는 게 아쉬움, LLM 등장 이전엔 정보검색과 머신러닝에서 엄격한 기준과 평가셋이 있었지만, 현시점에서 LLM이 더 범용적이고 다양한 과제를 해결할 수 있게 되었음에도 실제 LLM 대 다른 방법의 벤치마크 자료가 더 많지 않은 게 의아함, 연구계 동향을 잘 몰라서 내가 못 보고 있는 걸 수도 있음
  • LLM이 부정확한 정보 제공이라는 논란이 많은데, 이상적인 ‘도메스데이 정보 질의 데이터베이스’는 LLM + 파일 아카이브 구성이 최선이라 봄, 1단계: LLM이 인간의 모호한 질문을 이해해서 핵심 개념들과 관련 위키 문서 등 링크 목록을 제공, 2단계: 사용자가 제공된 문서에서 직접 신뢰도 높은 정보를 확인할 수 있음
    • 잔뜩 비관적인 나조차 LLM은 인간 글을 검색어로 번역해주는 도구로는 잘 쓸 수 있을 것 같음, 중개자보다는 조언자나 튜터로 활용하는 게 이상적이라고 생각함, 결국 사용자가 한계를 뛰어넘는 게 중요함
  • “$1-distill-$2”처럼 이름 붙은 모델은 (간혹 “-distill”없음) $2 모델에 $1의 출력을 학습시켜 만든 “지식 증류(distillation)”이므로, 이름과 달리 $1 그 자체가 아님, 기사에서 나오는 “Deepseek-R1 1.5B” 같은 모델은 실제 존재하지 않고 이런 식임
답변달기