AnZhihe | 安志合修改

2026-05-05 20:50:03

从单机到多节点分布式推理部署，架构上最大的变化是从"单机多卡"的内部通信变成了"跨节点"的网络通信。核心在于如何配置分布式节点和并行策略。

核心架构变化：从TP到PP+TP

在单机多卡部署时，我们主要使用 张量并行（Tensor Parallelism，TP），它在单节点内通过高速总线（如NVLink）拆分模型权重，通信开销极低。

但在多节点场景下，跨节点的网络带宽远低于节点内总线，如果继续单独使用TP，大量的数据传输会成为性能瓶颈。因此，多节点部署的核心策略是 流水线并行（Pipeline Parallelism，PP）+ 张量并行（Tensor Parallelism，TP） 的组合。

• PP (Pipeline Parallelism, 流水线并行)：将模型的不同层切分到不同节点上。数据像一个流水线一样，在节点间依次处理。这能有效减少跨节点的数据传输量。

• TP (Tensor Parallelism, 张量并行)：在每个节点内部，继续将切分到的层（Layer）拆分到多张GPU上，充分利用节点内的高速互联。

简单来说，策略就是：节点之间用PP，节点内部用TP。一个部署任务的总GPU数 = PP大小 × TP大小。

分布式推理：vLLM 集成 Ray

使用vllm做分布式推理，目前主流方案是与 Ray 分布式计算框架集成，将 Ray 作为分布式执行的后端调度器。在多节点场景下，Ray 负责管理集群资源、在节点间协调任务，而 vLLM 则作为推理引擎运行在 Ray 的 Worker 上，利用 Ray 分配好的 GPU 资源进行模型推理 。这两者形成了一种“资源调度（Ray）+ 计算引擎（vLLM）”的经典协作模式。

以下是它们集成的分层架构示意图：

下面从具体的配置步骤展开，涵盖从 Ray 集群搭建到 vLLM 集成以及生产环境调优的完整流程。

第一步：搭建 Ray 集群

在启动 vLLM 服务之前，需要在所有节点上安装并启动一个 Ray 集群。这是多节点部署的前提条件 。

1. 安装 Ray：在所有节点上执行以下命令安装 Ray。

pip install "ray[default]"

2. 启动 Head 节点：在选为主节点（管理节点）的机器上执行。

ray start --head --port=6379

也可以指定其他端口，6379 是 Ray 的默认端口。执行成功后，终端会显示 Ray 集群的地址，类似 192.168.1.10:6379 。

3. 连接 Worker 节点：在其余所有的 Worker 节点上，执行以下命令连接到 Head 节点。将 <HEAD_NODE_IP> 替换为 Head 节点的实际 IP 地址。

ray start --address=<HEAD_NODE_IP>:6379

执行完这些步骤后，一个多节点的 Ray 集群就运行起来了，此时 vLLM 就可以接入并使用集群内的所有 GPU 资源。

第二步：集成与配置 vLLM

Ray 集群就绪后，只需在 Head 节点上正常启动 vLLM 服务，并通过关键参数指定使用 Ray 作为分布式执行后端。

2.1 核心启动命令与参数

以 Qwen3 模型部署为例，使用2个节点，每个节点配有4张GPU，部署Qwen3-32B模型。以下是一个生产环境级别的vLLM启动命令示例：

vllm serve /path/to/Qwen3-32B \
    --tensor-parallel-size 4 \            # 每个节点内使用4卡进行TP
    --pipeline-parallel-size 2 \          # 共有2个节点进行PP
    --distributed-executor-backend ray \  # 多节点必须使用Ray作为后端
    --max-model-len 8192 \                # 根据实际场景设置，过长会消耗大量显存
    --gpu-memory-utilization 0.90 \       # 保留部分显存余量
    --max-num-seqs 256 \                  # 控制并发量，避免OOM
    --trust-remote-code \                 # Qwen3需要此参数
    --enforce-eager \                     # 多节点复杂图下可能更稳定（可选）
    --swap-space 16 \                     # 设置CPU交换空间（单位：GiB）
    --api-key $YOUR_API_KEY               # 设置访问认证token
    --enable-auto-tool-choice \
    --tool-call-parser hermes \
    --reasoning-parser qwen3 \
    --disable-custom-all-reduce
    ......

