2026-05-14 20:49:18

多路径磁盘简介

普通的电脑主机都是一个硬盘挂接到一个总线上，这里是一对一的关系。如果某一处发生故障，可能导致整个网络瘫痪，我们称这个存储网络中存在单点故障。随着现代信息技术的发展，在IT基础设施运行过程中，对存储网络的安全性和稳定性要求越来越高。在存储网络中，为了避免单点故障，高可靠的存储网络除了对设备和器件做了冗余设计，同时通过多条冗余路径的互联来规避链路的单点故障。而到了有光纤组成的SAN环境，或者由iSCSI组成的IPSAN环境，由于主机和存储通过了光纤交换机或者多块网卡及IP来连接，这样的话，就构成了多对多的关系。也就是说，主机到存储之间的IO有多条路径可以选择，每个主机到所对应的存储可以经过几条不同的路径。利用冗余设计满足存储网络的高可靠性和高性能，就需要通过多路径技术来实现。这种冗余设计既能提高整个存储网络运行的可靠性，又能利用冗余设计达到更高的性能要求。

多路径磁盘（Multipath Disk）的主要作用是提供冗余和负载均衡，以提高存储系统的可靠性和性能。具体来说：

1. 冗余/高可用性：当服务器和存储设备之间存在多条物理路径（例如，通过多个HBA卡、交换机或控制器连接）时，多路径技术可以确保在一条路径发生故障时，自动切换到另一条可用路径，从而避免单点故障，保证业务连续性。

2. 负载均衡：多路径软件可以将I/O流量分散到多条路径上，从而提高整体的带宽和性能。有些多路径实现还支持动态负载均衡，根据路径的当前负载情况调整流量分配。

3. 路径管理：多路径软件可以检测路径的状态，并自动处理路径故障和恢复。当一条路径恢复后，它可以被重新加入使用。

4. 设备统一命名：通过多路径软件，操作系统可以看到一个统一的设备名（如/dev/mapper/mpathb），而不是多个独立的设备节点（如/dev/sdj、/dev/sdk等）。这简化了管理，因为无论使用哪条路径，都访问同一个存储设备。

5. 提高性能：通过并发使用多条路径，可以增加存储访问的带宽，特别是对于高I/O需求的应用程序。

在Linux中，多路径功能通常由device-mapper-multipath包提供，它创建了一个虚拟设备（在/dev/mapper下）来代表多路径磁盘。这样，上层应用（如LVM、文件系统等）就可以像使用普通磁盘一样使用多路径设备，而不必关心底层路径的变化。

在配置LVM时，必须使用多路径设备（如/dev/mapper/mpathb）作为物理卷，而不是使用单个路径的设备节点（如/dev/sdj）。这是因为如果使用单个路径设备，当该路径故障时，LVM将无法访问该物理卷，即使还有其他路径可用。而使用多路径设备，即使一条路径故障，多路径软件会自动切换到其他路径，LVM不会受到影响。因此，多路径磁盘在需要高可用性和高性能的企业级存储环境中非常重要。

多路径磁盘（Multipath I/O）的作用详解

一、核心作用：提高存储可用性和性能

1. 高可用性（故障切换）：以华为UltraPath为例

主要作用：防止单点故障
物理拓扑：
   服务器
     ├── HBA卡1 → 光纤交换机1 → 存储控制器A
     └── HBA卡2 → 光纤交换机2 → 存储控制器B
                  ↓
               同一存储LUN

• 路径冗余：提供多条物理路径访问同一存储设备

• 自动故障切换：当某条路径故障时，自动切换到正常路径

在单路径组网中，主机HBA或iSCSI启动器在链路断开时会进行一段时间的尝试重连（即防闪断机制，一般30秒或60秒），如果重连成功则I/O能够继续执行；而在多路径组网中，由于存在备用路径，所以通常会设置缩短HBA或iSCSI的重连时间，以使多路径软件能够快速感知I/O失败并切换路径，从而减小上层应用I/O阻塞的时间。

• 零中断访问：应用无感知的路径切换，保证业务连续性

UltraPath在路径故障时可以自动将I/O转移到其他可用路径，流程如下图所示：

1）应用向UltraPath生成的虚拟磁盘下发I/O；

2）UltraPath将I/O转发给一个path 1（即SCSI设备）；

3）路径故障导致该path 1上I/O失败；

