企业官网建设流程全解析

这两年，“AI 本地部署”从一个极客玩具逐渐变成了很多开发者、产品经理甚至普通办公人员都会尝试的事情。热搜词里出现大量的“本地部署 DeepSeek”“ollama 本地部署”“Dify 本地部署教程”，说明大家不只是好奇，而是真的想把大模型装进自己的电脑或内网服务器里。

但以我观察到的技术社群情况来看，真正能把这套方案用起来、用稳定、用出价值的人，并没有想象中那么多。更多人折腾三天三夜，卡在“模型下载中断”“显存不足”“上下文窗口爆掉”“推理速度太慢”等一连串问题上，最后只能回到云端 API 的怀抱。

这不是配置能力的问题。更核心的原因是：很多人把“配置”当成了第一件事，而忽略了“想清楚”才是决定成败的前提。

这篇文章想说的就是这个判断：AI 本地部署，真正的门槛不在安装命令，而在部署前的需求判断、模型选型和硬件估算。安装 Ollama 这类工具只需要一行命令，但决定你要装哪个模型、用多少显存、跑多长上下文、拿它来干什么，才是真正需要花时间的事情。

读完这篇文章，你会得到一个完整的、可以落地的本地部署决策思路，以及一套从环境准备到运行验证的实操路径。如果你最近正准备尝试 AI 本地部署，建议先花 10 分钟把文章看完，再决定下一步敲什么命令。

1. AI 本地部署，到底解决了什么问题

聊本地部署之前，先要弄清楚一个底层问题：现在云端大模型已经这么方便了，为什么还有人要折腾本地部署？

从实际使用场景看，最核心的驱动力通常有三个。

第一是数据隐私。企业内部的业务文档、客服对话、代码仓库甚至员工绩效数据，很多人并不愿意把它们提交到外部 API。即使一些云厂商承诺数据不被用于训练，在合规审计面前依然难以给出完美的解释。本地部署最大的价值在于：数据不出内网，整个推理链路都在自己掌控范围内。

第二是长期成本。云端 API 按 Token 计费，日常轻量使用还好，一旦涉及高频调用、批量处理、长文档分析，费用会快速累积。相比之下，本地部署主要是硬件一次性投入加上电费，在“高频稳定使用”的前提下，成本往往更可控。

第三是可控性与定制空间。云端模型说升级就升级，说下架就下架，你无法锁定版本。而本地部署之后，模型跑在哪个版本、用哪种量化方式、系统提示词怎么组织、是否接入知识库和工具调用，全部由自己决定。对于做 AI Agent 开发、RAG 应用或者垂直领域调优的团队来说，这种可控性是刚需。

不过也必须说清楚一件事：本地部署不是万能的。模型能力参差不齐，7B、14B 这类消费级显卡能跑的模型，和 GPT-4o 级别、数百 B 参数的云端模型相比，在复杂推理、长文本理解、指令跟随能力上仍然有明显差距。

所以我不建议一上来就把所有工作负载都迁移到本地。更务实的做法是：把“私有数据敏感的、调用频率高的、格式相对固定的任务”放到本地，把“复杂推理、创作、深度分析任务”留给云端。

这样理解之后，再去看各种部署教程，你的心态会完全不一样——你不是在折腾一个新玩具，而是在搭建一条服务于真实业务的技术管道。

2. 动手配置之前，先想清楚三件事

很多人部署失败，不是因为教程写得不对，而是因为他没有回答几个基本问题就开始执行了。

我建议你在打开终端之前，先花一点时间，把下面这三个问题写下来。

第一个问题是：谁会使用这个本地模型？

这个问题直接决定了你要不要搞并发，要不要做权限控制，要不要接 API 服务。如果只是你自己在个人电脑上跑实验，那么 Ollama 这种单机工具完全够用。如果需要团队五六个人同时访问，那就不能靠个人电脑跑，需要一台内网服务器，并且考虑用 Docker 部署或者加一层 API 网关。如果需要做成公司内部应用，还要考虑日志审计和模型版本管理。

第二个问题是：模型主要使命是什么？

是做代码补全、文档问答、文本摘要、信息抽取，还是纯闲聊？不同的任务对模型能力的要求完全不同。代码生成需要模型有较强的指令遵循和结构化输出能力；中文文档问答需要较好的中文语料覆盖；信息抽取则需要稳定且格式化的输出。