2.2 关键参数详解

vLLM 在启动时会自动连接已经运行的 Ray 集群，无需额外指定 Ray 地址 。

第三步：生产环境网络通信及性能优化

在多节点、高性能生产环境中，网络通信往往是性能瓶颈。需要通过环境变量来精细控制底层通信库（如 NCCL）的行为，以确保数据能在节点间高速传输 。

建议在启动 vLLM 服务的 Head 节点上，预先设置以下环境变量：

环境变量可以在启动 vLLM 的终端中直接 export，或者将它们写入启动脚本的开头。例如：

# 设置 NCCL 超时时间，防止通信卡死
export NCCL_TIMEOUT=1800
# 设置共享内存大小，vLLM 会用到 /dev/shm 进行数据交换
export VLLM_SHM_SIZE=16GB

export NCCL_SOCKET_IFNAME=ib0
export NCCL_IB_DISABLE=0
export NCCL_DEBUG=INFO

vllm serve /path/to/Qwen3-32B \
    --tensor-parallel-size 4 \
    --pipeline-parallel-size 2 \
    --distributed-executor-backend ray \
    --trust-remote-code

生产环境重要配置及关键检查清单

1. 量化技术的应用：对于Qwen3-32B这样的模型，在生产环境中强烈建议使用量化版本（如FP8、AWQ、GPTQ）。例如，Qwen/Qwen3-32B-FP8 可以显著降低模型显存占用和跨节点通信的数据量，从而允许更大的并发度或更低的延迟。启动时需配合 --kv-cache-dtype fp8 和 --quantization fp8 等参数。

2. 性能调优测试：生产环境没有“一键最优解”。需要根据实际的请求流量、输入输出长度、SLA要求，对 TP 和 PP 的组合进行基准测试。例如，在8卡H100的节点上，对于Qwen3-32B，是选择 TP=8, PP=1（单节点）还是 TP=4, PP=2（双节点），需要通过压力测试来决定。

除了上述配置，在生产环境中还需要留意以下几点：

• 共享内存：确保所有 vLLM 容器或进程挂载了 /dev/shm（共享内存），并且大小足够（例如 16GB）。vLLM 在数据处理和进程通信中会大量使用共享内存 。在 Docker 或 Kubernetes 中，这通常需要显式配置。

• 环境一致性：确保所有节点上的 Python 环境、vLLM 版本、Ray 版本以及模型路径完全一致 。任何不一致都可能导致无法预料的错误。

• 权限设置：在 Kubernetes 等容器化环境中，可能需要为容器添加 IPC_LOCK 权限，以允许 Ray 和 vLLM 锁定内存中的页面，这对性能至关重要 。

• 监控与健康检查：利用 Ray 的仪表盘（默认在 Head 节点的 8265 端口）监控集群状态。同时，为 vLLM 服务配置健康检查端点（如 /health），以便于服务发现和自动恢复 。

使用vLLM + Ray 多节点多卡部署 DeepSeek 方案

生产环境部署概览

在开始之前，有几个关键点需要先明确：

1. 硬件假设：本次配置以 2 个节点、每个节点 4 张 Hopper 系列 GPU（如 H100）为例。这是 DeepSeek-V3.2 的常见部署场景。

2. 核心优化原则：对于 DeepSeek-V3.2，官方强烈推荐采用“数据并行 + 专家并行”（DP+EP）模式，而不是单纯的张量并行（TP）。因为其核心算子主要针对 TP=1 进行了优化，DP+EP 模式能避免因注意力头填充导致的性能开销，提供更优的吞吐量 。

3. 基础环境：请确保 Ray 集群已在所有节点上正确启动和配置，vLLM 将通过 --distributed-executor-backend ray 参数连接并使用该集群 。

1. 完整启动命令示例

以下命令需在 Ray Head 节点上执行。它将启动一个使用 2 个节点（共 8 张 GPU）、并启用工具调用和生产级性能优化的 DeepSeek-V3.2 服务。