4）UltraPath将I/O重新下发给另一个path 2；

5）path 2返回I/O成功； 

6）UltraPath向上层应用返回I/O成功。 

2. 负载均衡

I/O流量分发：
读取请求：path1 → path2 → path3 → path1...
写入请求：path2 → path3 → path1 → path2...

• 带宽聚合：多路径并发传输，提高吞吐量

• 性能优化：根据算法（RR、队列深度等）分配I/O请求

• 避免单路径瓶颈：防止单个HBA卡或端口成为性能瓶颈

3. 路径管理

• 路径检测：持续监控各路径健康状态

• 自动恢复：故障路径修复后自动重新启用

• 动态优化：根据路径性能动态调整流量分配

二、具体应用场景

场景1：SAN存储环境

# 典型SAN多路径配置
服务器：2个HBA卡 → 2台光纤交换机 → 存储双控制器
设备映射：
  /dev/sdc (HBA1 → 交换机1 → 控制器A)
  /dev/sdd (HBA1 → 交换机2 → 控制器B) 
  /dev/sde (HBA2 → 交换机1 → 控制器A)
  /dev/sdf (HBA2 → 交换机2 → 控制器B)
  
多路径聚合后：/dev/mapper/mpath0 (包含以上4条路径)

场景2：iSCSI多路径

# iSCSI多路径配置
服务器：2个网卡 → 2台交换机 → 存储双IP端口
路径：
  eth1 → 192.168.1.10 → LUN1
  eth1 → 192.168.2.10 → LUN1
  eth2 → 192.168.1.10 → LUN1
  eth2 → 192.168.2.10 → LUN1

三、技术优势对比

四、多路径软件实现

Linux常见多路径软件

1. DM-Multipath (device-mapper-multipath)

• RHEL/CentOS默认

• 配置简单，功能完善

• 商业软件

• 高级功能，厂商支持

• 虚拟化环境专用

• 与vSphere深度集成

工作模式对比

五、实际配置示例

Multipath安装与使用

linux中大多已经默认安装了multipath,只需设置开机启动即可.

systemctl enable multipathd.service

multipath.conf 配置详解

$multipath -T
defaults {
  verbosity 2
  polling_interval 5
  max_polling_interval 20
  reassign_maps "no"
  multipath_dir "//lib/multipath"
  path_selector "service-time 0"  #选择那一条路径进行下次IO操作
  path_grouping_policy "multibus" #路径组策略 
  uid_attribute "ID_SERIAL"
  prio "const"
  prio_args ""
  features "0"
  path_checker "tur"  # 决定路径状态的方法 
  alias_prefix "mpath"
  failback "immediate" #故障恢复的模式 
  rr_min_io 1000   # 在当前的用户组中，在切换到另外一条路径之前的IO请求的数目 
  rr_min_io_rq 1
  max_fds "max"
  rr_weight "uniform"
  no_path_retry "fail" #默认fail，在disable queue之前系统尝试使用失效路径的次数的数值 
  queue_without_daemon "no"
  flush_on_last_del "no"
  user_friendly_names "yes"
  fast_io_fail_tmo 5
  bindings_file "/etc/multipath/bindings"
  wwids_file "/etc/multipath/wwids"
  prkeys_file "/etc/multipath/prkeys"
  log_checker_err always
  all_tg_pt "no"
  retain_attached_hw_handler "yes"
  detect_prio "yes"
  detect_checker "yes"
  force_sync "no"
  strict_timing "no"
  deferred_remove "no"
  config_dir "/etc/multipath/conf.d"
  delay_watch_checks "no"
  delay_wait_checks "no"
  san_path_err_threshold "no"
  san_path_err_forget_rate "no"
  san_path_err_recovery_time "no"
  marginal_path_err_sample_time "no"
  marginal_path_err_rate_threshold "no"
  marginal_path_err_recheck_gap_time "no"
  marginal_path_double_failed_time "no"
  find_multipaths "on"
  uxsock_timeout 4000
  retrigger_tries 0
  retrigger_delay 10
  missing_uev_wait_timeout 30
  skip_kpartx "no"
  disable_changed_wwids ignored
  remove_retries 0
  ghost_delay "no"
  find_multipaths_timeout -10
  enable_foreign ""
  marginal_pathgroups "no"
}
 
