Giraak Blog

终身强化学习中的灾难性遗忘：从 LAICA 到 Cal-LAICA

Thu, 20 Nov 2025 00:00:00 GMT

问题背景

在标准强化学习中，我们通常假设动作空间固定不变。但在现实场景中——机器人安装新关节、推荐系统上架新商品、软件添加新功能——动作集是持续变化的。传统 RL 算法每当动作集变化就需要从零训练。

这是终身强化学习（Lifelong RL） 要解决的核心问题。

L-MDP：建模变化动作集的数学框架

传统的 MDP 定义为 $M = (S, A, P, R, \gamma)$，其中动作集 $A$ 是固定的。论文提出的 L-MDP（Lifelong MDP） 扩展了这一框架：

$$ L = (M_0, E, D, F) $$

组件	含义
$M_0$	初始 MDP
$E$	潜在动作结构空间（所有可能动作的向量表示）
$D$	新动作的采样分布
$F$	新动作被添加的频率

核心假设：所有动作（当前的和未来的）都来源于一个更大的潜在结构空间 $E$，智能体只是逐步发现其中的部分动作。

LAICA 的核心机制：策略分解

LAICA（Lifelong Adaptation and Improvement for Changing Actions）的核心思想是将策略拆分为两个组件：

$$ \pi(a|s) = \sum_{\hat e} \beta(\hat e|s) \cdot \hat\phi(a|\hat e) $$

组件	作用	是否随动作集变化
$\beta(s, \hat e)$	决策组件：在潜在空间中选择动作类型	❌ 固定不变
$\hat\phi(\hat e, A)$	映射组件：将潜在动作映射到具体动作	✅ 随新动作更新

关键优势：$\beta$ 的参数维度不受动作集大小影响，旧知识完整保留。新动作加入时只需更新 $\hat\phi$。

两阶段学习

阶段	目标	优化对象	是否需要奖励
Adaptation（适应）	快速学习新动作结构	$\hat\phi$	❌ 无监督学习
Improvement（改进）	优化整体策略性能	$\beta$	✅ 策略梯度

