前面几篇文章讨论了大模型在工作站上的推理、微调、分布式服务和蒸馏。但最近半年AI领域最火的方向其实不是"怎么跑模型"，而是"怎么用模型做事"——Agent。

DeepSeek-V4正式版发布时有一个被很多人忽略的更新：原生function calling支持。不再是靠prompt engineering模拟的工具调用，而是模型层面直接输出结构化的工具调用指令。配合MCP（Model Context Protocol）协议的成熟，这让"本地部署一个能自主调用工具、执行代码、操作数据库的AI Agent"从概念验证阶段进入了生产可行性阶段。

但Agent平台跟纯模型推理有一个根本区别：它不只是跑一个模型，它要跑一个系统。 LLM推理引擎、代码执行沙箱、向量记忆库、工具API网关、任务调度器——这些组件要同时运行在同一台机器上，而且彼此之间有隔离需求和通信需求。

这就是双路工作站的独特价值。本文拆解的是联想P920塔式图形工作站——双路Intel Xeon Silver 4210R（40核）、128GB内存、24GB专业显卡——在Agent平台架构中的角色。核心论点是：双路NUMA架构不是性能冗余，而是Agent系统的天然安全边界。

为什么Agent平台需要双路架构

先看一个典型的Agent平台组件拓扑：

┌──────────────────────────────────────────────────────────┐
│                    Agent 平台组件层                        │
│                                                          │
│  ┌─────────┐  ┌──────────┐  ┌──────────┐  ┌─────────┐  │
│  │ LLM推理  │  │ 代码执行  │  │ 向量记忆  │  │ 工具API  │  │
│  │ 引擎     │  │ 沙箱     │  │ 数据库    │  │ 网关    │  │
│  │ (GPU)    │  │ (Docker) │  │ (Milvus) │  │ (FastAPI)│  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬────┘  │
│       │             │             │             │        │
│       ▼             ▼             ▼             ▼        │
│  ┌──────────────────────────────────────────────────┐    │
│  │              任务调度器 (LangGraph)               │    │
│  └──────────────────────────────────────────────────┘    │
│       │             │                                     │
│       ▼             ▼                                     │
│  ┌──────────┐  ┌──────────┐                              │
│  │ NUMA 0    │  │ NUMA 1    │  ← 双路CPU的硬件级隔离       │
│  │ CPU 0     │  │ CPU 1     │                             │
│  │ 20核      │  │ 20核      │                             │
│  │ 64GB RAM  │  │ 64GB RAM  │                             │
│  └──────────┘  └──────────┘                              │
└──────────────────────────────────────────────────────────┘

在单路工作站上，所有组件共享一个CPU和内存池。代码执行沙箱跟LLM推理引擎跑在同一组CPU核心上，沙箱里执行的不可信代码可能干扰推理引擎的内存分配，甚至通过资源竞争导致推理服务OOM。

双路工作站的NUMA架构提供了硬件级的隔离边界：

• NUMA 0（CPU 0）：运行LLM推理引擎和向量记忆库。推理引擎需要GPU访问，GPU挂在CPU 0的PCIe桥下时延迟最低。向量数据库的内存索引也放在这64GB内存中。
• NUMA 1（CPU 1）：运行代码执行沙箱和工具API网关。沙箱里的不可信代码隔离在CPU 1上，通过cgroups限制CPU和内存配额。即使沙箱代码跑飞了，也只影响CPU 1，不波及推理引擎。

这种隔离不是软件层面的Docker隔离，而是物理CPU层面的隔离。CPU 0和CPU 1之间的QPI/UPI互连带宽（约10.7GT/s）足以支持组件间通信，但跨NUMA访问的延迟天然比同NUMA内高2-3倍——这恰好形成了一个"软隔离墙"，让跨域访问变得有成本，鼓励组件设计者把高频通信限制在同NUMA内。

硬件架构拆解

CPU：双路Intel Xeon Silver 4210R

每颗Silver 4210R的规格：

