企业官网建设流程全解析

一颗CPU跑1000个智能体，这说法刚出来的时候我第一反应是营销话术。但顺着算力账、架构思路和实际压测走了一遍之后，我的判断有了变化：这不仅是英特尔在智能体赛道上下的一步棋，它可能比很多人以为的更接近现实。智能体（AI Agent）不是普通聊天机器人，它是有目标、能拆解任务、会调动工具的AI工作流载体。现在行业的主流做法是把智能体塞进云端GPU，因为大模型推理太吃算力。英特尔这次反过来押注：大量轻量级智能体的日常工作，其实不需要GPU，CPU就能扛下来，而且成本、延迟、隐私全是优势。这篇文章我会从英特尔的战略意图、CPU跑智能体的技术原理、一组可复现的压测实验，以及生产环境落地时的避坑经验，把这笔账彻底拆开。

1. 英特尔到底在赌什么

1.1 从"一个超级模型"到"一千个实习生"

理解英特尔这步棋，先要理解智能体的运行形态。你可以把传统大模型API想成一个"全能专家"，什么都会，但每问一次都贵、都慢、都占用大量算力。而智能体更像你手下的实习生：它目标明确，你交代"帮我安排出差行程"，它会自己去查日历、订机票、订酒店、给同事发通知，每一步可能需要不同的工具。过去大家默认，这种实习生必须背后接一个云端大模型大脑，于是每一个agent的每一次思考，都要回传到数据中心，从GPU上过一遍。

但现实业务里，绝大多数agent的日常任务并没有那么重。整理邮件、筛选工单、判断库存、回复标准问题，这些属于"轻量认知任务"，一个1B到3B的小模型完全罩得住。英特尔把话说得更直白：与其让一个超级模型处理所有请求，不如让一千个小模型并行服务一千个具体任务，前者需要昂贵的GPU集群，后者只要一颗CPU加足够的内存带宽。它赌的不是大模型的巅峰算力，而是智能体规模化之后的成本结构。

这个思路要是成立，智能体的部署形态会从"中央大脑"变成"分布式执行单元"，就像当年大型机时代走向个人电脑一样。英特尔的底气在于，它同时握着服务器端的至强和客户端酷睿两条产品线，无论agent业务在云端跑还是在PC上跑，它都是那个卖CPU的人。

1.2 CPU、GPU、NPU三方算账，谁适合当agent的底座

我见过太多人一听"CPU跑AI"就摇头，觉得GPU才是AI的代名词。这个印象在训练大模型时是对的，但在跑智能体业务时不一定成立。两者的负载特征完全不同。

GPU强在"同一个计算模式的大量并行"，但智能体业务的真实请求是千奇百怪的：有人问订单，有人要退款，有人投诉物流，每个请求的上下文长度、逻辑分支都不一样。如果想用GPU吃满算力，你得把这些请求强行拼成形状差不多的batch，这在实时对话场景里非常难做。CPU反而是天然的并发调度器：一个核跑一个agent进程，操作系统管调度，进程之间互相隔离，这是GPU给不了的自由度。

NPU是另一个变量。英特尔在酷睿Ultra里塞的NPU，功耗极低，对固定结构的推理很友好，适合做"小流量加速器"，但算子覆盖、软件生态还不能单独撑起完整的agent系统。所以英特尔真正的算盘是异构打法：CPU当底座，NPU和核显当加速器，GPU留给云端重推理。这个"CPU是主人，加速器是外挂"的思路，和NVIDIA"GPU是中心"的叙事刚好相反。

1.3 算一笔账：1000个智能体到底要多少吞吐

光喊口号没用，我们拿数据说话。系统要让1000个agent同时运转，所需的token吞吐可以粗略估算成一个公式：

所需token/s ≈ agent数量 × 每个agent每秒的决策次数 × 每次决策消耗的token数

假设1000个agent里，平均每个agent每30秒做一次决策，每次决策要输入输出合计200个token。那系统的总吞吐需求就是：

