想象你是一位重度咖啡爱好者。以前想喝一杯好咖啡，只能去咖啡馆排队，或者从零开始学烘焙、磨豆、手冲。直到你买了一台智能咖啡机——Ollama：把咖啡豆（开源模型）放进机器，按下一个键，一杯咖啡（AI 回答）就出来了。你不需要懂电路图，也不用手动调水温——这台机器会自动完成磨豆、萃取，甚至帮你记住每次的配方。这篇文章带你把这台“智能咖啡机”搬回家：怎么购买豆子（模型管理）、怎么自定义配方（Modelfile）、怎么对外营业（API），以及你的操作台（显卡显存）该有多大。

岗位关联

学会 Ollama，你就掌握了本地大模型部署的最小闭环——花一天时间搞定它，之后的私有化部署、模型评测、端侧 AI 产品原型都从这里起步。

目录
  1. 可视化演示
  2. 初识Ollama
  3. 模型管理
  4. Modelfile定制
  5. API调用
  6. 多模型切换
  7. 横向对比
  8. 硬件要求
  9. 问题排查
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示模型一键部署、Modelfile自定义、API集成与多工具对比选型。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Ollama一行命令部署 ollama run自动下载模型并启动推理服务 自动管理GPU显存无需手动配置环境 Deploy = ollama run + Auto-Download 极简命令行实现本地大模型一键部署

初识Ollama

想象你请了一位私人咖啡师。你不需要自己烘焙、研磨、控制水温，只要说一声“来杯拿铁”，他就懂了。Ollama 之于大模型，就是这样一个随叫随到的咖啡师。它把“找到模型文件、配置 Python 环境、显存调度、启动推理服务”这一长串工序，压缩成一条命令：ollama run llama3.2。按下回车，模型自动下载、自动运行，一个能聊天的 AI 就在你的终端里开口了。

Ollama 是一个开源的本地大模型运行框架，社区基于 llama.cpp 生态构建。它解决的核心痛点是“部署痛苦”：传统方式要在 HuggingFace 下载权重、装 PyTorch、写推理脚本、调 GPU 驱动，折腾半天才能跑一句话。Ollama 把这些打包成了类似"App Store"的体验——模型仓库、推理引擎、HTTP 服务三者一体。

它由三部分组成：模型仓库管理（~/.ollama 下的模型文件）、推理引擎（基于 llama.cpp，自动用 Metal/CUDA 加速）、内置 REST API（监听 11434 端口）。支持 macOS / Linux / Windows，一行命令安装：

安装后即可运行 llama3.2、qwen2.5、gemma2 等开源模型。这就好比请了个全能咖啡师：进货、烘焙、推荐、出杯全包。你只负责享受——或者用接下来的篇幅，学会怎么“定制你自己的菜单”。

text1 行
curl -fsSL https://ollama.com/install.sh | sh

模型管理

咖啡馆的豆子要管库存：缺货了要进货（pull）、货架要盘点（list）、不卖的豆子要下架（rm）。Ollama 的模型管理就这三板斧。

ollama pull llama3.2 从 Ollama 官方仓库（类似 Docker Hub）下载模型到本地；ollama list 查看已安装的模型及大小；ollama rm llama3.2 删除不需要的模型。所有文件默认存放在 ~/.ollama/models，Ollama 按 blob 块存储并计算哈希，重复的层会被去重合并。这里的模型文件其实是 GGUF 格式（一种专门为大模型推理设计的量化打包格式），Ollama 会帮你处理好一切格式细节。

下载时间取决于模型体积和带宽。4.7GB 的 llama3.2:3b 在 50MB/s 的宽带下约需 96 秒：

模型管理就像咖啡豆的供应链管理：豆子有保质期，模型也有更新。ollama pull qwen2.5:7b 会拉取最新版本，blob 哈希保证只下载变化的层。管好货架，咖啡馆才不会堆满过期豆子。