# 后端设备(不包含以下设备节点)
blacklist {
  devnode "^sda"
  devnode "^hd[a-z]"
  devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
  devnode "^dcssblk[0-9]*"
  devnode "^(ram|zram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9]"
  devnode "^(td|hd|vd)[a-z]"
  devnode "^cciss!c[0-9]d[0-9]*"
}
  device {
    vendor "SGI"  #厂商名称，可通过multipath –v3获取到 
    product "Universal Xport"  #产品型号 
    getuid_callout "/sbin/scsi_id -g -u -s /block/%n" #获得唯一设备号使用的默认程序 
  }
  device {
          vendor "^DGC"
          product "LUNZ"
  }
  device {
          vendor "EMC"
          product "LUNZ"
  }
  device {
          vendor "DELL"
          product "Universal Xport"
  }
  device {
          vendor "IBM"
          product "Universal Xport"
  }
  device {
          vendor "IBM"
          product "S/390"
  }
  device {
          vendor "LENOVO"
          product "Universal Xport"
  }
  device {
          vendor "(NETAPP|LSI|ENGENIO)"
          product "Universal Xport"
  }
  device {
          vendor "STK"
          product "Universal Xport"
  }
  device {
          vendor "SUN"
          product "Universal Xport"
  }
  device {
          vendor "(Intel|INTEL)"
          product "VTrak V-LUN"
  }
  device {
          vendor "Promise"
          product "VTrak V-LUN"
  }
  device {
          vendor "Promise"
          product "Vess V-LUN"
  }
}
blacklist_exceptions {
  property "(SCSI_IDENT_|ID_WWN)"
}
devices {
  device {
    vendor "COMPELNT"
    product "Compellent Vol"
    path_grouping_policy "multibus"
    no_path_retry "queue"
  }
}
 
overrides {
  ...
}
 
multipaths {
  multipath {
    wwid "36000d3100366e6000000000000000021"   #磁盘的WWID 
    alias "k8sapp"
  }
  multipath {
    wwid "36000d3100366e6000000000000000020"
    alias "k8slog"
  }
}

多路径拓扑分析

# 查看详细路径拓扑
multipath -ll

输出示例：
mpathb (3600a0b80001234567890123456789012) dm-1 IBM,2145
size=100G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 2:0:0:1 sdc 8:32  active ready running
| `- 3:0:0:1 sde 8:64  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 2:0:1:1 sdd 8:48  active ready running
  `- 3:0:1:1 sdf 8:80  active ready running

路径状态解读：

• status=active：当前活动路径

• status=enabled：备用可用路径

• prio=50：优先级较高（主路径）

• prio=10：优先级较低（备路径）

六、企业级应用价值

业务连续性

• RTO（恢复时间目标）降低：路径切换秒级完成

• RPO（恢复点目标）保障：数据访问不中断

运维管理

# 在线维护示例
# 1. 更换HBA卡时
multipath -f /dev/mapper/mpath0  # 临时移除设备
# 更换硬件...
multipath -v2                     # 重新扫描识别
# 业务无感知完成维护

性能调优

# 多路径策略配置示例
/etc/multipath.conf:
  defaults:
    polling_interval     10
    path_selector        "round-robin 0"
    path_grouping_policy multibus
    rr_min_io            100
    rr_weight            priorities
    failback             immediate

七、与LVM结合的实践意义

存储虚拟化双层冗余

物理层冗余：多路径（多条物理路径）
逻辑层冗余：LVM镜像（多个PV镜像）
应用层：业务系统

配置最佳实践

1. 先配置多路径，后配置LVM

2. LVM只操作多路径设备（/dev/mapper/*）

3. 定期监控路径状态

总结

多路径磁盘的核心价值在于：

• 可靠性：消除单点故障，提供存储高可用

• 性能：聚合带宽，提升I/O吞吐量

• 可维护性：支持在线维护，降低运维窗口

• 可管理性：统一设备视图，简化存储管理

在企业级存储环境中，多路径是确保关键业务连续性和性能的基础必备技术，与LVM、RAID等技术协同工作，构建稳定可靠的存储架构。

参考：

• 华为多路径Ultrapath——原理篇
  

• 【linux】多路径|Multipath I/O 技术
  

• Multipath多路径管理基础介绍与安装配置使用
  

• 配置设备映射器多路径
  

• LVM卷在线扩缩容及常用操作
  

• fdisk/parted创建与删除分区
  

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