文章探讨了本地运行的大型语言模型（LLM）与离线维基百科下载文件的大小对比。作者通过比较Ollama库中的模型和Kiwix提供的维基百科下载文件，发现不同规模的LLM在存储空间上差异显著，部分模型如Qwen 3 8B和Deepseek-R1 8B的下载大小达到5.2GB，而精简版维基百科如“Best of Wikipedia”仅需356.9MB。文章旨在探讨在资源有限的情况下，如何选择合适的信息存储方式。

本地大语言模型与离线维基百科的对比

两天前，《麻省理工科技评论》发表了一篇题为《如何在你的笔记本电脑上运行大语言模型》的文章。文章开头讲述了一个在末日场景中使用离线大语言模型（LLM）的趣闻。“‘这就像拥有一个奇怪、浓缩且有缺陷的维基百科版本，所以我可以用我的小U盘帮助重启社会，’[西蒙·威利森]说道。”

这让我不禁思考：本地大语言模型的大小与离线维基百科下载的大小相比如何？

我将Ollama库中的一些模型与Kiwix上的各种下载进行了比较。我选择了一些可以在消费级硬件上运行的模型，以及没有图片的维基百科捆绑包，以便更好地进行比较。以下是我发现的结果，按大小排序：

| 名称 | 下载大小 | | --- | --- | | 维基百科精选（最佳5万篇文章，无详情） | 356.9MB | | 简单英语维基百科（无详情） | 417.5MB | | Qwen 3 0.6B | 523MB | | 简单英语维基百科 | 915.1MB | | Deepseek-R1 1.5B | 1.1GB | | Llama 3.2 1B | 1.3GB | | Qwen 3 1.7B | 1.4GB | | 维基百科精选（最佳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 | | 维基百科（无详情） | 13.82GB | | Mistral Small 3.2 24B | 15GB | | Qwen 3 30B | 19GB | | Deepseek-R1 32B | 20GB | | Qwen 3 32B | 20GB | | 维基百科：前100万篇文章 | 48.64GB | | 维基百科 | 57.18GB |

这个比较有许多需要注意的地方：

• 这是一个苹果与橙子的比较。百科全书和大语言模型有不同的目的、优势和劣势。它们是根本不同的技术！

• 文件大小并不是唯一重要的细节。大语言模型，即使是本地的，也可能占用大量内存和处理器资源。离线维基百科在我的老旧、低功耗笔记本电脑上运行得更好。

• 其他条目可能对特定目的更有用。例如，你可以下载关于化学的维基百科文章，或者一个更适合你硬件的大语言模型。（而且Kiwix还有很多其他可以下载的内容，比如整个Stack Overflow。）

• 我根据感觉选择了这些条目。这个比较并不严谨！

尽管有这些注意事项，我认为有趣的是，维基百科的最佳5万篇文章大致相当于Llama 3.2 3B。或者维基百科可以比最小的大语言模型更小，也可以比最大的更大——至少在消费级硬件的离线场景中。

也许我会两者都下载，以防万一。

评论内容主要围绕LLM（大语言模型）与Wikipedia的比较及其在不同场景下的应用展开，观点多样且各有侧重。以下是总结：

1. LLM与Wikipedia的结合

   • 有评论者认为LLM与Wikipedia的结合（如RAG模型）是可行的，甚至建议两者可以同时使用。
     • 引用："Why not both? LLM+Wikipedia RAG"（评论1）
   • 另一位评论者提到，将Wikipedia下载到USB上并与LLM结合使用是合理的，尤其是将MySQL转换为SQLite以优化存储。
     • 引用："Wikipedia dumps default to MySQL, so I’d prefer to convert that to SQLite and get SQLite FTS working."（评论2）

2. LLM的优势

   • LLM的核心优势在于其理解能力，能够处理模糊或不完整的问题，并帮助用户找到答案，尤其是在“重启社会”的场景下，这种交互性可能比静态知识更有价值。
     • 引用："LLMs will return faulty or imprecise information at times, but what they can do is understand vague or poorly formed questions and help guide a user toward an answer."（评论4）
   • 但也有评论者指出，LLM的输出质量依赖于输入提示的质量，如果用户不知道如何提问，信息可能无法有效获取。
     • 引用："If you don’t know what to ask (likely in the apocalypse scenario), then that info is locked away in the weights."（评论9）

3. Wikipedia的优势与局限性

   • Wikipedia的优势在于其可搜索性和全面性，用户可以直接阅读和查找信息，而不依赖于提问技巧。
     • 引用："On the other hand, with Wikipedia, you can just read and search everything."（评论9）
   • 但也有评论者指出，缺少讨论页面和版本历史的Wikipedia快照可能会丢失关键上下文，尤其是在LLM增强的文本分析中。
     • 引用："Wikipedia-snapshots without the most important meta layers... would be useless to me as critical contexts might be missing."（评论5）

4. 技术细节与实用性

   • 有评论者提到，Wikipedia的压缩率可能比LLM更高，且当前大容量USB存储设备使得存储Wikipedia成为可能。
     • 引用："1TB or more USB sticks are pretty available these days so it’s not like there’s a space shortage to worry about for that."（评论2）
   • 另一位评论者分享了使用LLM与Wikipedia结合的实际案例，如通过LLM对下载的游戏进行分类。
     • 引用："AFAICT the zim files have the pages as HTML and the file i’m downloading is ~100GB."（评论10）

5. 其他观点

   • 有评论者提出，AI公司通过提炼整个网络来训练LLM，而人类是否可以通过类似方式创建更优质的Wikipedia，以提升教育水平。
     • 引用："Why humans can’t do the same to make the best possible new Wikipedia with some copyrighted bits to make kids supersmart?"（评论3）
   • 还有评论者提到Wikipedia Monthly项目，提供了按语言分类的Wikipedia数据，适合本地搜索索引或NLP研究。
     • 引用："Wikipedia Monthly, a monthly dump of wikipedia broken down by language and cleaned MediaWiki markup into plain text."（评论11）

总结：评论者普遍认可LLM与Wikipedia的结合潜力，但也指出了各自的局限性。LLM在交互性和理解能力上具有优势，而Wikipedia在信息全面性和可搜索性上更胜一筹。技术细节如存储格式、压缩率和实际应用场景也被广泛讨论。