听起来很简单，但很多人恰恰在这里犯了错。看到别人用 32B 模型写代码很流畅，自己也跟着下载，结果自己的显卡只有 8GB，跑起来每秒蹦一两个字，最后只能放弃。如果只是做简单的意图识别或抽取，一个 7B 甚至 3B 的模型可能已经足够了。

第三个问题是：你追求的最好效果是什么？

以回答质量为目标，你就应该用你能带动的最强模型，哪怕牺牲一些速度；以响应速度为目标，你可能就要在模型规模和量化程度上做妥协；以“能跑通”为目标，那么一个最小的 Qwen2.5-3B 或者 Llama-3.2-3B 模型就能让你完成任务。

这三个问题想清楚之后，你才会明白为什么同一篇教程，别人跑通了，你跑不通。本质上不是教程的问题，而是硬件条件、模型选择和任务需求不匹配。

3. 模型选型认知：参数、量化与上下文窗口

很多人挑选模型时，只知道看“参数大小”。说实话，这个习惯需要改一改。

大语言模型的参数量可以粗略理解为模型的“知识容量”和“推理能力基础”，但它不是唯一指标。真正影响你能不能跑起来、跑得好不好的，还有量化方式和上下文窗口两个变量。

量化是什么？简单说，就是把模型权重从高精度（比如 FP16，每个参数占 2 字节）压缩到低精度（比如 INT4，每个参数占 0.5 字节）的过程。量化后的模型体积更小、推理时显存占用更低，代价是推理质量有轻微下降。同一个 7B 模型，FP16 版本可能需要 14GB 显存才能跑，但 4-bit 量化版本只需要 4GB 左右就能运行。

本地部署中最常见的量化格式包括 GGUF（由 llama.cpp 生态推动，Ollama 和 LM Studio 都支持）以及 GPTQ 等。GGUF 是目前个人电脑和中小服务器上兼容性最好的格式。

这里必须澄清一个常见误区：量化不意味着模型变成“残废”。以 Q4_K_M 这类常用量化等级为例，它在大多数任务上的表现和 FP16 版本的差距非常小，尤其在日常对话、文本总结、代码解释等场景，普通用户几乎感知不到差异。这也是为什么很多 8GB 显存显卡的用户能够流畅运行 7B 或者 14B 模型——他们用的就是量化版本。

上下文窗口则是另一个容易被忽略的关键参数。上下文窗口越大，模型能一次性处理的内容越多。但上下文越长，推理时需要的显存也越高，因为模型需要缓存更多的历史 token 参与计算，也就是所谓的 KV Cache。很多人在本地跑 7B 模型很流畅，把上下文调到 32K 之后立刻发现显存不够或者速度骤降，就是忽略了上下文长度带来的显存增量。

所以在选模型时，我的建议是不要只盯着参数大小，而是用这样一个公式去粗略思考：模型文件大小 + 估算的上下文额外开销 + 系统运行余量 = 你需要的显存空间。

如果你只有一个大致的“模型该选多大”的问题，可以参考下面的经验分层：

• 3B 至 4B 级别模型：适合 6GB 到 8GB 显存的环境，能完成简单问答、意图识别、轻度文本改写。
• 7B 至 9B 级别模型：适合 8GB 到 12GB 显存的环境，综合性价比很高，文本理解、代码解释、结构化输出都能胜任。
• 14B 级别模型：建议 16GB 显存以上，推理质量明显优于 7B，是比较推荐的质量与资源平衡点。
• 32B 级别模型：建议 24GB 显存以上，或者使用多张显卡，适合对回答质量要求较高且机器配置较强的场景。

这里需要说明的是，模型能力迭代非常快，具体的模型名称和版本推荐随时都在变，我更希望你能掌握这套判断思路，而不是记住某个特定版本。

4. 硬件需求拆分：显存、内存与硬盘怎么估算

很多新手对硬件配置有一个朴素的想象：只要硬盘能装下模型，电脑就能跑。这个想法离实际还挺远的。

模型推理的完整过程中，影响体验最大的硬件资源依次是显存、内存、硬盘。

先说显存。模型运行时，模型权重、KV Cache 和中间激活都需要显存来承载。显存不够时，系统会尝试把一部分数据放到内存里交换，但这会带来巨大的性能损耗——表现为生成速度骤降、甚至直接卡死。

