ハクソク

世界を動かす技術を、日本語で。

ローカルLLMとオフラインWikipediaの比較

2025年7月20日原文(evanhahn.com)

概要

MIT Technology Reviewの記事を受け、ローカルLLMのサイズとオフラインWikipediaのダウンロードサイズを比較。 OllamaライブラリのモデルとKiwixのWikipediaバンドルを対象。 消費者向けハードウェアで動作可能なモデルと画像なしWikipediaを選定。 ファイルサイズでの比較だが、用途や性能には違いあり。 面白い発見として、LLMとWikipediaのサイズが重なるポイントも存在。

LLMとオフラインWikipediaのサイズ比較

  • MIT Technology Review の記事で、オフラインLLMが終末シナリオで役立つという逸話
  • Simon Willison のコメント：「小型USBでWikipediaの凝縮・不完全版を持ち歩ける」
  • ローカルLLMとオフラインWikipediaの サイズ比較 への関心
  • Ollamaライブラリ のモデルと Kiwix のWikipediaダウンロードを選定
  • 画像なしWikipediaバンドル、消費者向けハードウェア対応モデルで比較

サイズ順リスト（抜粋）

  • Best of Wikipedia（5万記事、詳細なし）： 356.9MB
  • Simple English Wikipedia（詳細なし）： 417.5MB
  • Qwen 3 0.6B： 523MB
  • Simple English Wikipedia： 915.1MB
  • Deepseek-R1 1.5B： 1.1GB
  • Llama 3.2 1B： 1.3GB
  • Qwen 3 1.7B： 1.4GB
  • Best of Wikipedia（5万記事）： 1.93GB
  • Llama 3.2 3B： 2.0GB
  • Qwen 3 4B： 2.6GB
  • Deepseek-R1 8B： 5.2GB
  • Qwen 3 8B： 5.2GB
  • Gemma3n e2B： 5.6GB
  • Gemma3n e4B： 7.5GB
  • Deepseek-R1 14B： 9GB
  • Qwen 3 14B： 9.3GB
  • Wikipedia（詳細なし）： 13.82GB
  • Mistral Small 3.2 24B： 15GB
  • Qwen 3 30B： 19GB
  • Deepseek-R1 32B： 20GB
  • Qwen 3 32B： 20GB
  • Wikipedia: top 1 million articles： 48.64GB
  • Wikipedia： 57.18GB

比較時の注意点と発見

  • LLMと百科事典 は本質的に異なる技術、 用途・強み・弱み が異なる
  • ファイルサイズ だけでなく、LLMは メモリやCPU も多く消費
  • オフラインWikipediaは 低スペックPC でも安定動作
  • 目的に応じた選択 が重要
    • Wikipediaの特定分野記事セットや、ハードウェア最適化LLMの選択肢
    • KiwixではStack Overflow等、他リソースもダウンロード可能
  • 比較基準は主観的、厳密な調査ではない

面白いポイント

  • Wikipediaの「 Best 50,000 Articles」は Llama 3.2 3B と大体同じサイズ
  • Wikipedia全体は 最小LLMより小さく、最大LLMより大きい 場合も
  • オフライン環境での 柔軟な選択肢 として両方ダウンロードも一案

Hackerたちの意見

これは理にかなった比較だね。「小さなUSBメモリで社会を再起動する手助けをする」っていうのは、インタビューの中でジャーナリストに言った軽いジョークだったんだ。まさかそれを記事に使うとは思わなかったよ！ いくつかの人が、WikipediaをUSBメモリにダウンロードするのは賢いアイデアだって指摘してて、俺も同意するよ。WikipediaのダンプはMySQLがデフォルトだから、SQLiteに変換してSQLite FTSを使えるようにしたいな。1TB以上のUSBメモリは今は結構手に入るから、スペースの心配はないよね。

└

本当に価値があるのは両方だと思う。LLMは質問を洗練したり解釈したりするのに役立つし、ウィキはやろうとしていることの各要素に関する実際の情報を提供してくれる。でも、どちらも現代の技術には不十分で、出発点を指し示すだけに過ぎないよね。