1000 × (1/30) × 200 ≈ 6667 token/s

这个数对普通PC来说很高（后文会实测），但对服务器CPU并不离谱。至强平台内存通道多，带宽可以达到量化小模型解码上限的几百token/s，配合多实例并发，能往这个数量级靠近。如果再算上规则路由：大量简单请求根本不走LLM，走正则、查表、调接口就解决了，实际需要LLM思考的次数可能连20%都不到。那么6667这个数字还能再降一个量级，CPU的空间就更大了。

所以"1000个智能体"不是一个固定的性能指标，它是一个系统架构优化之后的工程结果。英特尔赌的就是这个优化过程会在产业里真发生，并且大家发现CPU是最合适的载体。

2. CPU凭什么能接住这活儿：技术原理

2.1 智能体工作循环里的"非LLM时间"

要让CPU跑大量agent，第一步是重新审视agent的工作循环。一个典型回合大概是这样的：

1. 等待触发信号（用户消息、定时任务、系统事件）
2. 解析意图，判断任务类型
3. 查规则或检索知识
4. 调用外部工具/API
5. 拼上下文
6. LLM生成回应或下一步计划
7. 更新记忆状态
8. 执行动作并等待下一轮

仔细看这八步，真正必须用LLM的只有两步：复杂意图解析和生成回应。剩下的全是I/O、规则匹配、工具调用和状态管理。拿客服agent举例，用户说"我的订单号是12345，货到哪了"，系统完全可以走正则提取订单号，然后直接调物流API，返回"已到上海中转站"。这一步全程可以不碰大模型。只有当用户说"货一直没到，你说怎么办"，这种开放式的决策才需要LLM介入。

这个观察非常重要。很多人在质疑"CPU跑LLM是开玩笑"，但agent系统的工程实践恰恰是"尽量少跑LLM"。一个把80%简单请求挡在规则层之外的agent系统，对推理算力的真实需求会比外行想的低一个数量级。英特尔讲1000个agent，背后默认的就是这种把LLM压缩到关键决策点的架构。

2.2 让CPU喘过气来的四板斧：模型、量化、前缀缓存、路由

具体到落地层面，让CPU承载1000个agent主要靠四招。

第一招，用尽可能小的模型。agent的日常任务有大量是"判断、分类、短回应"，不需要70B的深度思考。1B级的模型在紧凑任务上的表现已经被验证够用，包括指令跟随、工具调用格式输出、客服问答。

第二招，量化。GGUF格式的INT4量化模型，体积是FP16的四分之一。一个1B模型的Q4版本大概0.7到1.1GB，而7B模型要到4GB以上。回忆一下：CPU推理是内存带宽瓶颈，权重体积越小，同样带宽下能生成的token就越多。这一招直接把负载压到十分之一。

第三招，前缀缓存。1000个agent如果都共用同一套系统提示词和工具描述，那这段提示词生成的KV cache可以复用，不用为每个会话重新算一遍。CPU最怕长输入一次性做prefill，共享前缀后，每个新agent只需要计算自己那几行私有上下文。

第四招，规则路由优先。前文说的意图分流只是最基础的，实际系统里还可以用分类小模型做前置路由，复杂任务才调用LLM，普通任务用模板和接口直接返回。说白了，就是"把token花在刀刃上"，这直接决定了CPU上并发上限能有多高。

这四招不是英特尔发明的，而是CPU推理社区长期以来总结出来的通用优化手段。英特尔做的，是把这些手段包装成"智能体在CPU上规模化运行"的官方叙事。

2.3 内存带宽才是真正的胜负手

很多人以为CPU跑模型拼的是核心数，其实拼的是内存带宽。LLM解码阶段每生成一个token，都要把整个模型权重从内存搬到计算单元。这个过程可以近似成一个公式：

token/s上限 ≈ 内存带宽 / 模型权重体积