Tdownload=SmodelBbandwidthT_{\text{download}} = \frac{S_{\text{model}}}{B_{\text{bandwidth}}}
公式解读：下载时间 = 模型文件大小 ÷ 实际带宽。模型越大、网越慢，等得越久。
  1. 模型体积S_{\text{model}} 是模型文件的大小。4.7GB 的模型就是 4.7 × 1024 MB。
    Smodel=4.7×1024 MBS_{\text{model}} = 4.7 \times 1024\,\text{MB}
  2. 实际带宽B_{\text{bandwidth}} 是你的网络实际下载速度，通常比运营商标称值低。50MB/s 是较为理想的光纤速度。
    Bbandwidth=50 MB/sB_{\text{bandwidth}} = 50\,\text{MB/s}
  3. 计算耗时体积除以带宽得到秒数。带宽越大，T 越小，下载越快。
    Tdownload=4.7×102450≈96 秒T_{\text{download}} = \frac{4.7 \times 1024}{50} \approx 96\,\text{秒}

Modelfile定制

每位咖啡师都有自己的“秘密配方”：用什么豆、几克粉、水温多少。Modelfile 就是你的配方卡，纯文本文件，语法类似 Dockerfile。有了它，你可以在同一个基础模型之上，调出专属于你的“隐藏菜单”。

Modelfile 的核心指令有四条：FROM 指定基础模型（豆子品种）；PARAMETER 控制推理参数（研磨度与水温）；SYSTEM 设定系统提示词（服务话术）；TEMPLATE 决定对话模板（杯型与包装）。示例：

然后用 ollama create my-tutor -f Modelfile 生成一个专属模型。其中 temperature 参数直接影响回答的随机程度，背后的原理是 softmax 温度缩放：

有了配方卡，你可以给每个场景定制“咖啡师人格”：客服版、老师版、诗人版。Ollama 创建出的新模型，就像同一台机器上的不同“隐藏菜单”。

softmax(zi,T)=ezi/T∑jezj/T\text{softmax}(z_i, T) = \frac{e^{z_i / T}}{\sum_{j} e^{z_j / T}}
公式解读：temperature 越大，各候选词的概率越接近，回答越发散；temperature 越小，模型越倾向于选最高分词汇，回答越发确定。
  1. 原始打分z_i 是模型对候选词 i 的内部打分（logits），分数越高代表越可能被选。
    zi=logits(i)z_i = \text{logits}(i)
  2. 温度参数T 就是 Modelfile 里的 temperature。T 越大，z_i / T 的差异被压缩，所有词的机会更均等。
    T=0.7T = 0.7
  3. 指数变换e^{z_i / T} 把缩放后的分数映射为正数，并放大分数间的差距。
    ezi/T=exp⁡(ziT)e^{z_i / T} = \exp\left(\frac{z_i}{T}\right)
  4. 归一化分母\sum_j e^{z_j / T} 对所有候选词求和，把结果压成 0 到 1 之间的概率分布。
    ∑jezj/T\sum_{j} e^{z_j / T}
text3 行
FROM llama3.2:3bPARAMETER temperature 0.7SYSTEM 你是一位耐心的小学数学老师

API调用

客人不必走进后厨，把订单写在纸条上递进窗口就行。Ollama 的 API 就是这个“外卖窗口”：它把模型能力封装成标准的 HTTP 接口，任何语言、任何框架都能通过它来点单。

Ollama 启动后自动监听 http://localhost:11434。原生接口包括：POST /api/chat 发消息、GET /api/tags 查模型列表；同时它还提供 OpenAI 兼容接口 POST /v1/chat/completions。这意味着你以前写好的、面向 OpenAI SDK 的代码，只需要把 base_url 改成 http://localhost:11434 就能无缝切换到本地模型。

用 cURL 直接体验：

Python 端用 requests 或 urllib 三两行就能调用（后文 Python 演示会给出完整实现）。外卖窗口让整间“咖啡馆”可以被任何程序访问——团队里每个人拿到的是一份同样的菜单（API 文档），而不是挤进后厨翻豆子。

text4 行
curl http://localhost:11434/api/chat -d '{  "model": "llama3.2",  "messages": [{"role": "user", "content": "你好"}]}'

多模型切换