# 设置访问 API 密钥 (推荐从环境变量读取)
export VLLM_API_KEY="sk-your-secret-production-token"

vllm serve deepseek-ai/DeepSeek-V3.2 \
    # 模型加载相关
    --model deepseek-ai/DeepSeek-V3.2 \
    --tokenizer-mode deepseek_v32 \
    --trust-remote-code \
    --dtype auto \
    --kv-cache-dtype fp8 \
    \
    # 并行策略相关 (核心: Ray + DP + EP)
    --distributed-executor-backend ray \
    --data-parallel-size 8 \
    --enable-expert-parallel \
    --tensor-parallel-size 1 \
    \
    # 工具调用相关
    --enable-auto-tool-choice \
    --tool-call-parser deepseek_v32 \
    --reasoning-parser deepseek_v3 \
    --chat-template /path/to/xxx_deepseek.jinja \ # 可选
    \
    # 性能与内存调优
    --max-model-len 8192 \
    --gpu-memory-utilization 0.90 \
    --max-num-seqs 256 \
    --enable-chunked-prefill \
    --enable-prefix-caching \
    \
    # 服务器及API配置
    --host 0.0.0.0 \
    --port 8000 \
    --served-model-name deepseek-v3-2 \
    --api-key $VLLM_API_KEY \
    --disable-log-requests

2. 参数分类详解

模型加载配置

这类参数确保 vLLM 能正确识别和加载 DeepSeek-V3.2 的特殊架构。

并行策略配置（多节点核心）

这是与单机部署最大的区别所在。采用 DP + EP + TP=1 的黄金组合。

为什么是 DP=8, EP=8, TP=1？
这相当于在 8 张 GPU 上创建了 8 个模型副本（DP），同时每个副本的 MoE 专家层也被分布到所有 8 张 GPU 上（EP），而每个 GPU 上的模型其他部分则独立运行（TP=1）。这种模式完美匹配了 DeepSeek-V3.2 的 MoE 架构，是官方推荐的服务模式 。

Each GPU holds a complete copy of the model but processes a different batch of data. This is the simplest and most common strategy.

Models with a Mixture-of-Experts (MoE) architecture contain many "expert" sub-models. Only a subset of these experts is activated to process each request. Therefore, these expert sub-models can be stored on different GPUs. When an inference workload requires a specific expert, the data is routed to the relevant GPU.

工具调用（Function Calling）配置

让模型具备使用外部工具的能力。

性能与内存调优

生产环境稳定性和效率的保障。

服务器及 API 配置

对外提供服务的关键设置。

3. 生产环境补充建议

• 客户端调用示例：当设置了 --api-key 后，客户端代码（如 Python）需要这样配置请求头：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("VLLM_API_KEY"), # 使用与服务端相同的 key
    base_url="http://<你的模型服务IP>:8000/v1"
)

在需要启用“思考模式”时，需通过 extra_body 传递参数，这与 DeepSeek 官方 API 略有不同 ：

response = client.chat.completions.create(
    model="deepseek-v3-2",
    messages=[{"role": "user", "content": "..."}],
    tools=[...], # 调用工具定义
    extra_body={"chat_template_kwargs": {"thinking": True}} # 关键点
)
# 获取思考内容：response.choices[0].message.reasoning

• 关于 DeepGEMM：DeepSeek 模型依赖 DeepGEMM 库进行高效的 MoE 和 MQA 计算。默认安装即可。如果在 H20 等特定 GPU 上遇到性能问题或过长的预热时间，可以尝试通过设置环境变量 VLLM_USE_DEEP_GEMM=0 来禁用它 。

• 监控与告警：结合 Prometheus 和 Grafana 监控体系，关注 vLLM 暴露的指标，特别是抢占次数（preemption count）。如果抢占频繁，说明显存不足，需调整 max_num_seqs 或 gpu_memory_utilization 。

参考：

• https://docs.vllm.ai/en/v0.5.1/serving/distributed_serving.html

• Deploy multi-node distributed inference services
  

• https://docs.vllm.com.cn/en/latest/configuration/optimization/#performance-tuning-with-chunked-prefill

• DeepSeek-V3.2 使用指南