所以选择部署方案的第一个问题就是：你的显卡有多少显存？如果你没有独立显卡，或者显存只有 4GB 以下，那默认应该放弃“本地跑大模型”这个念头。可以考虑用 CPU 运行极小模型（如 1B-3B 级别），但体验只能说“能跑”，距离“可用”还有一段距离。

如果你有 8GB 显存，这意味着你能够舒适地运行 7B 模型的 4-bit 量化版本。如果想跑 14B 模型，就需要接受更激进的量化方式，同时把上下文窗口限制在 4K 到 8K。这个组合能用，但质量会有妥协。

如果你有 12GB 或 16GB 显存，你的选择空间会大很多。7B 模型可以跑更高精度的量化，14B 模型也能比较流畅地运行。这个区间是我认为本地部署“体验及格线”的起点。

如果你有 24GB 显存（比如 RTX 3090 或 4090 级别的显卡）以上，恭喜你，你已经可以挑战 32B 级别的模型了。这种配置已经能够满足大多数个人开发者和部分小型团队的日常需求。

除了显存，内存至少要有 16GB，最好上到 32GB。本地跑 Docker 容器、配合向量数据库、做知识库检索时，内存占用往往比想象中高。

硬盘方面，建议预留至少 50GB 到 200GB 的空间——模型文件从 2GB 到 30GB 不等，如果你下载多个模型，空间加起来会非常可观。现在的大模型部署普遍使用 SSD，模型加载速度对推理性能没有直接影响，但加载等待时间会明显缩短。

综合下来，我可以给出一个比较保守的判断：如果你想获得“接近可用”的本地大模型体验，一台 16GB 显存以上的消费级显卡机器是比较理想的起点。如果预算有限，8GB 显存也能做很多实验，但不要期待它能承载过高质量的应用级任务。

5. 主流本地部署工具选型对比

硬件想清楚之后，下一步才是选部署工具。目前社区里主流的本地大模型部署工具大概有这么几类。

第一类是 Ollama，目前最热门的轻量级本地推理工具。它把模型下载、模型运行、API 服务打包成了一个极简体验，一句话就能启动。对绝大多数个人开发者来说，Ollama 是最合适的起点，没有之一。它在 macOS、Linux、Windows 上都有安装包，而且兼容 AMD 和 NVIDIA 显卡。

第二类是 LM Studio，一个带图形界面的桌面端工具。它的优势在于可视化，适合不想敲命令、或者想先图形化体验模型效果的用户。从模型搜索、下载到加载运行，全部可以在界面里完成。它还能直接提供兼容 OpenAI 格式的本地 API，这对接开发调试很有帮助。如果你属于刚接触本地模型的普通用户，LM Studio 的学习曲线比 Ollama 更平缓。

第三类是 llama.cpp 及其衍生生态。它是最底层的推理引擎之一，目前 Ollama、LM Studio 等工具的底层本质上都借用了 llama.cpp 社区推动的 GGUF 格式和相关推理逻辑。直接使用 llama.cpp 的好处是极致灵活，可以针对特定显卡做 CPU 层数分配、批量推理参数调优。代价是要面对大量命令行参数，上手成本高。

第四类是 Dify。它不是一个单纯的模型运行工具，而是大模型应用开发平台。很多人会先部署 Ollama 拉起模型，然后在 Dify 里接入这个模型，继续搭建知识库问答、Agent 工作流、对话应用。如果你最终的目标不只是“本地跑个对话”，而是做一个知识库机器人或者自动化流程，Dify 这类平台是值得研究的方向。热门词里的“Dify 本地部署教程”也反映了这个需求正在快速增长。

第五类是 vLLM，面向服务化部署和大吞吐量推理的引擎。它通过 PagedAttention 等技术优化了显存利用率和并发能力，适合做多用户共享的模型服务。不过 vLLM 对硬件和 CUDA 环境的要求更高，部署成本也更大，我建议先从 Ollama 或 LM Studio 上手，等明确需要服务化部署后再迁移。

工具本身没有绝对的优劣，关键在于场景匹配。个人实验选 Ollama，图形化体验选 LM Studio，追求并发生产级服务选 vLLM，做复杂应用选 Dify。这几个方向可以互相组合，不需要一开始就定死某一个。

6. 从零跑通本地模型：以 Ollama 为例的实操路径