Adaptation 阶段使用类似 VAE 的目标函数，通过逆动力学模型 $\phi(s, s') \to \hat e$ 和重建损失来学习动作嵌入，完全不依赖奖励信号，数据效率极高。

Cal-LAICA 的改进

Cal-LAICA 在 LAICA 基础上引入两项关键改进：

LAICA 的问题	Cal-LAICA 的解决方案
纯在线 RL，数据效率低	CQL（Conservative Q-Learning）离线预训练
Q 值低估，恢复缓慢	Cal-QL 值函数校准，确保新 Q 值不低于参考策略
无旧数据复用	OORB（Online-Offline Replay Buffer）统一数据收集

Cal-LAICA = LAICA + CQL + Cal-QL + OORB，在 MiniGrid 迷宫环境（256 动作空间，5 阶段动作集开放）中表现出显著优势。

灾难性遗忘缓解方法对比

在 LAICA 框架中引入额外缓解方法时，我们对比了三种经典方案：

EWC（Elastic Weight Consolidation）

$$\mathcal{L}_{EWC} = \frac{\lambda}{2} \sum_i F_i (\theta_i - \theta_i^*)^2$$

以 Fisher 信息矩阵衡量每个参数对旧任务的重要性
在训练新任务时对重要参数施加二次惩罚
优点：实现简单，无需存储旧数据
缺点：Fisher 估计的准确性影响效果

GEM（Gradient Episodic Memory）

$$\text{约束条件：} \langle g_{current}, g_k \rangle \geq 0 \quad \forall k$$

维护每个旧任务的少量样本（默认 128 条）
投影当前梯度到不增加旧任务损失的方向
优点：有理论保证
缺点：需要额外存储 memory buffer

PackNet

每个任务完成后执行 L1 全局剪枝
通过 gradient hook 冻结已训练权重
优点：完全隔离不同任务
缺点：网络容量被逐步消耗

方法	核心机制	存储开销	适用场景
EWC	Fisher 正则化	无	任务数多、存储受限
GEM	梯度投影	少量样本	需要理论保证
PackNet	剪枝 + 权重冻结	无（但消耗容量）	网络容量充足

理论保证

LAICA 的两个核心定理：

Theorem 1 — 性能上界： $$v^{\mu^}(s_0) - v^{\pi_k^}(s_0) \leq \frac{\gamma \rho \epsilon_k}{(1-\gamma)^2} R_{max}$$

当前策略与"上帝视角"策略的差距由动作集稀疏度 $\epsilon_k$ 决定。随着动作集逐渐覆盖 $E$，$\epsilon_k \to 0$，性能差距消失。

Theorem 2 — 近似误差： $$v^{\mu^*} - v^{\pi_k^{**}} \leq \frac{\gamma (\rho \epsilon_k + \delta_k)}{(1-\gamma)^2} R_{max}$$

LAICA 的额外误差 $\delta_k$ 来自 $\hat\phi$ 的映射近似。Adaptation 阶段的目标就是最小化 $\delta_k$。

关键局限

LAICA 依赖平滑性假设：相似的潜在动作产生相似的状态转移。当新动作与所有旧动作完全不相关时（例如编程平台上突然加入烹饪教程），LAICA 的性能会退化到近似从零开始训练的水平。

总结

LAICA 通过策略分解巧妙地将"变化动作集"问题转化为潜在空间中的固定维度学习问题，Cal-LAICA 进一步通过离线 RL 和值函数校准提升了数据效率。在实际应用中，应根据任务相似度、存储约束和网络容量灵活选择 EWC/GEM/PackNet 等辅助方法。

DQN 入门实践：用 PyTorch 从零实现深度 Q 网络

Fri, 20 Jun 2025 00:00:00 GMT

什么是 DQN？

DQN（Deep Q-Network）是 DeepMind 在 2013 年提出的算法，首次将深度学习与 Q-Learning 结合，在 Atari 游戏上达到人类水平。它用神经网络来近似 Q 值函数 $Q(s, a)$，解决了传统 Q-Table 无法处理连续/高维状态空间的问题。

整体架构

DQN 系统由五个核心模块组成：

┌─────────────┐    ┌──────────┐    ┌──────────────┐
│ Environment │───▶│  Agent   │───▶│ Q-Network    │
│ (Gymnasium) │    │ (ε-greedy)│   │ (3-layer MLP)│
└─────────────┘    └──────────┘    └──────────────┘
                          │
                   ┌──────▼──────┐
                   │   Memory    │
                   │ (Replay Buf)│
                   └─────────────┘

Environment：Gymnasium 标准环境（如 CartPole）
Agent：决策主体，使用 ε-贪婪策略
Q-Network：3 层 MLP 神经网络
Memory：经验回放缓冲区（Deque）

第一步：搭建 Q 网络

网络输入是状态（如 CartPole 的 4 维向量：位置、速度、角度、角速度），输出是每个动作的 Q 值：

import torch.nn as nn

class DQN(nn.Module):
    def __init__(self, input_size, hidden_size, output_size):
        super(DQN, self).__init__()
        self.fc1 = nn.Linear(input_size, hidden_size)
        self.fc2 = nn.Linear(hidden_size, hidden_size)
        self.fc3 = nn.Linear(hidden_size, output_size)

    def forward(self, x):
        x = torch.relu(self.fc1(x))
        x = torch.relu(self.fc2(x))
        return self.fc3(x)  # 输出层不加激活函数

对于 CartPole：

input_size=4（状态维度）
hidden_size=64
output_size=2（左/右两个动作）

第二步：经验回放与 ε-贪婪策略

经验回放缓冲区

from collections import deque
import random

class ReplayBuffer:
    def __init__(self, capacity=10000):
        self.buffer = deque(maxlen=capacity)

    def push(self, state, action, reward, next_state, done):
        self.buffer.append((state, action, reward, next_state, done))

    def sample(self, batch_size=32):
        return random.sample(self.buffer, batch_size)

    def __len__(self):
        return len(self.buffer)

为什么需要经验回放？

打破样本的时间相关性
每个经验可被多次使用，提高数据效率

ε-贪婪策略

epsilon = 1.0          # 初始 100% 随机探索
epsilon_min = 0.01     # 保持至少 1% 探索
epsilon_decay = 0.995  # 每次衰减 0.5%

def select_action(state):
    if random.random() < epsilon:
        return random.randrange(n_actions)  # 探索
    else:
        with torch.no_grad():
            return q_network(state).argmax().item()  # 利用

第三步：Q-Learning 更新

核心公式——Bellman 方程的增量形式：

$$Q(s, a) \leftarrow r + \gamma \cdot \max_{a'} Q(s', a')$$

在代码中：

def train_step(batch):
    states, actions, rewards, next_states, dones = batch

    # 当前 Q 值
    current_q = q_network(states).gather(1, actions)

    # 目标 Q 值（使用 target network 稳定训练）
    with torch.no_grad():
        next_q = target_network(next_states).max(1)[0]
        target_q = rewards + gamma * next_q * (~dones)

    # MSE Loss
    loss = nn.functional.mse_loss(current_q.squeeze(), target_q)
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()

关键超参数：

参数	值	说明
$\gamma$ (gamma)	0.99	折扣因子，值越高越看重长期回报
batch_size	32	每次训练的样本数
lr	0.001	Adam 优化器学习率
target_update	100 steps	Target Network 的同步频率

第四步：完整训练循环

for episode in range(n_episodes):
    state, _ = env.reset()
    total_reward = 0

    for step in range(max_steps):
        action = select_action(state)
        next_state, reward, done, _, _ = env.step(action)

        memory.push(state, action, reward, next_state, done)

        if len(memory) >= batch_size:
            train_step(memory.sample())

        state = next_state
        total_reward += reward

        if done:
            break

    epsilon = max(epsilon_min, epsilon * epsilon_decay)

从 CartPole 到更复杂的环境

这套框架的模块化设计让它很容易扩展到其他任务：

换环境：

env = gym.make('LunarLander-v2')    # 登月器
env = gym.make('Atari-Pong')        # 雅达利游戏

换网络（图像输入用 CNN）：

class CNN_DQN(nn.Module):
    def __init__(self):
        self.conv1 = nn.Conv2d(4, 32, 8, stride=4)
        self.conv2 = nn.Conv2d(32, 64, 4, stride=2)
        self.fc = nn.Linear(64 * 7 * 7, 512)

自定义奖励函数：

if distance_to_target < 0.1:
    reward = 100       # 到达目标
else:
    reward = -0.01     # 时间惩罚，鼓励快速完成

总结

DQN 将深度学习引入强化学习的核心创新在于两点：经验回放打破样本相关性，Target Network 稳定训练过程。从 3 层 MLP + CartPole 起步，理解 Q-Learning 和 Bellman 方程的本质后，逐步升级到 CNN + Atari 就是水到渠成的事。

KTransformers 多并发架构深度分析：与 vLLM / SGLang 的对比

Thu, 15 May 2025 00:00:00 GMT

背景

在大模型推理场景中，多并发能力直接决定了线上服务的吞吐上限。KTransformers 作为 DeepSeek 模型的开源推理框架，在 v0.2.4 版本引入了多并发支持。本文基于对 KTransformers 源码的深入分析，将其与 vLLM 和 SGLang 进行全面对比，找出瓶颈与优化方向。

KTransformers 的三层架构

KTransformers v0.2.4 的多并发架构分为三层：

层次	职责	技术实现
Server（服务层）	接收请求，提供 OpenAI 兼容 RESTful 接口	HTTP API
Scheduler（调度层）	C++ 实现的 FCFS 批次调度器，支持 continuous batching	C++ / FlashInfer
Inference Engine（推理引擎）	执行模型前向推理，chunked prefill	FlashInfer CUDA Kernels

关键配置参数：

--chunk_size：单次引擎调用处理的最大 token 数
--max_batch_size：单次引擎运行同时处理的最大请求数（仅 balance_serve 模式）
--cache_lens：全局 KVCache 空间大小，所有请求共享

核心瓶颈：Prefill 阶段并行度受限

社区实测反馈揭示了一个关键瓶颈：KTransformers 当前最多同时并发 2 个请求执行 Prefill。

这意味着 4 路并发时，只有两条请求的上下文同时加载到 KVCache，其余请求须排队等待。结果：

前两条请求较快获得解码结果
后两条请求首包延迟显著增加
GPU 计算资源未被充分利用

作者在 Issue 回复中确认："prefill 阶段并发数限制为最多 2 个……max_batch_size 只影响 decode 阶段，并不影响 prefill"。

相比之下，vLLM 默认开启 Chunked Prefill，优先安排解码请求，再将剩余算力用于新前缀填充；SGLang 的零开销调度器则能实现 CPU/GPU 异步重叠。

KV Cache 管理对比

特性	KTransformers	vLLM	SGLang
管理方式	全局共享 KVCache，固定大小	PagedAttention 分块管理	RadixAttention 前缀树
前缀重用	不支持	块级缓存重用	Token 级别前缀复用
内存效率	请求完成后才释放，易产生碎片	按需分配/释放	前缀共享，内存高效

KTransformers 的全局共享 KVCache 设计简洁，但缺少前缀重用机制使得多用户场景下各请求无法共享重叠部分，重复计算加剧了 GPU 内存和带宽压力。

调度策略对比

维度	KTransformers	vLLM	SGLang
调度算法	FCFS 批次调度	自适应动态批次，优先 Decode	零开销连续批次，CPU/GPU 重叠
Prefill/Decode 并行	串行为主，Prefill 最多 2 路	Chunked Prefill 交错执行	持续批次混合执行
多 GPU 并行	手动 `transfer_map` 层拆分	DP/TP/PP 支持	DP + EP + PD 分离

七大优化方向

提升 Prefill 并发度：取消或提高并行前填充限制
优化 Prefill/Decode 调度：借鉴 vLLM 的优先解码 + 余量填充策略
引入前缀缓存：参考 vLLM PagedAttention 或 SGLang RadixAttention
调整 Chunk 大小与批次策略：根据硬件带宽优化参数
改进多卡并行：引入自动张量并行/流水线并行
细粒度异步调度：参考 SGLang 的零开销调度设计
充分利用硬件特性：CUDA Graph、FP8/INT4 量化

总结

KTransformers 在多并发场景下的主要短板是 Prefill 并行度不足和 KV Cache 管理的简化设计。以 vLLM 和 SGLang 为代表的框架已在调度策略、前缀缓存、多 GPU 并行等方面积累了成熟方案。后续版本若能在这些方向持续优化，KTransformers 有望在高并发推理场景中实现更接近硬件带宽极限的吞吐表现。

LLM 基础设施安全：从 OWASP Top 10 到 CVE 漏洞实战

Fri, 02 May 2025 00:00:00 GMT

背景

随着 LLM 基础设施（Ollama、OpenWebUI、vLLM 等）的快速部署，安全问题日益突出。这些系统通常直接暴露 API 端点、运行在容器中、处理敏感数据，一旦存在漏洞，攻击者可能实现远程代码执行（RCE）、未授权数据访问甚至模型篡改。

本文是我在实际部署 DeepSeek 推理服务过程中梳理的安全学习路径，分为三个阶段：基础理论 → 漏洞实战 → 高级加固。

第一阶段：Web 与 API 安全基础

OWASP Top 10 — Web 安全的基石

在深入 LLM 专项安全之前，必须掌握 Web 应用安全的通用知识体系。OWASP Top 10 是最权威的 Web 安全风险清单，核心条目包括：

漏洞类型	描述	在 LLM 场景中的风险
SQL 注入	恶意 SQL 语句注入数据库查询	LLM 应用的用户输入可能被拼接到查询
XSS（跨站脚本）	注入恶意脚本到网页	OpenWebUI 等前端界面的输入框
CSRF（跨站请求伪造）	诱导用户执行非本意操作	API 调用缺乏 Token 验证
IDOR（不安全的直接对象引用）	通过修改 ID 访问他人资源	这正是 CVE-2024-7041 的原理
路径遍历	`../../etc/passwd` 访问系统文件	CVE-2024-37032 的核心漏洞
命令注入	注入系统命令到服务器	Ollama 的 API 参数可能被注入
不安全的反序列化	恶意对象注入内存	模型文件加载过程的潜在风险

API 安全基础

LLM 推理服务几乎全部通过 RESTful API 暴露能力，API 安全三要素：

身份验证（Authentication）：你是谁？→ API Key / JWT / OAuth
授权（Authorization）：你能做什么？→ RBAC / Scope 限制
速率限制（Rate Limiting）：你能调用多少次？→ 防止滥用和 DoS

OpenWebUI 默认情况下可以通过环境变量 WEBUI_AUTH=False 禁用身份验证，这在个人使用场景方便，但暴露到公网时极其危险。

第二阶段：漏洞发现与复现

CVE-2024-37032 — Ollama 路径遍历 RCE

漏洞概述：Ollama 的 API 端点存在路径遍历漏洞，攻击者可以读取服务器上的任意文件，进而在特定条件下实现远程代码执行。

影响版本：Ollama < 0.1.34

攻击原理：

GET /api/show HTTP/1.1
Host: target:11434
Content-Type: application/json

{
  "name": "../../../../etc/passwd"
}

Ollama 的模型加载逻辑未对模型名称中的路径分隔符做充分校验，导致攻击者可以遍历到系统敏感文件。

修复措施：

升级到 Ollama ≥ 0.1.34
不要将 Ollama 绑定到 0.0.0.0（监听所有接口），改为 127.0.0.1
在前端使用 Nginx 反向代理，增加路径规范化层

CVE-2024-7041 — OpenWebUI IDOR 漏洞

漏洞概述：OpenWebUI 的某些 API 端点未正确校验用户身份，攻击者可以通过枚举 ID 访问其他用户的聊天记录、模型配置等敏感数据（典型的 IDOR 漏洞）。

攻击原理：

GET /api/v1/chats/1001 HTTP/1.1
Host: target:8080
Authorization: Bearer <attacker_token>

即使 chat_id=1001 不属于当前用户，缺乏权限校验的端点仍会返回该聊天的完整内容——包括对话历史、Prompt 甚至 API Key。

修复措施：

每个 API 端点必须校验 owner_id == current_user.id
实现中间件级别的全局权限拦截
对敏感操作添加审计日志

漏洞复现环境搭建

# 拉取有漏洞的版本
docker pull ollama/ollama:0.1.33

# 在隔离网络中运行
docker run -d --name vuln-ollama \
  --network isolated \
  -p 11434:11434 \
  ollama/ollama:0.1.33

# 使用 OWASP ZAP 扫描
zap-cli quick-scan http://localhost:11434

第三阶段：高级漏洞利用与防御

容器安全

LLM 推理服务几乎全部依赖 Docker 部署，容器安全是最后一道防线：

风险	说明	缓解措施
以 root 运行	默认容器内为 root 用户	`USER 1000:1000` 切换为非 root
特权模式	`--privileged` 授予所有能力	从不使用，按需 `--cap-add`
挂载敏感路径	`-v /var/run/docker.sock:...`	禁止挂载 Docker Socket
未限制资源	无 CPU/内存限制导致 DoS	`--cpus=4 --memory=16g`

# 安全加固的 Ollama 部署
FROM ollama/ollama:latest
RUN useradd -m -u 1000 ollama && \
    chown -R ollama:ollama /home/ollama
USER ollama

模型完整性保护

模型文件的完整性直接决定推理结果的可信度：

文件哈希校验：下载模型后计算 SHA256，与官方发布值比对
签名验证：使用 GPG 签名确保模型来源可信（HuggingFace 已支持）
只读挂载：模型目录以 :ro 挂载，防止推理服务篡改模型权重

# 验证模型完整性
sha256sum deepseek-r1-q4_k_m.gguf
# 对比官方发布的 checksum
echo "expected_hash deepseek-r1-q4_k_m.gguf" | sha256sum -c

网络隔离架构

推荐的 LLM 服务部署拓扑：

Internet
  │
  ▼
┌──────────────┐
│  Nginx (TLS) │  ← 反向代理 + WAF 规则
│  :443        │
└──────┬───────┘
       │
  ┌────▼────────────────────┐
  │  OpenWebUI (内网)       │  ← 仅暴露前端
  │  http://127.0.0.1:8080  │
  └────┬────────────────────┘
       │
  ┌────▼────────────────┐
  │  API Gateway        │  ← 鉴权 + 限流
  │  (Auth + Rate Limit)│
  └────┬────────────────┘
       │
  ┌────▼────────────┐
  │  Ollama / vLLM  │  ← 仅监听 127.0.0.1
  │  127.0.0.1:11434│
  └─────────────────┘

关键原则：

API 推理服务永远不直接暴露到公网
每一层都有独立的鉴权
所有通信走 TLS

安全工具链

工具	类型	用途	适用阶段
OWASP ZAP	DAST 扫描器	自动扫描 Web 漏洞	阶段一、二
Burp Suite Community	拦截代理	手动构造/重放 HTTP 请求	阶段二
Postman	API 测试	探索 API 端点，编写自动化测试	阶段一、二
Nikto	Web 服务器扫描	快速检查 6700+ 已知风险	阶段二
Nmap	网络扫描	识别开放端口和运行服务	阶段二
Docker Bench Security	容器审计	检查 Docker 配置合规性	阶段三

快速安全评估脚本

#!/bin/bash
# LLM 基础设施快速安全检查

TARGET="localhost"

echo "=== 端口扫描 ==="
nmap -p 11434,8080,3000,443,80 $TARGET

echo "=== HTTP 头检查 ==="
curl -sI http://$TARGET:11434 | head -20

echo "=== OpenWebUI 认证检查 ==="
curl -s http://$TARGET:8080/api/v1/chats \
  -H "Authorization: Bearer invalid_token" \
  | grep -q "Unauthorized" && echo "✅ 需要认证" || echo "❌ 认证可能被绕过"

echo "=== Docker 安全审计 ==="
docker run --rm -it \
  --net host --pid host --userns host \
  -v /var/run/docker.sock:/var/run/docker.sock \
  docker/docker-bench-security | grep -E "WARN|CRITICAL"

学习路径总结

阶段一：基础理论（2-3 周）
├── OWASP Top 10 理解与练习
├── API 安全基础（AuthN / AuthZ / Rate Limit）
└── 工具熟悉（ZAP / Postman / Burp Suite）

阶段二：漏洞实战（2-3 周）
├── CVE-2024-37032 环境搭建与复现
├── CVE-2024-7041 手动漏洞利用
└── OWASP ZAP 自动化扫描

阶段三：高级加固（1-2 周）
├── Docker 容器安全配置
├── 模型完整性验证
├── 网络隔离架构设计
└── WAF 规则编写

总结

LLM 基础设施安全本质上仍是经典 Web 安全 + 容器安全的延伸，真正的风险往往来自部署便利性对安全性的妥协——为了快速启动而绑定 0.0.0.0、关闭认证、以 root 运行容器。安全加固的每一点都是对便利性的取舍，但在生产环境中，这个取舍不容妥协。

安全不是产品，而是过程。一次扫描通过不代表永远安全，持续监控和定期审计才是真正的防线。

MQL5 算法交易入门：用 Python 构建你的第一个交易机器人

Thu, 10 Apr 2025 00:00:00 GMT

前言

MetaTrader 5（MT5）是全球最广泛使用的交易平台之一，不仅支持手动交易，还提供了强大的算法交易（Algorithmic Trading）能力。通过 MT5 的 Python API（MetaTrader5 包），我们可以用 Python 构建自己的智能交易机器人（Expert Advisor, EA），实现自动化策略回测和实盘交易。

本文基于实际操作经验，系统梳理从环境搭建到完整 EA 框架的全流程。

环境与基础概念

EA 是什么？

EA（Expert Advisor） 是 MT5 中的智能交易系统，可以：

自动获取实时行情数据
根据预设策略自动开仓/平仓
管理止损止盈
7×24 小时无人值守运行

Python vs MQL5 原生语言

维度	Python API	MQL5 原生 (C++ like)
上手难度	低，Python 生态丰富	中，类 C++ 语法
数据科学能力	✅ pandas / numpy / sklearn	❌ 需自行实现
执行速度	慢（通过网络通信）	快（平台内部执行）
适用场景	研究、回测、中低频策略	高频策略、平台内运行

结论：研究和开发阶段用 Python，生产环境可考虑 MQL5 原生。

连接 MT5

import MetaTrader5 as mt5

if not mt5.initialize():
    print("MT5 初始化失败，请检查终端是否运行")
    quit()

print("MT5 连接成功")
# 显示账户信息
print(mt5.account_info())

# 结束时务必调用
# mt5.shutdown()

信息获取：读懂市场数据

MT5 Python API 提供了 8 个核心函数用于获取交易所需的各类信息。

1. 交易品种详情：`symbol_info()`

symbol = mt5.symbol_info("EURUSD")
print(f"点值: {symbol.point}")      # 最小价格变动单位 → 0.00001
print(f"当前点差: {symbol.spread}")  # 买卖价差 → 17点
print(f"小数位: {symbol.digits}")    # 报价小数位数 → 5
print(f"最小手数: {symbol.volume_min}")  # → 0.01

返回的 namedtuple 包含 80+ 字段，涵盖交易模式、隔夜利息、保证金要求等全部交易参数。

2. 历史 K 线：`copy_rates_from_pos()`

import pandas as pd

rates = mt5.copy_rates_from_pos("EURUSD", mt5.TIMEFRAME_H1, 0, 100)
df = pd.DataFrame(rates)
df["time"] = pd.to_datetime(df["time"], unit="s")  # 时间戳转换
df.set_index("time", inplace=True)

# 列：open, high, low, close, tick_volume, spread, real_volume
print(df.tail())

时间周期常量：

常量	含义
`mt5.TIMEFRAME_M1`	1 分钟
`mt5.TIMEFRAME_M5`	5 分钟
`mt5.TIMEFRAME_H1`	1 小时
`mt5.TIMEFRAME_D1`	日线

3. 实时报价：`symbol_info_tick()`

tick = mt5.symbol_info_tick("EURUSD")
print(f"买价(Bid): {tick.bid}")   # 可卖出的价格
print(f"卖价(Ask): {tick.ask}")   # 可买入的价格
print(f"最后成交: {tick.last}")
print(f"点差: {(tick.ask - tick.bid) / symbol.point:.0f} 点")

4. 账户信息：`account_info()`

account = mt5.account_info()
print(f"余额: {account.balance}")
print(f"净值: {account.equity}")       # 余额 + 浮动盈亏
print(f"已用保证金: {account.margin}")
print(f"可用保证金: {account.margin_free}")
print(f"杠杆: 1:{account.leverage}")
print(f"浮动盈亏: {account.profit}")

# 计算保证金使用率
margin_level = (account.equity / account.margin * 100) if account.margin > 0 else 0
print(f"保证金水平: {margin_level:.1f}%")  # <100% 时可能触发强平

5-6. 持仓与挂单

# 获取所有持仓
for pos in mt5.positions_get():
    direction = "多" if pos.type == 0 else "空"
    print(f"[{pos.ticket}] {pos.symbol} {direction} "
          f"手数:{pos.volume} 开仓价:{pos.price_open} "
          f"当前价:{pos.price_current} 盈亏:{pos.profit}")

# 获取活跃挂单
for order in mt5.orders_get():
    type_map = {2: "Buy Limit", 3: "Sell Limit", 4: "Buy Stop", 5: "Sell Stop"}
    print(f"[{order.ticket}] {order.symbol} {type_map.get(order.type, '?')} "
          f"挂单价:{order.price_open} 剩余手数:{order.volume_current}")

7. 历史订单：`history_orders_get()`

from datetime import datetime, timezone

# 获取过去 24 小时的历史订单
start = datetime.now(timezone.utc).replace(hour=0, minute=0, second=0)
end = datetime.now(timezone.utc)
history = mt5.history_orders_get(start, end)

for order in history:
    if order.state == 3:  # 已成交
        print(f"[{order.ticket}] {order.symbol} 成交价:{order.price_open}")

8. 全部可交易品种：`symbols_get()`

all_symbols = mt5.symbols_get()
forex_pairs = [s.name for s in all_symbols if s.name.endswith(('USD', 'EUR', 'GBP', 'JPY'))]
print(f"外汇品种数: {len(forex_pairs)}")

交易操作：从下单到平仓

市价单

def market_order(symbol, volume, order_type, sl=0, tp=0, deviation=20, magic=123456):
    """发送市价单"""
    tick = mt5.symbol_info_tick(symbol)
    request = {
        "action": mt5.TRADE_ACTION_DEAL,
        "symbol": symbol,
        "volume": volume,
        "type": mt5.ORDER_TYPE_BUY if order_type == "BUY" else mt5.ORDER_TYPE_SELL,
        "price": tick.ask if order_type == "BUY" else tick.bid,
        "sl": sl,
        "tp": tp,
        "deviation": deviation,       # 允许最大滑点（点数）
        "magic": magic,               # EA 标识符
        "comment": "Python EA",
        "type_time": mt5.ORDER_TIME_GTC,
        "type_filling": mt5.ORDER_FILLING_FOK,  # 全成交或取消
    }

    result = mt5.order_send(request)
    if result.retcode == 0:
        print(f"✅ 市价单成功 订单ID:{result.order}")
    else:
        print(f"❌ 下单失败: {result.comment}")
    return result

# 使用示例
market_order("EURUSD", 0.1, "BUY", sl=1.08000, tp=1.09000)

挂单与修改

def pending_order(symbol, volume, order_type, price, sl=0, tp=0):
    """下挂单"""
    request = {
        "action": mt5.TRADE_ACTION_PENDING,
        "symbol": symbol,
        "volume": volume,
        "type": order_type,  # ORDER_TYPE_BUY_LIMIT / SELL_LIMIT 等
        "price": price,
        "sl": sl,
        "tp": tp,
        "type_time": mt5.ORDER_TIME_GTC,
        "type_filling": mt5.ORDER_FILLING_FOK,
    }
    return mt5.order_send(request)

# 修改止损止盈
mt5.order_modify(ticket=123456789, sl=1.07500, tp=1.09500)  # ticket 为订单ID

取消挂单与平仓

# 取消挂单
mt5.order_cancel(ticket=987654321)

# 平仓（需要持仓的 ticket）
mt5.position_close(ticket=1122334455)

下单前校验

def safe_order(symbol, volume, order_type, sl=0, tp=0):
    """下单前先校验参数"""
    tick = mt5.symbol_info_tick(symbol)
    request = {
        "action": mt5.TRADE_ACTION_DEAL,
        "symbol": symbol,
        "volume": volume,
        "type": mt5.ORDER_TYPE_BUY if order_type == "BUY" else mt5.ORDER_TYPE_SELL,
        "price": tick.ask if order_type == "BUY" else tick.bid,
        "sl": sl,
        "tp": tp,
        "deviation": 20,
        "magic": 123456,
        "type_time": mt5.ORDER_TIME_GTC,
        "type_filling": mt5.ORDER_FILLING_FOK,
    }

    # 预校验
    check = mt5.order_check(request)
    if check.retcode != 0:
        print(f"⚠️ 订单校验失败: {check.comment}")
        return None

    # 校验通过，执行下单
    return mt5.order_send(request)

EA 完整框架

以下是一个可直接运行的 EA 模板，包含完整的生命周期管理：

import MetaTrader5 as mt5
import time
from datetime import datetime

class TradingBot:
    def __init__(self, symbol="EURUSD", magic=123456):
        self.symbol = symbol
        self.magic = magic
        self.running = False

    def initialize(self):
        """初始化：连接 MT5"""
        if not mt5.initialize():
            raise ConnectionError("MT5 初始化失败")

        account = mt5.account_info()
        print(f"✅ 已连接 | 账户:{account.login} | "
              f"余额:{account.balance} | 杠杆:1:{account.leverage}")

    def get_market_data(self):
        """获取市场数据"""
        tick = mt5.symbol_info_tick(self.symbol)
        rates = mt5.copy_rates_from_pos(self.symbol, mt5.TIMEFRAME_M5, 0, 20)
        return tick, rates

    def strategy(self, tick, rates):
        """
        策略逻辑 — 在这里实现你的交易策略
        返回: "BUY", "SELL", "HOLD"
        """
        # 示例：简单的均线交叉策略
        if len(rates) < 20:
            return "HOLD"

        ma5 = sum(r["close"] for r in rates[-5:]) / 5
        ma20 = sum(r["close"] for r in rates[-20:]) / 20

        if ma5 > ma20 * 1.001:   # 金叉
            return "BUY"
        elif ma5 < ma20 * 0.999:  # 死叉
            return "SELL"
        return "HOLD"

    def execute_trade(self, signal):
        """执行交易信号"""
        positions = mt5.positions_get(symbol=self.symbol)
        has_position = len(positions) > 0

        if signal == "BUY" and not has_position:
            self._market_order(mt5.ORDER_TYPE_BUY)
        elif signal == "SELL" and not has_position:
            self._market_order(mt5.ORDER_TYPE_SELL)
        elif signal == "HOLD" and has_position:
            pass  # 保持持仓

    def _market_order(self, order_type):
        tick = mt5.symbol_info_tick(self.symbol)
        request = {
            "action": mt5.TRADE_ACTION_DEAL,
            "symbol": self.symbol,
            "volume": 0.1,
            "type": order_type,
            "price": tick.ask if order_type == mt5.ORDER_TYPE_BUY else tick.bid,
            "deviation": 20,
            "magic": self.magic,
            "type_time": mt5.ORDER_TIME_GTC,
            "type_filling": mt5.ORDER_FILLING_FOK,
        }

        result = mt5.order_send(request)
        direction = "BUY" if order_type == mt5.ORDER_TYPE_BUY else "SELL"
        if result.retcode == 0:
            print(f"✅ [{datetime.now():%H:%M:%S}] 开仓 {direction} @ {tick.ask if order_type == mt5.ORDER_TYPE_BUY else tick.bid}")
        else:
            print(f"❌ 下单失败: {result.comment}")

    def run(self):
        """主循环"""
        self.running = True
        print("🚀 EA 已启动...")

        while self.running:
            try:
                tick, rates = self.get_market_data()
                signal = self.strategy(tick, rates)
                self.execute_trade(signal)
                time.sleep(1)  # 控制频率，避免过载
            except KeyboardInterrupt:
                self.stop()
            except Exception as e:
                print(f"⚠️ 运行异常: {e}")
                time.sleep(5)

    def stop(self):
        """清理与断开"""
        self.running = False
        mt5.shutdown()
        print("👋 EA 已停止")


if __name__ == "__main__":
    bot = TradingBot(symbol="EURUSD", magic=123456)
    try:
        bot.initialize()
        bot.run()
    except Exception as e:
        print(f"❌ 致命错误: {e}")
    finally:
        bot.stop()

MQL5 原生 EA 骨架

如果策略需要高频执行或部署到生产环境，可以参考 MQL5 原生的 EA 结构（类 C++ 语法）：

#property copyright "Your Name"
#property version   "1.00"

int OnInit()
{
    // 初始化：验证参数、设置指标
    return(INIT_SUCCEEDED);
}

void OnDeinit(const int reason)
{
    // 清理：删除图形对象、关闭文件句柄
}

void OnTick()
{
    // 核心逻辑 — 每个 tick 执行一次
    // 1. 获取行情
    // 2. 策略判断
    // 3. 执行订单
}

安全实践

先模拟后实盘：所有策略必须在模拟账户上验证
风险控制：
- 单笔最大亏损限制
- 每日最大亏损/盈利停止
- 保证金使用率监控
订单校验：下单前使用 order_check() 验证参数
异常处理：网络断开、MT5 崩溃等情况要有恢复机制
日志记录：每笔交易和异常都要记录，便于复盘

总结

MT5 的 Python API 为量化交易提供了完整的基础设施：8 个信息获取函数覆盖了行情、账户、持仓的全部数据需求，5 个交易函数实现了从下单到平仓的完整生命周期。在此基础上构建的 EA 框架可以快速迭代策略，同时保留向 MQL5 原生迁移的路径。

对于算法交易初学者，建议路径：Python API 回测 → 模拟账户验证 → 小资金实盘 → 策略优化/原生迁移。

DeepSeek-R1 在 Tesla T4 上的推理优化实践

Fri, 28 Mar 2025 00:00:00 GMT

背景

NVIDIA Tesla T4 是云端推理场景中广泛使用的 GPU，但其 Turing 架构（Compute Capability 7.5）不支持 vLLM 和 SGLang 等主流推理框架的优化方法。在将 DeepSeek-R1 部署到 T4 集群时，需要探索替代优化方案。

T4 的硬件约束

架构：Turing (SM 7.5)
显存：16 GB GDDR6
不兼容：vLLM / SGLang 的 FP8 和 FlashAttention 优化路径
可用方案：llama.cpp（支持 CUDA CC 5.0+）

七大优化方法

1. 模型量化（Quantization）

方法	描述	适用场景
PTQ（训练后量化）	降低权重和激活值精度，减小模型大小	快速部署，可能损失精度
QAT（量化感知训练）	训练过程中集成量化	资源允许微调时精度更高
预量化模型	从 HuggingFace 直接使用 GGUF 等量化版本	最实用的起步方案

GGUF 格式的量化模型配合 llama.cpp 是 T4 上的首选方案。

2. 剪枝与稀疏性

移除不重要的权重或连接来减小模型规模。但老旧的 Turing 架构缺少专用稀疏矩阵运算硬件，剪枝带来的速度提升有限。

3. 知识蒸馏

使用 DeepSeek R1 作为教师模型，训练更小的学生模型（如 DeepSeek-R1-Distill-Qwen 系列），在性能和资源占用间取得平衡。

4. llama.cpp

最推荐的方案。 llama.cpp 对旧 GPU 兼容性最佳，支持：

GGUF 多精度量化格式
CUDA 计算能力 5.0+
CPU-GPU 混合推理（部分层卸载到 CPU）

# T4 上的 llama.cpp 推理示例
./llama-cli -m deepseek-r1-q4_k_m.gguf \
  -ngl 20 \         # GPU 层数
  -c 4096 \         # 上下文长度
  -t 8              # CPU 线程数

5. 内核融合

将多个 GPU 操作合并为单个内核以减少 kernel launch 开销。需要深入 CUDA 编程和对 Turing 架构的特定知识。

6. CPU-GPU 混合推理

当模型超出 T4 16GB 显存时，使用 llama.cpp 将部分层卸载到 CPU 内存。虽然比纯 GPU 推理慢，但使超大模型的推理成为可能。

7. KTransformers 异构计算

利用 KTransformers 的 GPU/CPU 异构分配能力：

MLA 注意力（算术强度 ~512） → GPU Tensor Cores
MoE 专家模块（算术强度 ~0.075） → CPU（仅 6/160 专家被激活）

# KTransformers YAML 配置示例
- name: lm_head
  device: cpu
- name: moe_experts
  device: cpu
- name: attention
  device: cuda:0

方法选择决策树

模型是否适配 16GB 显存？
├── 是 → GGUF 量化 + llama.cpp（纯 GPU）
└── 否 → CPU-GPU 混合推理
    ├── 有 CPU 计算资源 → KTransformers 异构计算
    └── 接受性能损失 → 知识蒸馏到小模型

总结

在 T4 上部署 DeepSeek-R1 需要灵活组合多种优化手段。短期最优路径是 GGUF 量化模型 + llama.cpp；长期来看，KTransformers 的 GPU/CPU 异构计算 和 知识蒸馏 提供了更好的性能天花板。关键是理解每种方法的算力和内存权衡，根据实际负载选择合适的组合策略。