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如果配置不高的情況下調用阿里云提供的大模型也是很好的學習也便宜還有免費額度。