04 · 命令行跑本地模型：Ollama 入门

【配图：封面——延续系列封面视觉规范（袖珍太阳视觉线），主题：终端窗口 + 本地模型运行场景】

系列：mac mini 玩转本地大模型 · 第 4 篇 副标题：brew 或官方包、tags 选型、性能基准到局域网开放

导读：02 篇用图形界面跑通了第一个模型，这一篇换成命令行。安装走官方包与 brew 两条路，读懂 tags 量化后缀，附 27B 模型四组基准数（解码 / 预填充 / 首字等待 / 并发），最后把服务开放到局域网。

开始之前

• 适合谁：想用命令行管理本地模型的读者（02 篇 GUI 路线的下一站；Apple Silicon 通用，Windows/独显读者可作思路对照）
• 需要什么：00/01 篇的配置与账本（或等效环境）+ 约 20GB 可用磁盘 + 一张可信的局域网
• 预计耗时：纯阅读约 15 分钟；跟着做约 1 小时（大头是 16.5GB 模型下载，视网速浮动）
• 本篇实测环境：被测机是 Mac mini（M5 Pro · 18 核 CPU / 20 核 GPU / 64GB / macOS 27.0）——27B 模型、全部性能基准、局域网服务端都在它身上。叙述从用户机（MacBook Pro · M1 Pro · 32GB）出发：brew 安装实录、测试驱动脚本都在这台完成，它是操作位，不是被测对象。Ollama 版本 0.34.4（两台同版本，2026-09-28 局域网复验）；性能数字实测日期 2026-09-27，口径见第四章

一、开篇：先交代两件事

02 篇预告的那口「命令行的炉子」，就是这一篇——Ollama，用命令行的方式跑本地模型。

动笔前交代两件事。

第一件，顺序。原计划 03 篇（量化课）在前、本篇在后，现在你看到的是 04 先发。原因直说：03 篇要做的 70B 重载实测还没完成，本篇的 Ollama 实测已经做完了，所以 04 先发、03 等实验完成后再发。不是跳票。

第二件，机器角色。被测机只有一台：Mac mini（M5 Pro · 64GB）——27B 模型、全部基准、局域网服务端都在它身上。文章站在用户机的视角写，也就是你日常用的那台电脑的位置：brew 安装实录、驱动测试的脚本都从用户机出发（写作用的这台是 32GB MacBook），它是操作位，不是被测对象。

装法对应你的场景：给常驻服务机装，走官方 .app；在自己日常电脑上装，走 brew。brew 路的步骤 32GB 机器照做无压力；基准数字是 64GB 服务机的档位——大内存看满配、小内存看自己档位，这套分法就是 02 篇的降档路线，本篇沿用。

本篇路线：装 Ollama → 拉第一个模型、读懂 tags → 跑通对话 → 看懂四组基准数 → 开放到局域网 → 与 LM Studio 对比选型。

二、安装 Ollama：官方包与 brew 两条路

2.1 两条路，都有实测

Ollama 在 macOS 上有两条安装路，本篇两条都走过：被测机 Mac mini（服务机）用的是官方安装包（.app，/Applications/Ollama.app，命令行工具落位 /usr/local/bin/ollama【写作期核对：CLI 落位路径】）；用户机（写作用的这台 MacBook）用的是 Homebrew。

先立一条与 02 篇同款的红线：官方 .app 只从官网 ollama.com 下载——第三方下载站捆绑安装器、过期版本都是常见的坑，这条对 Mac 软件通用。

怎么选按场景。不想碰命令行生态、要个菜单栏图标常驻的，走官方 .app；已经在用 brew 统一管理工具、或者打算把这台机器当无头服务器用的，走 brew。本篇步骤主线是 brew——后面的服务配置和防火墙坑都集中在这条路上，官方 .app 路线没有这些环节。

官方 .app 路线本篇只给最小覆盖：安装是官网下载 dmg、拖进 Applications；服务常驻和局域网暴露都在应用内设置里完成（设置项名称以官网当期为准【写作期核对：应用内设置项名称】），细节不逐步展开。官方文档若另有安装推荐口径，引用前会标来源【写作期核对：官方安装推荐口径】。

2.2 brew 实测口径

用户机实测（可照做）：

brew install ollama

约 3 分钟装完。装上的 Ollama 版本 0.34.4（bottled 预编译包），主程序 45 MB（/opt/homebrew/Cellar/ollama/0.34.4）。