货架上可以同时摆几种豆子：咖啡师可以一边做意式浓缩，一边准备手冲。但如果操作台（显存）不够大，就必须收起一套工具，给另一套腾地方。Ollama 的多模型管理正是这个逻辑。

Ollama 默认把最近用过的模型驻留在内存或显存中（keep_alive 默认 5 分钟），这样快速切换对话场景时不用重新加载。你可以通过环境变量或 API 参数调整：OLLAMA_KEEP_ALIVE=0 表示用完立即释放，keep_alive=-1 表示永久驻留。当显存不够时，系统会自动驱逐最久未使用的模型。

多个模型常驻的总显存开销，约等于各自开销之和：

切换策略很简单：小显存机器只驻留一个模型；业务上按需先 pull 再切；通过 API 调用时不显式传 keep_alive，就遵守服务端默认值。这就像咖啡师在高峰期前预判哪款单品卖得快，把对应的工具留在手边。

Mtotal≈∑i=1kNi×bi8×109M_{\text{total}} \approx \sum_{i=1}^{k} \frac{N_i \times b_i}{8 \times 10^9}
公式解读：同时驻留 k 个模型时，总显存约等于每个模型的参数量 × 量化位宽折算成 GB 后的累加。超出显卡容量就会触发自动驱逐。
  1. 参数量N_i 是第 i 个模型的参数量。7B 模型就是 70 亿，即 N_i = 7 \times 10^9。
    Ni=7×109N_i = 7 \times 10^9
  2. 量化位宽b_i 是每个权重占的比特数。FP16 是 16，Q4 量化是 4。
    bi∈{16,4}b_i \in \{16, 4\}
  3. 位转字节\times b_i / 8 把 bit 换算成 byte，再除以 10^9 得到 GB。
    Ni×bi8×109 GB\frac{N_i \times b_i}{8 \times 10^9}\,\text{GB}
  4. 累加求和\sum_{i=1}^{k} 把所有常驻模型的显存累加，k 越大，显存消耗越快。
    ∑i=1kMi\sum_{i=1}^{k} M_i

横向对比

市面上还有别的“咖啡机”。LM Studio 是另一个品牌的家用咖啡机：它有完整的图形界面，拖拽即用，适合完全不想碰命令行的用户，但脚本化、批量管理模型的能力较弱。vLLM 则是大型咖啡工厂：几十升的锅炉、流水线灌装，专为高并发生产设计。

Ollama 的定位介于两者之间——“小店一步到位”的平衡方案。它对新手友好，一条命令跑通；对老手也够用，支持 Modelfile 定制和 OpenAI 兼容 API。vLLM 虽然吞吐量更高（支持 PagedAttention 和连续批处理），但安装配置更重，需要一定的工程经验；LM Studio 的图形界面虽好，却难以嵌入自动化流程。

选型建议就看你的“店”要开多大：个人实验、产品原型选 Ollama；纯图形界面折腾选 LM Studio；日请求量大、追求 QPS 选 vLLM。三者都提供 OpenAI 兼容接口，今天用 Ollama，明天换 vLLM，代码几乎不用改。

就像咖啡馆各有定位——社区小馆、精品连锁、工业代工厂。没有最好的机器，只有最适合你客流量和预算的选择。

硬件要求

咖啡师再厉害，操作台只有一米宽，也摆不下两台意式机。显存就是大模型的操作台。决定模型能不能跑起来的第一因素，不是 CPU 算力，而是显存容量。

Ollama 支持 NVIDIA GPU（CUDA）、Apple Silicon（Metal）、AMD GPU（ROCm），纯 CPU 也能跑但速度明显慢。一个模型需要多少显存，可以用统一公式估算：

CPU 运行也不是不可能：只要内存大于模型体积的 1.5 倍，7B Q4 大约每秒生成 5-10 个 token，可以接受但不够爽。量化则是降显存的“浓缩咖啡豆”：同样的豆子做成浓缩粉，体积小、风味浓。Q4 损失一点精度，换来 1/4 的空间，是本地跑模型的默认选择。