• 常用AI模型介绍及多模型组合使用场景

• Docker部署bge-m3/bge-reranker模型

• vLLM 部署Qwen2.5 LLM & VLM 大模型

2026-04-28 10:59:03

DM8数据库的备份主要分为物理备份和逻辑备份两大类，两者适用的场景和命令不同。

• 物理备份：直接备份数据库的物理文件（如数据文件、日志文件等）。这种方式速度快，是保障数据安全最直接的手段，常用于全库级别的灾难恢复。

• 逻辑备份：使用 dexp 工具将数据库对象（如表、视图、存储过程等）的结构和数据导出为一个独立的文件。这种方式非常灵活，可以指定备份库、用户、模式或表，常用于数据迁移或特定对象的备份。

物理备份命令

物理备份分为冷备（数据库关闭）和热备（数据库运行中）两种。其中，热备需要提前开启数据库的归档模式。

1. 冷备（数据库关闭）

冷备需要在数据库服务关闭的状态下进行，操作简单，不需要开启归档。

使用 dmrman 命令行工具
进入达梦数据库安装目录的 bin 文件夹，执行 dmrman 命令进入交互界面，然后执行备份命令。

# 进入bin目录
cd /dm8/bin
# 执行dmrman
./dmrman

# 在RMAN交互界面中执行全量备份
RMAN> backup database '/dm8/data/DAMENG/dm.ini' full backupset '/dm8/backup/full_bak';

• 参数说明：

• /dm8/data/DAMENG/dm.ini：数据库实例配置文件路径，请根据实际路径修改。

• full：执行全量备份。

• backupset：指定备份集存放的目录。

2. 热备（数据库运行中）

热备在数据库运行时进行，不影响业务，但必须确保数据库已开启归档模式。

开启归档模式（SQL命令行）

在执行任何备份前，务必完成以下检查，否则备份可能失败或无法恢复。

-- 1. 将数据库切换至 Mount 状态
ALTER DATABASE MOUNT;
-- 2. 开启归档模式
ALTER DATABASE ARCHIVELOG;
-- 3. 添加本地归档目录（请替换 /dm8/arch 为实际路径，需要提前创建并授予 dmdba 用户读写权限。）
ALTER DATABASE ADD ARCHIVELOG 'DEST = /dm8/arch, TYPE = local, FILE_SIZE = 1024, SPACE_LIMIT = 2048';
-- 4. 切回 Open 状态
ALTER DATABASE OPEN;

-- 验证是否成功（返回 'Y' 表示成功）
SELECT ARCH_MODE FROM V$DATABASE;

• DEST 指定归档日志存放路径，请确保目录已创建且有写入权限。

使用 SQL 命令备份
归档开启后，可以在 disql 命令行工具中直接执行备份命令。

# 1. 登录 disql
cd /dm8/bin
./disql SYSDBA/SYSDBA@localhost:5236

# 2. 执行全量备份（备份集存至 /dm8/backup/full）
SQL> BACKUP DATABASE FULL BACKUPSET '/dm8/backup/full' COMPRESSED LEVEL 6;
# 说明：COMPRESSED LEVEL 6 为中等压缩，可节省磁盘空间 [citation:9]

# 3. 执行增量备份（基于上次全量备份，备份变化的数据）
# 增量备份命令会自动找到最近的基准备份
SQL> BACKUP DATABASE INCREMENT BACKUPSET '/dm8/backup/inc_20250326';

逻辑备份命令 (dexp)

逻辑备份使用 dexp 工具，数据库必须处于运行状态。dexp 支持四种级别的备份。

通用命令格式与参数：

./dexp USERID=<用户名>/<密码>@<IP>:<端口> DIRECTORY=<备份目录> FILE=<导出文件名> LOG=<日志文件名> <备份级别参数>

# 全库导出（一般用于迁移，生产环境频率较低）
./dexp SYSDBA/SYSDBA DIRECTORY=/dm8/backup/logic FILE=full_db.dmp LOG=full_db.log FULL=Y

# 关键表定时导出（例如每天凌晨导出核心业务表）
./dexp SYSDBA/SYSDBA DIRECTORY=/dm8/backup/logic FILE=order_table.dmp LOG=order_table.log \
TABLES="PROD.ORDER_TABLE,PROD.ORDER_DETAIL"

