ハクソク

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

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

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

└

情報化以前の社会が神のように扱う不安定なコンピュータ、まるでスタートレックのエピソードみたいだね。

└

ちょっと脱線するけど、https://en.wikipedia.org/wiki/The_Book_of_Koliに似てるね。重要なプロット要素はおしゃべりなソニーのAI音楽プレーヤーなんだ。ちょっとYAだけど、楽しい読み物だよ。

└

確かに。理想的には、他の人の要約を信じたくないし、自分でソースを見たいよね。批判的な目で見ることが大事だし。これは学校でみんな教わることだけど、みんな同意するって言いながら、実際にはほとんど誰もやってないんだよね（時にはそのアイデアを完全に否定する人もいるし）。学校を出たら、三次情報が完全に信頼できるものとして扱われるようになる。LLMを使うことで、そのトピックの現在の歴史学がどこにあるのか、どのソースを深く掘り下げるべきかを知るのに役立ってる。逆に、Wikipediaが信頼できないって言うと、敵対的になるWikipediaの編集者が多いことにがっかりしてる。信頼できないWikipediaの記事に出くわしたことがあって、他のソースを見なかったら大きく誤解されるところだったと思う。

└

オフラインのWikipediaや他のソースのデータベースとローカルLLMの組み合わせが一番いいと思う。LLMが簡潔で、関連ページへのリンクを提供してくれるならね。検索機能があるLLMは、余計なことを話しすぎて、もっと情報を探すためのリンクをくれないから弱いと思うんだ。

└

「もっと」価値があるかは分からないけど、確かに価値はあるよね。今のAIの使われ方は本当に嫌いだ。根本的にはステロイドを使ったオートコンプリートみたいな感じがする。ただ、Googleよりはずっと良い検索エンジンとして機能してるのは認めるよ。Copilotに簡潔な質問をすると、結構いい答えが返ってくることが多い。でも、すごく深い技術的な質問をすると、めちゃくちゃ妄想しちゃう。疑いも必要だね。古いCentOSのリリース用のリポジトリファイルをvault.centos.orgで作成してもらったんだけど、出力は完璧だったのに、唯一の欠点は、RPMの検証用のgpgkeyをローカルファイルじゃなくて普通のHTTPで指定してたこと。HTTPSについては気にしないけど（そのサイトはサポートしてるし）、その答えはセキュリティを完全に無視してたから、一文字の欠如で台無しになってた…

└

LLMは時々間違ったり不正確な情報を返すけど、曖昧な質問やうまく形成されていない質問を理解して、ユーザーを答えに導くことができるんだよね。つまり、メタプロンプトエンジニアリングってこと？

└

それは、ちゃんと動くコンピュータやスマホがまだある前提だけどね。ウィキペディアのハードコピーや数冊の選ばれた本が、もっと安全なバックアップになるかも。一方で、もし本当にそんなリブートをすることになったら、完全なコールドブートが必要かもしれないね…うまくいかなかったら、次は違うことを試してみるのもアリだよね。

└

質問を理解することが、正しい答えを出すことよりも価値がある？それってカルトの基盤だね。

└

社会が「リブート」しないようにする良い方法に聞こえるね。信頼できる知識の「凍結スナップショット」は、間違った指示を出して何が正しいのか分からないシステムよりも無限に価値があるよ。誰でも「複雑なアイデアを簡単に説明できる」けど、正確さを気にしなくていいならね。これってどんなシナリオなんだろう？そんな大惨事があったのに、社会を「リブート」する必要があって、なおかつLLMを動かすためのストレージや計算能力にはアクセスできるって？LLMファンのための終末準備者のファンタジーみたいだね。

└

ボーナスとして、LLMは無限にクソみたいなことを吐き出せるんだよね。

今面白いことに気づいたんだけど、今「wikipedia_en_all_maxi_2024-01.zim」をダウンロードしてるんだ。これをLLMと一緒に使うためにね。ページは「libzim」を使って抽出されるんだよ。:-P ZIMファイルはHTML形式でページが入ってるみたいで、今ダウンロードしてるのは約100GBだよ。（理由は、HDDにダウンロードしたゲームがたくさんあって、タイトルしか整理してなかったから、Wikipediaの記事と照らし合わせてジャンルや情報を整理しようと思ってるんだ。実験してみたら、特に量子化されたMistral Small 3.2がその混沌を理解できて、スクリプトからカスタムのllama.cppプログラムを使って動かすには十分な速さだったんだ。）

└

これこそがHNを読む理由だよ！個人的に投資したものを使って技術的なことをするっていう、ちゃんとしたコメントだね。ちょっとした詳細があって、興味をそそる。これが今までのGenAIのベストな使い方だと思う。俺のコードを書いてくれるわけでもなく、ただソースを読めばいいことを助けてくれるわけでもなく、くだらないスタートアップの資金集めを盛り上げるわけでもない。俺はゼロからLLMを作る作業をしてるんだけど、これが実際に役立ちそうなのは初めてだ。今のところあまり価値を見出せてなかったから、もっと学ぶべきことがあるんだな。教えてくれてありがとう。