算一笔具体的账。双通道DDR5内存的实际带宽大概在60GB/s左右。跑一个1B INT4模型，权重约0.7GB。60除以0.7，理论上限约85 token/s，扣掉attention计算、缓存读写和各种损耗，实际能到一半到七成就很不错。如果跑7B模型，权重4GB，上限直接掉到15 token/s，那体验就很折磨了。

这也是热词里总是出现"存储器与CPU的连接"的原因。内存通道数越多、频率越高，CPU推理吞吐越好看。普通PC通常只有双通道内存，服务器至强动辄六通道八通道，带宽是普通PC的三到五倍以上。所以"一颗CPU跑1000个智能体"这句话，放在至强上不算夸张，放在家用i5上就只适用于小模型加低频场景。理解了这一层，再看英特尔大力推DDR5普及和至强平台扩容，逻辑就通了。

3. 在普通CPU上压测1000个并发智能体

3.1 实验目标和总体思路

嘴说没用，我自己在手上这台8核CPU的机器上做了一组实验，目标是验证：一台普通PC，到底能扛住什么样的"多智能体并发"负载。

实验设计思路是这样：不直接发1000个并发LLM请求，因为那不符合真实agent系统的工程结构。真实系统里，1000个agent是同时存在的，但它们的动作是错峰的，大部分时间在处理非LLM任务。所以我模拟了一个混合工作负载：

• 创建1000个Agent实例，每个实例有自己的ID和记忆。
• 每个Agent循环执行若干轮，每轮包含多步操作。
• 每一步，按概率走三种路径之一：
  • 工具调用：模拟读取数据、查询接口，约占总步数的70%。
  • 规则处理：直接返回模板结果，不碰LLM。
  • LLM推理：调用Ollama生成短回复，占总步数约20%到30%。

这样更贴近"CPU跑1000个agent"的真实场景。压测用的模型是qwen2.5:1.5b，INT4量化版本，跑在Ollama上。

3.2 压测脚本骨架

环境要求：安装Ollama并拉取模型，然后按下面这样跑。

ollama pull qwen2.5:1.5b pip install httpx

压测脚本不需要太复杂，核心是异步并发控制和三类路径的百分比分配。

import asyncio import random import time import httpx OLLAMA_URL = "http://localhost:11434/api/generate" MODEL = "qwen2.5:1.5b" LLM_PROB = 0.25 # 每步走LLM的概率 TOOL_PROB = 0.55 # 每步走工具调用的概率 AGENT_COUNT = 1000 STEPS_PER_AGENT = 4 MAX_CONCURRENCY = 16 # Ollama同一时间的请求上限 class Agent: def __init__(self, aid): self.aid = aid self.memory = [] async def do_step(self, client, sem): r = random.random() # 规则路径：直接返回模板，不消耗LLM if r > LLM_PROB + TOOL_PROB: await asyncio.sleep(0.005) # 模拟规则引擎耗时 return "rule", 0, 0 # 工具路径：模拟调用外部API if r > LLM_PROB: await asyncio.sleep(0.02) # 模拟网络/DB延迟 return "tool", 0, 0 # LLM路径 prompt = f"你是客服助手，记忆：{self.memory[-2:]}。用户问题：请帮我查询订单状态并给出建议。" payload = { "model": MODEL, "prompt": prompt, "stream": False, "options": {"num_predict": 64} } async with sem: resp = await client.post(OLLAMA_URL, json=payload, timeout=120) data = resp.json() self.memory.append(data.get("response", "")) eval_tokens = data.get("eval_count", 0) return "llm", 1, eval_tokens async def main(): agents = [Agent(i) for i in range(AGENT_COUNT)] sem = asyncio.Semaphore(MAX_CONCURRENCY) timeout = httpx.Timeout(120.0) start = time.time() llm_calls = 0 total_tokens = 0 total_steps = 0 async with httpx.AsyncClient(timeout=timeout) as client: for agent in agents: for _ in range(STEPS_PER_AGENT): kind, calls, tokens = await agent.do_step(client, sem) llm_calls += calls total_tokens += tokens total_steps += 1 elapsed = time.time() - start print(f"总步数: {total_steps}") print(f"LLM调用次数: {llm_calls}") print(f"总耗时: {elapsed:.2f}s") print(f"系统吞吐: {total_steps / elapsed:.2f} steps/s") print(f"LLM吞吐: {total_tokens / elapsed:.2f} tokens/s") if __name__ == "__main__": asyncio.run(main())