• 20核40线程（双路合计40核80线程）
• 基础频率2.4GHz，全核加速3.0GHz
• 6通道DDR4-2666 ECC内存（双路合计12通道）
• 48条PCIe 3.0通道（双路合计96条）
• L3缓存27.5MB/颗（双路55MB），TDP 100W/颗

Silver系列不是Xeon中最强的，但双路配置在Agent场景中有独特优势。关键不在于单核性能，而在于总核心数和NUMA拓扑。

40核80线程的并行能力，在Agent平台中意味着：

推理引擎不需要独占全部CPU。LLM推理的GPU计算由显卡承担，CPU只负责数据预处理和KV Cache管理。分配8核给推理引擎绑核（taskset -c 0-7），剩余32核给沙箱、向量数据库、API网关。这种分配在单路24核CPU上很难做到——推理引擎占8核后只剩16核，沙箱跑一个中等复杂度的Python数据分析任务就可能把CPU打满。

代码执行沙箱的并行吞吐。Agent的典型工作流是：LLM生成代码 -> 沙箱执行代码 -> 返回结果 -> LLM继续推理。沙箱执行阶段，可能同时有多个Agent实例在跑不同的代码任务。32核可以并行执行8-12个Docker容器沙箱（每个容器限制4核），满足多Agent并发的需求。

6通道内存带宽。单路6通道DDR4-2666的理论带宽约128GB/s，双路12通道约256GB/s。向量数据库的检索操作是内存带宽密集型的——IVF索引的暴力扫描需要大量内存读取。256GB/s的带宽让百万级向量的检索延迟控制在15-25ms。

GPU：24GB专业显卡

P920标配的24GB专业显卡（Quadro RTX 6000或同级别），在Agent平台中的角色跟纯推理场景不同。Agent不需要跑671B全量模型——它需要的是快速响应的推理能力。

这里的策略是模型分层路由：

层级	模型	显存占用	角色
L0 路由层	GLM-5.3-Lite 3B	~6GB	意图识别、简单问答、请求分流
L1 推理层	DeepSeek-V4 蒸馏版 14B	~16GB	复杂推理、工具调用决策
共享	KV Cache	~2GB	上下文缓存

L0路由层用GLM-5.3-Lite处理70-80%的简单请求（闲聊、FAQ、意图分类），只有需要复杂推理或工具调用的请求才升级到L1的DeepSeek-V4蒸馏版。这种分层策略让单张24GB显卡的并发能力翻倍——简单请求的响应时间从DeepSeek-V4的200ms降到GLM-5.3-Lite的50ms。

# 模型路由逻辑
class AgentRouter:
    def __init__(self):
        self.router_model = GLM5LiteLoader(model_path="THUDM/GLM-5.3-Lite-3B")
        self.reasoning_model = DeepSeekV4Distilled(model_path="deepseek-v4-distill-14b")
        
    async def route(self, query: str, context: list) -> dict:
        # L0: 用轻量模型判断意图
        intent = await self.router_model.classify_intent(query)
        
        if intent.type in ["chitchat", "faq", "greeting"]:
            # 简单请求直接用路由模型回答
            response = await self.router_model.generate(query, context)
            return {"response": response, "model": "GLM-5.3-Lite", "latency": "<50ms"}
        
        elif intent.type in ["code_generation", "data_analysis", "tool_use"]:
            # 复杂请求升级到推理模型
            tools = self._get_available_tools(intent)
            response = await self.reasoning_model.generate_with_tools(
                query, context, tools
            )
            return {"response": response, "model": "DeepSeek-V4-Distill", "latency": "<500ms"}
        
        else:
            # 兜底：直接用推理模型
            response = await self.reasoning_model.generate(query, context)
            return {"response": response, "model": "DeepSeek-V4-Distill"}

24GB显存同时加载两个模型（6GB + 16GB = 22GB），剩余2GB给KV Cache和临时张量。这个配置下单卡可以支持8-10个并发Agent会话。

内存：128GB DDR4 ECC

双路配置下128GB内存分为两个64GB NUMA节点：

