3. 模型运行与交互：让Ollama真正为你工作
模型下载好了，就像买了一把好刀。但刀好不好用，得看你怎么使。这一节，我们就来聊聊怎么让模型真正跑起来，并且跟它顺畅地交流。
我个人习惯把这一章叫做「人机对话的桥梁搭建」。说白了，就是搞清楚怎么跟模型打招呼、怎么让它干活、以及怎么调教它让它更听话。
本章核心脉络：从命令行启动 → 交互式对话 → API调用 → 参数调优，一步步带你掌握模型运行的全流程。
3.1 用 ollama run 启动模型
最直接的方式，就是 ollama run 命令。你想想看，这就像在终端里敲了个「开门咒语」，模型就乖乖出来了。
# 启动一个已经下载好的模型
ollama run llama3.2
# 如果模型还没下载，ollama 会自动先下载再运行
ollama run qwen2.5:7b我第一次用的时候，以为要等很久。结果呢？几秒钟就进去了。嗯，这里要注意：首次加载会慢一些，因为要把模型参数加载到内存里。第二次再跑就快多了。
小技巧：如果你机器内存不大，可以加 --keep-alive 0 参数，用完就释放内存。我经常在开发机上这么干，省得模型一直占着资源。
3.2 命令行交互模式
启动之后，你就进入了一个对话界面。说白了，就是跟模型「聊天」。
>>> 你好，请介绍一下你自己
我是 Llama 3.2，一个开源的大语言模型...
>>> 1+1等于几？
1+1=2
>>> /bye # 退出对话这里有几个常用的「斜杠命令」，我列出来给你看：
| 命令 | 作用 | 我的备注 |
|---|---|---|
/bye |
退出对话 | 最常用，没有之一 |
/clear |
清空对话历史 | 上下文太长时用，能省显存 |
/show |
查看模型信息 | 调试时很有用 |
/set |
临时修改参数 | 比如 /set temperature 0.7 |
我曾经在调试客服系统时，发现模型回答越来越啰嗦。后来才发现，是对话历史太长，模型「学坏」了。用 /clear 清一下，立马恢复正常。
3.3 通过 API 调用模型
命令行交互适合测试。但真正的生产环境，肯定要用 API。Ollama 提供了非常简洁的 RESTful API，默认监听 11434 端口。
我个人最常用的是 /api/generate 和 /api/chat 两个接口。前者适合单轮问答，后者支持多轮对话。
3.3.1 单轮生成：/api/generate
curl http://localhost:11434/api/generate -d '{
"model": "llama3.2",
"prompt": "用一句话解释什么是大语言模型",
"stream": false
}'返回结果长这样：
{
"model": "llama3.2",
"response": "大语言模型是一种基于深度学习的人工智能模型...",
"done": true
}注意：stream 参数默认是 true，会流式返回。如果你想要一次性拿到完整结果，记得设成 false。我在做前端对接时，就因为这个踩过坑——前端没处理好流式数据，页面直接卡死了。
3.3.2 多轮对话：/api/chat
做客服系统，肯定要支持多轮对话。这个接口就是干这个的：
curl http://localhost:11434/api/chat -d '{
"model": "llama3.2",
"messages": [
{"role": "system", "content": "你是一个友好的客服助手"},
{"role": "user", "content": "你好，我想退货"},
{"role": "assistant", "content": "好的，请问您的订单号是多少？"},
{"role": "user", "content": "ORD-2024-001"}
],
"stream": false
}'你看，messages 数组里记录了完整的对话历史。模型会根据上下文来回答。我建议你每次请求都带上 system 消息，它能帮你控制模型的「人设」。
3.4 常用模型参数调整
模型跑起来了，但回答质量可能不尽人意。这时候就需要调参数了。两个最关键的参数：temperature 和 top_p。
3.4.1 temperature：控制「创造力」
说白了，temperature 控制模型回答的「随机性」。
| temperature 值 | 效果 | 适用场景 |
|---|---|---|
| 0.0 - 0.3 | 确定性高，每次回答几乎一样 | 客服问答、知识库查询 |
| 0.4 - 0.7 | 适度随机，有创意但不离谱 | 日常对话、文案生成 |
| 0.8 - 1.0 | 高随机性，可能「脑洞大开」 | 创意写作、头脑风暴 |
我在做客服系统时，temperature 一般设在 0.1 到 0.3 之间。为什么？你想想看，客户问「退货流程是什么」，你肯定不希望模型每次编出不同的答案。稳定才是王道。
3.4.2 top_p：控制「候选词范围」
top_p 是另一种控制随机性的方式。它跟 temperature 有点像，但机制不同。
简单理解：top_p 决定模型从「前百分之多少」的词里选答案。
- top_p = 0.1：只从前 10% 最可能的词里选，回答非常保守
- top_p = 0.9：从前 90% 的词里选，多样性更高
- top_p = 1.0：所有词都有可能，等于没限制
我的经验：一般建议只调其中一个参数。我个人习惯固定 top_p = 0.9，然后微调 temperature。两个一起调容易「打架」，效果反而不好。
3.4.3 在 API 中传参
参数怎么传？很简单，在请求体里加一个 options 字段：
curl http://localhost:11434/api/generate -d '{
"model": "llama3.2",
"prompt": "写一首关于春天的诗",
"options": {
"temperature": 0.8,
"top_p": 0.9
}
}'在命令行交互模式里，也可以用 /set 命令临时调整：
>>> /set temperature 0.3
Set parameter 'temperature' to 0.3避坑指南：我曾经把 temperature 设成 2.0 想看看效果，结果模型开始「胡言乱语」，输出了一堆乱码。官方建议范围是 0.0 到 1.0，超过 1.0 就别试了，真的会翻车。
3.5 小结一下
这一节我们走通了模型运行的完整链路：从 ollama run 启动，到命令行交互测试，再到 API 调用集成，最后用参数调优让模型更「听话」。
你可能会问：这些参数到底怎么组合最好？我的建议是——先跑起来，再慢慢调。别一开始就纠结参数，先把对话流程走通，后面有的是时间优化。
公众号:蓝海资料掘金营，微信deep3321