1.本人在使用本地部署的ollama進(jìn)行模型調(diào)用的時候響應(yīng)很慢一直以為是哪里配置問題一直在改代碼改Linux上面的配置查資料看官方文檔研究了兩天以下就是我總結(jié)的問題[請求進(jìn)入開始計時] 耗時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回復(fù)的token用時30秒 -- 最后一個token用時9秒 --最后結(jié)束幾毫秒的時間從日志可以看出后面幾個時間都沒有什么問題主要問題出現(xiàn)在請求到 --首個token處為什么會有一個30秒的時間這過程中他是在干什么當(dāng)時我也很好奇我使用curl 命令在linux和本地cmd里面測試都是正常的這就很奇怪我也是看了官方文檔后面又去網(wǎng)上查詢資料終于找到原因了問題出現(xiàn)原因1. 一般在練習(xí)ollama本地部署的時候都是使用的虛擬機(jī)但是虛擬機(jī)吃的是電腦本身的性能如果電腦本身配置不是很高那就會導(dǎo)致回復(fù)的很慢。2.為什么在虛擬機(jī)Linux、本地CMD、Postman等工具里面請求會比Api更快原因是APi調(diào)用底層有邏輯推理比如你Java自帶的一些提示詞之類的東西導(dǎo)致模型在慢的基礎(chǔ)上繼續(xù)推理就會顯得更加的慢而虛擬機(jī)Linux、本地CMD、Postman等是不帶有提示詞的所以就比API調(diào)用的更快。演示環(huán)節(jié)問候語句你好你叫什么代碼案例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 【服務(wù)器真實(shí)時間上下文】 當(dāng)前真實(shí)時間當(dāng)前時間%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發(fā)起] 耗時 (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; }響應(yīng)時間[HTTP發(fā)起] 耗時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結(jié)果可以看到總耗時是127644ms 2.1274 分鐘去掉提示詞進(jìn)行測試代碼案例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發(fā)起] 耗時 (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; }響應(yīng)時間[HTTP發(fā)起] 耗時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] [結(jié)尾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結(jié)果可以看到總耗時是12312ms 12.312秒結(jié)論1. 硬件算力瓶頸最根本原因沒有 GPU 或顯存不足大模型推理需要極高的并行計算能力。如果沒有獨(dú)立顯卡或者顯存裝不下模型比如 4GB 顯存跑 7B 模型模型就會被迫在 CPU 上運(yùn)行。CPU 處理這種矩陣乘法運(yùn)算的速度比 GPU 慢幾十倍。內(nèi)存帶寬限制純 CPU 推理時速度取決于內(nèi)存讀寫速度。普通電腦內(nèi)存帶寬遠(yuǎn)不及專業(yè)顯卡的顯存帶寬導(dǎo)致模型“讀數(shù)據(jù)”的時間比“算數(shù)據(jù)”的時間還長簡單來說就是電腦性能不足。2. 模型規(guī)模與提示詞長度輸入端壓力模型參數(shù)過大模型越大如 7B 對比 1.5B每次生成一個字需要計算的參數(shù)量就成倍增加。提示詞Prompt過長大模型是“逐字預(yù)測”的。在輸出第一個字之前它必須先“讀”完所有的系統(tǒng)提示詞、歷史對話和背景資料Prefill 階段。你 Java 代碼里帶的提示詞越多模型“讀題”的時間就越長。簡單來說就是支撐大模型運(yùn)行的各方面因素本來就不夠如果在來幾個長Prompt那更加的慢。3. 工程框架的額外開銷Java API 特有對象轉(zhuǎn)換與序列化Java 框架需要將請求對象轉(zhuǎn)成 JSON再把 Ollama 返回的 JSON 解析成 Java 對象這個過程消耗 CPU。連接池與攔截器企業(yè)級框架底層的 HTTP 連接池調(diào)度、網(wǎng)絡(luò)跨機(jī)傳輸宿主機(jī)到虛擬機(jī)、日志記錄、鏈路追蹤等都會增加毫秒級的延遲。這個本身對大模型回復(fù)的影響也比較小因?yàn)槲乙苍囍渲昧诉B接池啟動預(yù)加載效果也不是很大沒有前面兩個大。4. 系統(tǒng)資源搶占環(huán)境因素虛擬機(jī)性能損耗在虛擬機(jī)里跑大模型相當(dāng)于給模型套了一層“枷鎖”虛擬網(wǎng)卡、虛擬內(nèi)存的開銷會進(jìn)一步拖慢速度。內(nèi)存溢出與 Swap如果電腦物理內(nèi)存不夠系統(tǒng)會把部分模型數(shù)據(jù)塞到硬盤虛擬內(nèi)存里硬盤的讀寫速度會讓模型推理瞬間變成“PPT”。簡單點(diǎn)就是由于虛擬機(jī)本省就是運(yùn)行在電腦上面虛擬機(jī)里面的資源實(shí)際上也是本地電腦的資源所以本地電腦啟動的軟件也會搶占大模型所需要的資源這樣也會導(dǎo)致推理變慢。建議如果電腦性能高的話 比如4070以上可以建議玩玩ollama如果配置不高的情況下調(diào)用阿里云提供的大模型也是很好的學(xué)習(xí)也便宜還有免費(fèi)額度。