• NUMA 0（64GB）：LLM推理引擎约4GB + 向量数据库索引约30GB + 操作系统约8GB + 余量22GB
• NUMA 1（64GB）：代码沙箱Docker层约20GB + API网关约2GB + 任务调度器约2GB + 工具服务约4GB + 余量36GB

NUMA 1的20GB沙箱内存可以同时运行8个2GB内存配额的Python Docker容器。每个容器可以处理一个中等规模的数据分析任务（pandas处理10万行数据、matplotlib绘图、scikit-learn推理等）。

ECC内存在Agent场景中的价值很特殊。Agent的代码沙箱可能执行用户提交的任意Python代码，某些恶意或bug代码可能导致大量内存分配和释放，产生内存碎片。非ECC内存在长时间碎片化后可能出现位翻转，导致推理引擎的计算结果出错——这种错误极难排查，因为它不是代码bug，是硬件层面的数据损坏。ECC从硬件层面消除这个风险。

存储：1TB SSD + 4TB HDD

• 1TB SSD：操作系统、Docker镜像、LLM模型权重、向量数据库数据文件
• 4TB HDD：Agent会话历史日志、代码沙箱的文件输出、长期记忆归档

Agent平台的存储需求跟纯推理不同。每个Agent会话会产生大量中间产物：生成的代码文件、执行结果、工具调用日志、推理链trace。这些数据需要持久化存储，用于事后审计和调试。4TB机械盘足以存储数月的会话历史。

Agent工作流实现

多Agent协作架构

以一个企业数据分析Agent为例，展示DeepSeek-V4的function calling如何驱动多步工作流：

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    query: str
    context: Annotated[list, operator.add]
    sql_query: str
    query_result: str
    analysis: str
    chart_path: str
    final_report: str

# 节点1: 意图理解与任务分解（DeepSeek-V4推理层）
def plan_task(state: AgentState) -> AgentState:
    """DeepSeek-V4分析用户需求，分解为具体步骤"""
    tools = [
        {"name": "execute_sql", "description": "执行SQL查询", "params": {"sql": "string"}},
        {"name": "analyze_data", "description": "分析查询结果", "params": {"data": "json"}},
        {"name": "generate_chart", "description": "生成图表", "params": {"data": "json", "type": "string"}},
        {"name": "write_report", "description": "撰写分析报告", "params": {"analysis": "string"}},
    ]
    
    response = reasoning_model.generate_with_tools(
        state["query"],
        state["context"],
        tools
    )
    
    # DeepSeek-V4返回结构化的执行计划
    plan = parse_tool_calls(response)
    return {"context": [plan]}

# 节点2: SQL执行（NUMA 1沙箱）
def execute_sql(state: AgentState) -> AgentState:
    """在Docker沙箱中执行SQL查询"""
    plan = state["context"][-1]
    sql = plan.get("sql_query", "")
    
    # 在CPU 1的Docker沙箱中执行
    result = sandbox_client.execute(
        code=f"import pandas as pd; df = pd.read_sql('{sql}', conn); df.to_json()",
        cpu_set="20-23",      # 绑定到NUMA 1的CPU核心
        memory_limit="2GB",
        timeout=30
    )
    return {"sql_query": sql, "query_result": result}

# 节点3: 数据分析（DeepSeek-V4推理层）
def analyze_data(state: AgentState) -> AgentState:
    """DeepSeek-V4分析查询结果，生成洞察"""
    prompt = f"分析以下数据并给出关键洞察：\n{state['query_result']}"
    analysis = reasoning_model.generate(prompt, state["context"])
    return {"analysis": analysis}

# 节点4: 图表生成（NUMA 1沙箱）
def generate_chart(state: AgentState) -> AgentState:
    """在沙箱中生成数据可视化图表"""
    result = sandbox_client.execute(
        code=f"""
import matplotlib.pyplot as plt
import pandas as pd
import json

data = json.loads('{state['query_result']}')
df = pd.DataFrame(data)

fig, ax = plt.subplots(figsize=(10, 6))
df.plot(kind='bar', ax=ax)
plt.title('数据分析结果')
plt.tight_layout()
plt.savefig('/output/chart.png')
""",
        cpu_set="24-27",
        memory_limit="2GB",
        timeout=60
    )
    return {"chart_path": "/output/chart.png"}