MVRAM≈N×b8×109M_{\text{VRAM}} \approx \frac{N \times b}{8 \times 10^9}
公式解读：模型显存需求 ≈ 参数量 × 每个权重的位宽 ÷ 8 再 ÷ 10⁹。7B 模型 FP16 需约 14GB，Q4 量化只需约 3.5GB。实际使用还要额外预留 20%~30% 给注意力缓存（KV cache）和运行时开销。
  1. 参数量N 是模型参数总量。Llama 3.2 3B 就是 N = 3 \times 10^9，7B 就是 7 \times 10^9。
    N=7×109N = 7 \times 10^9
  2. 权重位宽b 是每个权重占的比特数。FP16 全精度是 16 位，Q4 量化是 4 位。
    b=16 或 4b = 16 \,\text{或}\, 4
  3. 位转字节除以 8 是因为 1 字节 = 8 比特。
    N×b8 bytes\frac{N \times b}{8}\,\text{bytes}
  4. 换算 GB再除以 10^9 得到 GB。7B × 16 ÷ 8 ÷ 10⁹ = 14GB。
    7×109×168×109=14 GB\frac{7 \times 10^9 \times 16}{8 \times 10^9} = 14\,\text{GB}

问题排查

咖啡没做好，先看水温还是粉量？有经验的咖啡师会按“由表及里”的顺序排查。Ollama 出问题也一样，不要一上来就重装系统。

常见问题有四类：第一，显存不足（OOM）。解决方案按优先级排列：换更小的模型、改用 Q4 量化、设置 keep_alive=0 及时释放、用 --num-ctx 限制上下文长度。第二，下载缓慢。可以配置代理、换镜像源，或者手动下载 GGUF 文件后通过 Modelfile 导入。第三，API 连接失败。先确认服务是否启动（ollama serve）、端口 11434 是否被占用、curl http://localhost:11434 能否连通，再检查防火墙。第四，输出质量差。优先调 temperature、top_p，或改写 SYSTEM 提示词，而不是盲目换更大的模型。

排查顺序建议遵循“日志 → 资源 → 配置”三步：先看终端日志有没有报错，再查显存/内存是否吃紧，最后调量化档位、上下文长度和采样参数。绝大多数问题都能用这三板斧解决。

就像咖啡师记一本“翻车日记”，每次拉花失败都写下原因。你也应该把每次 OOM、每次连接失败的场景记下来——你的本地 AI 咖啡馆会越开越顺。

AI 应用场景

企业内部私有知识库助手

阶段：模型部署与推理

解决的问题：传统做法把内部文档发给云端 ChatGPT 存在严重泄密风险；用 Ollama 在内网部署 qwen2.5:7b，配合本地向量库做 RAG，数据全程不出内网。一条命令完成部署，运维成本极低，非专业运维也能维护。

具体案例：某券商把内部规章制度、产品手册喂给本地 RAG 系统，投顾在浏览器里直接提问“代客理财的合规要点有哪些”，回答不经过公网，满足合规审计要求。

离线环境医疗终端辅助

阶段：端侧推理

解决的问题：手术室、乡镇卫生院没有稳定外网，却需要 AI 辅助生成病历摘要和质量检查。Ollama 装在带 NVIDIA T4 的医疗工作站上，模型随开机自启，医生在内网页面使用，断网也能工作。

具体案例：一家医疗 AI 公司用 Ollama 跑 7B 量化模型做初步病历质控，发现疑似漏项时自动提醒医生；联网后再把结构化结果异步同步到中心服务器。

模型选型的“试杯间”

阶段：模型评测与选型

解决的问题：上生产前要在多个开源模型之间对比效果，逐个部署太慢。用 Ollama 的 pull/run 命令快速切换候选模型，一小时跑完小样本评测，再决定用哪个模型、哪个量化档位，避免在云上烧钱做实验。

具体案例：某互联网公司要做一个客服助手，候选模型有 qwen2.5、llama3.2、glm4。算法工程师用 Ollama 在同一批测试集上逐一问答，对比回答质量和速度后，选定 qwen2.5:14b-q4 作为基座，再迁移到 vLLM 上线。

