上个月，一位做独立开发的朋友向我诉苦：他每天要在邮件、Slack 日志、本地 Markdown 笔记和 Chrome 标签页之间来回切，整理上下文就要 20 分钟。他试过 ChatGPT，但涉及客户数据他不敢上传。我给他看了我的方案——一台 M2 Ultra Mac Studio 上跑的本地助手，响应比云端快，数据全在本地，还能调用系统日历和文件。
他不信：“671B 的 DeepSeek-V3.1？这种大家伙只能在集群上跑吧？” 我给他演示后，他沉默了几秒，然后掏出手机开始查内存条价格。
这其实是一个常见误区——以为大模型本地部署一定需要天价硬件。实际上，有了量化技术和 Ollama 0.24.0 这类集成工具，把 DeepSeek-V3.1 搬上个人工作站，已经不再是工程师的专利。
谁需要本地个人助理？
简单说，只要你的工作流里频繁出现敏感数据——客户合同草稿、财务表格、未公开发布的设计稿——或者你对延迟极度敏感，一个纯离线的 AI 助理就比任何云端服务划算。
云端模型（哪怕是最快的 API）每次请求都要经过网络往返，还要在服务端排队。本地推理的延迟≈推理时间，对于代码补全、实时翻译这类高频场景，体验是碾压级的。
更关键的是数据主权。你的对话记录、文档内容不会离开你的设备。这对自由职业者和中小企业来说，不仅意味着隐私保护，有时还直接决定能否通过客户的安全合规审查。
硬件到底要多高？
先抛结论：不同硬件跑出来的助理能力差距极大，但起步门槛比你想象的低。
DeepSeek-V3.1 原版是一个 671B 参数的 MoE 模型——MoE 就像一家公司里有很多专家，每次来活儿只激活最相关的几位，所以实际运算量远比同尺寸的稠密模型小。但 671B 参数的完整精度（FP16）仍需要约 1.3TB 显存，普通用户显然扛不住。
打破这个瓶颈的关键技术叫量化——把模型参数从高精度浮点数压缩到低精度整数，就像把一张无损 TIFF 图片存成 JPEG：文件小了很多，肉眼几乎看不出区别。量化得越狠，需要的显存/内存越少，但回答质量会有相应折损。
以下是实测可用的几种配置：
| 量化级别 | 模型大小 | 最低内存 | 适用硬件 |
|---|---|---|---|
| Q4_K_M | ~320GB | 256GB+ | Mac Studio (M2 Ultra 192GB) 需内存溢写，速度很慢 |
| Q3_K_S | ~240GB | 192GB | M2 Ultra 192GB 勉强运行，约 4-5 token/s |
| IQ2_XS | ~180GB | 128GB | 两块 RTX 6000 Ada 或 M3 Ultra 128GB |
| IQ1_S | ~120GB | 96GB | 高端消费级双卡可选 |
如果你只有一台普通的 M 系列 MacBook（比如 64GB 统一内存），跑原版 671B 不现实。但你可以换用蒸馏版：DeepSeek 官方蒸馏的小模型（如 70B 参数），用 Ollama 加载 Q4_K_M 量化版后仅需 ~40GB 内存，在 M3 Max 64GB 机型上能跑到 12 token/s，足够日常助理使用。Ollama 支持 deepseek-v3.1:671b 标签，但你也可以在 ModelFile 里指定锅烧的量化模型。
用 Ollama 搭起来（只需 10 分钟）
即使你不会编程，只要会打开终端，也能搞定。
第一步：安装 Ollama 0.24.0
macOS 可以直接从官网下载，或者用 Homebrew：
brew install ollama
Windows 和 Linux 也有对应安装包。
第二步：下载模型并启动
打开终端，拉取 DeepSeek-V3.1（Ollama 会根据你的硬件自动选择合适的量化级别）：
ollama pull deepseek-v3.1:671b
下载过程可能持续数小时（模型文件巨大），完成后直接用命令行测试：
ollama run deepseek-v3.1:671b "帮我起草一封给客户的中文邮件，告知项目进度延迟一周，语气诚恳但不卑微。"
如果你硬件不够，Ollama 会报内存不足。这时可以拉一个蒸馏版本或更高压缩的量化模型（需从社区获取 GGUF 文件，然后用 Modelfile 导入）。
第三步：接入个人数据
光有一个大模型还不够，助理需要了解你的上下文。用 LangChain（langchain-core==1.4.0）搭建 RAG 管线——Retrieval-Augmented Generation，就是让模型在回答前先翻你的本地文档。你可以把 Obsidian 笔记、PDF 合同、邮件导出等放进本地向量数据库（如 ChromaDB 1.5.9），模型每次会先去检索相关片段再生成回答。
一个最简示例（需 Python 环境）：
from langchain_community.llms import Ollama
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
# 加载本地模型
llm = Ollama(model="deepseek-v3.1:671b", temperature=0.3)
embeddings = OllamaEmbeddings(model="nomic-embed-text")
# 加载本地向量库
db = Chroma(persist_directory="./my_notes_db", embedding_function=embeddings)
# 创建检索式问答链
qa = RetrievalQA.from_chain_type(llm=llm, retriever=db.as_retriever())
response = qa("上周客户反馈的主要问题有哪些？")
print(response)
配合 Open WebUI（v0.9.5）这类图形界面，你可以得到一个类似 ChatGPT 的聊天窗口，背后全是本地数据。
这意味着什么？
当 671B 参数的顶级模型可以跑在个人设备上，几个旧认知正在被打破：
对小团队和独立开发者： 以前只有 SaaS 巨头才能养得起的 AI 助理能力，现在变成了一次性硬件投入。你的月费归零，每次请求零成本，而且没有 API 调用频率限制。
对隐私敏感行业（法律、医疗、金融）： 合规不再是障碍。你可以把模型部署在物理断网的机器上，让它处理保密合同、病历、交易记录。
对硬件生态： 统一内存架构（比如苹果的 M 系列）突然变成 AI 工作站的香饽饽，因为它的内存既是 CPU 内存也是显存，能跑需要超大容量的模型。过去大家比的是 GPU 算力，现在比的可能是“你能塞多大内存”。
当然，现实也有局限：全速 671B 模型仍然需要接近 200GB 内存才能流畅，这不是每个人都有的配置。但在 Q3 量化下，一台顶配 Mac Studio 就能让它以 5 token/s 左右的速度工作——慢，但够用。而且硬件每年在进化，M4 Ultra 已经传出，内存上限还在往上推。
最终，本地 AI 助理不是要替代云端服务，而是多了一个选项：当数据主权、延迟、成本三个条件中任意两个成为瓶颈时，你有一个可行的备用方案——而且它就在你桌下那台主机里。
下次你再犹豫要不要把合同草稿扔进网页聊天框时，不妨想一想：也许它最好的去处，是不联网的那个终端窗口。