• USERID：连接数据库的认证信息，如果是本地数据库，@IP:端口 可以省略。

• DIRECTORY：指定备份文件存放的目录。

• FILE：指定导出的文件名。

• LOG：指定记录导出过程的日志文件。

生产环境备份方案选型

生产环境的首要原则是不影响业务，因此首选联机备份（热备）。针对不同场景，方案选择如下：

生产环境建议：以“每周一次物理全量热备 + 每天一次物理增量热备”为主，辅以“关键业务表每日逻辑导出”的双重保险策略 。

生产环境最佳实践建议

1. 备份集有效性检查：定期使用 dmrman 中的 CHECK BACKUPSET 命令验证备份集是否损坏。

2. 异地备份：生产环境的备份集务必通过脚本（如 rsync、scp）同步至另一台服务器或对象存储，防止物理硬件损坏。

3. 关键参数配置：

• COMPRESSED：备份时开启压缩（级别5-6），显著节省磁盘空间 。

• PARALLEL：多核服务器可设置并行度（如4或8），加快备份速度 。

常见生产环境报错及处理

备份恢复是数据库运维的“生命线”，建议在生产环境实施前，先在测试环境完整演练一遍备份和恢复流程。

参考：DM达梦数据库登陆方式及日常运维命令

2026-04-22 00:07:43

这三个参数都用于控制大模型输出的随机性和多样性，是调整模型行为最重要的超参数，但机制不同。简单理解：

• Temperature（温度）：控制概率分布的“陡峭”程度，影响整体随机性。

• Top-p（也称核采样）：限制候选词的累积概率范围，动态过滤掉极不可能的选项

• Top-k：截断采样策略，用于控制模型生成 token 时的候选词范围

Temperature（温度）

作用：控制输出分布的"尖锐度"

模型在生成每个 token 时，会先计算所有候选词的概率分布。Temperature 会对这个分布做如下变换：

P'(word) ∝ P(word)^(1/T)

Temperature 值 / 效果 / 适用场景

T = 0（或极低） — 始终选概率最高的词，输出完全确定 · 代码生成、数学计算、需要确定性答案的任务

T = 0.1~0.3 — 高度保守，几乎总是选最优解 · 事实问答、信息抽取、严格格式输出

T = 0.5~0.7 — 平衡随机性，主流默认值 · 通用对话、写作辅助、大多数场景

T = 0.8~1.0 — 明显增加多样性 · 创意写作、头脑风暴、角色扮演

T > 1.0 — 高度随机，可能产生无意义内容 · 艺术创作、探索性实验（不推荐日常使用）

本质： 低温度让分布更"尖锐"，高温度让分布更"平缓"。

Top_p（Nucleus Sampling / 核采样）

作用：动态截断低概率词

与 Temperature 固定缩放不同，Top_p 按概率从高到低累加，直到累计概率达到 p 值，只保留这些词，从保留的这些词中采样：

例如 top_p=0.9：
选词 A(40%) + B(30%) + C(20%) = 90% → 保留
词 D(10%) 被截断

Top_p 值 / 效果 / 特点

0.1 ~ 0.3 — 极度保守，只选最高概率词 · 类似低 temperature，但更动态

0.7 ~ 0.9 — 主流推荐值 · 在多样性和质量间取得平衡

0.9 ~ 0.95 — 允许更多低概率词 · 创意性更强，偶尔会跑偏

1.0 — 不做截断，等价于关闭 · 不推荐，可能采样到无意义词

优势： 比 Temperature 更"智能"——当模型很确定时自动收窄，不确定时自动放宽。

使用建议

通用原则

• 需要精确、低风险 → 低 temperature（0.1~0.3）+ 低 top-p（0.1~0.5）

• 需要创意、多样性 → 高 temperature（0.8~1.2）+ 高 top-p（0.9~1.0）

• 平衡模式（多数日常对话）→ temperature 0.7~0.8，top-p 0.9

常见场景推荐

通用默认配置

temperature = 0.7
top_p = 0.9