Python 演示

python96 行
# -*- coding: utf-8 -*-# Ollama 本地模型管理演示: list/pull/delete/chat 四个子命令.import jsonimport sysimport urllib.request  class OllamaClient:    # 极简 Ollama 客户端: 能连上真实服务就用真实API, 连不上走模拟模式.    def __init__(self, base_url="http://localhost:11434"):        self.base_url = base_url        self.local_cache = ["llama3.2:3b", "qwen2.5:7b"]     def _http(self, path, payload=None, method="GET"):        # 统一封装HTTP请求, 返回解析后的JSON或None.        data = None        if payload is not None:            data = json.dumps(payload).encode("utf-8")            method = "POST"        req = urllib.request.Request(            self.base_url + path, data=data, method=method,            headers={"Content-Type": "application/json"})        try:            with urllib.request.urlopen(req, timeout=10) as resp:                return json.loads(resp.read())        except Exception:            return None     def list_models(self):        # 获取本地模型列表, 失败时返回模拟缓存.        result = self._http("/api/tags")        if result is None:            return list(self.local_cache)        return [m["name"] for m in result.get("models", [])]     def pull_model(self, name):        # 拉取模型. 真实Ollama的pull会返回进度流, 这里简化处理.        payload = json.dumps({"name": name}).encode("utf-8")        req = urllib.request.Request(            self.base_url + "/api/pull", data=payload,            headers={"Content-Type": "application/json"})        try:            with urllib.request.urlopen(req, timeout=3600) as resp:                last_status = ""                for line in resp:                    item = json.loads(line)                    last_status = item.get("status", "")                return "拉取完成: " + last_status        except Exception:            if name not in self.local_cache:                self.local_cache.append(name)            return "模拟模式: 本地已登记 " + name     def delete_model(self, name):        # 删除本地模型.        payload = json.dumps({"name": name}).encode("utf-8")        req = urllib.request.Request(            self.base_url + "/api/delete", data=payload,            method="DELETE", headers={"Content-Type": "application/json"})        try:            with urllib.request.urlopen(req, timeout=10):                return "删除完成: " + name        except Exception:            if name in self.local_cache:                self.local_cache.remove(name)            return "模拟模式: 已删除 " + name     def chat(self, name, prompt):        # 发送对话请求, 使用OpenAI风格的消息结构.        result = self._http("/api/chat", {            "model": name,            "messages": [{"role": "user", "content": prompt}],            "stream": False})        if result is None:            return "[模拟回答] " + prompt        return result["message"]["content"]  def main():    if len(sys.argv) < 2:        print("用法: python ollama_demo.py list|pull <模型>|delete <模型>|chat <模型>")        return    client = OllamaClient()    cmd = sys.argv[1]    if cmd == "list":        print("本地模型:", ", ".join(client.list_models()))    elif cmd == "pull" and len(sys.argv) > 2:        print(client.pull_model(sys.argv[2]))    elif cmd == "delete" and len(sys.argv) > 2:        print(client.delete_model(sys.argv[2]))    elif cmd == "chat" and len(sys.argv) > 2:        print("AI回答:", client.chat(sys.argv[2], "你好, 请用一句话介绍你自己"))  if __name__ == "__main__":    main()
目的：这是一个兼容真实 Ollama 服务的极简 Python 客户端，覆盖 list / pull / delete / chat 四个核心操作；本地没有启动 Ollama 时自动降级为模拟模式，方便在任何环境运行演示。
  1. def _http(self, path, payload=None, method="GET")统一封装 HTTP 请求，把“发请求、读响应、解析 JSON”收敛到一个方法里，避免四个命令各写一遍网络逻辑
  2. data = json.dumps(payload).encode("utf-8")将 Python 字典转成 JSON 字节流，这是 Ollama API 要求的请求体格式
  3. result = self._http("/api/tags")调用 GET /api/tags 获取本地模型清单，对应 ollama list
  4. "messages": [{"role": "user", "content": prompt}]OpenAI 风格的消息结构，和调用 GPT 的写法一致
  5. "stream": False关闭流式输出，一次拿回完整回答，逻辑更简单
  6. except Exception: return None连不上 Ollama 时返回 None，外层方法据此切换到模拟模式，保证代码开箱即跑
  7. for line in resp真实 pull 接口返回的是逐行 JSON 进度流，逐行解析可以实时读取下载状态

