ollama 怎么调用 api

本地跑起了模型，一到写代码调用就卡壳：端口填哪个、请求发什么格式、流式怎么接、返回为什么是空。这篇不重复讲协议兼容和客户端配置，只给你一份调用前后的工程清单——连不通先查什么、参数怎么给、超时并发和日志怎么设，照着走能把第一次调用跑通。

本地模型能跑起来，不等于代码能调通。很多人卡在第一步：端口填哪个、请求发什么格式、流式怎么接、返回为什么是空的。这篇不重复讲协议兼容和客户端怎么配，只给一份调用前后的工程清单——先确认能连上，再组织请求体，然后处理流式、超时和并发，最后用日志和验收判断这次接入到底成没成。

照着这份清单走，第一次调用大概能在半小时内跑通。跑通之后别急着接业务，先按最后一节的验收方法过一遍，确认稳定、报错可读，再接正式流程，能少踩不少坑。

先把「能不能连上」这一步做扎实

调用前先确认三件事：服务在不在跑、监听地址写对没、端口通不通。本地默认监听回环地址，只允许本机访问；如果你在容器里或者另一台机器上调用，必须显式改成对外监听，否则连不上根本不是代码问题。路径前缀和请求方式也是高频坑，同一个地址少一段或多一段就直接返回找不到，别凭记忆写。

1. 先看服务在不在在终端敲一条最简命令，看服务进程是否存活、端口是否被占；进程没跑就先把服务起起来，别急着改代码。
2. 命令行整一次最简请求用 curl 或官方命令行工具发一次请求，把返回原样贴出来。链路通了再写业务代码，能省掉在代码里瞎改参数的时间。
3. 按顺序排查连不上服务是否在跑 → 端口是否被占 → 防火墙与容器网络 → 请求地址是否拼错。逐层排除，不要一言不合就重装。
4. 跨机调用改监听容器内或跨机调用时，确认服务监听地址已改成对外，同时放行对应端口；改完再用命令行验证一次。

请求体怎么组织：模型名、消息、参数三块

一次调用最少要给两样东西：用哪个模型、说什么内容。模型名必须和服务里已拉取的名称一致，写错会直接报找不到模型。对话式接口把多轮消息按角色顺序传进去，角色区分系统设定与用户输入，顺序错了模型理解会偏。生成参数按需调，温度、输出长度上限、采样相关字段各管一段，先都用默认跑通，再一个一个改，别一次改一堆。

拿不准参数名先去站内术语页核对，别猜。有些接口的参数名相近但作用不同，写错不会报错，只会让输出悄悄跑偏，比直接报错更难查。

流式要不要开，超时和并发怎么设

流式适合边生成边展示的场景，非流式适合一次性拿完整结果再做后续处理。两者请求体差别很小，但客户端读取方式完全不同，接之前先定好。流式最容易出的问题是读取没读到结尾就断开，导致内容截断；处理时要把每段增量拼接，并显式处理结束标记，别看到一段就当作完整结果。

• 流式：把每段增量按顺序拼接，显式判断结束标记，收到结束再落库或展示
• 非流式：一次性等完整返回，适合拿结果再做解析、校验或写库
• 超时：区分连接超时和读取超时，本地模型首字时间比云端长，读取超时给小了会在正常生成中途被掐断
• 并发：本地推理受显存和算力限制，请求排队会让单个请求变慢，批量任务要分批投、限制在跑数量、失败单独重投

超时值别拍脑袋定，先量一个本地延迟基线：发一条典型长度的输入，记下首字时间和总耗时，再按这个基线留出余量。并发也一样，先测单个请求的稳定耗时，再决定同时跑几个，一上来就压满通常只会让所有请求一起变慢。

日志该记什么，怎么判断这次接入算成了

每次调用至少记下这几项：请求时间、模型名、参数快照、耗时、返回状态、输出长度。出问题时这几项就能定位是慢、是贵还是报错。参数和模型名要一起记，改过参数之后才能对比前后差异，不然只看到结果变了却不知道是谁导致的。

验收别只看「有返回」。至少跑三种输入：正常问题、超长输入、明显超范围的输入，看返回是否稳定、报错是否可读。本地模型升级或换模型后，同一批输入重跑一遍对比输出，确认没有跑偏再接入正式流程。