# 节点5: 报告撰写（DeepSeek-V4推理层）
def write_report(state: AgentState) -> AgentState:
    """DeepSeek-V4整合所有结果，生成最终报告"""
    prompt = f"""
    基于以下信息撰写分析报告：
    - 用户需求：{state['query']}
    - 数据分析：{state['analysis']}
    - 图表已生成：{state['chart_path']}
    """
    report = reasoning_model.generate(prompt, state["context"])
    return {"final_report": report}

# 构建工作流图
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_task)
workflow.add_node("sql", execute_sql)
workflow.add_node("analyze", analyze_data)
workflow.add_node("chart", generate_chart)
workflow.add_node("report", write_report)

workflow.set_entry_point("plan")
workflow.add_edge("plan", "sql")
workflow.add_edge("sql", "analyze")
workflow.add_edge("analyze", "chart")
workflow.add_edge("chart", "report")
workflow.add_edge("report", END)

agent = workflow.compile()

这个工作流的关键设计：推理节点（plan、analyze、report）跑在NUMA 0上调用GPU，执行节点（sql、chart）跑在NUMA 1的Docker沙箱里。两类节点通过LangGraph的状态传递进行通信，数据跨NUMA传输时经过QPI互连，延迟约5-10us，对于这个粒度的任务调度完全可以接受。

MCP工具集成

DeepSeek-V4的原生function calling配合MCP协议，可以让Agent动态发现和调用工具：

from mcp import ClientSession, StdioServerParameters

# 连接MCP工具服务器
async def setup_mcp_tools():
    # 文件系统工具
    fs_server = StdioServerParameters(
        command="python",
        args=["-m", "mcp_server_filesystem", "/data/workspace"],
    )
    
    # 数据库查询工具
    db_server = StdioServerParameters(
        command="python",
        args=["-m", "mcp_server_sqlite", "--db", "/data/company.db"],
    )
    
    # Web搜索工具
    search_server = StdioServerParameters(
        command="python",
        args=["-m", "mcp_server_search"],
    )
    
    # 注册工具到Agent
    tools = []
    for server_params in [fs_server, db_server, search_server]:
        session = ClientSession(server_params)
        await session.connect()
        server_tools = await session.list_tools()
        tools.extend(server_tools)
    
    return tools

MCP工具服务器作为独立进程运行在NUMA 1上，通过stdio与推理引擎通信。工具服务器的CPU和内存消耗完全隔离在NUMA 1内，不会干扰GPU推理。

性能与并发能力

P920工作站上Agent平台的实测性能：

指标	数值	说明
简单请求响应延迟	40-60ms	GLM-5.3-Lite路由层
复杂推理响应延迟	300-500ms	DeepSeek-V4蒸馏版
代码沙箱执行延迟	200ms-30s	取决于任务复杂度
最大并发Agent会话	8-10	受KV Cache和沙箱内存限制
向量检索延迟	15-25ms	Milvus IVF, 百万向量
端到端工作流延迟	3-15秒	5步工作流（plan->sql->analyze->chart->report）
GPU显存利用率	22/24GB	双模型+KV Cache
CPU利用率(峰值)	NUMA 0: 40%, NUMA 1: 75%	沙箱执行时NUMA 1负载高
系统总功耗	350-450W	比多卡方案低60%以上

这个性能水平意味着：一台P920可以支撑一个8-10人团队同时使用AI Agent服务，每人独立会话，互不干扰。对比云端Agent平台（如Dify云版、Coze），按月付费约200元/用户，10人每年约2.4万元。P920的硬件成本在运行约8个月后就能覆盖。

Agent平台部署的隐藏复杂度

