最近在整理一臺(tái)本地推理服務(wù)器時(shí)我發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象同一個(gè) 7B 模型單純做對(duì)話請(qǐng)求時(shí) GPU 利用率能跑到 70% 以上但一旦掛上 Agent 工作流GPU 反而經(jīng)常只有 30% 左右CPU 卻被頂?shù)搅?90% 以上。這讓我開(kāi)始重新審視一個(gè)問(wèn)題代理AI時(shí)代CPU 和 GPU 真的要做到“1:1”配比嗎這個(gè)“1:1”并不是某個(gè)官方標(biāo)準(zhǔn)而是工程師們?cè)诓渴?Agent 類應(yīng)用時(shí)逐漸形成的一種直覺(jué)。本文不打算追逐熱點(diǎn)而是想把 CPU 與 GPU 在代理AIAI Agent場(chǎng)景下的分工、算力配比邏輯、本地模型部署觀測(cè)方法以及常見(jiàn)坑點(diǎn)完整拆解一遍。文章會(huì)比較長(zhǎng)既有概念解釋也有可復(fù)制的本地實(shí)操代碼適合正在做 Agent 應(yīng)用、本地模型部署或算力規(guī)劃的同學(xué)收藏備用。1. 代理AI時(shí)代為什么 CPU 重新被討論1.1 從“大模型生成”到“智能代理工作流”過(guò)去兩年大家接觸最多的 AI 應(yīng)用形態(tài)是“對(duì)話框”用戶輸入 prompt模型生成回復(fù)。這種模式的技術(shù)鏈路很短一次請(qǐng)求就是一次推理主要算力壓力集中在 GPU 上。GPU 負(fù)責(zé)矩陣計(jì)算CPU 只需要做基礎(chǔ)的請(qǐng)求接收、結(jié)果返回負(fù)載并不高。但代理AIAI Agent完全不同。Agent 不再是“問(wèn)一句答一句”而是把一個(gè)復(fù)雜任務(wù)拆解成多個(gè)步驟自主規(guī)劃、調(diào)用工具、讀取外部數(shù)據(jù)、驗(yàn)證中間結(jié)果再?zèng)Q定下一步動(dòng)作。一個(gè)典型的 Agent 任務(wù)會(huì)經(jīng)歷多輪“模型推理 工具調(diào)用 結(jié)果解析”的循環(huán)整個(gè)鏈路里 GPU 推理只是其中一環(huán)CPU 的負(fù)擔(dān)會(huì)明顯上升。我用一張簡(jiǎn)化的流程對(duì)比來(lái)說(shuō)明傳統(tǒng)對(duì)話 用戶輸入 - GPU推理 - 返回結(jié)果 代理AI任務(wù) 用戶輸入 - 任務(wù)規(guī)劃 - 模型推理(GPU) - 調(diào)用工具(CPU/內(nèi)存) - 解析工具結(jié)果(CPU) - 再次模型推理(GPU) - 驗(yàn)證結(jié)果(CPU) - 繼續(xù)規(guī)劃(GPU) ... - 返回最終結(jié)果可以看出Agent 場(chǎng)景下 CPU 承擔(dān)的任務(wù)不再只是“接口轉(zhuǎn)發(fā)”還包括工具調(diào)度、上下文管理、結(jié)果校驗(yàn)、多線程并發(fā)等。CPU 和 GPU 在一條流水線上交替工作任何一方成為瓶頸整個(gè) Agent 的執(zhí)行效率都會(huì)下降。1.2 CPU 和 GPU 的分工邊界很多初學(xué)者容易走入一個(gè)誤區(qū)認(rèn)為 AI 計(jì)算全部由 GPU 完成CPU 不重要。實(shí)際在代理AI場(chǎng)景里分工非常清晰硬件主要承擔(dān)任務(wù)典型負(fù)載特征GPU模型推理、張量計(jì)算、embedding 生成高并行、計(jì)算密集CPU任務(wù)調(diào)度、工具調(diào)用、數(shù)據(jù)預(yù)處理、上下文拼接、多 Agent 并發(fā)管理邏輯密集、IO 密集內(nèi)存上下文窗口、工具結(jié)果緩存、Agent 狀態(tài)存儲(chǔ)容量敏感這里有一個(gè)容易被忽略的點(diǎn)GPU 推理的前后都需要 CPU 做數(shù)據(jù)準(zhǔn)備。比如把多輪對(duì)話歷史拼成 prompt、把工具返回的 JSON 轉(zhuǎn)成模型能理解的文本、對(duì)模型輸出做采樣和后處理。這些操作單個(gè)看耗時(shí)不多但在 Agent 的多輪循環(huán)中會(huì)被無(wú)限放大。所以代理AI時(shí)代的算力規(guī)劃不是“無(wú)腦堆 GPU”就完事而是要重新評(píng)估 CPU 核心數(shù)、內(nèi)存容量和 GPU 顯存之間的平衡。2. 推理任務(wù)的結(jié)構(gòu)變化為什么不是只有 GPU2.1 代理AI的典型執(zhí)行鏈路要理解 CPU 和 GPU 配比首先要拆解 Agent 的一次完整執(zhí)行鏈路。下面以一個(gè)“查詢信息并生成報(bào)告”的簡(jiǎn)單 Agent 為例接收任務(wù)用戶輸入自然語(yǔ)言請(qǐng)求。任務(wù)規(guī)劃模型推理拆解子任務(wù)GPU 計(jì)算。工具調(diào)用Agent 根據(jù)規(guī)劃結(jié)果調(diào)用搜索 API、數(shù)據(jù)庫(kù)或本地函數(shù)CPU 計(jì)算。結(jié)果處理將工具返回的數(shù)據(jù)整理、截?cái)?、格式化重新拼入上下文CPU 計(jì)算。繼續(xù)推理模型基于新上下文生成下一步?jīng)Q策或最終答案GPU 計(jì)算。循環(huán)直到結(jié)束重復(fù)步驟 3 到 5。在這個(gè)過(guò)程中GPU 的工作量并不是“一次推理”決定的而是由“推理次數(shù)”決定的。Agent 任務(wù)越長(zhǎng)推理次數(shù)越多但 CPU 側(cè)的工具調(diào)用和上下文處理次數(shù)也同樣線性增長(zhǎng)。一個(gè)更實(shí)際的經(jīng)驗(yàn)是普通對(duì)話場(chǎng)景下一個(gè) 7B 模型的單次推理可能只需要 2 到 5 秒但在 Agent 場(chǎng)景下一次完整任務(wù)可能需要 10 次以上的模型調(diào)用總體耗時(shí)會(huì)呈倍數(shù)增長(zhǎng)。此時(shí)如果 CPU 核數(shù)不足工具調(diào)用和 prompt 拼接會(huì)成為隱性瓶頸。2.2 關(guān)鍵瓶頸調(diào)度、工具調(diào)用與上下文管理很多人只盯著 GPU 利用率忽略了 Agent 框架本身的調(diào)度開(kāi)銷(xiāo)。無(wú)論是 LangChain、LlamaIndex 還是自己寫(xiě)的 Agent 循環(huán)都會(huì)大量使用 Python 或 Node.js 運(yùn)行時(shí)。這些運(yùn)行時(shí)本身吃 CPU尤其在以下場(chǎng)景多 Agent 并發(fā)每個(gè) Agent 實(shí)例都是一個(gè)獨(dú)立任務(wù)需要 CPU 調(diào)度。工具解析JSON 解析、正則匹配、代碼執(zhí)行等操作。向量檢索如果 Agent 接入了 RAG向量數(shù)據(jù)庫(kù)的檢索和重排序會(huì)占用大量 CPU。上下文壓縮長(zhǎng)會(huì)話場(chǎng)景下需要對(duì)歷史消息做摘要或截?cái)噙@部分也是 CPU 密集操作。這些瓶頸有一個(gè)共同特點(diǎn)無(wú)法被 GPU 加速只能靠 CPU 核心數(shù)和主頻硬扛。所以在代理AI場(chǎng)景里CPU 和 GPU 是“接力跑”的關(guān)系而不是“單向依賴”的關(guān)系。3. 算力配比CPU 與 GPU“1:1”的說(shuō)法從哪來(lái)3.1 “1:1”是一個(gè)工程經(jīng)驗(yàn)值不是硬性標(biāo)準(zhǔn)網(wǎng)上關(guān)于“CPU 和 GPU 1:1 配比”的說(shuō)法大多數(shù)來(lái)自本地模型部署場(chǎng)景。所謂“1:1”通常指的是 CPU 核心數(shù)與 GPU 顯存容量或 GPU 卡數(shù)之間存在某種經(jīng)驗(yàn)配比。嚴(yán)格來(lái)說(shuō)這個(gè)說(shuō)法并不統(tǒng)一有人按“每張 GPU 配 N 個(gè) CPU 核”計(jì)算有人按“CPU 總核心數(shù)約等于 GPU 顯存 GB 數(shù)”估算。以本地跑 7B 到 14B 模型為例比較常見(jiàn)的經(jīng)驗(yàn)是單張 12GB 顯存的 GPU建議搭配 8 核以上的 CPU。單張 24GB 顯存的 GPU建議搭配 16 核以上的 CPU。多張 GPU 并行推理時(shí)CPU 核心數(shù)需要根據(jù)并發(fā)任務(wù)數(shù)同步增加。這些經(jīng)驗(yàn)值的核心邏輯是GPU 負(fù)責(zé)把推理延遲壓下來(lái)CPU 負(fù)責(zé)把“喂給 GPU 的數(shù)據(jù)”和“GPU 吐出的結(jié)果”處理好。如果 CPU 太弱GPU 會(huì)頻繁進(jìn)入等待狀態(tài)利用率自然就上不去。3.2 配比失衡的表現(xiàn)判斷 CPU 和 GPU 配比是否合理最直接的方法是看運(yùn)行指標(biāo)失衡方向表現(xiàn)結(jié)果CPU 過(guò)少Agent 任務(wù)排隊(duì)、工具調(diào)用慢、GPU 利用率波動(dòng)大單個(gè)任務(wù)耗時(shí)長(zhǎng)并發(fā)能力差CPU 過(guò)多GPU 一直被占滿CPU 利用率低算力資源浪費(fèi)成本偏高內(nèi)存不足上下文較長(zhǎng)時(shí)報(bào) OOMAgent 狀態(tài)丟失任務(wù)中斷穩(wěn)定性差顯存不足模型無(wú)法加載或加載后上下文窗口被壓縮輸出質(zhì)量下降這里需要特別說(shuō)明的是“1:1”只是一個(gè)方便討論的切入點(diǎn)真正的配比應(yīng)該根據(jù)具體的模型大小、Agent 任務(wù)類型、并發(fā)數(shù)、上下文長(zhǎng)度來(lái)做容量規(guī)劃。不同業(yè)務(wù)之間的差異可能非常大不能盲目照搬別人的配置。4. 本地模型環(huán)境搭建與算力觀測(cè)實(shí)操4.1 環(huán)境準(zhǔn)備這一節(jié)我們用真實(shí)可運(yùn)行的示例演示如何在本地環(huán)境部署一個(gè)支持 Agent 調(diào)用的模型服務(wù)并觀測(cè) CPU 與 GPU 的占用情況。本文示例環(huán)境操作系統(tǒng)Windows 11 / Ubuntu 22.04 均可GPUNVIDIA 顯卡建議顯存 8GB 以上驅(qū)動(dòng)NVIDIA 驅(qū)動(dòng)需支持 CUDAPython3.9 或更高版本模型管理工具OllamaPython 依賴requests、psutil、pynvml版本需要根據(jù)你的項(xiàng)目實(shí)際情況調(diào)整本文示例以常見(jiàn)環(huán)境為例重點(diǎn)演示配置思路。如果你使用的是 AMD GPU、Intel GPU 或純 CPU 環(huán)境命令和指標(biāo)會(huì)有所差異但觀測(cè)思路是通用的。4.2 使用 Ollama 部署本地模型Ollama 是目前比較流行的本地模型管理工具一條命令就能拉起一個(gè)大模型服務(wù)對(duì)新手非常友好。安裝完成之后先拉取一個(gè)適合 Agent 調(diào)用的小參數(shù)模型。# 拉取 qwen2.5 7B 模型 ollama pull qwen2.5:7b # 查看本地已有模型 ollama list # 啟動(dòng)模型服務(wù)默認(rèn)監(jiān)聽(tīng) 11434 端口 ollama serve模型拉取完成后可以通過(guò)命令行直接測(cè)試推理ollama run qwen2.5:7b 請(qǐng)用一句話介紹你自己正常情況會(huì)輸出一段模型生成的文本。如果這一步能跑通說(shuō)明模型服務(wù)已經(jīng)可用。接下來(lái)驗(yàn)證 Ollama 是否真正使用了 GPU。在模型加載后另開(kāi)一個(gè)終端執(zhí)行nvidia-smi在輸出列表中找到ollama進(jìn)程對(duì)應(yīng)的顯存占用。如果顯存占用為 0說(shuō)明模型正在 CPU 上運(yùn)行后面常見(jiàn)問(wèn)題部分會(huì)給出解決辦法。4.3 Python 調(diào)用本地模型為了讓 Ollama 能接入 Agent 流程我們通過(guò) HTTP API 調(diào)用模型。以下是一個(gè)最小可運(yùn)行的 Python 示例# 文件路徑ollama_chat_test.py import requests OLLAMA_URL http://localhost:11434/api/chat payload { model: qwen2.5:7b, messages: [ {role: user, content: 用一句話解釋什么是 AI Agent} ], stream: False } response requests.post(OLLAMA_URL, jsonpayload) data response.json() print(模型回復(fù), data[message][content])運(yùn)行腳本python ollama_chat_test.py這段代碼的邏輯很簡(jiǎn)單向本地模型服務(wù)發(fā)送一個(gè)聊天請(qǐng)求打印模型回復(fù)。它是后續(xù) Agent 循環(huán)里最核心的“推理調(diào)用”單元。4.4 編寫(xiě)一個(gè)模擬 Agent 循環(huán)下面我們寫(xiě)一個(gè)極簡(jiǎn)的 Agent 循環(huán)模擬“規(guī)劃 - 調(diào)用工具 - 再推理”的過(guò)程。這個(gè)例子不依賴任何 Agent 框架邏輯足夠清晰方便你看到 CPU 和 GPU 分別在哪里工作。# 文件路徑mini_agent_demo.py import json import time import requests OLLAMA_URL http://localhost:11434/api/chat MODEL_NAME qwen2.5:7b def call_llm(messages: list) - str: 調(diào)用本地模型返回文本內(nèi)容 payload { model: MODEL_NAME, messages: messages, stream: False } resp requests.post(OLLAMA_URL, jsonpayload) resp.raise_for_status() return resp.json()[message][content] def get_current_time() - str: 模擬一個(gè)工具返回當(dāng)前時(shí)間 return time.strftime(%Y-%m-%d %H:%M:%S) def run_agent_task(task: str) - str: 極簡(jiǎn) Agent 循環(huán) messages [ {role: system, content: 你是一個(gè)智能助手可以調(diào)用工具獲取當(dāng)前時(shí)間。}, {role: user, content: task} ] # 第一輪模型判斷是否需要調(diào)用工具 print( 第一輪推理GPU) first_reply call_llm(messages) print(模型輸出, first_reply) # 模擬工具調(diào)用CPU 密集區(qū)域 print( 工具調(diào)用CPU) tool_result get_current_time() print(工具結(jié)果, tool_result) # 第二輪把工具結(jié)果交給模型生成最終回復(fù) print( 第二輪推理GPU) messages.append({role: assistant, content: first_reply}) messages.append({role: tool, content: tool_result}) final_reply call_llm(messages) return final_reply if __name__ __main__: result run_agent_task(現(xiàn)在幾點(diǎn)了請(qǐng)結(jié)合工具結(jié)果回答。) print(最終回答, result)運(yùn)行這個(gè)腳本你會(huì)看到輸出分為幾個(gè)階段第一輪推理、工具調(diào)用、第二輪推理。通過(guò)觀察 CPU 和 GPU 指標(biāo)的變化就能直觀感受到 Agent 任務(wù)的算力消耗模式。4.5 實(shí)時(shí)觀測(cè) CPU 與 GPU 占用為了不在任務(wù)執(zhí)行過(guò)程中“兩眼一抹黑”我們可以寫(xiě)一個(gè)監(jiān)控腳本同時(shí)輸出 CPU 利用率和 GPU 利用率。首先安裝依賴pip install psutil pynvml requests# 文件路徑monitor_cpu_gpu.py import time import psutil from pynvml import nvmlInit, nvmlDeviceGetHandleByIndex, nvmlDeviceGetUtilizationRates, nvmlDeviceGetMemoryInfo # 初始化 NVML nvmlInit() handle nvmlDeviceGetHandleByIndex(0) def get_gpu_info(): util nvmlDeviceGetUtilizationRates(handle) mem nvmlDeviceGetMemoryInfo(handle) return util.gpu, mem.used / 1024 / 1024, mem.total / 1024 / 1024 if __name__ __main__: print(CPU%, GPU%, 顯存使用(GB), 顯存總量(GB)) try: while True: cpu_percent psutil.cpu_percent(interval1) gpu_percent, mem_used, mem_total get_gpu_info() print(f{cpu_percent:5.1f} {gpu_percent:5.1f} {mem_used:8.2f} {mem_total:8.2f}) except KeyboardInterrupt: print(\n監(jiān)控結(jié)束)監(jiān)控腳本會(huì)每秒刷新一次數(shù)據(jù)。你可以先啟動(dòng)mini_agent_demo.py再啟動(dòng)監(jiān)控腳本觀察 CPU 和 GPU 的利用率變化曲線。一般情況下模型推理階段 GPU 利用率升高工具調(diào)用和解析階段 CPU 利用率升高。4.6 觀察結(jié)論如何判斷配比是否合理通過(guò)上述監(jiān)控我們可以得到一個(gè)基本判斷如果 GPU 利用率長(zhǎng)期低于 50%且 CPU 利用率接近 100%說(shuō)明 CPU 是瓶頸需要增加 CPU 核數(shù)或優(yōu)化工具調(diào)用邏輯。如果 GPU 利用率長(zhǎng)期高于 90%CPU 利用率只有 20% 左右說(shuō)明當(dāng)前任務(wù)對(duì) GPU 依賴更強(qiáng)CPU 存在富余。如果顯存占用接近上限同時(shí)上下文長(zhǎng)度被迫縮短說(shuō)明顯存是瓶頸需要換更大顯存的顯卡或使用量化模型。從工程角度看代理AI場(chǎng)景比較理想的 CPU 和 GPU 配比是讓兩者在任務(wù)執(zhí)行過(guò)程中交替達(dá)到較高利用率而不是某一方長(zhǎng)時(shí)間處于等待狀態(tài)。5. 代理AI部署中的常見(jiàn)問(wèn)題與排查思路5.1 模型跑在 CPU 上GPU 利用率始終為 0問(wèn)題現(xiàn)象常見(jiàn)原因解決思路nvidia-smi看不到 ollama 進(jìn)程驅(qū)動(dòng)或 CUDA 版本不匹配更新 NVIDIA 驅(qū)動(dòng)確保 CUDA 可用GPU 利用率很低但 CPU 很高模型未被 GPU 加載檢查ollama ps確認(rèn)模型加載設(shè)備排查步驟如下執(zhí)行ollama ps查看模型是否已加載。輸出中會(huì)顯示PROCESSOR列如果是100% CPU說(shuō)明模型沒(méi)有走 GPU。執(zhí)行ollama rm qwen2.5:7b后重新ollama pull qwen2.5:7b有時(shí)候舊模型文件會(huì)導(dǎo)致加載異常。檢查環(huán)境變量。在 Linux 下可以執(zhí)行ollama serve --debug查看詳細(xì)日志確認(rèn)是否識(shí)別到 GPU。5.2 WSL 環(huán)境下 GPU 訪問(wèn)失敗在 WSL 中運(yùn)行 Ollama 時(shí)可能會(huì)遇到類似報(bào)錯(cuò)failed to initialize nvml: gpu access blocked by the operating system這個(gè)報(bào)錯(cuò)的意思是 NVML 初始化失敗GPU 訪問(wèn)被系統(tǒng)阻止。常見(jiàn)原因有兩個(gè)Windows 側(cè)沒(méi)有安裝正確的 NVIDIA 驅(qū)動(dòng)。當(dāng)前 WSL 版本不支持 GPU 透?jìng)?。解決思路更新 Windows 側(cè) NVIDIA 驅(qū)動(dòng)建議使用 Game Ready 或 Studio 驅(qū)動(dòng)的最新版本。確認(rèn) WSL 版本為 WSL 2WSL 1 不支持 GPU 透?jìng)?。?WSL 內(nèi)執(zhí)行nvidia-smi如果能正常顯示顯卡信息說(shuō)明 GPU 透?jìng)饕焉А?.3 Agent 高并發(fā)時(shí) CPU 被打滿當(dāng)多個(gè) Agent 任務(wù)同時(shí)執(zhí)行時(shí)CPU 很容易成為瓶頸。常見(jiàn)原因包括每個(gè) Agent 實(shí)例都獨(dú)立占用 CPU 做工具調(diào)用。Python 的全局解釋器鎖GIL限制了多線程任務(wù)的并行能力。上下文拼接和向量檢索消耗大量 CPU。解決思路1. 使用多進(jìn)程而非多線程處理 Agent 任務(wù)。 2. 對(duì)工具調(diào)用增加緩存避免重復(fù)請(qǐng)求。 3. 如果任務(wù)并發(fā)量很高將工具調(diào)用拆分為獨(dú)立服務(wù)與模型推理服務(wù)分離部署。 4. 必要時(shí)增加 CPU 核心數(shù)或在代碼層面降低不必要的日志輸出和格式化操作。5.4 顯存不足導(dǎo)致模型無(wú)法加載在 Agent 場(chǎng)景中上下文會(huì)越積越長(zhǎng)顯存占用也會(huì)持續(xù)上升。如果任務(wù)中同時(shí)跑多個(gè) Agent很容易出現(xiàn) OOM。解決思路使用更高量化的模型例如 Q4_K_M、Q8_0。限制單 Agent 的上下文長(zhǎng)度或定期對(duì)歷史消息做摘要壓縮?？刂仆粫r(shí)刻的 Agent 并發(fā)數(shù)。使用OLLAMA_MAX_LOADED_MODELS環(huán)境變量限制同時(shí)加載的模型數(shù)量。# 限制同時(shí)最多加載 1 個(gè)模型 export OLLAMA_MAX_LOADED_MODELS16. 實(shí)踐建議如何規(guī)劃 CPU 與 GPU 配比6.1 按任務(wù)類型區(qū)分配比策略代理AI場(chǎng)景的負(fù)載差異非常大我把常見(jiàn)的任務(wù)類型分成三類來(lái)規(guī)劃任務(wù)類型典型特征配比建議純對(duì)話/單輪問(wèn)答GPU 推理為主優(yōu)先保證 GPU 顯存和算力CPU 可以適當(dāng)弱一些工具調(diào)用密集型 Agent高頻調(diào)用搜索、數(shù)據(jù)庫(kù)、代碼執(zhí)行CPU 核心數(shù)要充足建議 16 核以上長(zhǎng)上下文分析型 Agent大量文本讀取、總結(jié)、多輪推理內(nèi)存和顯存都要大CPU 負(fù)責(zé)上下文壓縮6.2 容量規(guī)劃的三個(gè)步驟第一步先跑通單 Agent 任務(wù)。用監(jiān)控腳本記錄單個(gè)任務(wù)的 CPU 峰值、GPU 峰值和顯存峰值這是最基礎(chǔ)的容量數(shù)據(jù)。第二步根據(jù)并發(fā)目標(biāo)估算總資源。如果單個(gè)任務(wù)需要 4 核 CPU 和 6GB 顯存計(jì)劃同時(shí)跑 10 個(gè)任務(wù)理論上就需要 40 核 CPU 和 60GB 顯存。實(shí)際還要考慮上下文增長(zhǎng)和模型負(fù)載建議預(yù)留 30% 的余量。第三步用壓測(cè)驗(yàn)證。不要只在單次任務(wù)上做判斷盡量模擬真實(shí)業(yè)務(wù)的多輪循環(huán)和并發(fā)請(qǐng)求觀察 CPU 與 GPU 的利用率是否均衡。6.3 監(jiān)控與調(diào)優(yōu)建議建立基礎(chǔ)監(jiān)控CPU 利用率、內(nèi)存占用、GPU 利用率、顯存占用、模型推理延遲。關(guān)注“等待時(shí)間”如果 Agent 任務(wù)大量時(shí)間花在等待 GPU 響應(yīng)上而 CPU 空閑說(shuō)明模型太大或 GPU 太弱如果等待時(shí)間花在工具調(diào)用上而 GPU 空閑說(shuō)明 CPU 或 IO 是瓶頸。模型量化不是降級(jí)很多場(chǎng)景下 4bit 量化的 14B 模型在 Agent 任務(wù)中的整體表現(xiàn)可能優(yōu)于 8bit 的 7B 模型因?yàn)橥评泶螖?shù)減少、上下文保留能力更強(qiáng)。注意生產(chǎn)環(huán)境變更規(guī)范調(diào)整模型、驅(qū)動(dòng)、依賴版本前先在測(cè)試環(huán)境驗(yàn)證避免直接在生產(chǎn)環(huán)境操作。7. 總結(jié)與下一步學(xué)習(xí)方向代理AI時(shí)代的算力配比確實(shí)和傳統(tǒng)“對(duì)話式 AI”有明顯區(qū)別。CPU 和 GPU 不再是“誰(shuí)強(qiáng)誰(shuí)說(shuō)了算”而是像流水線上的兩道工序需要協(xié)同工作。所謂的“1:1”本質(zhì)上是對(duì)這種協(xié)同關(guān)系的一種經(jīng)驗(yàn)描述真正的配比取決于你的任務(wù)類型、模型大小、并發(fā)規(guī)模和上下文長(zhǎng)度。如果你想繼續(xù)深入這個(gè)方向可以從三個(gè)維度往下走一是學(xué)習(xí)推理引擎的參數(shù)調(diào)優(yōu)比如 Ollama 的OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS、上下文長(zhǎng)度設(shè)置等理解這些參數(shù)如何影響 CPU 和 GPU 的負(fù)載分布。二是研究 Agent 框架的設(shè)計(jì)模式特別是如何把工具調(diào)用、向量檢索從模型推理鏈路中解耦出來(lái)降低 CPU 側(cè)的壓力。三是建立一套屬于自己的性能基準(zhǔn)測(cè)試方法。我現(xiàn)在的習(xí)慣是每上線一個(gè) Agent 應(yīng)用先跑一遍單任務(wù)監(jiān)控記錄峰值指標(biāo)再逐步增加并發(fā)直到某一項(xiàng)資源接近 80% 就停止加壓。這套方法雖然樸素但比任何理論配比都更可靠。