1.本人在使用本地部署的ollama进行模型调用的时候响应很慢一直以为是哪里配置问题一直在改代码改Linux上面的配置查资料看官方文档研究了两天以下就是我总结的问题[请求进入开始计时] 耗时4ms 2026‑08‑23T16:06:26.41708:00 DEBUG 7600 --- [home-ai] [ctor-http-nio-3] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [eval-duration] [首token] 总耗时30507ms, token今天 2026‑08‑23T16:06:56.92308:00 DEBUG 7600 --- [home-ai] [ctor-http-nio-3] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration] [末尾token] 总耗时39664ms, token日 2026‑08‑23T16:07:06.07408:00 DEBUG 7600 --- [home-ai] [ctor-http-nio-3] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration] [接口完成] 总耗时40021ms 2026‑08‑23T16:07:06.43108:00 DEBUG 7600 --- [home-ai] [ctor-http-nio-3] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration]从上面可以看出来请求 -- 到首个Ai回复的token用时30秒 -- 最后一个token用时9秒 --最后结束几毫秒的时间从日志可以看出后面几个时间都没有什么问题主要问题出现在请求到 --首个token处为什么会有一个30秒的时间这过程中他是在干什么当时我也很好奇我使用curl 命令在linux和本地cmd里面测试都是正常的这就很奇怪我也是看了官方文档后面又去网上查询资料终于找到原因了问题出现原因1. 一般在练习ollama本地部署的时候都是使用的虚拟机但是虚拟机吃的是电脑本身的性能如果电脑本身配置不是很高那就会导致回复的很慢。2.为什么在虚拟机Linux、本地CMD、Postman等工具里面请求会比Api更快原因是APi调用底层有逻辑推理比如你Java自带的一些提示词之类的东西导致模型在慢的基础上继续推理就会显得更加的慢而虚拟机Linux、本地CMD、Postman等是不带有提示词的所以就比API调用的更快。演示环节问候语句你好你叫什么代码案例GetMapping(value /ai/stream, produces text/event-stream;charsetUTF-8) public FluxString streamChat(RequestParam String prompt) { LocalDateTime now LocalDateTime.now(); DateTimeFormatter fmt DateTimeFormatter.ofPattern(yyyy‑MM‑dd HH:mm:ss); String weekCn now.getDayOfWeek().getDisplayName(TextStyle.FULL, Locale.CHINA); String timeInjectPrompt 【服务器真实时间上下文】 当前真实时间当前时间%s今天是%s .formatted(fmt.format(now), weekCn); long t0 System.currentTimeMillis(); FluxString content chatClient.prompt() .system(timeInjectPrompt) .user(prompt) .stream() .content() .doOnSubscribe(s - { long t1 System.currentTimeMillis(); System.out.println([HTTP发起] 耗时 (t1 - t0) ms); }) .doOnNext(token - { long t2 System.currentTimeMillis(); System.out.println([首token] 总耗时 (t2 - t0) ms, token token); }) .doOnComplete(() - { long t3 System.currentTimeMillis(); System.out.println([完成] 总耗时 (t3 - t0) ms); }) .doOnError(e - { long t4 System.currentTimeMillis(); System.out.println([错误] 总耗时 (t4 - t0) ms, error e.getMessage()); }); return content; }响应时间[HTTP发起] 耗时115ms 2026-08-24T13:43:33.62008:00 INFO 17056 --- [home-ai] [nio-8010-exec-1] o.s.web.servlet.DispatcherServlet : Completed initialization in 1 ms [首token] 总耗时116696ms, token您好 2026-08-24T13:45:30.39608:00 DEBUG 17056 --- [home-ai] [onPool-worker-1] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration] [首token] 总耗时127301ms, token 2026-08-24T13:45:41.00308:00 DEBUG 17056 --- [home-ai] [ient-1-Worker-3] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration] [完成] 总耗时127644ms结果可以看到总耗时是127644ms 2.1274 分钟去掉提示词进行测试代码案例GetMapping(value /ai/stream, produces text/event-stream;charsetUTF-8) public FluxString streamChat(RequestParam String prompt) { long t0 System.currentTimeMillis(); FluxString content chatClient.prompt() .user(prompt) .stream() .content() .doOnSubscribe(s - { long t1 System.currentTimeMillis(); System.out.println([HTTP发起] 耗时 (t1 - t0) ms); }) .doOnNext(token - { long t2 System.currentTimeMillis(); System.out.println([首token] 总耗时 (t2 - t0) ms, token token); }) .doOnComplete(() - { long t3 System.currentTimeMillis(); System.out.println([完成] 总耗时 (t3 - t0) ms); }) .doOnError(e - { long t4 System.currentTimeMillis(); System.out.println([错误] 总耗时 (t4 - t0) ms, error e.getMessage()); }); return content; }响应时间[HTTP发起] 耗时134ms 2026-08-24T13:58:11.25908:00 INFO 15268 --- [home-ai] [nio-8010-exec-1] o.s.web.servlet.DispatcherServlet : Completed initialization in 8 ms [首token] 总耗时3167ms, token您好 2026-08-24T13:58:14.50108:00 DEBUG 15268 --- [home-ai] [onPool-worker-1] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration] [结尾token] 总耗时11988ms, token。 2026-08-24T13:58:23.32508:00 DEBUG 15268 --- [home-ai] [ient-1-Worker-0] o.s.a.c.metadata.ChatResponseMetadata : Ignore null value for key [total-duration] [完成] 总耗时12312ms结果可以看到总耗时是12312ms 12.312秒结论1. 硬件算力瓶颈最根本原因没有 GPU 或显存不足大模型推理需要极高的并行计算能力。如果没有独立显卡或者显存装不下模型比如 4GB 显存跑 7B 模型模型就会被迫在 CPU 上运行。CPU 处理这种矩阵乘法运算的速度比 GPU 慢几十倍。内存带宽限制纯 CPU 推理时速度取决于内存读写速度。普通电脑内存带宽远不及专业显卡的显存带宽导致模型“读数据”的时间比“算数据”的时间还长简单来说就是电脑性能不足。2. 模型规模与提示词长度输入端压力模型参数过大模型越大如 7B 对比 1.5B每次生成一个字需要计算的参数量就成倍增加。提示词Prompt过长大模型是“逐字预测”的。在输出第一个字之前它必须先“读”完所有的系统提示词、历史对话和背景资料Prefill 阶段。你 Java 代码里带的提示词越多模型“读题”的时间就越长。简单来说就是支撑大模型运行的各方面因素本来就不够如果在来几个长Prompt那更加的慢。3. 工程框架的额外开销Java API 特有对象转换与序列化Java 框架需要将请求对象转成 JSON再把 Ollama 返回的 JSON 解析成 Java 对象这个过程消耗 CPU。连接池与拦截器企业级框架底层的 HTTP 连接池调度、网络跨机传输宿主机到虚拟机、日志记录、链路追踪等都会增加毫秒级的延迟。这个本身对大模型回复的影响也比较小因为我也试着配置了连接池启动预加载效果也不是很大没有前面两个大。4. 系统资源抢占环境因素虚拟机性能损耗在虚拟机里跑大模型相当于给模型套了一层“枷锁”虚拟网卡、虚拟内存的开销会进一步拖慢速度。内存溢出与 Swap如果电脑物理内存不够系统会把部分模型数据塞到硬盘虚拟内存里硬盘的读写速度会让模型推理瞬间变成“PPT”。简单点就是由于虚拟机本省就是运行在电脑上面虚拟机里面的资源实际上也是本地电脑的资源所以本地电脑启动的软件也会抢占大模型所需要的资源这样也会导致推理变慢。建议如果电脑性能高的话 比如4070以上可以建议玩玩ollama如果配置不高的情况下调用阿里云提供的大模型也是很好的学习也便宜还有免费额度。