大模型本地运行：B、bit 与调用方式详解

一、为什么要本地跑大模型

先说结论：本地跑大模型，现在已经不是发烧友的玩具了。 一台带 8GB 显存的普通游戏本，就能流畅运行一个相当能打的中文模型。

值得本地跑的理由有四个：

• 隐私——数据不出本机。合同、病历、内部文档这类东西，很多人根本不敢往云端传
• 成本——云端 API 按 token 计费，用得多了是真金白银；本地跑除了电费，不花钱
• 离线可用——断网也能用，出差、内网环境不受限制
• 可控——模型版本、参数、上下文长度全部自己说了算，不会被服务商突然改掉

但真动手的时候，几乎所有人都会卡在同样几个问题上：

7B 是什么意思？Q4 又是什么？我这张显卡到底能跑多大的？跑起来之后怎么用？

这篇文章就把这几个问题一次讲清楚。重点在两件事：模型标识里的 B 和 bit 到底意味着什么，以及跑起来之后怎么调用它。

二、B 是什么：参数量

2.1 基本概念

B 是 Billion 的缩写，意思是"十亿"。 7B 就是 70 亿参数。

那"参数"又是什么？你可以把它理解成模型内部的旋钮。一个模型在训练时，会不断调整这些旋钮的数值，让输出越来越接近正确答案。训练结束后，这些数值就固化下来，构成了模型文件。

所以：

参数量 = 模型里有多少个可调数值
       = 模型"记住"和"理解"世界的能力容量

2.2 常见规模

2.3 一个重要提醒

参数量大 ≠ 一定更好用。 这句话在通用任务和垂直领域里，含义完全不同。

在垂直领域（比如农业、医疗、法律），一个配了高质量知识库的 8B 模型，经常能打赢没有知识库的 32B。因为垂直场景的答案取决于"资料准不准"，而不是"模型聪不聪明"——模型再大，没见过你们本地的规范，它也只能编。

另外还有两个变量影响实际表现：

• 训练数据质量——喂的是论文教材，还是网上爬的垃圾，差别巨大
• 训练方式——指令微调、强化学习做得好不好

所以看到两个都是 7B 的模型，实际能力可能差很多。B 只是体重，不是智力。

三、bit 是什么：精度与量化

3.1 为什么会有 bit 这回事

参数是一个个数字，而数字在电脑里要用固定位数来存。这个"位数"就是 bit。

最原始的模型用 FP32（32 位浮点）存每个参数——精度最高，但占地方。一个 7B 模型用 FP32 存，光权重就要 28GB，普通人根本跑不动。

于是就有了量化（Quantization）：

用更少的位数来存同样的参数，牺牲一点点精度，换来体积和速度上的巨大收益。

3.2 各精度的体积

核心公式只有一条，记住它就能自己估算任何模型：

模型体积(GB) ≈ 参数量(B) × 每参数字节数

FP32 = 32 bit = 4   字节
FP16 = 16 bit = 2   字节
INT8 =  8 bit = 1   字节
INT4 =  4 bit = 0.5 字节

套进去算：

看到 Q4 那一列的威力了吗——8B 模型从 16GB 压到 4.5GB，一张 8GB 显存的显卡就能舒服地跑起来。

3.3 量化的质量代价

省了这么多空间，代价是什么？答案是：比大多数人想象的小得多。

关键在 Q4 这个档位——研究表明，模型参数从 16bit 降到 4bit，性能损失通常在可接受范围内；但再往下砍（Q3、Q2），质量会断崖式下跌。

实用结论：优先 Q4_K_M。显存够就上 Q6_K 或 Q8_0。低于 Q4 要谨慎，低于 Q3 基本不建议。

3.4 为什么会有这么多带后缀的名字

你会看到 Q4_K_M、Q5_K_S 这种命名，拆开看：

• Q4——主要量化到 4bit
• K——使用了 K-quant 方法，对不同层用不同精度（重要的层多留几位）
• _M / _S——Medium / Small，同一档位内的粗细之分，M 通常质量更好

所以 Q4_K_M 就是"4bit 主量化 + K 方法 + 中等档"，这是目前公认性价比最高的一档。

四、显存到底要多少

模型体积算出来了，但这不等于显存需求。实际还需要加三块：

实际显存 ≈ 模型权重
         + KV Cache（上下文缓存）   ← 容易被忽略
         + 运行时开销

4.1 KV Cache 是什么

模型在生成文字时，需要记住前面已经说过的内容，否则每生成一个字都要重读全部上文。KV Cache 就是用来存这些中间结果的。

它的大小取决于：上下文长度、模型层数、注意力头数。

经验值：一个 7-8B 模型，在 8K 上下文下，KV Cache 大约占 1-2GB；如果开到 32K 甚至 128K，这块开销会显著增长，有时候比模型本身还大。

所以显存规划时，别只按模型体积算，至少留 1-2GB 给 KV Cache 和运行时。

4.2 推理 vs 训练，差别巨大

举例：8B 模型 Q4 推理约 5GB，但 QLoRA 微调建议 16GB 以上的显存。这是很多人踩的坑——推理跑得动，不等于能微调。

五、怎么跑起来

5.1 工具选择

5.2 用 Ollama 跑起来（三步）

第一步，安装。 官网下载对应系统的安装包，装完即可，不用配环境。