依赖列表值得看一眼：mlx-c 0.6.0_4、mlx 0.32.1（198.7 MB）、python@3.14、readline、xz、mpdecimal。装一个 Ollama，把 MLX 生态也连带装上了——系列 05 篇讲 MLX 路线时会用到，此处先记一笔。

2.3 起服务：launchd 常驻

brew 路线起服务（可照做）：

brew services start ollama

这条命令把 Ollama 交给 launchd 管理：登录自启，服务常驻。官方 .app 路线的常驻形态是菜单栏图标，它的自启行为不在本篇实测口径内，不与 brew 的结论套用。

断电场景本篇没有实测，不写结论；想自测的读者，方法在第六章作业里（对照 02 篇实录）。

2.4 探活与版本

服务起来后，先探活（可照做）：

curl localhost:11434/api/version
# {"version":"0.34.4"}

这里有个小坑：服务没启动时，ollama --version 只报 client 版本并给出告警——版本验证放在服务起来之后做，别拿 client 版本当服务版本。

2.5 下载中断与断点续传

实测中的一段插曲，对读者有用：用户机曾拉 qwen3:0.6b，测试中途有意中止，~/.ollama 目录里留下约 169 MB 的断点；之后再拉会续传，进度不丢。下载 16.5 GB 级的大模型中断了，重跑命令接着来就行。

三、下载与运行 qwen3.8：读懂 tags 与内存占用

3.1 tags 体系怎么读

拉模型（可照做）：

ollama pull qwen3.8

拉下来的模型名是 qwen3.8:latest，但 latest 只是个指针——当前实际指向 qwen3.8:27b-q4_K_M。这不靠猜：2026-09-28 实测 /api/tags 接口，返回的 parent_model 字段直接给出了这个值（模型库 tags 页也可查【写作期核对：tags 页截图】）。

把这个 tag 拆开读：

• 27b：参数量档位（270 亿）
• q4_K_M：量化等级（GGUF 量化体系的一档）
• 合起来，指定 GGUF 格式族的一个具体发行版

量化信息显式写在 tag 里，要换档就显式指定——比如 :27b-q8_0 是高量化档。对照 02 篇 LM Studio 的写法：量化嵌在发行名里（Qwen3.8-27B-MLX-4bit），能读，但要靠命名约定。这是 Ollama 用起来更顺的一处——量化档位直接写在名字里，换档、锁版本都是显式操作。

Q4_K_M 到底什么意思、和 q8_0 差在哪——03 篇量化课主场，本篇只教「怎么读」。

【配图：tags 量化后缀解读卡——qwen3.8:27b-q4_K_M 三段拆解 + latest 指向说明 + 与 LM Studio 发行名 Qwen3.8-27B-MLX-4bit 对照】

3.2 磁盘与驻留实测

qwen3.8:latest 下载完成后占用磁盘 16.5 GB。这个数字 09-28 复验过：/api/tags 返回 size 17,741,872,154 字节 ≈ 16.53 GiB；同一响应还给出 capabilities：completion / vision / tools / thinking——能看图、支持工具调用、带思考模式。02 篇 LM Studio 侧跑的同一模型（qwen3.8-27b，MLX 格式）同样标注这些能力。两工具标注口径一致，这是口径事实，不是质量结论。

运行起来之后看驻留（可照做）：

ollama ps

实测：驻留内存 18 GB · 100% GPU · context 16384【写作期核对：context 16384 来历（默认值还是显式设定）+ ollama ps 输出截图】。100% GPU 的意思是模型完全由 GPU 承载——Apple Silicon 是统一内存架构，这块「GPU 内存」和 01 篇讲的统一内存是同一块，18 GB 驻留占的就是它。

3.3 上下文：模型上限 262,144，实跑 16384

这个模型的上下文上限是 262,144（256k，/api/tags 的 context_length 字段）。实跑显示 16384——与 02 篇 LM Studio 默认加载 208K 形成对照。

16384 是默认值还是我们拉起时显式设的，写作期正在核对。两种情况的含义分开说：若是 Ollama 的默认值，那么两个工具的默认策略相反——Ollama 默认给得小、要显式调大，LM Studio 默认给得大；若是显式设定，那是我们自己的选择，不能代表工具默认行为。

无论哪种，使用建议不变（01 篇口径，02 篇同样收尾）：日常对话 8k-16k 起步，长文档场景再逐步试高。上下文可以用 num_ctx 参数调大，代价是 KV cache 内存随之上涨——细算归 03 篇。