└

HDDにダウンロードしたゲームのタイトルだけで、さらに分類もしてないから、ウィキペディアの記事と照らし合わせてジャンルや情報を整理しようとしてるんだけど、実験の結果、LLM、特に量子化されたMistral Small 3.2がその混沌をある程度理解できて、カスタムのllama.cppプログラムを通じてスクリプトから動かすのに十分な速さで動くことが分かった。Wikidataのクエリを使えば、もっと簡単にできるし、英語のウィキペディア記事がまだ存在しないゲームも含まれるよ。

偶然、Wikipedia Monthlyについて投稿したばかりなんだけど、これは言語ごとに分けられたWikipediaの月次ダンプで、MediaWikiのマークアップがきれいに整形されたプレーンテキストだから、ローカル検索インデックスや他のシナリオにぴったりなんだ。341の言語があって、データは205GBもあるよ。英語だけで24GBも！シンプル英語のWikipediaについての私の見解だけど、まあまあだけど、内容は浅くて不正確なことが多いね。0: https://omarkama.li/blog/wikipedia-monthly-fresh-clean-dumps...

「彼らは異なることをする」というポイントはもっと詳しく説明する価値があるね。WikipediaやarXivのダンプ、ダウンロードしたオープンソースコードなどは、実行されるコードと、どんな欠点があっても通常は推測されない情報を持ってる。検索も安価で、何かのためにすぐに使えることが多い。FOSSアプリは実行可能だし、ウィキはトピックを紹介したり調査したりするしね。LLMは特に小さいものは、でっち上げることがあるけど、クリーンなキーワード検索じゃない質問にも対応しようとするし、理論的にはいくつかのタスクを質的に簡単にすることができるかもしれない。例えば、質問に対する答えを得るために大量の生情報を読み込むことができるかもしれない。元の引用のシナリオは、今の私にはちょっと野心的すぎるけど、オフラインでコーディングすることを考えると、既存のライブラリを呼び出す方が、再構築しようとするよりもずっと楽しいだろうなと思う。いいコーディングアシスタントがいるとしてもね。非コーディングのタスクにもアナロジーがあるかも？盲点として、ローカルモデルについての実体験は全くないし、うまく動かせるハードウェアも持ってない。Aiderのような公のベンチマークを見ている限り、Qwen3 32Bのようなものはコーディングをある程度こなせるみたいだから、何か使い道があると考えるべきだね。

LLMが生成する不正確な情報について多くの影が指摘されているから、理想的な終末情報クエリデータベースは、LLMとファイルアーカイブの組み合わせで構築されるべきだと思う。1. LLMは人間からの曖昧なクエリを理解して、必要な点をつなげて、ユーザーに概要を提供し、トピック名や実際のWikipedia記事へのローカルファイルリンクのリストを渡す。2. ユーザーはそのリストにあるWikipedia記事から正確な情報を直接読むことができる。

└

俺はちょっとひねくれた悲観主義者だけど、LLMが活躍できる場所の一つは、文章を検索用語に翻訳するツールとしてだと思うんだ。ただの仲介役じゃなくて、横で励ましてくれるチューターみたいな存在で、普通のユーザーは最終的にはそれを超えていく感じ。

仮想のボイジャー3号ミッションのために、金のディスクの代わりにLLMを搭載すべきだって思ったんだ。最初はすごくシンプルなインターフェースを説明して、単一のデジタルチャンネルの最も簡単な形から始めて、徐々にもっと複雑なものにしていく。すべてのインターフェースの背後には、提供された入力に応じて反応するLLMがいて、最終的には人類の知識を明らかにするっていう感じ。

いいアイデアが浮かんだ！ローカルのLLMとウィキペディアを組み合わせたツールを作るのは面白そうだね。LLMを使って一般的な答えを組み立てて、ウィキペディアをフルテキスト検索やRAGで調べて、根拠となる事実を探す感じ。小さいモデルのハルシネーションをかなり軽減できると思う。

└

こういうのがもっとあってもいいと思うんだ。情報のデータベースや正確なツールに支えられたLLMとか。例えば、複雑な問題を大幅に単純化するリスクはあるけど、LLMは数学が苦手じゃない？計算機を使わせることはできないかな？

あまり話題にされていない利点の一つは、LLMが知識を言語に依存しないものにすることだね。主に英語のウィキペディアを利用する人にはあまり分からないかもしれないけど、他の多くの言語では、よく理解されている概念でもページが貧弱だったりするんだ。でも英語のウィキにも、他の言語でカバーされている大きなギャップがある（主に人や場所について）。LLMはこれらの全てのユニオンを提供して、任意の言語の「レンズ」を通して見ることができるんだ。