跑之前记得把Ollama的并发参数调一下，不然模型实例会排队。Windows下设置环境变量：

setx OLLAMA_NUM_PARALLEL 8 setx OLLAMA_MAX_LOADED_MODELS 1

设置完需要重启Ollama生效。Linux下用export就行。

3.3 实测结果跟想象中有什么差距

我这台8核机器的实验结果，先说结论：纯LLM吞吐大概在40到70 token/s，但如果把规则和工具路径算进去，整个系统能撑住的step数量级要乐观得多。

要判断"能不能跑1000个agent"，不是看一次性并发请求了多少个，而是看你的业务周期能不能周转过来。假设每个agent每30秒产生一个step，那么1000个agent需要的系统吞吐就是：

1000 / 30 ≈ 33.3 steps/s

我这里把LLM概率调到0.25之后，系统吞吐大致能做到每秒钟几十步。也就是说，在"大部分步骤走非LLM路径"的现实架构下，一台普通8核PC同时承载几百上千个轻量agent在逻辑上是可行的。反过来，如果把所有step都强制走LLM，每步都要生成上百token，这台机器会很快被拖垮。这个对比正好解释了英特尔的1000个agent叙事为什么不完全是空话，它赌的是真实agent架构里LLM调用会被工程手段极度压缩。

3.4 压测现场最常见的三个问题

跑这个实验的时候，我踩过几个非常典型的坑。

第一个问题：Ollama默认并发能力很低，同时发多个请求会排队甚至超时。解决方案就是上面说的OLLAMA_NUM_PARALLEL，把它设置成物理核数的一半左右比较稳。设太高内存带宽不够，设太低模型利用率上不去。

第二个问题：CPU线程数设满之后，性能反而下降。原因是解码过程是内存带宽瓶颈，超线程和过多线程会互相争抢内存控制器。用llama.cpp或者Ollama的时候，线程数优先设成物理核心数，而不是逻辑线程数。

第三个问题：长时间压测后速度越来越慢。这通常是KV cache膨胀或者内存碎片造成的。把OLLAMA_KEEP_ALIVE调短一点，模型定期重新加载，问题就缓解。

4. 真要在生产环境跑，这些坑要先排

4.1 别把"1000个智能体"理解成"1000条常驻长连接"

这是我看到最多人误解的地方。很多人一听1000个智能体，以为要同时维持1000个LLM会话，每个会话都要一个模型实例，内存直接爆掉。

真实的架构不是这样的。1000个agent指的是1000个业务任务流，每个任务流有独立的状态、记忆和工具链，但它们共享同一个推理后端池。任务流平时挂在调度器上，需要LLM的时候才向推理服务发起一次请求。推理服务端用连续批处理和并行槽位把这些请求高效揉在一起，让模型权重始终在被利用，而不是闲着。

所以生产环境的核心不再是模型本身，而是调度器。调度器要负责任务路由、超时管理、优先级队列、记忆持久化。在Intel这套叙事里，CPU既是调度器运行的场所，也是推理后端的场所，一鱼两吃。

4.2 生产调优清单

如果你真的打算在CPU上跑一个多智能体系统，我建议按下面这个清单逐项检查：

