企业 Agent 的落地瓶颈正在从“有没有模型”转向“推理算力能否稳定、低延迟地贴近业务现场”。随着 OpenClaw、Hermes 等桌面级 Agent / 桌面 AI 应用走热推理请求正在从云端和中心机房进一步进入办公室、部门现场和个人工作流。中心化本地算力适合集中式批处理与共享服务而高频、隐私敏感、碎片化的交互请求更适合由边缘侧本地算力承接。本文聚焦以 GB10、AMD Ryzen AI Max 395 等 AI 计算盒为代表的桌面级边缘推理节点从容量、带宽、Agent 负载和推理引擎选择四个层面拆解技术约束统一内存决定模型、上下文和 KV Cache 能否放得下有效内存带宽决定 token 能否稳定流出来Agent 的长上下文和在线交互会持续放大容量与调度压力而在同一芯片上TensorRT-LLM、llama.cpp 等不同推理引擎的算子实现、量化格式、KV Cache 管理和请求调度也会带来不同的 TTFT、TPS 与工程体验。公开社区实验数据进一步说明长上下文不仅会放大 KV Cache 和内存容量压力也会直接拉低 decode 阶段的持续吞吐。关键词企业 Agent边缘算力本地推理统一内存显存墙内存带宽KV Cache长上下文推理引擎TensorRT-LLMllama.cpp0. 符号与指标符号 / 指标含义工程解释T上下文 token 数输入越长KV Cache 越大LTransformer 层数层数越多单 token 访存越重d_h每个 attention head 的维度与 KV Cache 容量线性相关B_mem可用内存带宽解码阶段吞吐上限的关键约束TTFTTime To First Token用户感知的首 token 延迟TPSTokens Per Second稳态解码吞吐TCOTotal Cost of Ownership总拥有成本C_a(q)请求 q 在动作 a 下的成本本地成本、云端 token 成本、机会成本都可纳入先说结论企业 Agent 落地缺的不是模型本身而是一个靠近业务现场、能承接长上下文在线推理的边缘推理底座。OpenClaw、Hermes 这类桌面级 Agent / 桌面 AI 应用的走热让一个问题变得更具体模型推理不再只是云端 API 或机房集群里的后台任务而是直接进入办公桌面、部门现场和个人工作流。所以这篇文章里的“本地算力”不是泛泛而谈的机房私有化。企业本地算力可以分成中心侧和边缘侧中心侧是私有化机房、集中式 GPU 集群边缘侧是部署在工位、办公室、茶水间或业务现场附近的推理节点。本文优先讲后者。这篇文章讲清楚四件事1. 为什么云端和中心机房都不能完全承接桌面级 Agent 推理需求2. 边缘侧硬件为什么要先解决模型、上下文和 KV Cache 放不放得下的问题3. 放得下之后内存带宽、KV Cache 和在线调度如何决定 token 能不能稳定流出来4. 同一块芯片上推理引擎选择为什么会影响实际体验全文较长技术同学可以直接跳到第二节。第二节会把端侧推理的技术挑战拆成四个层次容量决定模型和上下文能不能放得下带宽决定 token 能不能稳定流出来Agent 负载特征解释为什么长上下文和在线速度会成为基础设施问题推理引擎选择则说明为什么同一芯片在不同运行时下也会跑出不同体验。具体芯片结构、生态适配和产品工程化落地会放到后续文章展开。一、问题出在哪本地 Agent 很好用但还有提升空间先看一个再普通不过的场景。一位律师或者一位行业分析师一天的工作里有多少次需要 AI会议纪要、合同条款比对、几百页研报的摘要和检索——这类需求有三个特点高频、实时、碎片化。不是一天跑一次的批处理任务而是一天几十上百次的小请求每次都希望“问完就有”。这类需求放到云端 API 上跑会撞上三道墙第一道墙数据出不去。金融、政务、医疗这些行业客户合同、病历、内部研报按合规要求根本不允许传到公网。这不是“加密传输”能解决的问题——很多监管要求是数据物理上不离开受控环境。第二道墙网络不稳定。Agent 交互对首 token 延迟TTFT极其敏感。网络一抖流式输出就可能卡顿用户体验直接下降出差、客户现场、断网会议室等场景还会进一步放大不确定性。第三道墙账单不可控。按 token 计费在 demo 阶段感觉不到痛但全员高频使用之后月账单的增长曲线会让财务先找上门。看到这里很多人的第一反应是“这些问题我建个私有化机房不就解决了”还真不一定。我们见过太多客户走到这一步才发现中心化机房方案的几个结构性问题1.网络依赖还在。服务器搬进了自家机房但终端到服务器之间仍然是网络链路。内网穿透、网段隔离、VPN 策略——员工在园区另一栋楼、在工厂车间、在客户现场照样访问不了。1.传输链路本身就是合规盲区。“服务器在自家机房”不等于“数据没有风险”。数据在终端和服务器之间要经过交换机、负载均衡、各种日志系统。真正的强合规场景要求的是数据不离开终端设备传输这个动作本身就是风险面。2.利用率偏低。企业内部 Agent 的负载特征是碎片化小请求不是训练任务。共享 GPU 集群跑这种负载利用率常年趴在 15%~30%但机柜、电力、运维的钱一分不少花。3.扩容追不上业务增长。GPU 服务器采购周期 3~6 个月起步。业务部门今天说要给 50 个新座席开 Agent 权限机房说下个季度再议。所以中心机房和桌面级边缘节点不是替代关系是互补关系。打个比方中心机房是 L2 缓存边缘推理节点是 L1 缓存——重任务、批处理归机房实时交互、隐私敏感、离线场景归边缘。那么问题来了边缘侧拿什么跑大模型这就是桌面级边缘推理节点要出现的原因把推理算力从远处的云端和中心机房进一步下沉到更贴近业务现场的位置。二、端侧推理的技术挑战从放得下到跑得快第一节的问题可以归结为一句话企业 Agent 的推理需求正在离业务现场越来越近而云端和中心机房都很难同时满足隐私、实时性、离线可用和成本可控。端侧/边缘侧推理因此是一个很好的答案它解决的是“算力放在哪里”的问题把推理能力放到办公室、工位、会议室、业务网点和个人工作流附近。但端侧不是把模型搬到本地就万事大吉。桌面级边缘节点仍然要面对三类硬约束和一类关键工程变量第一模型权重、上下文和 KV Cache 能不能放得下第二放下之后 token 能不能以足够稳定的速度流出来第三Agent 这种带记忆、带工具、长上下文、在线交互的负载会不会把容量和带宽压力继续放大第四在同一芯片上推理引擎如何通过算子、量化、KV Cache 和调度把硬件能力真正释放出来。所以下面先不急着讨论具体产品形态而是进入技术面的硬核分析先看容量再看带宽再回到 Agent 负载最后看推理引擎选择。2.1 容量层内存、显存与统一内存很多人对“本地跑大模型”的印象还停留在游戏本插独显、显存焦虑、风扇起飞。这个印象该更新了。边缘算力产品首先要解决的不是 benchmark 上的峰值 TOPS而是一个更朴素的问题模型、上下文和 KV Cache 到底放不放得下。放不下后面的推理速度、引擎调度和在线体验优化都没有意义。2.1.1 内存和显存先算模型权重能不能放得下在传统 GPU 架构里模型通常必须装进 GPU 显存。24GB 的消费级显卡连 30B 模型的 FP16 权重都装不下更不用说 70B 模型、长上下文 KV Cache 和运行时临时缓冲。于是工程上只能切片、量化、CPU offload性能损失一层叠一层。可以先做一笔非常粗的容量账7B 模型 FP16 权重约 14GB30B 约 60GB70B 约 140GB如果做 INT4 量化权重体积大约降到 3.5GB、15GB、35GB 这个量级。这个数字只是权重本身还没有算 tokenizer、运行时缓冲、KV Cache、多个模型同时驻留以及操作系统和应用自身的内存占用。估算对象简化配置理论占用量级说明700 亿参数权重FP1670 × 10^9 × 2 bytes约 140GB不含运行时额外开销700 亿参数权重INT470 × 10^9 × 0.5 bytes约 35GB还需 scales / metadata单会话 KV CacheL32,H_kv32,d_h128,T8192,s2约 4GB只估 KV不含权重多座席并发N 个活跃上下文近似随 N 线性增长Prefix 复用可降低实际占用CPU 内存容量通常更大但传统 CPU 独显架构里CPU 内存和 GPU 显存是分离的。权重如果放在 CPU 内存里推理时就要跨 PCIe 搬运权重如果放在 GPU 显存里又会被显存容量卡住。这个矛盾决定了很多“本地跑模型”的体验不是不能跑而是跑得很勉强。所以看桌面级边缘推理硬件第一眼不应该只看算力标称而要先看可供加速器直接使用的内存容量。对于企业 Agent这个容量不仅要装下一个主模型还要给长上下文、系统提示词、工具定义、RAG 文档片段和多轮会话留下空间。2.1.2 统一内存把模型权重和 KV Cache 放进同一个大池子2025 年以来桌面级边缘推理硬件出现了一个关键转折统一内存架构UMA的大内存平台开始量产。这直接改变了游戏规则。统一内存架构把 CPU、GPU、NPU 看到的内存池合在一起。模型权重不用在“CPU 内存容量大但离加速器远”和“GPU 显存近但容量小”之间二选一KV Cache 也不用在显存里精打细算地腾挪。对边缘推理节点来说这相当于先把“能不能完整承载模型”这个基础问题解决掉。这里还要把 KV Cache 单独拿出来看。论文里 Transformer 的核心注意力计算通常写成Attention(Q, K, V) softmax((QKᵀ) / √dₖ) V推理服务真正麻烦的地方不只是这个算子本身而是每个会话都会持续增长的 KV Cache。一个简化的容量估算式是M_KV ≈ 2 · B · T · L · H_kv · d_h · s其中 B 是 batch sizeT 是上下文长度L 是层数H_kv 是 KV head 数d_h 是 head 维度s 是每个数值的字节数。前面的 2 分别对应 Key 和 Value。这个公式传达的工程含义很直接上下文越长、并发会话越多、模型层数越深KV Cache 就越快膨胀。桌面 Agent 如果要承接长文档、长会话和持续记忆统一内存不是锦上添花而是让模型和上下文能一起放下来的底座。2.2 带宽层带宽如何影响推理速度容量问题解决之后下一步才是速度问题。对交互式 Agent 来说用户感受到的速度不是模型参数表里的峰值 TOPS而是首 token 多久出来、后续 token 能不能稳定流出来。2.2.1 Decode 阶段带宽对速度的影响典型自回归模型推理可以拆成两个阶段prefill 阶段并行处理输入上下文decode 阶段逐 token 生成。Prefill 更像一次大规模并行计算输入越长首 token 延迟越容易被拉高decode 则是每次生成一个 token再把这个 token 回灌到下一轮计算里。对交互式 Agent 来说用户真正盯着看的往往是 decode 阶段的 TPS。这个阶段小 batch、碎片化请求很多矩阵计算规模不够大GPU / NPU 的峰值 TOPS 很难长期吃满真正先被打满的是有效内存带宽。在每一步 decode 中芯片要反复从统一内存里读取模型权重、读取或更新 KV Cache并写入中间激活。大模型参数越大单 token 需要扫过的权重量级越大上下文越长KV Cache 读写也越重。最终决定 token 速度上限的往往不是“理论每秒多少次运算”而是“每秒能把多少有效数据喂给计算单元”。图 1边缘推理中的数据搬运路径。每生成一个 token权重、KV Cache 和激活读写都会争抢有效内存带宽。更接近工程直觉的单 token 耗时式可以写成t_token ≈ (S_weight S_KV S_act) / B_eff t_compute t_schedTPS_decode ≈ 1 / t_token其中S_weight 是单步生成中需要读取的模型权重量级S_KV 是与上下文长度和并发会话相关的 KV Cache 读写量S_act 是中间激活和临时缓冲读写量B_eff 是实际可用的有效内存带宽。t_compute 和 t_sched 分别代表算子计算、kernel 启动、批处理窗口和调度带来的额外耗时。举个数量级例子70B 模型 INT4 后权重量级约 35GB如果有效内存带宽按 1TB/s 估算仅“读权重”这一项的理论上限也只有约 1000 / 35 ≈ 28 token/s如果是 FP16权重量级约 140GB上限会降到约 7 token/s。真实系统还要扣掉 KV Cache、激活读写、kernel 和调度开销所以实际 TPS 只会更低。这也是为什么桌面级边缘推理硬件不能只看 TOPS统一内存容量决定模型和上下文装不装得下内存带宽决定 token 能多快流出来KV Cache 管理和推理引擎调度则决定多会话、多模型混跑时速度是否稳定。图 2aPrefill 阶段。输入上下文先被并行处理并将中间状态写入 KV Cache。图 2bDecode 阶段。交互式 Agent 的体验通常先看 TTFT再看 decode 阶段的稳定 TPS。2.3 Agent 推理层长上下文带来的速度挑战前面两小节讲的是容量和带宽如何影响推流。这里反过来看 Agent 自己为什么 Agent 推理比普通聊天更依赖容量和带宽。2.3.1 长上下文记忆、工具和文档让上下文持续增长普通聊天可以把上下文理解成“用户刚才问了什么”。Agent 不一样它要记住用户偏好、项目背景、工具调用结果、任务中间状态、历史决策和外部文档。也就是说Agent 的上下文不是一段对话而是一套持续增长的工作现场。以 Hermes 的记忆机制为例它把持久记忆拆成 agent 自己的 MEMORY.md 和用户画像 USER.md并在会话开始时把这些记忆作为冻结快照注入 system prompt。这个设计很有代表性一方面记忆让 Agent 能跨会话延续用户偏好、项目事实和环境约束另一方面只要这些记忆进入 prompt它们就会占用上下文窗口并在 prefill 和 KV Cache 中形成真实的容量压力。Hermes 选择冻结会话开始时的记忆快照是为了保持前缀稳定方便利用 prefix cache。这个取舍说明了 Agent 记忆系统的本质矛盾记忆越丰富Agent 越像一个持续工作的助手但记忆越多输入 token、KV Cache、首 token 延迟和上下文管理压力也越大。公开资料里的数字也能说明这个问题Agent 的 token 消耗往往不是用户那一句问题而是为了完成问题而被反复带入上下文的工具定义、工具返回、历史轨迹和中间状态。表 2简单 Agent 任务的 token 消耗量级公开资料与工程估算场景用户看起来的问题典型 token 消耗与膨胀原因普通单轮问答“今天有哪些会议”“帮我总结一句话。”约 200-2,000 tokens/轮主要是系统提示、用户问题和最终回答这是对比基线。简单工具型 Agent“查一下日程并告诉我下午有没有空。”约 5,000-15,000 tokens/任务。即使只调用 1-2 个工具也要把工具 schema、调用参数、工具返回和二次综合放进上下文。中等工具/RAG Agent“查知识库找相关制度再给我一个结论。”约 15,000-50,000 tokens/任务。3-5 次检索或工具调用后文档片段、观察结果和历史消息会被多轮重读。MCP/企业工具目录“从 Drive 取一份文档再同步到 CRM。”Anthropic 的 MCP 案例中传统方式约 150,000 tokens按需加载工具定义后约 2,000 tokens节省 98.7%。这说明大量消耗来自工具定义本身。大 API 工具面“改一个 DNS 记录”或“查一条 Cloudflare 配置。”Cloudflare 披露若把全 API 暴露成传统 MCP 工具工具定义可达 1.17M tokensCode Mode 将固定工具面压到约 1,000 tokens。编码/文件型 Agent“修一个小 bug”或“改一处配置。”Stanford 相关研究指出agentic coding 可比 code reasoning / code chat 多消耗约 1000x tokens。关键原因是每轮都携带完整历史、文件观察和工具输出。这张表要表达的不是某个框架一定会消耗固定数量的 token而是一个更稳定的工程事实Agent 的上下文成本由“任务轨迹”主导而不是由用户问题长度主导。用户只问一句话底层可能已经带上几千 token 的系统提示、几千到几十万 token 的工具描述以及多轮工具返回和中间状态。企业 Agent 的压力还会更大。除了用户记忆它还要塞进企业制度、合同片段、知识库检索结果、工具 schema、审批状态和多轮任务轨迹。一个看似简单的“帮我审一下这份合同”背后可能同时包含系统提示词、用户偏好、合同全文、历史类似案例、检索结果和当前任务计划。长上下文因此不是可选功能而是企业 Agent 的基本负载特征。所以前面强调容量并不是为了堆参数而是为了回答 Agent 能不能在本地完整承接这些上下文。模型权重只是第一层真正进入企业场景之后KV Cache、RAG 上下文、工具定义和多模型组件都会一起吃内存。这个判断可以用 vLLM 社区的一个长上下文性能 issue 来做旁证。该 issue 在固定 batchsize90、单卡 A800 80G 等条件下观察 prompt length 与 decode 吞吐的关系短上下文区间可以维持约 5.3k-5.5k tokens/s但当 prompt length 增长到 4000-8000 时降到 782 tokens/s超过 8000 时进一步降到 273 tokens/s。表 3vLLM 长上下文解码吞吐实验数据单卡 A800 80Gbatchsize90Prompt length解码吞吐tokens/s相对 0-100工程观察0-1005364100.0%短上下文基线。100-2005500102.5%与基线基本持平短区间存在轻微波动。200-500472288.0%开始出现下降但仍处于高吞吐区间。500-1000281552.5%吞吐接近腰斩长 prompt 已明显影响 decode。1000-2000248446.3%相当于短上下文吞吐的一半以下。2000-4000162730.3%多轮工具调用和 RAG 上下文会进入这个压力区。4000-800078214.6%约为短上下文的 1/7流式输出稳定性显著变差。80002735.1%约为短上下文的 1/20长上下文成为主要瓶颈。数据来源vLLM GitHub issue #11286 “Performance: decoding speed on long context”这组数据的价值不在于给所有硬件和模型下一个绝对结论而在于揭示一个方向性事实在 decode 阶段每生成一个新 token 都要回看更长的历史 K/V。上下文越长KV Cache 的读取、寻址、调度和显存/内存带宽压力越大实际 TPS 就越容易从“能跑”滑向“用户明显感到慢”。因此Agent 的长上下文挑战不能只用“上下文窗口够不够大”来衡量。窗口越大确实能装下更多记忆、文档和工具轨迹但如果推理底座没有足够的有效带宽、KV Cache 管理和在线调度能力长上下文会同时拖慢 TTFT 和 decode 吞吐最终表现为用户眼里的卡顿、等待和多轮任务中断。2.3.2 在线推理TTFT、TPS 和流式体验必须稳定Agent 的第二个特点是在线。离线批处理可以慢一点晚几分钟出结果也能接受但桌面 Agent 是人在等、工作流在等、下一步工具调用也在等。它的体验指标不是平均吞吐而是 TTFT、稳定 TPS 和交互过程中的抖动。这也是为什么边缘推理节点的价值不只是“省云端费用”。本地推理把网络不确定性从关键路径里拿掉让首 token 延迟更可控统一内存和高有效带宽让长上下文下的 token 流更稳定推理引擎则通过 KV Cache 复用、prefix cache、批处理窗口和模型加载优化把多轮 Agent 任务中的等待时间压下来。这也引出最后一个工程变量同样的芯片和同样的模型推理引擎不同最终 TTFT、TPS、内存占用和多轮 Agent 体验也可能明显不同。2.4 推理引擎的选择同一芯片不同引擎也会跑出不同体验到这一步还要回答一个容易被低估的问题买到同一块芯片并不等于拿到同样的推理体验。芯片决定算力、带宽和内存池的上限推理引擎决定这些资源如何被模型权重、KV Cache、量化算子和请求调度真正用起来。差异通常会在五个环节被放大模型格式与量化方案、attention / GEMM 等核心算子实现、KV Cache 的布局和复用、prefill 与 decode 阶段的调度策略以及硬件后端和驱动栈的成熟度。对桌面级 Agent 来说单请求 TTFT、稳定 TPS、冷启动和多模型切换体验往往比单一 benchmark 峰值更重要。以 TensorRT-LLM 和 llama.cpp 为例二者并不是简单的谁取代谁而是侧重点不同维度TensorRT-LLM 的侧重点llama.cpp 的侧重点定位面向 NVIDIA GPU 的高性能服务化推理栈围绕 TensorRT / CUDA 生态做深度优化。轻量 C/C 本地推理栈强调少依赖、易部署和广泛硬件覆盖。硬件后端主要绑定 NVIDIA GPU可利用 CUDA、Tensor Cores、多卡和多节点并行能力。覆盖 CPU、Apple Silicon / Metal、CUDA、HIP、Vulkan、SYCL 等后端也支持 CPUGPU 混合推理。模型部署通常需要模型转换、engine 构建和平台调优前期准备更重但运行期优化空间更大。以 GGUF 模型直接运行和快速切换为核心体验适合本地验证、多模型实验和离线部署。量化策略支持 FP8、FP4、INT4 AWQ、INT8 SmoothQuant 等面向 GPU 的量化路径。提供多种低比特 GGUF 量化格式重点是降低内存占用、扩大可运行模型范围。KV Cache 与调度强调 in-flight batching、paged KV cache、chunked context 和 serving scheduler提高并发吞吐和 GPU 利用率。更偏单机本地会话与轻量 server最终表现取决于具体后端、量化格式和上下文配置。典型场景固定 NVIDIA 平台、追求高吞吐、可观测性、并发服务和生产化部署。异构桌面/边缘设备、快速上手、离线运行、模型评测和多硬件适配。选型代价平台绑定和工程复杂度更高需要围绕特定 GPU、驱动和模型版本做持续调优。平台覆盖更广但同一硬件上的峰值性能和稳定性更依赖后端成熟度与参数调校。这张表的核心不是判断哪个引擎“绝对更好”而是提醒选型必须同时看硬件、模型和负载。如果底层是固定的 NVIDIA GPU并且目标是服务化并发和极致 GPU 利用率TensorRT-LLM 更容易把定制 kernel、paged KV cache 和批处理调度的优势打出来如果目标是多芯片覆盖、桌面离线可用、快速模型切换和低部署门槛llama.cpp 的工程弹性会更强。企业边缘节点更现实的路线往往是在上层保持 OpenAI-compatible API在底层按硬件和负载做多引擎路由大模型、高并发、固定 NVIDIA 平台走 TensorRT-LLM轻量模型、异构桌面设备和离线场景走 llama.cpp。这样上层 Agent 框架只需要切换 base_url 或模型名底层仍然可以持续迭代引擎、量化和调度策略。总结一下这一节的主线容量回答模型和上下文能不能放得下带宽回答 token 能不能稳定流出来Agent 负载解释为什么长上下文和在线速度会把容量、带宽、KV Cache 和调度推到基础设施层面推理引擎选择则决定同一硬件上这些能力能被释放多少。后续文章再展开具体芯片结构、生态适配和产品工程化落地。vLLM issue #11286 的公开数据也提示长上下文会把 Agent 推理从“容量够不够”进一步推到“速度稳不稳”的问题上。三、写在最后先技术分析到工程实践本文没有急于讨论某一款芯片或推理引擎而是希望先建立一个理解桌面级边缘推理的分析框架对于企业 Agent 而言真正影响推理体验的不只是模型规模或峰值算力而是容量、带宽、推理引擎以及 Agent 负载特征之间的共同作用。后续我们将沿着这条主线继续展开分别分析 GB10、AMD Ryzen AI Max 395 等主流桌面级边缘算力平台从芯片架构、统一内存、内存带宽、软件生态到推理引擎适配和调度策略进一步讨论它们如何影响模型选择、并发能力、TTFT 与实际 TPS 等关键指标。当这些基础能力被拆解清楚之后再回头看不同平台之间的工程实现与优化思路就会更容易理解桌面级 Agent 推理系统为什么会呈现出不同的性能表现。参考文献1. Vaswani et al., Attention Is All You Need, 2017.2. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023.3. Nous Research, Hermes Agent Documentation: Persistent Memory, 2026.4. ggml-org, llama.cpp README and project documentation.5. vLLM project documentation and PagedAttention implementation notes.6. NVIDIA, TensorRT-LLM documentation and developer guide.7. OpenAI, Function Calling Guide: Token Usage.8. Anthropic, Code execution with MCP: building more efficient AI agents, 2025.9. Cloudflare, Code Mode: give agents an entire API in 1,000 tokens, 2026.10. Bai et al., How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks, 2026.11. Iternal AI, Tokenization in NLP: Tokens, Usage Cost Guide, 2026.12. vLLM project, [Performance]: decoding speed on long context, GitHub issue #11286, opened Dec 18, 2024. https://github.com/vllm-project/vllm/issues/11286