企业官网建设流程全解析

企业 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-LLM；llama.cpp

0. 符号与指标

先说结论：企业 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 权重约 14GB，30B 约 60GB，70B 约 140GB；如果做 INT4 量化，权重体积大约降到 3.5GB、15GB、35GB 这个量级。这个数字只是权重本身，还没有算 tokenizer、运行时缓冲、KV Cache、多个模型同时驻留，以及操作系统和应用自身的内存占用。

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 size，T 是上下文长度，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_sched

TPS_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 管理和推理引擎调度，则决定多会话、多模型混跑时速度是否稳定。

图 2a：Prefill 阶段。输入上下文先被并行处理，并将中间状态写入 KV Cache。

图 2b：Decode 阶段。交互式 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，而是一个更稳定的工程事实：Agent 的上下文成本由“任务轨迹”主导，而不是由用户问题长度主导。用户只问一句话，底层可能已经带上几千 token 的系统提示、几千到几十万 token 的工具描述，以及多轮工具返回和中间状态。

企业 Agent 的压力还会更大。除了用户记忆，它还要塞进企业制度、合同片段、知识库检索结果、工具 schema、审批状态和多轮任务轨迹。一个看似简单的“帮我审一下这份合同”，背后可能同时包含系统提示词、用户偏好、合同全文、历史类似案例、检索结果和当前任务计划。长上下文因此不是可选功能，而是企业 Agent 的基本负载特征。

所以前面强调容量，并不是为了堆参数，而是为了回答 Agent 能不能在本地完整承接这些上下文。模型权重只是第一层，真正进入企业场景之后，KV Cache、RAG 上下文、工具定义和多模型组件都会一起吃内存。

这个判断可以用 vLLM 社区的一个长上下文性能 issue 来做旁证。该 issue 在固定 batchsize=90、单卡 A800 80G 等条件下观察 prompt length 与 decode 吞吐的关系：短上下文区间可以维持约 5.3k-5.5k tokens/s，但当 prompt length 增长到 4000-8000 时降到 782 tokens/s，超过 8000 时进一步降到 273 tokens/s。

表 3：vLLM 长上下文解码吞吐实验数据（单卡 A800 80G，batchsize=90）

数据来源：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 为例，二者并不是简单的谁取代谁，而是侧重点不同：

这张表的核心不是判断哪个引擎“绝对更好”，而是提醒选型必须同时看硬件、模型和负载。如果底层是固定的 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