下面进入实操环节。我以目前用户基数最大、最不容易出错的 Ollama 为例，演示一套最小可行的本地部署流程。文章中的命令和配置以通用步骤为准，具体版本号请以实际下载到的最新稳定版为准。

6.1 安装 Ollama

安装本身很简单。Windows 用户直接下载安装包运行；macOS 可以下载安装包或者用 Homebrew 安装；Linux 用户执行官方提供的一键命令即可。

在 Linux 服务器上，常见的安装方式是执行：

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

安装完成后，可以用版本命令验证是否安装成功：

ollama --version

如果系统能正常输出版本信息，说明安装成功。

这里有一个小提醒：Windows 下安装完成后最好重启一下终端工具，否则环境变量可能没有立即生效。如果执行ollama提示找不到命令，就需要手动检查系统环境变量里的安装路径。

6.2 下载并运行一个模型

Ollama 模型库中有大量模型，但在这里不建议盲目下载大模型，先把一个中小模型跑通，比一上来挑战大模型更重要。

以 Qwen2.5 系列为例，你可以先尝试 3B 或者 7B 级别的版本。运行命令非常直观：

ollama run qwen2.5:7b

如果你是第一次运行，Ollama 会自动从模型库下载模型到本地。这个下载过程需要等待一段时间，具体时间取决于模型大小和网络速度。下载完成后会自动进入一个交互式对话界面，你可以直接在里面输入问题和它聊天。

输入/bye可以退出对话界面。

打开另一个终端，可以使用下面的命令查看本机已经下载好的模型列表：

ollama list

常见输出大致如下，具体信息视你所下载的模型不同而不同：

NAME ID SIZE MODIFIED qwen2.5:7b 1a7c2e2a78cc 4.7 GB 2 hours ago

这个列表会告诉你模型名称、ID、占用的磁盘空间以及最后的修改时间。

除了交互式对话，Ollama 还支持一种更方便的用法——用 HTTP API 调用模型。因为在真实开发场景里，你不会总在终端里聊天，而是需要让自己的代码和本地模型通信。Ollama 默认会在本机的 11434 端口启动一个 API 服务，执行下面的 curl 就能验证：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "你好，请用一句话介绍你自己", "stream": false }'

其中stream: false表示等待完整生成结束之后一次性返回结果。返回的 JSON 里会包含response字段，里面就是模型的回答。

其实 Ollama 还提供了兼容 OpenAI 格式的 API 端点，路径是/v1/chat/completions。这意味着你原来写的基于 OpenAI SDK 的应用，只要把base_url改成本地地址，就能切换到本地模型，代码几乎不用做大的改动。这一步对很多开发者来说，是真正能把本地模型接进自己项目的关键。

6.3 配置自定义模型

Ollama 不只是让你直接下载别人做好的模型，它还支持基于已有模型创建定制版本。通过编写一个Modelfile文件，可以定义系统提示词、推理参数、模板等。我平时用得最多的场景是固定某个角色的系统提示词以及调整温度参数，让模型输出更稳定。

下面是一个最小示例，创建一个名为my-assistant的自定义模型：

# 文件路径：Modelfile FROM qwen2.5:7b SYSTEM 你是一名专业的技术助手。回答问题时请使用简洁清楚的中文，必要时提供代码示例。 PARAMETER temperature 0.3 PARAMETER num_ctx 8192

在包含该文件的目录下执行以下命令创建模型：

ollama create my-assistant -f Modelfile

可以简单解释一下参数的差异：温度参数temperature越低，模型的输出越确定、保守，适合技术问答和结构化内容生成；越高则更有创造性但也更容易胡编。num_ctx是上下文窗口长度，这里设置 8192 意味着模型能同时记住的 token 数量大约为 8192。

创建完成后，你和这个定制模型的交互方式跟普通模型一样：

ollama run my-assistant

这个机制的实用价值在于：团队内部可以把一套精调过的系统提示词和参数作为共享配置，而不是每次让使用者自己敲一长串提示词。

6.4 Docker 方式部署服务端

如果你需要在服务器上稳定运行一个随时可被其他机器访问的模型服务，更推荐用 Docker 来部署 Ollama。

在已经安装好 Docker 的前提下，执行：

docker run -d --name ollama-server \ -v ollama_data:/root/.ollama \ -p 11434:11434 \ ollama/ollama

