ollama的API怎么输入

本地把模型拉起来之后，很多人卡在「下一步到底怎么把话发进去」：不知道请求该往哪个地址打、body 里写什么字段、返回是一串一串吐还是一次性给。这篇不讲原理，只按顺序做一遍：先确认服务在跑、再找到接口地址、然后用一个最小请求跑通，最后给一份报错排查顺序，让第一次调用能出结果。

本地把模型拉起来之后，很多人卡在「下一步到底怎么把话发进去」：不知道请求该往哪个地址打、body 里写什么字段、返回是一串一串吐还是一次性给。这篇不讲原理，只按顺序做一遍：先确认服务在跑、再找到接口地址、然后用一个最小请求跑通，最后给一份报错排查顺序，让第一次调用能出结果。

整个过程里唯一不能猜的就是地址和模型名，这两个值抄错基本必挂。其余参数先全部留空走默认，等你确认模型能正常回话，再回头调。下面的顺序照做一遍，一般十几分钟能见到第一段输出。

动手前先确认三件事

先别急着写代码，手上有三个事实确认了，后面能省掉大半排查时间。这三件事里有一件不成立，你发出去的请求都不会有正常返回。

• 服务确实在跑：命令行里能正常对话，说明模型和服务都起来了，接口才可能通
• 模型名要写对：请求里填的是你本地已经拉下来的那个模型标识，写法跑偏就会报找不到模型
• 端口和地址知道在哪：默认是本机某个端口，装的时候改过或跑在容器里就得换成对应的主机与端口，不确定就去站内 /ai-dict/category/infra 对一遍术语

请求往哪打、内容怎么写

Ollama 对外就是普通的 HTTP 接口，请求方式统一是 POST，内容类型按 JSON 交。它主要给你两个入口：一个偏对话、一个偏补全，选哪个取决于你要做的事，不取决于你用什么语言。

对话式接口

把消息按角色和内容组织成一组，一次可以塞多轮，适合持续对话的场景

文本生成式接口

只给一段提示词就行，适合补全、改写这类单轮任务，字段更少

公共字段

模型名、是否流式、以及可选的温度、最大输出长度等参数，不写就走默认值

请求方式

POST，body 是 JSON，这点跟大多数 HTTP 接口一样

第一次调用建议只写两个必填字段：模型名和一条提示词。等你看到返回了，再往里加角色、多轮、参数这些。字段加得越少，出问题时越容易定位。

流式和非流式怎么选

这是最容易让人误会的地方：同一个接口，开不开流式，返回的结构完全不一样。选之前先想清楚你在哪用，别两头都想占。

• 非流式：等服务把整段生成完再一次性返回，代码最好写，适合脚本和批处理
• 流式：一个字一个字往回推，体感快，适合聊天界面，但客户端要按行拆包处理
• 拿不准先用非流式把链路跑通，确认模型能出结果，再改成流式调体验
• 长回答场景下流式更稳，一次等太久容易被浏览器或网关提前断开

什么情况下不适用流式：你要把整段结果直接丢给下游做结构化解析时，流式反而添乱，得先把碎片拼回来。反过来，如果只是命令行自己看，两种都行，非流式更快写完。

第一个请求跑通的检查清单

1. 先用最朴素的工具发一次拿 curl 或任意 HTTP 客户端发原始请求，别一上来就套 SDK，这样能排除掉封装层带来的问题。
2. 确认返回里的字段名看返回 JSON 里真正装着文本的键叫什么，再把这段解析逻辑写进你自己的代码。
3. 记下这次成功的取值把地址、模型名、参数三项抄下来，以后换模型或换机器就是改这三个值。
4. 量一条延迟基线想对照本地链路快慢，可以到站内 /tools/speed-test 先跑一遍，后面变慢了好比对。

curl -X POST http://本机地址:端口/api/generate -H 'Content-Type: application/json' -d '{"model":"你的模型名","prompt":"说一句你好","stream":false}'

报错按这个顺序查

报错信息五花八门，但排查顺序是固定的：从外到内，先看连不连得上，再看模型认不认，最后看格式对不对。跳着查容易在明明没问题的地方反复折腾。

如果上面都排过了还是慢，那就不是接口的问题，是硬件跟模型不匹配。这种情况去站内 /models/deploy 按它给的测算方式对一遍模型和显卡，比继续改请求参数有用。想顺带看看同类本地方案的差异，可以到 /rankings 对照当时的数字。