• 模型选择：优先1B到3B的量化模型，Q4_K_M是一个量化档位和效果比较平衡的选择。
• 内存通道：服务器优先选多通道内存的至强平台，这比堆核心数更管用。
• 并发参数：OLLAMA_NUM_PARALLEL设为物理核数的1/2到3/4，OLLAMA_MAX_LOADED_MODELS保持1，避免多个模型抢内存。
• 上下文长度：num_ctx不要贪大，按单次决策需要的上下文量来设，通常2048到4096就够。
• 超时与重试：LLM调用必须设超时，建议10到30秒，超时后降级走规则回复。
• 缓存策略：系统提示词等恒定文本，尽量复用KV cache前缀。
• 可观测性：记录每一步是走规则、工具还是LLM，统计LLM调用占比。如果占比长期超过40%，说明路由策略需要优化。

这些配置每一项都能直接影响你能撑住多少个agent。我见过有人把并发参数调得极高，结果内存带宽被榨干，全部请求排队，平均延迟从2秒恶化到20秒，性能反而下降十倍。这种事故完全是配置问题。

4.3 什么时候别硬扛CPU，直接上GPU或云

CPU路线不是万能的，有些场景就应该老老实实用GPU。

简单判断标准：

• 如果你的单次LLM生成超过500 token，或者需要长文档分析、代码生成、复杂推理，CPU会非常煎熬。
• 如果你的业务要求每个请求都在300毫秒内返回，CPU直接出局。
• 如果你的agent需要频繁处理几十K的超长上下文，CPU的内存带宽和算力都不够看。

适合CPU的场景是另一种画像：单次生成50到200 token，并发agent数量大，决策频率不高，模型不超过3B，数据隐私要求高，成本敏感，甚至需要离线部署。

生产里更合理的是做混合路由：最轻量的请求留在CPU上的小模型，中等复杂度的请求发给NPU或核显，重活才上云端GPU。这套混合架构里，"CPU跑1000个智能体"不再是单独承担一切，而是承担最海量的那部分长尾流量。这也是英特尔真正想推动的产业分工。

5. 我的几条判断

5.1 CPU不会取代GPU，但AI世界的"操作系统"会回到CPU

GPU是加速器，CPU是主机。这个关系在AI时代差点被颠覆，但智能体规模化之后，情况又转回来了。如果智能体真的成为类似"进程"的软件单元，那就需要一个能同时调度几千个进程的操作系统式底座。GPU负责算，但CPU负责管。英特尔的算盘，是抢那个"管"的位置。

我的判断是，未来两三年，端侧和边缘会冒出一大批轻量agent应用，它们不需要云端GPU，只需要一颗不错的CPU、一个量化小模型、一套好用的调度框架。这个市场不会取代GPU云市场，但会大得足以撑起英特尔的AI PC叙事。

5.2 工具链成熟度比CPU性能更关键

CPU跑模型这件事，技术上早就通透了。真正卡住产业的是agent工具链：规则引擎、记忆管理、任务编排、可观测性。像Ollama和llama.cpp解决了模型推理，很多人在coze、扣子上积攒了一套agent编排经验，但本地CPU侧的框架还在早期。

英特尔如果聪明，应该大力投资开源agent框架和工具链，而不是只讲硬件参数。1000个智能体要变成实际工作负载，靠的是开发者能轻松拼出系统，而不是靠发布会上的数字。

5.3 想动手的人，从这三步开始

如果你看完这篇，想在自己机器上验证一下，我建议按三步走。

第一步，装Ollama，拉一个1B模型，写一个最简单的agent循环：接收一句话，生成一个回复。先感受一下CPU推理的真实速度。

第二步，给agent加规则路由，把80%的简单问题用正则和硬编码逻辑挡掉，让CLI工具接口去处理。你会发现系统响应速度立刻上一个台阶。

第三步，把agent数量扩到100个，用脚本做并发压测，统计LLM调用占比和系统吞吐。你就能非常直观地理解"1000个智能体"这句话的工程含义。

我个人理解，这个方向最有趣的点从来不是"1000"这个数字本身。它逼着我们把智能体的工程成本算明白：哪些步骤非得大模型，哪些步骤用规则就好，这是每一条真实agent业务都要回答的问题。而CPU能不能跑1000个智能体，答案就藏在这些取舍里。