3.4 为什么 27B 放在 mini 上跑

27B Q4_K_M 驻留 18 GB，这个数字印证了 01 篇速查表对内存需求的量级估计。但 32GB 机器到底能不能跑——没实测，不知道。用户机日常还要干别的，内存余量紧；重模型交给 64GB 的 mini，是服务机与用户机的分工，也是保守决策。

这是 01 篇速查表第二次用于真机决策（02 篇选 27B 是第一次）。表是经验推导口径，决策时留足余量，两次都走得很顺。

3.5 降档路线（04 版）

照例给不同内存档位的读者指路（01 篇速查表「舒服跑」列，Q4 口径；该表为经验推导口径，非逐档实测）：

• 32GB 机器：14B
• 16GB 机器：7B-8B

32GB 机的降档按 01 篇速查表指路——我们没在这档机器上实测过，不虚标数字。32GB 读者跑完欢迎回贴数字。

3.6 跑通第一次对话 + 常用命令一览

进入对话（可照做）：

ollama run qwen3.8

交互界面里直接聊，回复逐字刷出，读得过来。交互场景的精确数字本篇没有单独测，性能数字以第四章 API 口径为准。

常用命令一张表：

命令	作用
ollama pull <模型>	拉模型
ollama run <模型>	进入对话
ollama list	列已装模型
ollama ps	看驻留状态
ollama stop <模型>	卸载驻留
ollama rm <模型>	删除模型（删模型即释放磁盘，本篇这个模型是 16.5 GB 级）
ollama show <模型>	看模型规格（参数量 / 量化 / 上下文）
ollama serve	前台手动起服务（调试用；brew/launchd 已托管时不必）

四、性能基准：解码、预填充、首字等待与并发

4.1 先立口径：全文数字对这张表负责

项	口径
被测硬件	Mac mini M5 Pro（18 核 CPU / 20 核 GPU / 64GB / macOS 27.0，沿用 02 篇已发布真机口径）
软件	Ollama 0.34.4（两台同版本）——mini 官方 .app 与用户机 brew 均 0.34.4（2026-09-28 /api/version 局域网实测）
模型	qwen3.8:latest（= 27b-q4_K_M）· GGUF · 磁盘 16.5 GB
驱动方式	用户机经局域网 API 驱动 mini（LAN 开销 <1 ms，相对 token 耗时可忽略；用户机侧统一 /usr/bin/curl，原因见 5.4）
计时方法	/api/generate 返回的 load_duration / prompt_eval_* / eval_*（纳秒精度），拆成加载 / 预填充 / 解码三段
控制变量	temperature=0；num_ctx 显式固定；keep_alive 常驻；每组唯一前缀破坏 KV 缓存（原因见 4.7 坑一）
样本量纪律	样本 ≥128 token 才可信——8 token 小样本曾测出 17 t/s 伪差；各场景 2-8 轮，数值作量级参考；解码 23.5-24.5 区间多轮交叉，置信较高

4.2 冷加载：4.07 秒

模型从磁盘进统一内存，实测 4.07 s（16.5 GB 全量载入）。粗算磁盘读取速度：16.5 GB ÷ 4.07 s ≈ 4 GB/s 量级。说明一下：这是粗算，不是 SSD 实测，SSD 实际带宽没测。

keep_alive 设成常驻后，这个加载过程只发生一次。

4.3 解码速度：24.5 t/s

短上下文场景（约 22 token prompt，128/256 token 生成 × 8 轮）：中位 24.5 t/s（23.5-24.5，多轮波动范围很窄）。长 prompt（约 8.3k token）下 23.5-24.2——衰减不到 5%，解码速度对上下文长度不敏感。

这个数字与 01 篇带宽公式的关系，本篇先不对账。初步核算发现口径存疑（按 01 篇公式，这个速度对应的带宽账算不平），正式查账是 03 篇量化课的第一件事。此处记住量级即可。

4.4 预填充与首字等待

预填充（prefill，生成开始前把你的输入完整处理一遍）四档实测：

prompt 长度	prefill 速度
392 tok	277 / 279 t/s
2937 tok	344 / 337 t/s
8194 tok	318 t/s
11673 tok	287 / 281 t/s

汇总：277-344 t/s（约 280-340），跨长度平稳。

首字等待（TTFT，从发出请求到第一个字落地）三档：22 token 约 0.15-0.3 s；2937 token 约 8.8 s；11673 token 约 42 s（TTFT 含 <1 ms 局域网开销，可忽略）。

