本地跑模型的理由通常很实在：数据不出网、没有按量计费、离线也能用、响应延迟可控。 但动手之前有两件事必须先想清楚，否则大概率是折腾一圈又回到 API：**显存够不够**，以及**本地模型到底能干什么**。 ## 显存估算：一个够用的公式 模型占用的显存主要由两部分构成。 **第一部分：权重** ``` 权重显存 ≈ 参数量 × 每个参数占用的字节数 ``` 常见的每参数字节数： | 精度 | 每参数字节 | 7B 模型约需 | |---|---|---| | FP16 | 2 | 14 GB | | INT8 | 1 | 7 GB | | Q4 量化 | 约 0.5-0.6 | 约 4 GB | **第二部分：KV Cache** 这是容易被忽略的一块。上下文越长，缓存的键值越多，占用越大，而且**它随并发数和上下文长度线性增长**。多开几个会话、上下文拉长，显存就上去了。 再加上框架本身的开销，**结论是：给估算值留出 20% 到 30% 的余量。** 所以一块 8GB 显存的卡，跑 Q4 量化的 7B 模型是合适的；想跑 13B 就得 Q4 加短上下文，并且实测。 ## 用 Ollama 上手 Ollama 把模型下载、量化选择、服务启动都打包了，是目前最省事的选择。 ```bash # 安装后拉一个模型（以 7B 级别为例） ollama pull qwen2.5:7b # 直接对话 ollama run qwen2.5:7b # 作为服务启动（默认 11434 端口，兼容 OpenAI 风格接口） ollama serve ``` 启动服务之后，现有代码里把 `base_url` 指向本地即可，很多 SDK 直接支持： ```python from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "总结一下这段日志的异常"}], ) ``` 这样迁回云端 API 时只改两行，代价很低。 **量化版本怎么选**：Ollama 的模型标签里会带量化信息（如 `q4_K_M`、`q8_0`）。显存紧张选 Q4，追求质量选 Q8 或 FP16。**Q4 是大多数场景的甜点**，质量损失不明显，显存占用减半。 ## 现实的能力预期 这部分比技术细节更重要，很多失望来自预期错位。 **本地小模型擅长的**： - 文本分类、打标签 - 结构化信息抽取（从日志里提出 IP、时间、错误码） - 固定格式的摘要与改写 - 简单的意图识别 这些任务有共同点：**判断空间小、输出短、可验证。** 7B 级别的模型做得不比大模型差多少。 **不擅长的**： - 多步推理、复杂代码生成 - 需要广博知识的开放问答 - 长文档的深度理解 一句话：**让本地模型做「流水线上的一道工序」，别让它做「需要思考的任务」。** 如果你的场景是每天处理几千条日志、给文章分类、做批量抽取，本地部署的经济性非常明显——电费加显卡折旧，远低于按 token 付费。 ## 什么时候不该本地部署 - **需求波动大**：大部分时间闲置、偶尔峰值，按量付费更划算； - **需要最强能力**：旗舰模型的能力差距在复杂任务上仍然明显； - **没有合适的显卡**：CPU 推理能用，但速度会让你放弃； - **运维精力有限**：本地部署意味着你要自己管显卡驱动、模型更新、服务可用性。 ## 小结 本地部署的决策顺序是：**先估显存（参数量 × 每参数字节 + KV Cache + 余量）→ 再想清楚任务类型 → 最后才是选工具。** Ollama 把门槛降得很低，半小时能跑起来。但真正决定它值不值的，是你有没有一个**高频、固定、可验证**的任务让它干。有的话很划算，没有的话它只是一块会发热的显卡。