常见误区

误区反正电脑配置还行，直接把 70B 模型拉下来，效果肯定比 7B 好很多。

正解70B 模型即使做 Q4 量化也要约 35GB 显存，常见单卡根本装不下，强行运行会 OOM 或退化到 CPU 慢如蜗牛。7B Q4 只需要 3.5GB。模型不是越大越好，而是“能跑起来 + 适配任务”最好。就像咖啡豆再名贵，你的磨豆机塞不下，也只能干瞪眼。

为何常见：评测榜单给的都是大模型绝对分数，让人误以为“本地也能享受同样效果”，忽略了硬件约束。

误区我的电脑是 AMD 显卡或者 Apple Silicon，估计用不了 Ollama。

正解Ollama 官方原生支持 macOS（M 系列芯片走 Metal 加速）、Linux 下 NVIDIA CUDA，Windows 也有完整支持。AMD 显卡可通过 ROCm 后端运行，纯 CPU 模式更是永远可用，只是速度慢一些。就像有高级意式机、手冲壶、甚至简易摩卡壶，都能做出咖啡，只是效率和风味不同。

为何常见：早期版本确实以 NVIDIA CUDA 为主，信息滞后导致不少用户误以为只有 N 卡才能用。

误区本地部署 Ollama 和用 vLLM 部署没区别，反正都是跑大模型，那生产环境直接用 Ollama 好了。

正解Ollama 主打“开箱即用”，适合个人、小团队快速验证和产品原型；vLLM 是高性能批处理引擎，用 PagedAttention 等优化支撑高并发，适合生产级服务。日均请求上万时，Ollama 的简单调度会成为瓶颈。一个是家用咖啡机，一个是连锁工厂的产线，各有各的战场。

为何常见：两者都提供 OpenAI 兼容接口，从 API 层看“长得太像”，让人忽略了底层吞吐能力的巨大差异。

误区从网上下载的 llama3.2 模型文件，直接拷到 U 盘里发给同事就能用。

正解Ollama 把模型按 blob 分块存储并通过哈希索引，直接拷贝文件而不注册到仓库里是无法运行的，正确做法是用 ollama pull，或通过 ollama create 从本地 GGUF 导入。另外还要注意模型许可证（比如 Llama 社区许可对商用有限制），就像咖啡豆有产地认证一样，乱贴标签会出事。

为何常见：用户习惯把模型等价于“一个文件夹”，忽略了 Ollama 的注册表机制和模型许可的法律边界。

面试题

Q1. 在 Ollama 中，拉取（下载）模型到本地的命令是？

单选题 · easy

  • A.ollama fetch llama3.2
  • B.ollama pull llama3.2← 正确答案
  • C.ollama download llama3.2
  • D.ollama install llama3.2

答案：B。Ollama 借用 Docker 的语义，下载模型用 pull，对应“进货咖啡豆”；fetch、download、install 都不是 Ollama 的命令。注意和 ollama run（下载并直接运行）区分开。

Q2. 查看本地已经下载了哪些模型，应使用哪个命令？

单选题 · easy

  • A.ollama list← 正确答案
  • B.ollama show
  • C.ollama status
  • D.ollama models

答案：A。ollama list 会列出本地所有模型及占用空间，相当于盘点咖啡馆货架。show 用于查看单个模型详情，status 不是子命令，models 是易混淆的错误选项。

Q3. 一个 70 亿参数（7B）模型，用 Q4 4 位量化后，理论显存需求约为？

单选题 · mid

  • A.约 7 GB
  • B.约 14 GB
  • C.约 3.5 GB← 正确答案
  • D.约 28 GB