拿 2937 token 那档验一下 TTFT 和 prefill 的关系：2937 ÷ 344 ≈ 8.5 s（粗算，344 是该档实测 prefill 速度），对上实测 TTFT 8.8 s——首字等待基本就是预填充时间加零头。

两组数放在一起，结论一句话：TTFT 由预填充主导——决定首字等待的是输入长度，不是解码速度。解码 24.5 t/s 的机器，一次输入 1.2 万 token 的 prompt，照样等 40 多秒才见第一个字。

体验建议沿用 02 篇红线：单请求 prompt 控制在 4k 以内（02 篇已发布口径，经验建议，非实测阈值）。

4.5 并发：默认配置下是排队

4 路并行请求 vs 4 路串行请求，总耗时 7.14 s vs 7.32 s（0.98x）——几乎没有差别。原因在默认配置：OLLAMA_NUM_PARALLEL=1，多路请求完全排队，并发没有吞吐收益。

排队期间的表现：单流解码速度不变（该场景实测 29.2-29.4 t/s——注意这是排队场景的口径，与 4.3 主基准的 24.5 属不同场景，不是数字打架）、无 503 报错、最长排队 5.5 s 计入客户端侧的 TTFT。

一句话记：默认配置下，并发不是加速，是排队。02 篇 LM Studio 默认 4-5 路连续批处理、聚合 47.6 t/s，两个工具的默认形态差异明显（对比口径见 6.1 表注）。

4.6 瓶颈排序与优化抓手

四组数摆完，瓶颈排序可以定下来：长 prompt 的 TTFT ≫ 并发排队 ≫ 解码速度。优化抓手按性价比依次：

1. 控制上下文长度——零成本，直接压最大头（TTFT）
2. 按需设 OLLAMA_NUM_PARALLEL——需要并发吞吐时打开；代价是 KV 内存按并行数放大，细算归 03 篇
3. OLLAMA_FLASH_ATTENTION / KV 量化 q8_0——brew 安装时的 Caveats 默认建议；未实测，此处作一般配置知识表述

三个都是环境变量级配置，写法与 5.2 的 OLLAMA_HOST 相同：加进 plist 的 EnvironmentVariables，再 bootout / bootstrap 一次让它生效。

4.7 基准方法论两课

跑基准时踩过两个方法论坑，记在这里，你复测时用得上。

坑一：前缀 KV 缓存命中把 prefill 推得虚高。 同一前缀重复请求时，KV 缓存命中能把 prefill 推到 83271 t/s——这不是真实算力，是缓存命中。基准测试每组加唯一前缀绕开它；生产环境反过来该利用它，多轮对话的加速就来自这块缓存。

坑二：会话间切换 num_ctx 触发 KV 重分配。 8192↔16384 来回切，触发约 1.9 s 的重分配开销。基准固定 num_ctx，或忽略每组第一个请求。

【配图：基准数字卡——解码 24.5 t/s / prefill 277-344 t/s / TTFT 三档 / 并发 0.98x 四组数一图；角标注样本量、上下文长度、并发场景】

五、开放到局域网：配置顺序与安全边界

5.1 默认就有服务：11434 端口

与 02 篇 LM Studio 要在界面里手动「开服务」不同，Ollama 没有这一步：官方 .app 装好就是菜单栏常驻；brew 路线在 2.3 用 brew services start 起过服务之后，11434 端口就一直可用——原生 API，外加 OpenAI 兼容的 /v1 端点。

OpenAI 兼容意味着现成脚本零改动接入（可照做）：

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8",
    "messages": [{"role": "user", "content": "从1数到5"}]
  }'

07 篇 OpenClaw 联动的地基就是这一步（与 02 篇同一句承诺）。

默认监听 127.0.0.1，只有装它的这台机器自己能连。开放给局域网要改配置——本章主线。

5.2 正确的配置顺序（brew 路线 · 用户机侧实录）

原理一句话：brew 版服务由 launchd 拉起，环境变量 OLLAMA_HOST=0.0.0.0:11434 要写进 plist 的 EnvironmentVariables。顺序（可照做；brew services start 在 2.3 已做，此处从第二步起）：

# 1. 保持服务运行状态，向 plist 写入环境变量
/usr/libexec/PlistBuddy -c "Add :EnvironmentVariables:OLLAMA_HOST string 0.0.0.0:11434" \
  ~/Library/LaunchAgents/sh.brew.ollama.plist

