ollama 如何 使用 api

模型在本地跑起来了，但一到写代码就卡：不知道该打哪个地址，参数名和云端接口对不上，返回是一串流式文本不好解析，换用 OpenAI 兼容写法又怕漏字段。这篇按「确认服务在听 → 选端点 → 传参 → 处理返回」的顺序走一遍，只讲接口层面的动作，不重复选型结论。

模型在本地跑起来了，机器也热了，可一到写代码就卡壳：不知道该打哪个地址，参数名和云端接口对不上，返回是一串分段的流式文本不好解析，换用 OpenAI 兼容写法又怕漏字段。这篇不聊选型，只讲接口层面怎么把请求发出去、怎么把返回读明白。

整条路径拆成四步：确认服务在听 → 选端点 → 传参 → 处理返回。每一步都有能马上验证的动作，卡住的时候按顺序回退，比在一个报错上反复改参数快得多。下面按这个顺序走一遍。

先确认服务在听、地址对不对

本地服务默认监听回环地址上的固定端口。听起来简单，但出错最多的就是这一步：调用方在容器里、在 WSL 里、在局域网另一台机器上，这三种情况看到的「本地」完全不是同一个东西。先把「调用方在哪」想清楚，再决定 base url 写什么。

• 最轻的探测方式是调列出已下载模型的接口，能返回列表就说明端口和路径都通，不通就先查服务起没起、端口有没有被占。
• 要让容器或别的机器调到，需要改绑定地址与端口的环境变量，改完必须重启服务才生效。
• 跨容器调用时，回环地址指的是容器自己，不是宿主机，写错了会一直连接被拒；这种情况换成宿主机的可达地址或服务名。
• 对外暴露之前先想清楚同网段谁能访问，暴露风险的处理思路可以到 /guides 里的相关说明核对。

两个端点，先搞清用哪个

服务同时提供两套入口：一套是单轮补全式，一套是对话式。前者可以理解成无状态的文本拼接，把上下文当成一整段文本送进去；后者按消息数组组织，每条消息带角色字段。多轮对话选对话式，能省掉自己维护历史拼接的那层逻辑。

新手最常见的坑是把一边的字段名照抄到另一边：两个端点的请求体结构不一样，模型名、消息字段、运行项的位置都有差异，抄错了就是参数错误。确定端点之后再动手写请求体。

参数怎么传，哪些值得动

模型名必须在请求里显式指定，而且要和本地已经拉取的名字完全一致，大小写和后缀标签对不上就会提示找不到模型。这一点没有捷径，先列出本地已有模型，从返回值里复制名字。

模型名

必须显式传，和本地已拉取名字逐字符一致

采样类参数

控制随机性与候选范围，影响输出风格不影响连通性

长度上限

限制单次输出长度，设太小会截断长回答

驻留时长

控制模型在内存里保留多久，常驻省加载时间但占显存

流式开关

决定返回是一段段推还是一次性给全

建议先全部用默认值把请求跑通，再按任务微调采样和长度。常见误区是一上来就调一堆参数，结果分不清是参数写错了还是接口没通。机器上还跑着别的任务时，模型常驻要权衡显存占用。各端点的字段口径，到 /tools 里的接口说明和术语词典核对当时的版本，比照着报错猜字段快得多。

返回怎么读：流式与一次性

默认情况下返回是一串分段推送的 JSON，每段带一小块增量文本和一个结束标记。客户端要按行拆开，逐段取出增量字段拼起来，最后一段才带统计信息，比如耗时和 token 计数。直接拿整包当 JSON 解析会失败。

curl 本地服务地址/对话端点 \;  -H 'Content-Type: application/json' \;  -d '{"model":"已拉取的模型名","messages":[{"role":"user","content":"你好"}],"stream":false}'

想省事就把流式关掉，一次拿到完整结构，代价是长输出时首字等待明显变长，交互式界面不建议这么做。按 OpenAI 格式写的客户端可以直接用兼容入口，base url 指向本地服务即可，现成 SDK 大多不用改代码。解析出问题时先看原始响应长什么样，确认是分段还是一整包，再回头查自己的解析逻辑。

卡住了按这个顺序排查

1. 量基线用站内测速工具打一次请求，能出结果说明服务和网络没问题，剩下的都是参数或解析层面的事。
2. 对齐字段把请求体、模型名、端点路径三项依次比对，一次只改一个变量，改完立刻重试。
3. 看返回提示报错里点名的字段往往就是要补的参数；如果是超时，先想模型是不是正在加载、显存是不是不够。
4. 看服务端日志服务会记录每次请求的模型加载与报错，比在客户端反复打印请求体直接，把日志留档下次同类问题秒查。

这套顺序不适用于一种情况：如果连接根本建立不起来，先别纠结字段，回到第一节把地址和服务状态确认一遍。字段层面再怎么调，也救不了一个没连上的请求。

接口问题十有八九不是参数没调好，而是地址没对准或格式没拆对。