这是大多数 API 的默认值，适合 80% 的场景

注意事项

1. 不要同时设极值：T=0 + top_p=0.1 会导致输出极度单调

2. Temperature 优先调：多数情况下调 T 就够了，Top_p 保持 0.9 不动

3. 需要确定性时用 T=0：此时 Top_p 失效（贪婪解码优先）

4. 不同模型敏感度不同：同样参数在不同模型上效果可能差异较大

5. batch 生成时注意：同一 prompt 多次调用，参数相同也会得到不同结果

快速记忆

• Temperature → "敢不敢冒险"：越低越保守，越高越大胆

• Top_p → "备选池多大"：越低选择越少，越高越自由

• 两者配合 → T 定基调，Top_p 做微调

大模型 top_k 参数详解

在基于 Transformer 的大语言模型（如 GPT、LLaMA 等）文本生成中，top_k 是一个常用的采样参数，用于控制输出 token 的随机性和多样性。它直接限制了模型每一步可选的候选词范围。

1. 基本定义

top_k：在每一步生成时，只保留概率最高的 k 个 token，然后在这 k 个 token 中重新归一化概率并进行采样（或配合其他策略比如温度采样）。

• 如果 top_k=1，则退化为贪婪搜索，每次都选最高概率的 token。

• 如果 top_k 很大（比如等于词表大小），则等价于不做 top_k 过滤（仅靠温度等控制）。

注意：top_k 是一个“硬截断”机制——不考虑 k 个候选之外的所有 token，即使它们的概率也没有低到微不足道。

2. 工作原理示意

假设词表中有 10 个 token，模型原始输出的 logits（未归一化分数）经过 softmax 得到概率分布：
token: A B C D E F G H I J
prob: 0.3 0.2 0.15 0.1 0.08 0.05 0.04 0.03 0.03 0.02

设置 top_k=3：

1. 选择概率最高的 3 个 token：A(0.3), B(0.2), C(0.15)

2. 对这三个概率重新归一化（除以和 0.65）：
   A: 0.462, B: 0.308, C: 0.231

3. 根据这个新的分布随机采样得到下一个 token。

3. 常见使用场景

4. top_k 与 top_p 的区别

示例对比（依然用上面的概率分布）：

• top_k=3 → 固定 3 个候选

• top_p=0.6 → 从高到低累加概率：A(0.3) → B(0.5) → C(0.65) 超过 0.6，所以选中 A+B，候选池大小=2

实际建议：常同时使用 top_k 和 top_p，例如 top_k=50 + top_p=0.95，先按 top_k 截断，再按 top_p 过滤，可以使候选更加稳妥又不过于机械。

5. 与 temperature 的交互

• temperature 在 softmax 前对 logits 做缩放：低温度使概率分布更陡（偏向高概率 token），高温度使分布更平坦。

• top_k 作用于缩放后的概率分布。
  如果温度很低，原始概率已经尖锐，再应用 top_k 可能只剩下 1~2 个候选（近似贪婪）。
  如果温度很高，分布平坦，top_k 可以排除长尾中的极低概率词，防止生成完全随机的无意义内容。

常用组合：

• 创意写作：temperature=0.9，top_k=50，top_p=0.95

• 精确问答：temperature=0.2，top_k=10，top_p=0.9

• 完全确定性：top_k=1（忽略 temperature）

6. 优缺点分析

优点：

• 简单有效，能显著降低生成“无意义词”的概率。

• 计算成本低（只是截取前 k 个，重新归一化）。

• 直观易调：k 越大，多样性越高。

缺点：

• 固定大小的 k 不能适应不同分布形状。当概率质量异常集中时，k 个 token 中后面的 token 可能概率极低，仍会选到；当分布非常平缓时，k 个 token 会漏掉大量中等概率的合理词。

• 需要手动调整，不同任务最优 k 不同。

7. 实践建议

8. 库函数示例（HuggingFace transformers）

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("gpt2")
tokenizer = AutoTokenizer.from_pretrained("gpt2")