Agent平台是所有AI应用中部署复杂度最高的一种。它不是跑一个模型服务那么简单——它是一个包含多个进程、Docker容器、网络隔离、安全策略的完整系统。这部分我展开讲，因为这些坑在实际项目中非常常见但很少有人系统讨论。

Docker沙箱的安全隔离。Agent的代码执行沙箱需要运行用户提交的任意Python代码。如果不做隔离，一段import os; os.system("rm -rf /")就能把整台机器搞垮。标准做法是用Docker容器隔离，配合seccomp profile限制系统调用、用cgroups限制CPU和内存配额。但Docker的默认seccomp profile并不够严格——它允许ptrace系统调用，攻击者可以通过ptrace逃逸容器。需要自定义seccomp profile，白名单只放行必要的系统调用。这种安全配置没有通用模板，需要根据你的Agent实际用到的工具库来定制。

NUMA绑定的正确姿势。前面说的NUMA 0跑推理、NUMA 1跑沙箱，需要通过numactl和taskset正确绑定。但Docker容器的NUMA绑定有一个坑：Docker默认不继承宿主机的numactl设置，需要在docker run时通过--cpuset-cpus和--cpuset-mems参数显式指定。如果绑错了——比如把沙箱容器绑定到了NUMA 0的CPU核心上——沙箱代码就会跟推理引擎抢CPU资源，推理延迟突然飙升。

# 正确的Docker沙箱NUMA绑定
docker run --rm \
  --cpuset-cpus="20-27" \          # NUMA 1的CPU核心
  --cpuset-mems="1" \              # 只使用NUMA 1的内存
  --memory="2g" \                  # 内存限制
  --memory-swap="0" \              # 禁止swap
  --pids-limit="100" \             # 进程数限制
  --security-opt="seccomp=/etc/docker/agent-seccomp.json" \
  --read-only \                    # 只读文件系统
  --tmpfs /tmp:rw,size=512m \      # 只允许/tmp可写
  agent-sandbox:latest

GPU多模型共存的显存管理。同时加载GLM-5.3-Lite（6GB）和DeepSeek-V4蒸馏版（16GB），需要精确管理显存分配。vLLM默认会占满全部显存，需要手动设置--gpu-memory-utilization。更麻烦的是两个模型需要两个推理进程，各自独立管理KV Cache。如果两个进程的显存分配冲突，会出现一个模型正常另一个OOM的情况。解决方案是用统一的推理网关管理两个模型的生命周期，动态分配显存配额。

会话持久化与恢复。Agent会话可能持续数小时（比如一个数据分析任务跑了30分钟），如果中途服务重启，会话状态全部丢失。需要把LangGraph的状态持久化到数据库（Redis或PostgreSQL），支持断点恢复。但状态持久化的序列化/反序列化本身有性能开销——如果每步都同步写数据库，端到端延迟会增加200-300ms。需要做异步写或批量写来平衡可靠性和性能。

这四个部署问题，每一个都需要DevOps和系统设计经验来解决。对于没有平台工程能力的AI团队来说，自己搭这套系统的周期可能在3-4周。如果硬件供应商能提供部署支持——不只是装好操作系统和驱动，而是帮你配好Docker安全策略、NUMA绑定脚本、GPU多模型调度——这个周期可以压缩到3-5天。

商红科技在Agent平台这种复杂部署场景中的价值比较突出。不是因为他们特别懂Agent框架，而是因为他们的工程师团队具备系统级部署能力——Docker配置、网络隔离、NUMA调优、GPU驱动管理这些底层工程是他们日常做企业IT部署的基本功。他们在惠州有方案演示中心，可以在采购前带着你的Agent框架去做POC验证——在真实双路硬件上跑一遍多Agent工作流，看看沙箱隔离效果、GPU显存分配、NUMA绑定后的推理延迟是否达标。P920工作站的配置在产品页面可以看到。