第二步，拉模型并进入对话。

# 拉取一个 8B 的 Q4 模型（约 4.7GB）
ollama pull qwen3:8b

# 直接进入对话
ollama run qwen3:8b

>>> 你好，介绍一下你自己

第三步，验证是否在跑。

# 查看已下载的模型
ollama list

# 查看正在运行的模型
ollama ps

就这么简单。 Ollama 会自动根据你的硬件选择量化版本，并加载到显存里。

5.3 如果显存不够会怎样

模型会自动把一部分层放到内存（CPU）上跑，这叫 offload。结果是：

• 能跑起来，但速度会明显变慢
• 内存占用会升高，因为要装下剩余的权重
• 如果内存也不够，就会开始用硬盘交换，慢到无法接受

所以显存是第一优先级，内存是第二道保险。 内存足够大（比如 64GB）的话，靠 offload 也能跑起比显存大得多的模型，只是慢。

六、跑起来之后怎么调用

这是很多人卡住的第二关——模型跑起来了，怎么用到自己的程序里？

6.1 方式一：命令行对话

就是上面演示的 ollama run，适合临时测试、快速验证效果。

6.2 方式二：HTTP API（最实用）

Ollama 默认在本地 11434 端口提供一个 HTTP 接口，而且兼容 OpenAI 的调用格式。 这意味着你现有的代码几乎不用改，只要把地址换一下。

先确认服务在跑：

curl http://localhost:11434/api/tags

用原生接口调用：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "用一句话解释什么是量化",
  "stream": false
}'

用 OpenAI 兼容接口调用：

curl http://localhost:11434/v1/chat/completions -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "你好"}]
}'

6.3 方式三：Python 代码集成

如果你已经在用 openai 这个库，改一行就行：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",   # ← 只改这里
    api_key="ollama",                        # 本地不需要真 key，占位即可
)

resp = client.chat.completions.create(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "帮我写一个 Python 快排"}],
)
print(resp.choices[0].message.content)

用 requests 直接发请求也可以：

import requests, json

r = requests.post(
    "http://localhost:11434/api/chat",
    json={
        "model": "qwen3:8b",
        "messages": [{"role": "user", "content": "你好"}],
        "stream": False,
    },
    timeout=120,
)
print(r.json()["message"]["content"])

关键点：base_url 指向本地，api_key 随便填（本地服务不校验）。这就是本地模型最大的好处——代码是同一套，随时能在云端和本地之间切换。

6.4 方式四：接进现成的客户端

如果你不想写代码，很多桌面客户端可以直接连本地服务：

• Cherry Studio——支持多模型管理，配置里填 Ollama 地址即可
• Open WebUI——浏览器界面，可以多人共用一台机器上的模型
• 各类 IDE 插件——如 Continue，把本地模型接进编辑器做代码补全

配置方式都一样：填一个地址 http://localhost:11434，选一个模型名。

6.5 让局域网其他机器也能调用

默认只监听本机。如果想让同事的电脑也能用：

# Linux/macOS 设置环境变量后重启服务
export OLLAMA_HOST=0.0.0.0:11434

然后别人就可以通过 http://你的IP:11434/v1 调用了。注意：开放到局域网就没有任何鉴权了，内网可控环境下再用。

七、怎么选配置

内存也很重要：即使显存不够，靠内存 offload 也能跑更大的模型，只是速度慢。有 32GB 以上内存的话，容错空间会大很多。

八、常见问题

8.1 速度太慢怎么办

• 降量化——Q4 换 Q3，体积小了速度会快，但质量下降
• 换小模型——14B 换 8B，速度提升往往比量化更明显
• 缩短上下文——KV Cache 是主要负担之一
• 检查是不是在 CPU 上跑——用 ollama ps 看，如果显示 100% CPU，说明显存没吃上

8.2 回答质量不如云端

这是正常的，本地 8B 和云端旗舰模型确实有差距。但差距在两类任务上表现完全不同：

• 通用问答、翻译、总结——本地小模型够用
• 复杂推理、长文档理解——云端更强

如果任务本身依赖专业知识，更有效的办法不是换大模型，而是给它配知识库（RAG）——这个提升往往立竿见影。

8.3 模型下载很慢

Ollama 的模型放在国外服务器，国内下载可能很慢。可以：

• 直接下载 GGUF 模型文件，手动导入
• 从国内的模型平台（如魔搭）下载，速度会快很多
• 用 llama.cpp 加载本地 GGUF 文件，绕开下载环节

九、小结

把最核心的东西压缩成几句话：

• B = 参数量，决定模型的"体重"和容量，但不等于智力
• bit = 每个参数占几位，决定体积。公式：体积 ≈ 参数量 × 每参数字节数
• Q4_K_M 是甜点，兼顾体积和质量；低于 Q3 不建议用
• 实际显存 = 模型 + KV Cache + 开销，别只按模型体积算
• 推理能跑 ≠ 能微调，微调需要的显存是推理的好几倍
• 调用靠 API，Ollama 兼容 OpenAI 格式，改一行 base_url 就能切换

本地跑大模型这件事，门槛比大多数人想的低，天花板比大多数人想的高。一台普通游戏本就能起步，而真正决定效果的，往往不是模型多大，而是你有没有把它的能力用在对的地方。