inputs = tokenizer("The quick brown fox", return_tensors="pt")
outputs = model.generate(
    **inputs,
    max_new_tokens=20,
    do_sample=True,      # 启用采样，否则 top_k 无效
    top_k=50,            # 只从概率最高的 50 个 token 中选
    top_p=0.95,          # 可选，配合使用
    temperature=0.8
)

9. 总结

• top_k 是控制生成多样性与连贯性的一个简单但强大的参数。

• 通过限制每一步的候选 token 数量，可以有效剔除极端低概率的无意义词。

• 与 top_p、temperature 组合使用可以更精细地调节输出质量。

• 没有绝对最优值，通常需要通过实验针对具体任务调参。

理解 top_k 的本质后，就可以根据模型行为（是否出现不合理 token、是否重复、是否缺乏创意）来快速调整该参数，并与其他采样策略配合达到最佳生成效果。

2026-04-19 21:39:24

Hermes Agent是个啥？

Hermes Agent 是 Nous Research（Hermes 模型背后的团队）开发的自改进（self-improving）AI Agent，核心创新在于内置学习闭环（closed learning loop）：

• 持久多层记忆：使用 SQLite + FTS5 全文搜索 + LLM 自动总结，跨会话永久记住你的偏好、风格和历史，不会“健忘”。

• 自动技能进化：任务完成后自动生成 Markdown Skill 文件，下次直接调用；还会自我迭代优化 Skill。

• 自主执行力：支持终端命令、浏览器、文件操作、代码生成、Web 搜索等工具，可在 CLI 或 Telegram/Discord 等平台运行。

• 模型超灵活：支持 OpenRouter（200+模型）、OpenAI、Anthropic、Nous Portal、本地 Ollama 等，几乎零切换成本。

• 完全开源免费：MIT 协议，可在 $5 VPS、本地、Docker、Modal 等环境运行。

简单说：普通AI是工具，Hermes是会自己进化的私人AI助手。用得越久，它就越像你的"数字分身"。

官方文档：https://hermes-agent.nousresearch.com/docs/

最近AI圈爆火的Hermes到底是什么？
OpenClaw vs Hermes：一文深入理解两大通用 Agent

安装

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# 安装完成后重载 shell：
source ~/.bashrc  # 或 source ~/.zshrc

2026-04-14 00:02:14

socat（SOcket CAT）是一个基于命令行的实用程序，其核心原理是在任意两个独立的数据通道之间建立双向传输的桥梁。它本身不解读或处理应用层协议（如HTTP），只是忠实地在指定的源和目的地之间转发原始字节流。这种"数据搬运工"的特性，使其成为构建轻量级网络代理的理想工具。有点类似于netcat (即nc命令)，nc是单纯面向网络的，而socat连接的更多。

socat安装

# CentOS/RHEL
yum install socat
# Debian/Ubuntu
sudo apt-get install socat
# macOS (Homebrew)
brew install socat

socat进阶配置

在实际使用时，为了让代理更稳定、安全，你还可以关注以下选项和要点：

• 基础命令格式：socat [options] <源地址> <目标地址>。

• 常用选项：

• -u 或 -U：设定数据流为单向（从源到目标或反之）。

• range=<ip-range>：限制允许连接代理的客户端IP范围，例如range=192.168.1.0/24。

• su=<user>：让socat进程以指定低权限用户（如nobody）运行，增强安全性。

• 启动与保持：

• 默认命令会在前台运行，按Ctrl+C终止。

• 如需在后台运行，可以在命令末尾添加 & 符号。

• 对于需要长期运行的代理，建议配合 systemd 或 supervisor 等进程管理工具使用。

socat使用场景

下面的表格总结了socat作为代理的几种常见用途、对应命令和典型场景：

使用参考：

• 官网：http://www.dest-unreach.org/socat/

• 使用示例：http://www.dest-unreach.org/socat/doc/socat.html#EXAMPLES

• socat(1) - Multipurpose relay (SOcket CAT)

• Getting started with socat, a multipurpose relay tool for Linux

• socat ，连接不同数据源的中继转发程序-腾讯云开发者社区-腾讯云

• Set Up a Basic TCP Proxy with socat

• SSH Access Proxy with Socat: A Practical Guide

• Access Proxy with Socat: Simplifying Network Access Control