挂载ollama_data卷是为了让模型数据持久化，即使容器重建，已经下载的模型也不会丢失。容器启动后，进入容器去拉取模型：

docker exec -it ollama-server ollama run qwen2.5:7b

之后局域网内其他设备就可以通过这台服务器的 IP 地址来访问 API，例如：

curl http://192.168.1.100:11434/api/generate -d '{"model": "qwen2.5:7b", "prompt": "你好"}'

Docker 的优势是把运行环境全部封装好，不会污染宿主机，卸载也干净。对于后续要上生产环境或换机的团队来说，这一步非常值得。

7. 验证本地模型的效果：不只是“能聊天”

模型跑通之后，很多人会陷入一种幻觉：它能正常回复，就认为部署完成了。严格来说，这只是第一步。

部署工作流里应该有一环叫“效果验证”，也就是用一套固定的测试问题去衡量模型输出是否达到业务要求。这个过程不需要很复杂，但必不可少。

我的建议是准备一组覆盖不同类型任务的评测问题，每个问题都设定“通过标准”。

例如，如果你想用本地模型做文档摘要，那么评测问题应该包含一段测试文本，通过标准是“摘要是否保留关键结论”而不是“摘要是否通顺”。如果你想用模型做格式化信息抽取，那应该测试它能否稳定输出 JSON。如果你想做代码解释或生成，需要测试它能否理解常见的编程概念并给出可运行的代码。

除了问题层面，还要留意两个技术指标。

第一个是响应时间。用机器跑模型和用云端 API 的最大体验差异是响应速度。不同硬件配置下差异巨大：8GB 显存的笔记本跑 7B 模型，生成速度可能只有每秒 10 到 20 个 token；数据中心级 GPU 跑同样的模型可能每秒几百个 token。

可以用下面的小测试大致感受一下生成速度：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "请用 200 字介绍杭州", "stream": false }'

通过观察返回结果中是否包含耗时信息，或者自己用time命令来计时，可以大概知道这个模型在你机器上处于什么速度水平。

第二个是上下文长度。语境越长，模型处理越慢、显存占用越高。我建议测试时，故意把一段长文本输入进去，观察是否出现“答非所问”“突然截断”或者“显存溢出”的情况。如果出现问题，就应该在启动参数里限制最大上下文长度，而不是指望模型硬扛。

只有在这些验证都通过之后，你才能真正说：这个本地模型可以被项目用了。而不仅仅是“它跑起来了”。

8. 常见问题与排查思路

结合社区里大家的高频反馈，这里整理了几类本地部署过程中最常遇到的问题。给你一个排查表做参考：

排查问题时有一个通用的原则：不要在现象层面反复横跳，先去看日志。Ollama 在运行时的错误日志比任何猜测都更可靠。Windows 和 macOS 可以查看ollama serve命令启动时终端输出的日志；Docker 部署则使用下面命令查看实时日志：

docker logs -f ollama-server

很多时候，你花半小时搜索错误的解法，不如花两分钟看一下日志里第一行报错信息来得直接。

9. 从“跑通模型”到“跑通应用”：RAG 与 Agent 接入

很多人完成第一步“模型能聊天”之后，会觉得本地部署不过如此。产生这个想法太正常了，因为直接对话只是大模型的原始形态，不是应用形态。真正的价值在于把模型接入到实际工作流中。

一个最典型的应用方向是知识库问答（RAG）。

场景是这样的：你有一堆内部文档、产品说明书或者历史工单，直接问模型，它不一定知道答案，因为模型训练的数据里没有这些内容。传统的做法是让用户自己去文档里找答案。而 RAG 的做法是先将这些文档切分成小块，用 Embedding 模型把每块文本转成向量，存入向量数据库。当用户提问时，系统把问题也转成向量，在数据库中找出最相似的内容片段，拼接成提示词，再交给大模型生成最终回答。

这带来的价值很明显：本地大模型不需要针对每个领域重新训练，就能回答私有知识相关的问题，答案还附带了来源引用。这套方案在企业内部已经得到大量应用，也是 Dify 这类工具很重要的落地方向。

LangChain 和 LlamaIndex 是目前个人开发者搭建这类应用最常用的框架。

另一个应用方向是 Agent 接入。所谓 Agent，就是让模型不只是“回答问题”，而是能够根据目标拆解任务、调用外部工具、观察返回结果并决定下一步行动。在本地部署场景里，最经典的工具调用方式是 Function Call。