# 2. 卸载服务（保留 plist 文件）
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/sh.brew.ollama.plist

# 3. 重新加载，环境变量生效
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/sh.brew.ollama.plist

plist 文件名以 brew services list 显示的为准——本篇实测时 brew 生成的是 sh.brew.ollama.plist，旧版 Homebrew 则叫 homebrew.mxcl.ollama.plist，动手前先看一眼。

为什么不能中途 brew services stop（本篇坑一）：stop 会删掉 plist；PlistBuddy 随即静默新建一个残缺 plist，bootstrap 时报 I/O error，你盯着报错找不到原因。正确做法是改 plist 前保持服务运行，用 bootout 卸载——它只卸服务，保留 plist 文件。

Mac mini 侧（官方 .app 路线）没有 plist 环节，暴露走应用内设置（设置项名称以官网当期为准【写作期核对：设置项名称】）。

排障入口一句：brew services list 看服务状态；服务日志的位置与查看方式以官方文档为准【写作期核对：日志位置与链接】，不凭记忆写路径。

5.3 验证：两个方向分别验

brew 侧（用户机）：lsof -iTCP:11434 -sTCP:LISTEN 看监听地址，从 127.0.0.1:11434 变成 *:11434 即生效；然后 curl 用户机自己的局域网 IP，/api/version、/api/tags 均通（09-27 实测）。

官方 .app 侧（mini 服务机）：从用户机 curl mini 的 11434 端口，/api/version、/api/tags 均通（09-27 实测；09-28 复验返回 version 0.34.4）。

反向（mini→用户机）的复测还没做【待补 #4】，本篇只写已验证的方向。

5.4 两个网络坑

坑二：macOS 防火墙放行规则绑版本化路径。 防火墙的放行规则绑定版本化的 Cellar 路径，brew 一升级 Ollama，路径变了、规则失配，局域网流量被静默丢弃——没有报错，现象就是连不上。解法是放行 opt/ 软链路径（软链在升级后仍指向新版）：

sudo socketfilterfw --add /opt/homebrew/opt/ollama/bin/ollama

【写作期核对：完整命令——--add 之后是否还需 --unblockapp】

坑三（含坑六）：TCC 本地网络权限与 PATH 抢占。 macOS 的「本地网络」权限默认只放行系统二进制，anaconda 的 curl、Command Line Tools 的 python 直连局域网地址会报 EHOSTUNREACH(65)。雪上加霜的是 PATH 里 anaconda 的 curl 排在前面，你敲 curl 时用的是它。排查两个动作：探测前 which curl 查一眼；局域网脚本统一写全路径 /usr/bin/curl。也可以走系统设置，给对应 App 授权本地网络。

5.5 安全边界：11434 没有鉴权

实测结论：11434 端口无任何鉴权，暴露即全功能开放——任何能连到这个端口的人，可调模型，也可删模型。所以下面的边界不是建议，是硬约束：

1. 家用可信局域网内开放，可控
2. 公共网络（咖啡馆、访客网一类）场景，维持 127.0.0.1 不动
3. 禁止公网裸端口映射（与 02 篇安全清单同口径）
4. 真要远程用，反向代理加鉴权是正路——具体做法超出本篇范围（涉及未实测组件，不给示例）；公共网场景的结论就是先别暴露

【配图：局域网开放与安全卡——127.0.0.1 → 0.0.0.0 监听变化示意 + 配置顺序四步 + 无鉴权警示】

六、Ollama × LM Studio：八维对比与选型建议

6.1 八维对比表

两篇实测放一起（LM Studio 数据来自 02 篇 09-24 实测，Ollama 数据来自本篇 09-27 实测）：

维度	LM Studio（02 篇实测）	Ollama（本篇实测）
模型格式	Qwen3.8-27B-MLX-4bit（15 GB）	qwen3.8:27b-q4_K_M GGUF（16.5 GB）
单流解码	18.8 t/s†	24.5 t/s†
prefill	123-129 t/s（1.2k / 3.2k tok，02 篇实测口径）†	277-344 t/s（约 280-340；0.4k-11.7k tok）†
并发默认行为	4~5 路连续批处理，聚合 47.6 t/s	1 路串行排队，吞吐无提升
服务端口	1234（OpenAI 兼容）	11434（原生 API + OpenAI 兼容 /v1）
安装形态	dmg App（GUI）	官方 .app 或 brew formula（CLI / launchd）
断电自启	App 登录项 + Local LLM Service，实测约 40 s 服务恢复	未实测，不可比（launchd 常驻）
量化后缀可读性	发行名内嵌（-4bit）	tags 显式（:27b-q4_K_M）

