用 Ollama 和 LM Studio 处理你的文档——本地模型能扛什么、扛不了什么
通过 Ollama 或 LM Studio 运行的本地模型，能做好短小、边界清楚的文档活——解释一段文字、回答关于一篇打开着的论文的问题、整理一篇笔记——而且这些活从不离开你的电脑。它吃力的是那些需要大上下文和可靠工具调用的长活：一章一章地读完一整本书、翻译几百页、起草书级篇幅的东西。
这个分界值得在开始之前就知道，而不是在一个做不完的任务跑了四个小时之后。
人们为什么想要这个
理由通常就一句话：什么都不能离开这台电脑。 一份签了保密协议的合同、病人的记录、一份未发表的书稿、客户的财务数据。对这类材料，「文字发给一家隐私政策很好的服务商」并不是同一个答案，区别对待是对的。
本地运行的模型，是唯一一种能老实回答「什么都没发到任何地方」的配置。自带一个云端 API key，能从路径上去掉一方；但去不掉这条路径。
本地模型擅长什么
笔记本级别的模型进步很快，对很多日常文档活来说，它们确实够用：
- 解释选中的一段文字——文字短，问题局部。
- 关于一份打开着的文档的问题，只要它能宽裕地装进模型的上下文。
- 整理、改写和总结你自己写的笔记。
- 小修改，反正每一处你都会读。
做这些，主要的代价是速度，在一台新近的电脑上通常可以接受。
它在哪里吃力
有三个特性把大活和小活分开，而笔记本级别的模型在这三点上都最弱：
- 长上下文。 把一本书读好，意味着同时装下大量文字。本地模型跑的上下文常常比云端同类小得多，或者随着上下文填满急剧变慢。
- 可靠的工具调用。 在一本书里导航——打开目录、挑章节、读它们、回头再找一章——是一连串工具调用。一个在某次调用上稍有差错的模型，会让整串都脱轨。
- 几个小时里保持一致。 一份三百页的翻译或一份长稿，是几百次都必须遵循同样指令的调用。小模型会漂。
所以：对整本书的 AI 通读批注、整本书翻译和书级篇幅的起草，是我们不会在本地模型上开始的活。它做起来会很慢，或者做不完。
读图是另一个问题
就框选的一张图表提问、识别一张扫描页，或者读一张拍下来的白板，需要一个能看图的模型。很多流行的本地模型只能处理文字。如果你的模型是这样，这些功能就没有模型可用，直到你把这类活指向一个能读图的模型。
把活分开
对大多数人来说，实际的配置不是全有或全无。MindMax 把模型的活分成几个档位——快活、日常的活、要紧的通读，以及读图——每个档位放哪个模型由你选，还可以按任务单独覆盖。
- 如果什么都不能离开这台电脑，就把每个档位都指向本地模型，并接受长活够不着这件事。把这些文档放在它们自己的文件夹里，这样你永远清楚适用哪套规则。
- 如果一部分材料敏感、一部分不敏感，敏感文件夹的日常问题用本地模型，其他一切的长活用云端模型。
- 如果你只是想省钱，快活用本地模型是个不错的起点。先量一量，再下结论说总体更便宜；你的时间也是账单的一部分。
本地服务商不需要 key。请求发往你自己电脑上的一个地址，关于它们的任何东西都不会到达我们这里。
我们没有声称什么
我们没有发布过具体本地模型的评测，模型能力也每个月都在变。这里的说法是关于活的形态：短小、边界清楚的没问题；长的、多步骤的，才是笔记本级别的模型撑不住的地方。先拿一份短文档，试试你真正需要的那件活。
配置方法见使用你自己的 API key，完整的说明——包括自带 key 在哪些地方等于、哪些地方不等于隐私——见自带 API key。为什么让每个功能都能用你自己的 key 运行，背后的理由见订阅是一种便利，不是一道门槛。