答案：C。套用公式 M = N × b ÷ 8 ÷ 10⁹。7B × 4 ÷ 8 = 3.5GB。14GB 是 FP16 全精度的结果，7GB 是“参数 × 1字节”的常见误算，28GB 是把 FP32 当成 Q4 位宽算出的。

Q4. Ollama 相比传统 HuggingFace 自建推理，优势有哪些？

多选题 · mid

  • A.一条命令完成下载与运行← 正确答案
  • B.自动选择 GPU 或 CPU 运行← 正确答案
  • C.内置模型仓库与管理工具← 正确答案
  • D.显著提升模型推理准确率

答案：ABC。A、B、C 都是 Ollama 的真实优势：命令一体化、硬件自动调度、仓库开箱即用。D 是错的——Ollama 只负责“把模型跑起来”，不改变模型参数，也就不可能提升准确率，就像换一台更贵的咖啡机并不会让同一批豆子变得更香。

Q5. Modelfile 中指定“使用哪个基础模型”的指令是？

单选题 · mid

  • A.BASE llama3.2
  • B.MODEL llama3.2
  • C.FROM llama3.2← 正确答案
  • D.USE llama3.2

答案：C。Modelfile 采用类似 Dockerfile 的语法，基础镜像用 FROM，基础模型也用 FROM。BASE、MODEL、USE 都是干扰项。后面的 PARAMETER、SYSTEM、TEMPLATE 则分别负责参数、人设和模板。

Q6. 关于 Ollama 的 API 调用，下列说法正确的是？

多选题 · mid

  • A.提供 REST 风格的原生接口← 正确答案
  • B.支持 OpenAI 兼容的请求格式← 正确答案
  • C.必须使用 Python 语言才能调用
  • D.通过本地 11434 端口提供服务← 正确答案

答案：ABD。Ollama 原生接口是 REST 风格（如 /api/chat、/api/tags），同时暴露 /v1/chat/completions 的 OpenAI 兼容端点，服务默认监听 11434 端口。C 错误——API 是 HTTP 的，任何语言都能调，cURL 一行就能测通。

Q7. 多模型切换时，控制模型在内存中驻留时长的参数是？

单选题 · mid

  • A.参数 keep_alive← 正确答案
  • B.参数 max_tokens
  • C.参数 num_ctx
  • D.参数 top_p

答案：A。keep_alive 决定模型加载后驻留内存/显存的时间，默认 5 分钟，设 0 即用完立刻释放，设 -1 永久驻留。max_tokens 是最大回复长度，num_ctx 是上下文窗口，top_p 是采样参数，都和驻留无关。

Q8. 在 8GB 显存显卡上，最适合运行哪种模型配置？

单选题 · hard

  • A.7B 模型 FP16 全精度
  • B.7B 模型 Q4 量化版本← 正确答案
  • C.70B 模型 Q4 量化版本
  • D.13B 模型 FP32 全精度

答案：B。7B Q4 约 3.5GB，再加 KV cache 和运行时开销约 20%~30%，8GB 显存刚好从容。7B FP16 需 14GB 直接溢出；70B Q4 需 35GB；13B FP32 更是高达 52GB。选型时永远先算显存，再谈效果。

Q9. 哪些情况更适合选 vLLM 而不是 Ollama？

多选题 · hard

  • A.需要每秒处理上千个请求← 正确答案
  • B.追求极致吞吐与批处理← 正确答案
  • C.个人电脑上快速体验模型
  • D.生产环境高并发服务← 正确答案

答案：ABD。vLLM 的核心优势是 PagedAttention 和连续批处理带来的高吞吐，适合大规模高并发生产场景。C 恰恰是 Ollama 的主场——个人电脑上快速验证，追求的是“一键跑通”而非压榨吞吐。

Q10. Ollama 默认将模型文件存储在哪个位置？

单选题 · easy

  • A.~/.ollama/models← 正确答案
  • B./usr/local/models
  • C.~/models/ollama
  • D./var/lib/ollama

答案：A。Ollama 默认把模型存放在用户主目录下的 ~/.ollama/models，并按 blob 分块 + 哈希索引管理。其他路径都是干扰项。了解存放位置对排查磁盘占用、迁移模型非常有用。