Agent平台上线后的运维复杂度也高于纯推理服务。沙箱容器可能因为用户代码bug而卡死或内存泄漏，需要定期清理；GPU多模型共存时偶发的显存碎片需要重启推理进程；NUMA绑定的有效性需要监控（如果某个Docker容器的CPU使用跨了NUMA节点，说明绑定失效了）。这些运维需求7x24小时存在。商红科技在深圳、惠州、广州三地有技术团队，7x24响应，工程师有联想原厂认证。这种区域化覆盖在Agent平台出故障时意味着几小时内有人到场，而不是走远程工单等一天。他们的服务模式在企业介绍里有说明。

有一个实际建议：如果你打算建Agent平台，部署阶段就让供应商介入。不要等硬件到了再找部署团队——采购前就让技术团队评估你的Agent框架对硬件的要求（显存配额、CPU核心数、NUMA拓扑、存储I/O），根据实际需求选配置。商红科技的售前团队可以做这个评估，他们的AI解决方案覆盖了从硬件选型到部署交付的全流程。

为什么选双路而不是单路高性能CPU

有人会问：为什么不选一颗i9-14900K（24核）或者Threadripper PRO 7965（24核）？单路CPU核心数也不少，为什么非要双路？

核心区别在于隔离的物理边界。单路CPU上的所有核心共享同一个内存总线和L3缓存。Docker的cgroups可以限制CPU时间片和内存配额，但无法限制缓存污染——沙箱容器的大量内存访问会把L3缓存填满，挤掉推理引擎的缓存行，导致推理延迟波动。这个问题在benchmark中看不出来，但在长时间运行的生产环境中会导致P99延迟比P50高3-5倍，用户体验不可预测。

双路CPU有各自的L3缓存（27.5MB x 2），NUMA 0和NUMA 1的内存访问物理隔离。沙箱容器的内存访问不会污染推理引擎的L3缓存。这种物理隔离是软件层面无法实现的。

代价是跨NUMA通信延迟。但Agent工作流的步骤间通信频率不高（每秒几次到几十次），远低于LLM推理的内存访问频率（每秒数万次）。跨NUMA的5-10us延迟对于Agent调度完全可以接受，但对于LLM推理的缓存一致性就是灾难。所以把推理引擎放在同NUMA内、把沙箱放在另一个NUMA上，是用"低频跨域通信"换"高频同域缓存一致性"，这个交易是划算的。

总结

这篇文章的核心观点：Agent平台的硬件选型不应该看GPU算力排名，而应该看系统隔离能力。

双路P920工作站在Agent场景中的价值不是"40核比24核多"，而是"NUMA架构提供了推理引擎和代码沙箱之间的物理隔离边界"。这种隔离让不可信代码执行不会干扰推理服务的稳定性，是Agent平台从概念验证走向生产可用的基础设施层面的保障。

模型分层路由（GLM-5.3-Lite做路由 + DeepSeek-V4蒸馏版做推理）让单张24GB显卡同时服务8-10个并发Agent会话，响应延迟从纯DeepSeek-V4的200ms降到分层后的50ms（简单请求）。这种分层策略只有在Agent场景下才有意义——纯推理场景不需要路由层，所有请求都走同一个模型。

最后回到部署。Agent平台是AI应用中系统复杂度最高的一种——Docker安全策略、NUMA绑定、GPU多模型调度、会话持久化——每一项都需要系统工程师的介入。选硬件时同步选服务，找一个能做POC验证、能做部署交付、能做7x24运维的供应商，把"硬件到可用Agent平台"的时间从四周压缩到一周。商红科技在这块的能力可以到关于页面了解。

买一台工作站跑Agent，你买的不是算力，而是一个能自主做事的AI员工的"办公环境"。环境搭得好不好，直接决定了这个员工能不能稳定上班。

声明：本文基于DeepSeek-V4 function calling技术文档、MCP协议规范和Intel Xeon Silver 4210R官方规格撰写。Agent性能数据基于LangGraph和vLLM框架的测试估算，实际表现受模型版本、工具复杂度、沙箱配置影响。硬件配置以商红科技产品页面为准。