• MVP Socat is the fastest way to move network data where you need it

• SOCAT as a Polymorphic Networking Tool | Cybrary

使用systemd、supervisor启动socat

使用 systemd 或 supervisor 来管理 socat 进程，能确保其稳定运行、开机自启和方便管理。下面分别是两种方式的配置示例。

方案一：使用 Systemd 托管

核心思路：将 socat 包装成一个系统服务。

1.创建服务文件
以用 socat 将本地 8080 端口转发到 192.168.1.100:80 为例，创建文件：

vim /etc/systemd/system/socat-proxy.service

2.写入配置
将以下内容写入上述文件，注意根据实际情况修改 ExecStart 命令和 User 等参数：

[Unit]
Description=Socat TCP Proxy (8080 -> 192.168.1.100:80)
After=multi-user.target
Requires=network.target

[Service]
Type=simple
# 以低权限用户运行，提升安全性（可选）
User=nobody
# 关键：此处替换为你的socat转发命令
ExecStart=/usr/bin/socat TCP4-LISTEN:8080,fork,reuseaddr TCP4:192.168.1.100:80
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=5
MemoryHigh=1G
MemoryMax=8G
LimitNOFILE=65536
LimitMEMLOCK=infinity
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

3.启用并启动服务

# 重载systemd配置
sudo systemctl daemon-reload
# 设置开机自启
sudo systemctl enable socat-proxy
# 立即启动服务
sudo systemctl start socat-proxy
# 查看服务状态和日志
sudo systemctl status socat-proxy
journalctl -u socat-proxy -f

方案二：使用 Supervisor 托管

核心思路：将 socat 作为由 supervisor 监控的常驻进程。

1.安装 Supervisor（以Ubuntu/Debian为例）

sudo apt update && sudo apt install supervisor

2.创建进程配置文件
以同样的转发任务为例，创建文件：

vim /etc/supervisor/conf.d/socat-proxy.conf

3.写入配置

[program:socat-proxy]
command=/usr/bin/socat TCP4-LISTEN:8080,fork,reuseaddr TCP4:192.168.1.100:80
autostart=true
autorestart=true
startretries=3
user=nobody
# 可选：指定工作目录
directory=/tmp
# 可选：重定向日志，方便排查
stdout_logfile=/var/log/supervisor/socat-proxy.log
stderr_logfile=/var/log/supervisor/socat-proxy-err.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=3

4.启用并启动进程

# 重载supervisor配置
sudo supervisorctl reread
sudo supervisorctl update
# 启动指定进程
sudo supervisorctl start socat-proxy
# 查看进程状态
sudo supervisorctl status socat-proxy

重要提示与建议

• 命令测试：在写入配置文件前，务必先在终端直接运行 socat 命令，确保其按预期工作。

• 路径确认：使用 which socat 确认 socat 的安装路径是否为 /usr/bin/socat，如果不是请在配置中修改。

• 选择依据：

• Systemd 通常是Linux系统首选，与系统集成度高，管理命令统一。

• Supervisor 更适合管理用户级、非系统服务，或者在一个系统上集中管理多个业务进程的场景，其Web界面有时更方便。

• 安全考虑：示例中使用了 User=nobody 来降低权限。如果你的转发涉及特权端口（如80、443），可能需要调整权限（如 setcap 或 authbind），但更推荐的做法是监听非特权端口（如8080），再用反向代理（如Nginx）转发。

两种方式都能很好地完成任务。通常，如果你的服务是系统基础服务的一部分，优先选用 systemd；如果是一个独立的用户应用进程，Supervisor 的进程管理界面可能更友好。

总结

socat是一个功能强大且灵活的"瑞士军刀"。它最适合用于快速搭建临时性代理、调试网络问题、跨协议中继或为简单服务增加SSL层。它的优点在于命令简单、无需复杂配置、资源占用少。

对于需要高性能、负载均衡、用户认证、复杂日志审计或长期稳定运行的生产级代理场景，socat可能不是最佳选择，而应选用专门的代理软件如Nginx、HAProxy等。

参考：Systemd 入门到精通：编写一个生产级的 Service 配置文件