四条表注，读表前先看：

1. 非同格式严格对照：两边同是 qwen3.8 27B，但量化实现（MLX 4bit vs GGUF Q4_K_M）与推理后端不同——表中数字是「两种格式 × 后端组合的实测差异」，不是工具优劣
2. † 角标（单流解码、prefill 两行）：所有对比数字均为各自工具 / 格式 / 后端下实测，不可换算倍率——不要拿 24.5 除以 18.8 去算倍率，那样得到的数字没有意义
3. 带宽口径：24.5 t/s 只作量级引用，本篇不做带宽利用率核算（口径存疑，03 篇处理，见 4.3）
4. 安装形态一行含 brew / 官方 .app 两条子路线，不可简化为单一形态

6.2 怎么选

基于两篇实测，按场景给结论：

• 要图形界面、点鼠标、开箱即聊——LM Studio
• 要命令行、脚本化、服务器化（无头运行、launchd 托管、tags 版本可控）——Ollama
• 多路并发当轻量网关——LM Studio 默认连续批处理更从容（02 篇实测口径）
• 单流长文档场景——两边 prefill 数值并列（Ollama 侧 277-344，LM Studio 侧 123-129），格式与后端不同，不能换算倍率；这个场景的选型看需求，不看跨工具快慢（注意表注 1 的口径）

迁移视角补一句边界：网上常说「GGUF 双工具通用、模型文件可复用」——这是通用格式层面的一般知识；02 篇里我们在 mini 上用 LM Studio 跑的是 MLX 格式，跨工具复用没有经我们的数据证明【待验证】。

需求变了再装另一个工具也不迟——两篇的命令和口径都在，随时对照。

6.3 验收清单

本篇已验证（mini 服务机与用户机，两台真机）：

• 双路安装：官方 .app（mini 服务机）+ brew 0.34.4（用户机）
• 服务探活（11434，两台同版本 0.34.4）
• qwen3.8 拉取与驻留（16.5 GB 磁盘 · 18 GB 常驻 · 100% GPU）
• 四组基准数（解码 / prefill / TTFT / 并发，口径见 4.1）
• 局域网开放：用户机侧暴露配置 + 用户机→mini 方向验证（mini→用户机反向待补）

读者作业：

• 断电自启自测（对照 02 篇实录方法）：断电约十秒后来电，在局域网另一台机器 curl 探活 11434，记录服务恢复时间——02 篇 LM Studio 侧的对照值是约 40 s
• 32GB 读者按 3.5 降档路线选模型跑起来，回贴你的数字

6.4 下一篇：03 篇量化课

03《显存账与量化课：M5 Pro 64GB 到底能跑多大》：GGUF 量化等级拆解（Q4_K_M 到底什么意思——本篇 tags 只教了读法）、70B 级重载实测 + GPU 长时散热观察（02 篇的补偿承诺在此兑现）、prefill 背后的算力账，以及本篇 4.3 埋的那个带宽疑点的正式查账。

---

参考资料

• Ollama 官网与文档：https://ollama.com/
• Ollama 模型库 qwen3.8 页：https://ollama.com/library/qwen3.8（tags 与 latest 指向以当期页面为准）【写作期核对：截图核对时同步验证链接可访问性】
• 本系列 02 篇《第一个模型住进盒子：LM Studio 入门》（对比数据来源之一，2026-09-24 实测口径）
• 本系列 01 篇《开箱点火：64GB 统一内存到底意味着什么》（速查表与降档指路基准）
• 本篇性能数字来源：系列实验日志 05《Ollama 真机实测》（2026-09-27，口径详见第四章口径表）

---

免责声明

本文内容仅供学习交流，所述方法需结合实际场景灵活运用。文中性能数字为特定硬件、软件与模型版本下的探索性基准，实际表现因环境而异；Ollama 界面与设置项以当期官方版本为准。

本地服务默认无鉴权，请遵守文中安全边界，勿将服务暴露至公网。

本文由 AI 辅助创作，经人工审核编辑后发布。

---

字数统计：正文 4,895 汉字（含导读与开始之前块，不含参考资料与免责声明；另含命令与表格，汉字+标点合计约 5,790）