└

SQLiteとそのFTSを使うって面白いアイデアだね。FTSの質にはすごく感心したし、これは素晴らしいユースケースだと思う。

└

数週間前の自分のコメントを再投稿するね。 > 「すべてのデジタル化された本は、圧縮すると数TBになる。」実際に生のテキスト形式でどれくらいのデータになるかを推定しようとしたんだ。# annas archive stats papers = 105714890 books = 52670695 # 単語数の推定 avrg_words_per_paper = 10000 avrg_words_per_book = 100000 words = (papersavrg_words_per_paper + booksavrg_words_per_book ) # 数冊の本からの2700万単語のサンプル sample_words = 27809550 sample_bytes = 158824661 sample_bytes_comp = 28839837 # zpaq -m5を使って bytes_per_word = sample_bytes/sample_words byte_comp_ratio = sample_bytes_comp/sample_bytes word_comp_ratio = bytes_per_wordbyte_comp_ratio print("total:", wordsbytes_per_word1e-12, "TB") # total: 30.10238345855199 TB print("compressed:", wordsword_comp_ratio*1e-12, "TB") # compressed: 5.466077036085319 TB だから、非圧縮で約30TB、圧縮で約5.5TBのデータになるんだ。それは3つの2TBのマイクロSDカードに収まるから、SanDiskから750ドルで買えるよ。

└

もちろん、彼らがその角度から記事を開くことにしたのは分かるよね。こういうツールを壮大な言葉で表現しようとするのが気に障る。あなたはどう感じる？

└

こういうタイプの準備知識がたくさん入ったUSBメモリを売る会社を誰か始めるべきだよ。お金を稼ぐだけじゃなくて、世界的な大災害が起きたときに本当に役立つかもしれない。USBメモリを小さな箱に入れて、太陽フレアやEMPの影響から守ることもできるし。保存すべき最も重要な知識は、世界的な大災害リスクについての知識だと思うから、事件の後に人類が再び立ち直れるようにして、同じことが起こらないようにできる。残念ながらこの本は著作権があるから、USBメモリにダウンロードできないけどね：https://www.amazon.com/Global-Catastrophic-Risks-Nick-Bostro... でも、クローリングできるウェブページがあるかもしれないね：https://www.lesswrong.com/w/existential-risk

└

SQLをいじる必要なんてないよ、Kiwixを使えばいい。

└

もう10年以上、ローカルのウィキペディアダンプをスマホやPDAに持ち歩いてるよ（ここ5年は画像付きで）。kiwixやzimの前は、tomeraiderやaardを使ってた。災害対策のためでもあるし、オフラインの準備のためでもある。意外と頻繁に起こるんだよね。でも最近のモデルの有用性について考えていて、次のステップはローカルモデルとローカルウィキペディアをRAGスタイルで組み合わせることだと思うんだ。両方の良いところを活かせるしね。

ちょっと関連する話だけど、AI企業はウェブ全体をLLMに凝縮してコンピュータを賢くしたけど、人間はどうして同じことができないの？著作権のある部分を使って、子供たちを超賢くするための新しいWikipediaを作ることはできないのかな？なんで子供たちはAI企業より劣ってて、ただぶらぶらしてるんだろう？

└

それはやったし、今もやってるよ。今の人たちは百科事典をあまり買わないからね。

└

それってライブラリじゃない？

重要な違いは、LLMの強みは単に知識を保存したり取り出したりすることじゃなくて、理解力にあるってことだね。LLMは時々間違ったり不正確な情報を返すこともあるけど、あやふやな質問や不完全な質問を理解して、ユーザーを正しい答えに導くことができるんだ。複雑なアイデアを簡単な言葉で説明したり、ユーザーの理解度に応じて応答を調整したり、異なる分野をつなげたりもできる。もし「社会を再起動する」シナリオがあれば、そのインタラクティブな理解力はもっと価値があるかもしれないね。単なる知識の静止したスナップショットじゃなくて、人々がそれを使う手助けができるツールになるんだから。

Hacker Newsで議論の続きを見る