Ollama 本身支持工具调用能力，也就是说你可以在发起请求时声明一批函数接口，模型会根据用户的诉求，决定调用哪个函数并返回结构化的调用参数。你的程序再去真实执行这个函数，把执行结果传回给模型，让模型继续生成最终回答。

这种模式的开源生态很丰富，包括经典的 OpenAI Function Calling 兼容链路、LangChain 的工具调用机制，以及 Spring AI、Dify 等平台对 Agent 工作流的支持。

我举一个非常小的例子。假设你有一个本地工具函数，功能是查询某个城市的天气。你可以把“获取当前天气”这个函数的描述和参数格式传给模型，当用户说“今天北京适合出门吗”，模型并不直接回答，而是返回一个意图正确的函数调用请求。你的后端代码执行真实查询，把结果“北京今天晴，25 度”返回给模型，模型再综合这个输出编排出完整的回答。

这个过程的本质是：大模型负责理解意图和编排任务，外部代码负责获取真实数据。模型还是那个模型，但它从“聊天机器人”变成了“智能助理”。以当前最热门的需求来看，这类从模型到应用的路由、工作流和编排，才是 AI 本地部署真正值得花精力的部分。

10. 本地部署要想用得久，这几件事需要养成习惯

最后聊聊长期维护。很多人把模型部署好之后，就把一切抛在脑后。结果模型跑了一两个月，版本没有更新，模型库越堆越占硬盘，日志文件越来越大，甚至系统升级之后原来的服务启动不了了。

我建议在项目一开始，就给自己定义几条维护规则。

第一，模型的下载和管理要统一。不管是 Ollama、LM Studio 还是 vLLM，都要保证同一类模型只保留一个合理版本。不要见一个模型就下载一个，硬盘不是无限的。

第二，将自定义配置和部署环境做成可复现的脚本或 Dockerfile。这样即使某天系统重装，也能快速恢复整套环境，而不是靠记忆重新配置。

第三，在初步跑通后及时停用一些多余的服务。本地部署的本质是对硬件资源的管理，模型进程默认会常驻显存，如果你不下线它，显存就一直被占着，其他需要 GPU 的任务就会受影响。养成不需要时执行ollama stop的习惯。

第四，所有涉及团队共享的应用，都要在服务端做一层基础的使用记录。无论只是按用户维度记录调用频率，还是记录模型的输入输出日志，这对后续排查问题和评估效果都有帮助。特别是内部业务场景，甚至可能触达合规审计要求，日志这件事不能省略。

第五，尽量避开“谁部署、谁独享”的单点模式。如果团队中有多个人都需要使用模型，就部署在一台大家都能访问的服务器上，不要每个人在自己电脑上各跑一份。既消耗团队整体硬件资源，还让模型版本不一致，后续维护成本非常高。

此外，在把任何私有数据输入本地模型之前，依然要确认模型的提供方和数据传输链路是否安全。本地部署不等于天然安全，比如你部署了一个第三方模型，模型本身在推理时是否会上传数据，需要按模型来源和授权策略仔细确认。对于生产环境，优先选择可信开源模型，并在隔离网络环境内运行相关服务。

最后的建议

AI 本地部署并不是一次“装好就结束”的任务，而是一个“准备 - 推理 - 验证 - 迭代”的循环。

准备阶段，先让自己想清楚部署场景，将模型要完成什么任务、谁在用、性能底线是什么列清楚，再做规划设计。选型阶段，老老实实对照自己的显卡显存、内存储备和下载带宽，选择真正能跑得动的模型。验证阶段，准备一套自己的测试问题集，告诉自己要接受什么标准。迭代阶段，逐渐把知识库、Agent 能力、服务化 API 依次接入，让模型真正进入工作流。

如果你现在正准备下载第一个模型，我只提一个具体建议：先别碰你硬盘里最大那个，先跑通一个小模型。让ollama run那行命令成功返回，让 Python 代码通过 API 拿到结果，把整条链路摸顺再说。

部署本身只是开始，以后怎么用、怎么维护，才是真正有挑战也最有回馈的方向。希望这篇文章能帮你少走一段弯路。建议收藏备用，下次准备在电脑上跑一个新模型时，可以回来重新读一遍前面的判断部分。