Raspberry Pi 携手江波龙,推出自有品牌 A2 认证 MicroSD 存储卡

Raspberry Pi 当地时间昨日(2024/10/08)新闻博客,树莓派官方宣布推出自有品牌 MicroSD 存储卡,包含 32GB、64GB 和 128GB 三种容量,旨在 Raspberry Pi 生态用户提供高性价比选择

Raspberry Pi 携手江波龙,推出自有品牌 A2 认证 microSD 存储卡

Raspberry Pi SD Card 符合 SD 6.1 规范,可在 -25℃~+85℃ 下工作,拥有 C10、U3、V30 速度等级认证,在搭配 Raspberry Pi 5、使用 SDR104 总线速度模式时随机 4K 读写性能分别可达 5000 \ 2000 IOPS。

Raspberry Pi 官方表示,其在对可提升随机 I/O 吞吐性能的 SD 存储卡命令队列(CQ)模式进行兼容性验证时发现,部分第三方 A2 应用程序性能等级存储卡并未良好实现 CQ 模式,这成为 Raspberry Pi 推出第一方 A2 速度等级存储卡的动机。

Raspberry Pi 最终选择江波龙为第一方“经济高效”存储卡的 OEM 合伙伙伴。江波龙生产的这批存储卡通过了在重 I/O 负载下意外断电 1 万次的稳健性测试,并针对 Raspberry Pi 5 进行了优化。

Raspberry Pi SD Card 存储卡 32GB 款在合作伙伴处售价 9.95 美元(备注:当前约 70.1 元人民币),64GB 款则为 11.95 美元(当前约 84.2 元人民币)。

Raspberry Pi 本次还为 Raspberry Pi 5 推出了定价 3 美元(当前约 21.1 元人民币)的 Bumper 卡扣式硅胶底座,可保护单板计算机的底部和边缘。

参考链接


软考系列(系统架构师)- 2021年系统架构师软考案例分析考点

试题一 软件架构(架构风格、质量属性)

阅读以下关于软件架构设计与评估的叙述,在答题纸上回答问题1 和问题2。

【说明】

某公司拟开发-套机器学习应用开发平台,支持用户使用浏览器在线进行基于机器学习的智能应用开发活动。
该评台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程,采用自助方式进行智能应用设计、实现与部署,并可以开发新算法组件加入平台中。在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下:

  1. 平台用户分为算法工程师、软件工程师和管理员等三种角色,不同角色的功能界面有所不同;
  2. 平台应该具备数据库保护措施,能够预防核心数据库被非授权用户访问;
  3. 平台支持分布式部署,当主站点断电后,应在20 秒内将请求重定向到备用站点;
  4. 平台支持初学者和高级用户两种界面操作模式,用户可以根据自己的情况灵活选择合适的模式;
  5. 平台主站点宕机后,需要在15 秒内发现错误并启用备用系统;
  6. 在正常负载情况下,机器学习流程从提交到开始执行,时间间隔不大于5 秒;
  7. 平台支持硬件扩容与升级,能够在3 人天内完成所有部署与测试工作;
  8. 平台需要对用户的所有操作过程进行详细记录,便于审计工作;
  9. 平台部署后,针对界面风格的修改需要在3 人天内完成;
  10. 在正常负载情况下,平台应在0.5 秒内对用户的界面操作请求进行响应;
  11. 平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致;
  12. 平台提供机器学习算法的远程调试功能,支持算法工程师进行远程调试。

在对平台需求、质量属性描述和架构特性进行分析的基础上,公司的架构师给出了三种候选的架构设计方案,公司目前正在组织相关专家对平台架构进行评估。

问题:1.1    (9分)
在架构评估过程中,质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。 请将合适的质量属性名称填入图1-1中(1)、(2)空白处,并从题干中的(a)-(i)中选择合适的质量属性描述,填入(3)-(6)空白处,完成该平台的效用树。

图1-1 质量属性效用树
图1-1


问题:1.2    (16分)
针对该系统的功能,赵工建议采用解释器(interpreter)架构风格,李工建议采用管道过滤器(pipe-and-filter)的架构风格,王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景,从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析,并指出该平台更适合采用哪种架构风格。

【问题1】(9分)

在架构评估过程中,质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。 请将合适的质量属性名称填入图1-1中(1)、(2)空白处,并从题干中的(a)-(i)中选择合适的质量属性描述,填入(3)-(6)空白处,完成该平台的效用树。

图1-1
图1-1

【问题2】(16分)
针对该系统的功能,赵工建议采用解释器(interpreter)架构风格,李工建议采用管道过滤器(pipe-and-filter)的架构风格,王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景,从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析,并指出该平台更适合采用哪种架构风格。

试题二 系统开发(用例图、顺序图填空、模型对比)

某医院拟委托软件公司开发一套预约挂号管理系统,以便为患者提供更好的就医体验,为医院提供更加科学的预约管理。本系统的主要功能描述如下:
(a)注册登录,(b)信息浏览,(c)账号管理,(d)预约挂号,(e)查询与取消预约,(f)号源管理,(g)报告查询,(h)预约管理,(i)报表管理和(j)信用管理等。

问题:3.1    (6 分)
若采用面向对象方法对预约挂号管理系统进行分析,得到如图2-1所示的用例图。请将合适的参与者名称填入图2-1中的(1)和(2)处,使用题干给出的功能描述(a)~(j),完善用例(3)~(12)的名称,将正确答案填在答题纸上。

图2-1 用例图
图2-1


问题:3.2    (10分)
预约人员(患者)登录系统后发起预约挂号请求,进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息,在数据库中调用医生列表,并调取医生出诊时段表,将医生出诊时段反馈到预约界面,并显示给预约人员;预约人员选择医生及就诊时间后确认预约,系统反馈预约结果,并向用户显示是否预约成功。
采用面向对象方法对预约挂号过程进行分析,得到如图2-2所示的顺序图,使用题干中给出的描述,完善图2-2中对象(1),及消息(2)~(4)的名称,将正确答案填在答题纸上,请简要说明在描述对象之间的动态交互关系时,协作图与顺序图存在哪些区别。
图2-2 顺序图
图2-2


问题:3.3   (9分)
采用面向对象方法开发软件,通常需要建立对象模型、动态模型和功能模型,请分别介绍这3种模型,并详细说明它们之间的关联关系,针对上述模型,说明哪些模型可用于软件的需求分析?

(1)系统管理员 (2)患者 (3)(a)注册登录 (4)(c)账号管理 (5)(f)号源管理 (6)(h)预约管理 (7)(i)报表管理 (8)(j)信用管理号(4)~(8)答案可以互换 (9)(b)信息浏览 (10)(d)预约挂号 (11)(e)查询与取消预约 (12)(g)报告查询(9)~(12)答案可以互换

(1)预约人员(患者) (2)预约挂号请求 (3)显示医生可预约时段 (4)显示预约是否成功

顺序图强调的是消息的时间次序。
协作图强调的是发送和接收消息的对象之间的组织结构。

【问题3】(9分)
采用面向对象方法开发软件,通常需要建立对象模型、动态模型和功能模型,请分别介绍这3种模型,并详细说明它们之间的关联关系,针对上述模型,说明哪些模型可用于软件的需求分析?

试题三 嵌入式

阅读以下关于嵌入式数据架构设计的相关描述,回答问题1至问题3。
【说明】
数据架构(Data architecture)是系统架构设计的主要工作之一。它主要用于描述业务数据以及数据间的关系。数据架构着重考虑“数据需求”,关注的是持久化数据的组织。数据架构的设计过程主要包括:数据定义、数据分布与数据管理。某公司为了适应宇航装备的持续发展,提升本公司的核心竞争力,改变原来事件驱动的架构设计模式。公司领导将新产品架构规划工作交给张工。张工经过分析、调研给出了本企业宇航产品的未来架构规划方案。

【问题1】(9分)
张工在规划方案中指出:宇航装备要实现以数据为中心的架构设计模式,就应改变传统的各个子系统独立的设计方式,打破原宇航装备的生产关系。为了达到这个目标,我们首先要解决装备数据的共享、管理和存储等问题,做好顶层的数据架构规划工作。请用 300 字以内的文字说明数据定义、数据分布与数据管理的具体内涵。
【问题2】(7分)
张工在规划方案中提出公司未来产品设计要遵从一种开放式的架构体系,并在此基础上完善数据架构的设计工作,形成一套规格化的数据模型语言。张工给出了基于 FACE(Future Airborne Capability Environment) 架构的新产品架构,其中,图 3-1 说明了数据模型语言在架构模型中的作用。

图3-1 数据模型语言在架构模型中的作用

请根据你所掌握的数据架构的相关知识,从以下a~g中进行选择,填充完善 图 3-1 中的(1)~(7)空。
a.数据模型定义
b.平台数据模型(PDM)
c.UoP(Unit of Portability)数据模型(UM)
d.提炼
e.传输定义
f.代码和配置
g.概念数据模型(CDM)
【问题3】(9分)
“数据需求”是数据架构设计中需要着重考虑的问题。在张工给出的基于FACE架构的新产品架构中,分别就架构中的各个部分逐条给出了需求项。请判断 表3-1 给出的 9 项需求是否属于数据需求。

表 3-1 张工给出的需求项

试题四 数据库(反规范化设计方法、数据不一致、Redis 同步)

某医药销售企业因业务发展,需要建立线上药品销售系统,为用户提供便捷的互联网药品销售服务、该系统除了常规药品展示、订单、用户交流与反馈功能外,还需要提供当前热销产品排名、评价分类管理等功能。通过对需求的分析,在数据管理上初步决定采用关系数据库(MySQL)和数据库缓存(Redis)的混合架构实现。
经过规范化设计之后,该系统的部分数据库表结构如下所示。

供应商(供应商ID,供应商名称,联系方式,供应商地址);
药品(药品ID,药品名称,药品型号,药品价格,供应商ID);
药品库存(药品ID,当前库存数量);
订单(订单号码,药品ID,供应商ID,药品数量,订单金额)。

问题:2.1    (9分)
在系统初步运行后,发现系统数据访问性能较差。经过分析,刘工认为原来数据库规范化设计后,关系表过于细分,造成了大量的多表关联查询,影响了性能。例如当用户查询商品信息时,需要同时显示该药品的信息、供应商的信息、当前库存等信息。
为此,刘工认为可以采用反规范化设计来改造药品关系的结构,以提高查询性能。修改后的药品关系结构为:
药品(药品ID,药品名称,药品型号,药品价格,供应商ID,供应商名称,当前库存数量);
请用 200 字以内的文字说明常见的反规范化设计方法,并说明用户查询商品信息应该采用哪种反规范化设计方法。

问题:2.2    (9分)
王工认为,反规范化设计可提高查询的性能,但必然会带来数据的不一致性问题。请用 200 字以内的文字说明在反规范化设计中,解决数据不一致性问题的三种常见方法,并说明该系统应该采用哪种方法。

问题:2.3    (7分)
该系统采用了 Redis 来实现某些特定功能(如当前热销药品排名等),同时将药品关系数据放到内存以提高商品查询的性能,但必然会造成 Redis 和 MySQL 的数据实时同步问题。
(1) Redis的数据类型包括 String、 Hash、 List、 Set和 ZSet 等,请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
(2)请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。


【问题2】(9分)
王工认为,反规范化设计可提高查询的性能,但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中,解决数据不一致性问题的三种常见方法,并说明该系统应该采用哪种方法。

【问题3】(7分)
该系统采用了Redis来实现某些特定功能(如当前热销药品排名等),同时将药品关系数据放到内存以提高商品查询的性能,但必然会造成Redis和MySQL的数据实时同步问题。
(1) Redis的数据类型包括String、 Hash、 List、 Set和ZSet等,请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
(2)请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。

试题五 Web应用(云平台智能家居,看图填空,TCP/UDP 区别)

某公司拟开发一个智能家居管理系统,该系统的主要功能需求如下:

1)用户可使用该系统客户端实现对家居设备的控制,且家居设备可向客户端反馈实时状态;
2)支持家居设备数据的实时存储和查询;
3)基于用户数据,挖掘用户生活习惯,向用户提供家居设备智能化使用建议。

基于上述需求,该公司组建了项目组,在项目会议上,张工给出了基于家庭网关的传统智能家居管理系统的设计思路,李工给出了基于云平台的智能家居系统的设计思路。经过深入讨论,公司决定采用李工的设计思路。

问题:4.1    (8分)
请用400字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点,以说明项目组选择李工设计思路的原因。

问题:4.2    (12分)
请从下面给出的(a) ~ (j) 中进行选择,补充完善 图  5-1 中空 (1) ~ (6) 处的内容,协助李工完成该系统的架构设计方案。

(a) Wi-Fi
(b) 蓝牙
(c)驱动程序
(d)数据库
(e)家庭网关
(f)云平台
(g)微服务
(h)用户终端
(i)鸿蒙
(j)TCP/IP

图5-1 系统架构设计方案
图 5-1

问题:4.3    (5分)
该系统需实现用户终端与服务端的双向可靠通信,请用300字以内的文字从数据传输可靠性的角度对比分析TCP和UDP通信协议的不同,并说明该系统应采用哪种通信协议。

【问题1】(8分)
请用400字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点,以说明项目组选择李工设计思路的原因。

【问题3】(5分)
该系统需实现用户终端与服务端的双向可靠通信,请用300字以内的文字从数据传输可靠性的角度对比分析TCP和UDP通信协议的不同,并说明该系统应采用哪种通信协议。

参考链接


Raspberry Pi 配置成不间断电源 UPS 服务器

UPS (Uninterruptible Power Supply),是一种含有储能装置的不间断电源。主要用于给部分对电源稳定性要求较高的设备,提供不间断的电源。

一般的 UPS 都支持通过 USB 连接到电脑或者 NAS 等设备上,Linux/Mac/Windows 均支持使用 UPS。

因为电路不稳定,存在偶尔断电的情况,因此希望通过 UPS 保护树莓派、路由器、光猫、硬盘录像机等设备;将 UPS 通过 USB 接口连接到树莓派,由树莓派控制其他设备在断电时关机。

当前主要有两个方案,一个是 NUT(Network UPS Tools)  另一个是使用 apcupsd (Apcupsd UPS control software),两者二选一即可。

如果是群晖,可能只有使用 NUT(Network UPS Tools)  ,如果使用 U-NAS 可能只能使用  apcupsd (Apcupsd UPS control software)。

从配置简便性上,推荐  apcupsd (Apcupsd UPS control software)。

apcupsd 配置

图 1 施奈德后备式UPS电源APC BK650M2。
图 1 施奈德后备式UPS电源APC BK650M2。

虽然施奈德官方提供的 PowerChute 软件只支持 Windows 系统,但 Linux 下亦有 apcupsd 可以使用。该软件以守护进程的方式运行,通过串行数据通信的方式(串口或 USB )实时获取 UPS 电源信息,包括当前外部输入电压、负载功率、电池电量等。当电池电量低于指定值时,会自动运行脚本程序 /etc/apcupsd/apccontrol ,以实现电脑系统的自动关闭或任何用户指定的操作。

把 UPS 电源与电脑连好后,根据 apcupsd说明文档,我们首先使用 lsusb 命令检查 Linux 系统是否能检测到已连接的 UPS 电源。

确认能够找到设备后。

安装:

编辑 apcupsd 的配置文件 /etc/apcupsd/apcupsd.conf,将其中 UPSCABLEUPSTYPE 两项均设为 usb

因为台式机与 UPS 电源之间是通过 USB 通讯的,所以需要注释掉配置文件中的串口设置部分:

将 NISIP 值设为 0.0.0.0 或你想绑定的指定主机 IP

其余保持默认即可。

至此,可以启动 apcupsd 系统服务了。

该服务启动后,除了正常的 UPS 电源实时监测外,还会在本机的端口上开启一个服务器。我们可以在命令行终端使用apcaccess命令来获得电源的运行状态。其中的主要参数为:

  • LINEV:线电压

  • LOADPCT:负载占比

  • TIMELEFT:电池剩余维持时间

  • LOTRANS:最低容许输入电压

  • HITRANS:最高容许输入电压

  • BATTV:电池输出电压

  • NOMPOWER:额定功率

客户端配置:

安装:

打开 apcupsd 配置文件 /etc/apcupsd/apcupsd.conf

  • 将 UPSCABLE 值设为 ether
  • 将 UPSTYPE 值设为 net
  • 将 DEVICE 值设为你的 apcupsd 服务端地址和端口(也就是和 UPS 以 USB 相连接的主机)

与 NIS 相关的设置保持默认(也就是保持 NETSERVER 为 on

启动 apcupsd 服务,输入 apcaccess 命令,你应该能看到 apcupsd 输出电源信息。

NUT 配置

安装 NUT

NUT (Network UPS Tools) 是一种开源软件工具,其主要功能特点是实时监控与管理不间断电源(UPS)设备,支持多种通信协议,自动执行操作以应对电力故障,适用于多平台,并允许集中管理多个UPS设备,以确保与这些设备连接的计算机和设备在电力问题发生时能够继续正常运行或安全关闭。

NUT中的主要软件组件和功能:

  • Driver(驱动程序):NUT包括各种不同制造商的UPS设备的驱动程序,使NUT能够与多种型号的UPS设备通信。这些驱动程序负责与UPS设备建立连接,并获取有关电源状态、电池状态和其他参数的信息。

  • upsd(UPS守护进程):upsd是NUT的核心守护进程,负责与UPS设备通信,并将UPS状态信息提供给其他NUT组件和客户端。它可以通过网络协议(如SNMP、HTTP、XML-RPC等)向其他计算机提供UPS状态信息。

  • upsmon(UPS监控守护进程):upsmon监控守护进程用于监视UPS状态,并在检测到电力问题时执行操作。它可以配置为执行自定义脚本、关闭计算机或发送警报通知,以确保系统的连续性和数据完整性。

  • upslog(UPS事件记录器):upslog用于记录UPS事件和状态信息,以便后续分析和故障排除。它可以生成日志文件,其中包含UPS的运行历史和电力事件。

  • nutclient(NUT客户端工具):NUT提供了一些用于监控和管理UPS的命令行工具,例如upsc用于查询UPS状态,upscmd用于发送命令到UPS,以及upsrw用于修改UPS配置。

  • 安装

通过 USB 连接 UPS

在将 UPS 通过 USB 连接到树莓派后,可以通过查看 USB 设备进行检查

  • 检查 USB 连接

其中的 Device 003 就是 UPS,说明 USB 连接正常

  • 通过 nut-scanner 检查 UPS 设备

正确识别到连接的 UPS 设备,驱动为 usbhid-ups,产品为 SANTAK TG-BOX

或者如下:

配置 UPS

###配置 UPS 驱动

驱动程序负责与UPS设备建立连接,并获取有关电源状态、电池状态和其他参数的信息

  • 将 UPS 设备添加到 NUT

使用 nut-scanner 将连接的 UPS 信息追加到 /etc/nut/ups.conf 配置中,其中的 nutdev1 是设备的名称,可以自定义

  • 启动 NUT

使用 upsdrvctl 命令启动 NUT

配置 UPS 守护进程

upsd 负责与UPS设备通信,并将UPS状态信息提供给其他NUT组件和客户端

  • 启动 upsd

查看 UPS 状态

使用 upsc 命令查看 UPS 设备的状态;其中的 nutdev1 是 /etc/nut/ups.conf 中配置的名称

该命令会返回 UPS 设备的所有信息

也可以指定名称查看 UPS 状态

配置关机策略

配置 upsd 用户

upsd 用户对应的配置文件是 /etc/nut/upsd.users,配置用户用于读取 UPS的信息;在以下配置中,用户名是 upsmon,密码是 123456,运行模式是 master,即该设备为主节点(如果有同时使用其他 UPS则可以是 slave

  • 重启 upsd

配置关机策略

关机策略使用的是 upsmon,upsmon 监控守护进程用于监视UPS状态,并在检测到电力问题时执行操作,它可以配置为执行自定义脚本、关闭计算机或发送警报通知

  • 配置关机策略

修改 /etc/nut/upsmon.conf,添加如下配置,使用的是刚才创建的用户信息,这样,当设备监听到 UPS 发出的 LOWBATT 命令后,就会执行关闭系统

这个命令告诉NUT要监控名为 “ups” 的UPS设备,该设备位于本地主机上。监控用户 “monuser”,可以使用密码 “123456” 连接到NUT,并具有 “master” 角色的权限。这允许用户通过NUT连接来监视和管理UPS设备

  • 启动 upsmon

执行自定义动作

NUT 通过 upssched 支持监听 UPS 事件并执行指定脚本,因此可以用于执行一些自定义的动作,如发送通知等

配置 upsmon

修改 /etc/nut/upsmon.conf 文件,添加如下配置

  • 指定运行命令

该配置用于在发生事件时运行 /sbin/upssched 服务

  • 配置触发条件

这里监听了 ONLINEONBATT, 和 LOWBATT三个事件,分别是电源供电、电池供电和低电量事件;SYSLOG声明记录事件日志到系统中,WALL声明通知所有在线用户,EXEC 声明需要执行命令

配置 upssched

配置好 upsmon 后,还需要配置 upssched 执行相关的命令,需要将以下内容添加到 /etc/nut/upssched.conf 中

  • 配置 upsmon

CMDSCRIPT 指定了监听到事件后需要执行的脚本 PIPEFNLOCKFN指定了监听事件的管道并加锁,避免被修改 AT 和 EXECUTE 指定了监听的事件并执行相关的脚本;当监听到 ONBATTONLINE 和 LOWBATT 时执行 CMDSCRIPT指定的脚本,并将 battery_onpower_online 和 low_battery作为参数 AT 和 START-TIMER 启动了一个计时器,在 60s 后执行 AT 和 CANCEL-TIMER 指定如果在启动计时器60s 内发生了 ONLINE事件,则取消计时器

  • 配置 upssched-script.sh

这段脚本用于接收事件,并执行动作;这里通过 Bark 发送了通知

记录 UPS 日志

ups 支持通过 upslog 记录 UPS 日志

这段命令中,通过 -l指定了输出文件为 /var/log/ups.log-i 1 表示1s输出一次,-s ups@localhost指定了 UPS 位置,-f 指定了日志输出格式

输出日志参考:

配置 UPS 监控

NUT 支持通过 HTTP 接口对外提供 UPS 的信息,因此可以用于监控 UPS; https://github.com/helloworlde/nut_exporter 提供了 Prometheus Exporter,可以使用 Prometheus 和 Grafana 对 UPS 进行监控

修改 NUT 运行模式

配置文件是 /etc/nut/nut.conf;将模式修改为 netserver的目的是允许通过局域网访问 UPS 的设备信息,用于其他设备监控、监听 UPS 的状态;如果不需要监听则不需要配置

配置 upsd

修改 upsd 对应的配置文件 /etc/nut/upsd.conf,添加监听的地址和端口;添加局域网 IP 是用于局域网内其他设备进行监控,否则可能会拒绝连接

  • 重启 upsd

配置 NUT Exporter
  • 配置 docker-compose.yaml

  • 配置 .env

Server 的地址即为树莓派局域网的IP地址,用户名和密码是 upsd 的用户和密码;NUT_EXPORTER_VARIABLES是需要抓取的监控指标类型,不同的设备可能指标不一样;可以通过 upsc ups@localhost 获取所有的指标名称进行替换

  • 配置 Prometheus

  • 配置 Grafana 面板

导入 https://github.com/helloworlde/nut_exporter/blob/master/dashboard/dashboard.json 即可

参考链接


ZipCrypto算法回顾

ZipCrypto,也称为 PKZIP Stream Cipher,是一种弱加密手段,在1994年就已经被攻破,该加密方式不能经受已知明文攻击(Known Plaintext Attack,KPA)。

明文攻击主要利用大于 12 字节的一段已知明文数据进行攻击,从而获取整个加密文档的数据。也就是说,如果手里有一个未知密码的压缩包和压缩包内某个文件的一部分明文(不一定非要从头开始,能确定偏移就行),那么就可以通过这种攻击来解开整个压缩包。比如压缩包里有一个常见的 license 文件,或者是某个常用的 dll 库,或者是带有固定头部的文件(比如 xml、exe、png 等容易推导出原始内容的文件),那么就可以运用这种攻击。

Biham和Kocher文中回顾了PKZIP Stream Cipher加密解密过程。

原始论文链接: A Known Plaintext Attack on the PKZIP Stream Cipher

本站链接: A Known Plaintext Attack on the PKZIP Stream Cipher

首先,文件压缩后形成压缩包,PKZIP在压缩包中每个文件头部加上12字节的文件头,用于随机化,也用于在解密时识别错误的密钥,然后该文件头和文件内容一起进行加密。

加密过程如下:

  • 首先初始化,key为用户输入的二进制的密钥序列。key0,key1,key2为三个全局变量,在加/解密每个字节时都会用到。小写L表示第L个字节

Update_keys()函数定义如下,输入为一个字节。

  • 然后就是加文件头,开始加密。Pi代表明文第i字节

解密过程如下:

  • 首先初始化,和加密过程初始化完全相同
  • 然后解密,Ci代表加密的内容。解密后P1-P12是文件头,仅留作校验,解密后不再需要

附上一段代码,实现PKZIP解密,加密类似。

总结:PKZIP Stream Cipher是一种按照文件顺序、逐个字节进行加密/解密的算法。实际使用中,还需要注意到每遇到一个压缩包内的文件,就会从头进行一遍加密/解密过程。实现一个已知密钥zip archive的解密还需要了解ZIP格式等问题,这里就不再赘述了。

参考链接


chrome浏览器如何跟踪新开标签的网络请求?

调试前端页面的时候,有时候会遇到点击弹窗后从另外一个标签页打开页面的情况,这个时候如果手工去打开调试工具,页面加载之前的网络接口调用就追踪不到了,这个问题查询了一下,从 Chrome 50 版本开始支持页面跳转调试器自动跟踪。只是默认情况下,此功能没有开启,需要手工开启此功能。

具体开启此功能的操作如下:

1. 打开浏览器控制台(F12)/开发者工具

2.使用三点菜单(F1,控制台右上角X号旁边的那个按钮打开 setting 栏)

继续阅读chrome浏览器如何跟踪新开标签的网络请求?

TLS 加速技术:Intel QuickAssist Technology(QAT)解决方案

本文介绍了 Intel QAT 技术方案,通过 Multi-Buffer 技术和 QAT 硬件加速卡的两种方式实现对 TLS 的加速

一、背景

当前 TLS 已经成为了互联网安全的主要传输协议,TLS 带来更高的安全性的同时,也带来了更多的性能开销。特别是在建连握手阶段,TLS 的 CPU 开销,相对于 TCP 要大很多。

业界在优化 TLS 性能上已经做了很多软件和协议层面的优化,包括:Session 复用、OCSP Stapling、TLS1.3等。然而在摩尔定律"失效"的今日,软件层面的优化很难满足日益增长的流量,使用专用的硬件技术卸载 CPU 计算成为目前通用的解决方案。本文将介绍 Intel 在 TLS 加速领域提供的 QAT 技术方案。

二、Intel QuickAssist Technology(QAT)技术方案

Intel 提供了 TLS 异步加速的完整解决方案: Intel QuickAssist Technology(QAT),简称 Intel QAT 技术。

如下图所示,QAT 支持加速的密码算法覆盖了 TLS 的整个流程,包括:握手阶段的签名、秘钥交换算法,数据传输的 AES 加解密算法等。

图1. QAT 对TLS流程的密码算法的支持
图1. QAT 对 TLS 流程的密码算法的支持(图片来源

QAT 提供了对称与非对称两类密码算法的支持,主要包括:

  1. 非对称加密算法:RSA, ECDSA, ECDHE
  2. 对称加密算法:AES-GCM(128,192,256) 

注:QAT 加速的优势主要体现在非对称加密上,从官方的整体性能数据看,非对称算法性能提升 1.6~2 倍,对称算法性能提升 10%~15%

2.1 QAT Engine 软件栈

QAT Engine 是 QAT 技术方案的核心模块,主要的作用是作为应用程序和硬件之间的中间层,负责 “加解密操作的输入输出数据” 在用户应用程序与硬件卡之间进行传递,主要操作就是IO的读写。

QAT Engine 是以 OpenSSL 第三方插件的方式提供给用户,这个意味用户可以使用 OpenSSL 标准的 API,就可以实现对 TLS 的加速,只需要对原有代码做 OpenSSL 异步改造,就可以享受 QAT 技术带来的 TLS 性能加速,业务侵入性较小。

图2. Intel QAT Engine 软件栈
图2. Intel QAT Engine 软件栈(图片来源

如上图所示,QAT  Engine 支持两种加速方式:

  • 软件加速(qat_sw):使用 Multi-Buffer (SIMD)技术,对密码算法进行并行处理优化。
  • 硬件加速(qat_hw):使用 QAT 硬件加速卡,将密码算法计算从 CPU OffLoad 到硬件加速卡。

下面将介绍软件和硬件两种加速路径的实现方式。

三、软件加速:采用 Intel Multi-Buffer 技术

Intel 从 Whitely 平台开始加入了新的指令集,结合 Intel Multi-Buffer 技术,实现对密码算法的 SIMD 优化方案。

3.1 Intel Multi-Buffer 技术

Intel Multi-buffer 基本原理就是使用 CPU 的 SIMD 机制,通过 AVX-512 指令集并行处理数据,来提升RSA/ECDSA算法性能。

  • SIMD (Single Instruction Multiple Data) 即单指令流多数据流,是一种采用一个控制器来控制多个处理器,同时对一组数据(又称“数据向量”)中的每一个分别执行相同的操作从而实现空间上的并行性的技术。简单来说就是一个指令能够同时处理多个数据。
  • Multi-Buffer 技术基于 SIMD AVX-512 指令集,通过队列和批量提交策略,结合 OpenSSL 的异步能力,每次可以最多并行处理8个密码算法操作。

Intel 的 Multi-Buffer 方案,实际上是对应 Intel 两个开源工程( Multi Buffer 技术实现的通用密码算法底层lib库),集成在 QAT Engine 里,从而实现软件加速。

图3. Intel Engine集成了基于Multi-Buffer技术的密码算法lib
图3. Intel Engine集成了基于Multi-Buffer技术的密码算法lib

1、IP SEC lib

2、IPP CRYPTO lib

简而言之,QAT 的软件加速的本质就是通过 AVX-512 指令集进行并行处理优化,针对并发场景性能有显著提升(下文有针对 Multi-Buffer 优化场景的性能测试)。

四、 硬件加速:采用QAT硬件加速卡卸载

除了通过 Multi-Buffer 技术进行软件加速外,QAT Engine 还支持 QAT 硬件加速卡,通过将密码算法的计算卸载(OffLoad)到硬件加速卡,实现性能加速。

硬件加速核心是将 TLS 中的非对称加解密操作剥离出来,放到硬件加速卡里计算,即解放了 CPU,同时专用的硬件加速卡也提供了更高的加解密性能,这是典型的硬件 OffLoad 技术方案。

下图为典型的 Nginx+ Intel QAT Software Stack + QAT 硬件加速卡的典型应用场景:

图4.  nginx+ Intel QAT Software Stack + QAT硬件加速卡的典型应用场景
图4.  Nginx+ Intel QAT Software Stack + QAT 硬件加速卡的典型应用场景(图片来源)(本站链接)

这个典型应用场景包括四个部分:

  1. Nginx (Async Mode):  Intel 基于官方 Nginx(Version 1.18)提供了 Patch,支持 Nginx 工作在 OpenSSL 的异步模式。Patch开源在:https://github.com/intel/asynch_mode_nginx
  2. OpenSSL(支持Async Mode):  OpenSSL-1.1.1 新增了 async mode 特性,应用层软件可以通过标准的 OpenSSL 接口,实现异步调用,提升性能。
  3. QAT Engine:   OpenSSL Engine 插件。向下和 QAT API 交互,将处理请求提交给硬件。详见项目开源地址: https://github.com/intel/QAT_Engine
  4. QAT Driver:QAT 加速卡的驱动程序。分为用户态和内核态两个部分。用户态的 LIB 库提供 QAT API,内核态的driver则直接和 QAT 硬件加速卡打交道。

Intel QAT 依赖了 OpenSSL 的两个特性 OpenSSL Async Mode 和 OpenSSL Engine:

  • OpenSSL Async Mode 能够在 async_job 执行过程中,在等待加速卡结果的时候,将 CPU 让出去;如果没有开启 async 模式,调用 OpenSSL 函数会阻塞,CPU 会阻塞等待。
  • OpenSSL Engine 则是提供了自定义注册加解密的方法,可以不使用 OpenSSL 自带的加解密库,指定调用第三方的加解密库。

基于两个特性,应用程序的加解密操作只需要保持使用原来相同 OpenSSL API,只需要做异步模式的兼容。另外,可以在调用 OpenSSL 的 API 时,指定到 Engine QAT上就行,不需要做任何额外的修改,就可以使用 QAT 卡进行加解密加速。

4.1 OpenSSL 的Async Mode特性

通过上面的介绍,我们可以看到 QAT 卡的本质是让一部分原本由 CPU 进行的计算转移到 QAT 卡上进行,因此提高 QAT 的利用率,降低 CPU 的切换开销和等待时间是性能最大化的核心工作。

OpenSSL 未启用异步ASYNC模式时,OpenSSL 调用是同步阻塞的,直到QAT_Engine返回结果。如下图的同步模式,在并发处理执行流的场景,大量CPU处于空闲等待的状态(图中虚线表示CPU处于空闲状态),无法有效地利用CPU。

图5. QAT_Engine + OpenSSL 同步模式
图5. QAT_Engine + OpenSSL 同步模式(图片来源)(本站链接)

OpenSSL 开启异步 ASYNC 模式后,OpenSSL 调用是非阻塞的。如下图的异步模式,OpenSSL 的调用不需要等待QAT_engine的处理完成,可以有效地利用 CPU,提高 QAT 的利用率,提升并发处理性能。

图6. QAT_Engine + OpenSSL 异步模式
图6. QAT_Engine + OpenSSL 异步模式(图片来源)(本站链接)

通过 OpenSSL 的同步和异步模式的对比,可以看到 OpenSSL-1.1.1 新增的异步 Async 特性,支持了异步非阻塞调用,提高了 QAT 的利用率,可以显著提升加解密性能。

4.2 QAT Engine ASYNC运行流程

接下来还有一个问题,CPU 如何知道 QAT 卡完成了计算呢? 

Async模块为了达到并行的目的,在单线程中实现了协程(async job)。加解密操作抽象为job,多个job同时运行,使用协程进行调度。

在async job执行的过程中,当计算操作提交给QAT卡后,CPU 可以把当前任务暂停,切换上下文(保存/恢复栈,寄存器等)返回给用户态。

用户态需要主动去poll这个async job的状态,是否是ASYNC_FINISHED状态。如果是,说明之前的任务已经完成,则可以继续后面的操作(取回加密/解密结果)。

注:QAT Engine 通过轮询来获取QAT卡的计算状态,基本原理是启动一个线程,不停的调用qatdriver的polling api,轮询获取qat的计算状态,得到相应结果后,写入eventfd,唤醒async job。

图7. QAT engine ASYNC运行流程
图7. QAT engine ASYNC运行流程(图片来源)(本站链接)

如上图所示,QAT Engine Async的基本流程为:

  1. 主 job 调用 SSL_accept,等待 TLS 客户端发起 TLS handshake。
  2. SSL 内部组织了一个状态机,将握手,读写等操作抽象为两个job,ssl_io_intern(读写), ssl_do_handshake_intern(握手), 统一通过api ASYNC_start_job()进行job调度。这里启动了一个握手的job协程。
  3. 握手job执行 RSA_sign 签名操作时,将sign算法卸载到硬件上计算。调用 ASYNC_pause_job()  切回主job, 并将job状态设置为 ASYNC_PAUSE ,这个时候 CPU 会交还给主 job 进行其它计算工作,同时 QAT 并行的进行自己的计算。
  4. 主job通过SSL_waiting_for_async() 接口获得的一个eventfd,并epoll这个eventfd。当 QAT 卡计算完成,会执行回调写入eventfd,通知主job计算已完成。
  5. 主job切换回握手job,握手job的完成剩余流程后,再调用ASYNC_pause_job()切换主job,并将job状态设置为ASYNC_FINISH,结束协程完成握手动作。

五、QAT 性能评测

通过上面的介绍,我们了解了 QAT 技术方案的基本原理,下面我们看下 QAT 的实际加速效果。

QAT Multi-Buffer 加速方案,依赖的 OpenSSL、QAT Engine、ipp-crypto、 Intel-ipsec-mb 软件栈都是开源项目,我们可以方便的使用 OpenSSL Speed 原生加解密算法对 Multi-Buffer 方案进行性能评估。

硬件环境

  • Intel(R) Xeon(R) Platinum 8369B CPU @ 2.70GHz
  • CPU(s): 8

软件环境

  • Linux Kernel: 4.19.91-24.1.al7.x86_64
  • OpenSSL 1.1.1g
  • gcc (GCC) 8.3.0
  • cmake version 3.15.5
  • NASM version 2.15.05
  • GNU Binutils 2.32
  • 安装 QAT Engine
  • 安装 ipp-crypto、 Intel-ipsec-mb 开源lib库

测试数据

  • numactl -C 0 ./openssl speed rsa2048
  • numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 rsa2048

  • numactl -C 0 ./openssl speed ecdhp384
  • numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 ecdhp384

  • numactl -C 0 ./openssl speed aes-256-cbc
  • numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 aes-256-cbc

TLS 握手阶段的签名和秘钥交换算法

  • RSA 2048 Sign/Verify  提升 4.9/2.9倍
  • ECDH Key Exchange 提升 12倍

对称加解密算法

  • AES-256-CBC 性能持平

根据性能测试结果,QAT 的加速优势在于 TLS 握手阶段的签名和秘钥交换算法,适合频繁进行 TLS 建连的应用场景,比如:Nginx 网关、长连接网关等。

六、总结

本文介绍了 Intel QAT 技术方案,并讨论了方案提供的 Multi-Buffer 软件加速以及 QAT 硬件加速两种方式。同时,通过性能评估测试,我们可以看到 QAT 技术对 TLS 握手阶段的加解密算法有显著的性能提升。

最后,我们讨论一下 Intel QAT 技术的优缺点和应用场景:

6.1 优点和缺点

主要的优点

  • 高性能:可以显著提高计算密集型任务的性能,减少 CPU 的负载,提高系统吞吐量和响应速度。
  • 低功耗:可以将计算密集型任务卸载到专用硬件上,降低系统功耗,提高能效比。

主要的缺点

  • 成本较高:需要额外的硬件支持,增加了系统的成本。
  • 应用范围受限:主要适用于计算密集型任务,对于其他类型的任务可能没有显著的性能提升。
  • 不支持所有处理器:只支持 Intel 特定系列的处理器,需要特定的硬件和软件支持。
  • 改造成本高:需要对应用程序进行 QAT 异步化改造,需要一定的学习成本和技术支持。
6.2 应用场景

除了加解密算法之外,Intel QAT 还支持压缩和解压缩、随机数生成、数字签名、视频编解码等算法。Intel QAT 主要可以用于以下场景:

  • 接入网关:比如 Nginx 网关、长连接网关。QAT 可以加速 TLS 协议处理,提升网关的性能
  • 虚拟私人网络(VPN):QAT 可以加速 VPN 流量的加密和解密过程,提高吞吐量,减少延迟
  • 存储加速:QAT 可以加速数据压缩和解压缩,减少需要传输和存储的数据量
  • 视频编解码:QAT 可以加速视频编解码算法,提高视频处理的效率和质量

总的来说,Intel QAT 可以将计算密集型任务从 CPU 中分离出来,显著提高系统的性能和能效比,可以广泛应用于计算密集型任务的加速,包括网络安全、数据处理、云计算、存储加速、视频处理等多个领域。

参考资料


pip(3) install,完美解决 externally-managed-environment

前言

现象

在 Manjaro 22、Ubuntu 23.04、Fedora 38、macOS 14.6.1 等最新的 Linux/macOS 发行版中运行 pip install时,通常会收到一个错误提示:error: externally-managed-environment,即“外部管理环境”错误,但这不是一个 bug。

如果您想阅读,这是完整的错误信息:

背后的原因

“外部管理环境”错误背后的原因:Manjaro 22、Ubuntu 23.04、Fedora 38、macOS 14.6.1 以及其他的最新发行版中,正在使用 Python 包来实现此增强功能。

这个更新是为了避免「操作系统包管理器 (如pacman、yum、apt、homebrew) 和 pip 等特定于 Python 的包管理工具之间的冲突」。

这些冲突包括 Python 级 API 不兼容和文件所有权冲突。

更多详情可以在官方查看:

PEP 668 – Python base environments


解决方案

方案一、(简单) 使用 "user" 标志

通过 "user" 参数要求 pip 安装到用户私有目录下,仅对当前用户有效。建议在当前用户目录下的 ~/.pip/pip.conf 增加如下配置:

和之前一样,现在您可以直接运行 pip(3) install package_name 命令来安装python模块。

方案二、(粗暴) 去掉这个提示

强制删除此警告,回归到熟悉的操作。

将 “x” 替换为实际版本。

和之前一样,现在您可以直接运行 pip(3) install package_name 命令来安装python模块。

方案三、使用pipx

您在上面看到的涉及手动工作。Pipx 使其自动化。

它会自动为您安装的每个应用程序创建一个新的虚拟环境。不仅。它还在 中创建指向它的链接.local/bin。这样,安装该软件包的用户就可以从命令行中的任何位置运行它。

我想这就是大多数桌面 Linux 用户想要的。

使用以下命令在 Ubuntu 上安装 pipx:

它可能会安装大量的依赖项:

现在将其添加到 PATH 中,以便您可以从任何地方运行。

提示:

您必须关闭终端并重新登录才能发生更改。

现在我们可以使用 Pipx 而不是 Pip 安装 Python 包:

这个是一个例子:

提示:

要删除使用 pipx 安装的软件包,请使用 pipx uninstall package_name 命令。

方案四、(高阶) 使用venv

如果您是开发人员,

在运行或构建py文件时遇到如下图 ModuleNotFoundError: No module named 'xxx' 的错误,

推荐切换为该方案,即使用Python虚拟环境。

借助虚拟环境,您可以使用不同版本的包依赖项和Python。这样,您就可以避免包之间的任何冲突。

这种方法适合从事 Python 项目的软件开发人员和程序员。

安装 venv

生成一个Python虚拟环境

现在,您将看到一个.env在您的主目录中,并且在 .env 中,您将拥有项目目录。

每个虚拟环境项目目录中都会有自己的 Python 和 Pip 副本。

安装模块,如 algoliasearch

用新的虚拟环境执行py文件

这只是 Python 虚拟环境的一个简短示例。如果您想了解更多信息,这里有一份详细指南。

Python Virtual Environments

方案五、(其他) 使用原生包

据我所知,Pip 提供了一种安装 Python 包的舒适方法。然而,一些Python应用程序也打包为APT或其他本机包。在您的发行版存储库中搜索它并从那里安装它(如果可用)。

例如,我试图安装 WoeUSB-ng。如果我使用 Arch Linux,AUR 也提供相同的软件包。

结论

Pip 是一个在系统上获取 Python 包的好工具。个人认为它始终是为 Python 程序员设计的,而不是为最终用户设计的。显然它不能用作原生发行包的替代品,Python 开发人员已经明确表示了这一点。

当然最新的改动的好处是,程序员和最终用户都有替代方案。

参考链接


pip(3) install,完美解决 externally-managed-environment

AI 模型量化格式介绍

在 HuggingFace 上下载模型时,经常会看到模型的名称会带有fp16GPTQGGML等字样,对不熟悉模型量化的同学来说,这些字样可能会让人摸不着头脑,我开始也是一头雾水,后来通过查阅资料,总算有了一些了解,本文将介绍一些常见的模型量化格式,因为我也不是机器学习专家,所以本文只是对这些格式进行简单的介绍,如果有错误的地方,欢迎指正。

What 量化

量化在 AI 模型中,特别是在深度学习模型中,通常指的是将模型中的参数(例如权重和偏置)从浮点数转换为低位宽度的整数,例如从 32 位的浮点数转换为 8 位整数。通俗地说,量化就像是把一本详细的、用高级词汇写的书简化为一个简短的摘要或儿童版故事。这个摘要或儿童版故事占用的空间更小,更容易传播,但可能会丢失一些原始书中的细节。

Why 量化

量化的目的主要有以下几点:

  1. 减少存储需求:量化后的模型大小会显著减小,这使得模型更容易部署在存储资源有限的设备上,如移动设备或嵌入式系统。
  2. 加速计算:整数运算通常比浮点运算更快,尤其在没有专门的浮点硬件支持的设备上。
  3. 减少能耗:在某些硬件上,整数运算消耗的能量更少。

但是,量化也有一个缺点:它可能会导致模型的精度下降。因为你实际上是在用较低的精度来表示原始的浮点数,可能会损失一些信息,这意味着模型的能力会变差。为了平衡这种精度损失,研究者们开发了各种量化策略和技术,如动态量化、权重共享等,可以在尽量少降低模型能力的情况下,尽可能多地降低模型所需的损耗。打个比方,如果我们一个模型的完整能力是 100,模型大小和推理所需内存也是 100,我们将这个模型量化后,模型的能力可能会降低到 90,但模型大小和推理所需内存可能会降低到 50,这个就是量化的目的。

FP16/INT8/INT4

HuggingFace 上模型名称如果没有特别标识,比如 Llama-2-7b-chatchatglm2-6b,那么说明这些模型一般是全精度的(FP32,但也有些是半精度 FP16),而如果模型名称中带有fp16int8int4等字样,比如Llama-2-7B-fp16chatglm-6b-int8chatglm2-6b-int4,那么说明这些模型是量化后的模型,其中fp16int8int4字样表示模型的量化精度。

量化精度从高到低排列顺序是:fp16>int8>int4,量化的精度越低,模型的大小和推理所需的显存就越小,但模型的能力也会越差。

ChatGLM2-6B 为例,该模型全精度版本(FP32)的大小为 12G,推理所需用到的显存为 12~13G,而量化后的 INT4 版本模型大小为 3.7G,推理所需显存为 5G,可以看到量化后的模型大小和显存需求都大大减小了。

FP32 和 FP16 精度的模型需要在 GPU 服务器上运行,而 INT8 和 INT4 精度的模型可以在 CPU 上运行。

GPTQ

GPTQ 是一种模型量化的方法,可以将语言模型量化成 INT8、INT4、INT3 甚至 INT2 的精度而不会出现较大的性能损失,在 HuggingFace 上如果看到模型名称带有GPTQ字样的,比如Llama-2-13B-chat-GPTQ,说明这些模型是经过 GPTQ 量化的。以Llama-2-13B-chat为例,该模型全精度版本的大小为 26G,使用 GPTQ 进行量化成 INT4 精度后的模型大小为 7.26G。

如果你用的是开源模型LLama,可以使用GPTQ-for-LLaMA这个库来进行 GPTQ 量化,它可以将相关的Llama模型量化成 INT4 精度的模型。

但现在更流行的一个 GPTQ 量化工具是AutoGPTQ,它可以量化任何 Transformer 模型而不仅仅是Llama,现在 Huggingface 已经将 AutoGPTQ 集成到了 Transformers 中,具体的使用方法可以参考这里

GGML

讲 GGML 之前要先说下llama-cpp这个项目,它是开发者 Georgi Gerganov 基于 Llama 模型手撸的纯 C/C++ 版本,它最大的优势是可以在 CPU 上快速地进行推理而不需要 GPU。然后作者将该项目中模型量化的部分提取出来做成了一个模型量化工具:GGML,项目名称中的GG其实就是作者的名字首字母。

在 HuggingFace 上,如果看到模型名称带有GGML字样的,比如Llama-2-13B-chat-GGML,说明这些模型是经过 GGML 量化的。有些 GGML 模型的名字除了带有GGML字样外,还带有q4q4_0q5等,比如Chinese-Llama-2-7b-ggml-q4,这里面的q4其实指的是 GGML 的量化方法,从q4_0开始往后扩展,有q4_0q4_1q5_0q5_1q8_0,在这里可以看到各种方法量化后的数据。

GGUF

最近在 HuggingFace 上的模型还发现了一些带有GGUF字样的模型,比如Llama-2-13B-chat-GGUFGGUF其实是 GGML 团队增加的一个新功能,GGUF 与 GGML 相比,GGUF 可以在模型中添加额外的信息,而原来的 GGML 模型是不可以的,同时 GGUF 被设计成可扩展,这样以后有新功能就可以添加到模型中,而不会破坏与旧模型的兼容性。

但这个功能是Breaking Change,也就是说 GGML 新版本以后量化出来的模型都是 GGUF 格式的,这意味着旧的 GGML 格式以后会慢慢被 GGUF 格式取代,而且也不能将老的 GGML 格式直接转成 GGUF 格式。

关于 GGUF 更多的信息可以参考这里

GPTQ vs GGML

GPTQ 和 GGML 是现在模型量化的两种主要方式,但他们之间有什么区别呢?我们又应该选择哪种量化方式呢?

两者有以下几点异同:

  • GPTQ 在 GPU 上运行较快,而 GGML 在 CPU 上运行较快
  • 同等精度的量化模型,GGML 的模型要比 GPTQ 的稍微大一些,但是两者的推理性能基本一致
  • 两者都可以量化 HuggingFace 上的 Transformer 模型

因此,如果你的模型是在 GPU 上运行,那么建议使用 GPTQ 进行量化,如果你的模型是在 CPU 上运行,那么建议使用 GGML 进行量化。

Groupsize

在 HuggingFace 上,不管是什么格式的量化模型,模型名称中还经常出现一些32g128g字样,比如pygmalion-13b-4bit-128g,这些又是表示什么意思呢?

128g中的g其实表示的是 groupsize 的意思,在量化技术中,权重可能会被分成大小为 groupsize 的组,并对每组应用特定的量化策略,这样的策略可能有助于提高量化的效果或保持模型的性能。

groupsize 的值有:1024、128、32,GPTQ 默认的 groupsize 值是 1024。如果 groupsize 没有值,那么 groupsize 就为-1( 注意不是 0)。groupsize 会影响模型的准确性和推理显存大小,groupsize 根据同等精度模型准确性和推理显存从高到底的排列顺序是:32 > 128 > 1024 > None(-1),也就是说 None(-1) 是准确性和显存占用最低的,而 32 是最高的。

参考资料


Llama大模型运行的消费级硬件要求【CPU|GPU|RAM|SSD】

大型语言模型 (LLM) 是强大的工具,可以为各种任务和领域生成自然语言文本。 最先进的LLM之一是 LLaMA(大型语言模型 Meta AI),这是由 Facebook 的研究部门 Meta AI 开发的一个包含 650 亿个参数的模型。

要在家运行 LLaMA 模型,你需要一台配备强大 GPU 的计算机,能够处理推理所需的大量数据和计算。 在本文中,我们将讨论本地运行 LLaMA 的一些硬件要求。

在消费类硬件上运行 LLaMA 模型有多种不同的方法。 最常见的方法是使用单个 NVIDIA GeForce RTX 3090 GPU。 该 GPU 具有 24 GB 内存,足以运行 LLaMA 模型。 RTX 3090 可以运行 4 位量化的 LLaMA 30B 模型,每秒大约 4 到 10 个令牌。 24GB VRAM 似乎是在消费类台式电脑上使用单个 GPU 的最佳选择。

但是,如果你想运行更大的模型,则必须使用双 GPU 设置。 这将允许你将模型权重放入 VRAM 中。 你还可以使用高级 GPU,例如 NVIDIA A100。 这个GPU非常昂贵,但有40GB内存,可以更好地运行模型。

你还可以在 CPU 上运行 LLaMA 模型。 必须使用模型的 GGML 版本(LLaMA、Vicuna、Alpaca 和 GPT4All)以及名为 llama.cpp 的软件才能使用CPU。 运行 LLaMA 的合适 CPU 是 Core i7 12900K 和 Ryzen 9 5900X。 有关此主题的更多信息,请查看 CPU 部分。

请记住,训练或微调 LLaMA 模型需要比运行模型更多的 VRAM。 这是因为训练过程需要将模型以及训练数据存储在 VRAM 中。 训练所需的 VRAM 量取决于模型的大小和训练数据量。

为了在台式电脑上使用 LLaMA 模型,请查看需要满足的一些硬件要求:

7-19更新:LLAMA  2 权威指南
7-30更新:LLAMA 2本地运行的3个方案

1、运行 LLaMA 的 GPU要求

在消费级机器上运行 LLaMA 时,GPU 是最重要的计算机硬件,因为它负责运行模型所需的大部分处理。 GPU的性能将直接影响推理的速度和准确性。

模型的不同变体和实现可能需要功能较弱的硬件。 不过,GPU 仍将是系统中最重要的部分。

4 位量化 LLaMA 模型的 GPU 要求:

LLaMA Model Minimum VRAM Requirement Recommended GPU Examples
LLaMA-7B 6GB RTX 3060, GTX 1660, 2060, AMD 5700 XT, RTX 3050
LLaMA-13B 10GB AMD 6900 XT, RTX 2060 12GB, 3060 12GB, 3080, A2000
LLaMA-30B 20GB RTX 3080 20GB, A4500, A5000, 3090, 4090, 6000, Tesla V100, Tesla P40
LLaMA-65B 40GB A100 40GB, 2x3090, 2x4090, A40, RTX A6000, 8000
  • LLama-7B

为了有效运行 LLaMA-7B,建议使用至少具有 6GB VRAM 的 GPU。 适合此模型的 GPU 示例是 RTX 3060,它提供 8GB VRAM 版本。 其他 GPU(例如 GTX 1660、2060、AMD 5700 XT 或 RTX 3050)也具有 6GB VRAM,可以作为支持 LLaMA-7B 的良好选择。

  • LLaMA-13B

为了获得 LLaMA-13B 的最佳性能,建议使用至少具有 10GB VRAM 的 GPU。 满足此要求的 GPU 示例包括 AMD 6900 XT、RTX 2060 12GB、3060 12GB、3080 或 A2000。 这些 GPU 提供必要的 VRAM 容量来有效处理 LLaMA-13B 的计算需求。

  • LLaMA-30B

为确保 LLaMA-30B 顺利运行,建议使用至少 20GB VRAM 的 GPU。 RTX 3080 20GB、A4500、A5000、3090、4090、6000 或 Tesla V100 是提供所需 VRAM 容量的 GPU 示例。 这些 GPU 可实现 LLaMA-30B 的高效处理和内存管理。

  • LLaMA-65B

LLaMA-65B 与至少具有 40GB VRAM 的 GPU 配合使用时,性能最佳。 适用于此型号的 GPU 示例包括 A100 40GB、2x3090、2x4090、A40、RTX A6000 或 8000。这些 GPU 提供充足的 VRAM 容量来处理与 LLaMA-65B 相关的密集计算任务。

每个 LLaMA 模型都有特定的 VRAM 要求,建议的 GPU 是根据其满足或超过这些要求的能力来选择的,以确保相应的 LLaMA 模型平稳高效的性能。

2、运行LLaMA 的 CPU要求

除了 GPU 之外,你还需要一个可以支持 GPU 并处理其他任务(例如数据加载和预处理)的 CPU。 基于 GPQT (GPU) 的模型对 CPU 的要求低于针对 CPU 优化的模型。

适合 LLaMA 的 CPU 是 Intel Core i9-10900K、i7-12700K 或 Ryzen 9 5900x。 但是,为了获得更好的性能,你可能需要使用更强大的 CPU,例如具有 64 核和 128 线程的 AMD Ryzen Threadripper 3990X。 最后,真正重要的是 CPU 的速度。 这才是真正的力量所在。 当在昂贵的服务器 CPU 和高端游戏 CPU 之间进行选择时,后者占据主导地位。

我们必须注意,本文讨论的模型是针对 GPU 的,但也有针对 CPU 的 LLaMa 模型优化器。 例如,GGML 是一种解决方案,可以解决处理大型模型时 GPU 内存带来的限制。 如果你更喜欢使用 CPU,建议运行 GGML 格式的模型文件。

你可以使用名为 llama.cpp(LLaMA 模型的接口)的软件来利用你的 CPU。 llama.cpp 最近的更新引入了新的增强功能,使用户能够在 CPU 和 GPU 之间分配模型的工作负载。 这不仅有利于加载更大的模型,而且还提高了令牌的速度。

这是使用 Ryzen 7 3700X 和 128GB RAM 运行 llama.cpp 的示例。

GGML Model Memory per Token Load Time Sample Time Predict Time Total Time
LLaMA-7B 4-bit 14434244 bytes 1270.15 ms 325.76 ms 15147.15 ms / 117.42 ms per token 17077.88 ms
LLaMA-13B 4-bit 22439492 bytes 2946.00 ms 86.11 ms 7358.48 ms / 216.43 ms per token 11019.28 ms
LLaMA-30B 4-bit 43387780 bytes 6666.53 ms 332.71 ms 68779.27 ms / 533.17 ms per token 77333.97 ms
LLaMA-65B 4-bit 70897348 bytes 14010.35 ms 335.09 ms 140527.48 ms / 1089.36 ms per token 157951.48 ms

3、运行LLaMA 的内存要求

除了GPU和CPU之外,你还需要足够的RAM(随机存取存储器)和存储空间来存储模型参数和数据。 4 位 LLaMA-30B 的最低 RAM 要求为 32 GB,可以将整个模型保存在内存中,而无需交换到磁盘。 但是,对于较大的数据集或较长的文本,你可能需要使用更多 RAM,例如 64 GB 或 128 GB。

CPU 和内存之间的带宽是一个关键因素,我想强调它的重要性。 当生成单个 token 时,整个模型需要从内存中读取一次。 假设你有 Core i9-10900X(4 通道支持)和 DDR4-3600 内存,这意味着吞吐量为 115 GB/s,而你的型号大小为 13 GB。 在这种情况下,理论限制约为每秒 8.8 个令牌,无论你的 CPU 有多快或有多少个并行核心。

RAM 的大小取决于 GGML 量化的类型和你使用的模型(LLaMA、Alpaca、Wizard、Vicuna 等)。

这些是 在CPU上使用 LLaMA 模型的内存 (RAM) 要求:

GGML Model Original size Quantized size (4-bit) Quantized size (5-bit) Quantized size (8-bit)
7B 13 GB 3.9 – 7.5 GB 7.5 – 8.5 GB 8.5 – 10.0 GB
13B 24 GB 7.8 – 11 GB 11.5 – 13.5 GB 13.5 – 17.5 GB
30B 60 GB 19.5 – 23.0 GB 23.5 – 27.5 GB 28.5 – 38.5 GB
65B 120 GB 38.5 – 47.0 GB 47.0 – 52.0 GB 71.0 – 80.0 GB

在 CPU 上运行时基于内存 (RAM) 速度的模型 (8GB) 推理速度:

RAM speed CPU CPU channels Bandwidth *Inference
DDR4-3600 Ryzen 5 3600 2 56 GB/s 7 tokens/s
DDR4-3200 Ryzen 5 5600X 2 51 GB/s 6.3 tokens/s
DDR5-5600 Core i9-13900K 2 89.6 GB/s 11.2 tokens/s
DDR4-2666 Core i5-10400f 2 41.6 GB/s 5.1 tokens/s

速度为理论最大值,取决于操作系统和系统负载。

4、运行LLaMA的存储要求

LLaMA的最低存储要求是1TB NVMe SSD,可以存储模型文件和数据文件,读写速度很快。 但是,为了更多数据或备份目的,你可能需要使用更多存储空间,例如 2 TB 或 4 TB SSD。

选择高速存储。 选择具有出色顺序速度的 PCIe 4.0 NVMe SSD,以促进存储和系统 RAM 之间的快速数据传输。

5、模型量化如何影响 GPU 的选择?

量化 LLM使用更少的位数来存储和处理模型的权重和激活。 这使得它们的 GPU 部署更快、更高效。

4 位量化 LLM 每个权重或激活仅使用 4 位。 这意味着它们比全精度模型占用更少的内存和计算时间。 它们可以在 VRAM 容量较低的 GPU 上平稳运行。

8 位量化 LLM 每个权重或激活使用 8 位。 与全精度模型相比,这仍然减少了内存和计算成本,但不如 4 位量化那么多。 它们需要更多的 GPU 内存和计算能力才能良好运行。 它们更适合具有高 VRAM 容量和计算能力的 GPU。

总而言之,4 位量化 LLM 效率更高,并且可以在 VRAM 容量较低的 GPU 上运行。 8 位量化 LLM 的效率稍低,需要具有高 VRAM 容量和计算能力的 GPU。

LLaMA Precision GPU Memory Requirements Computational Demands Suitable GPU
Native (32-bit) Higher requirements Higher computational demands GPUs with larger VRAM capacities and high computational capabilities
16-bit Quantized Moderate requirements Moderate computational demands GPUs with moderate VRAM capacities and good computational capabilities
8-bit Quantized Relatively higher requirements Slightly higher computational demands GPUs with larger VRAM capacities and higher computational capabilities
4-bit Quantized Lower requirements Lower computational demands GPUs with limited VRAM capacities

正如你所看到的,LLaMA 的精度对其 GPU 内存需求和计算需求有直接影响。 原生(32 位)LLM 需要最多的 GPU 内存和计算能力,而 4 位量化 LLM 需要最少。

适用于 LLaMA 的 GPU 取决于其精度以及您想要使用它执行的特定任务。 如果您需要在各种任务上运行大型 LLaMA,那么您将需要具有大 VRAM 容量和高计算能力的 GPU。 如果您只需要在几个特定任务上运行小型 LLaMA,那么您可以使用具有较小 VRAM 容量和较低计算能力的 GPU。

需要注意的是,随着量化级别的降低,模型的准确性也会降低。 这是因为精度降低可能会导致模型预测出现错误。

最适合你的量化级别取决于你的具体需求和要求。 如果需要一个小而高效的模型,那么你可能需要考虑使用 4 位或 8 位量化模型。 但是,如果你需要高度准确的模型,那么可能需要使用 16 位模型。

6、双GPU是否有效提升 LLaMA性能?

添加第二个 GPU 可能不会像预期那样加快文本生成速度。 瓶颈似乎阻碍了增加更多计算能力的简单解决方案。 一些测试显示出令人惊讶的结果,低端 GPU 每秒生成令牌的速度比高端 GPU 更快。 其原因尚不清楚,文本生成程序可能需要更好的优化才能很好地使用双 GPU 设置。

双 GPU 设置总共具有更多 VRAM,但每个 GPU 仍然有其自己的 VRAM 限制。 30B LLaMA 需要大约 20GB VRAM,因此两个 RTX 3090 GPU(每个都有 24GB VRAM)仍然只有 24GB VRAM 可用。 该模型应适合一个 GPU 的 VRAM 才能正常运行。

但是,如果模型太大而无法容纳单个 GPU 的 VRAM 并且需要利用系统 RAM,则使用多个 GPU 确实可以加快该过程。 在这种情况下,每个 GPU 可以处理模型的一部分,并且计算负载在它们之间分配。 这种并行化可以提高超过单个 GPU 的 VRAM 容量的大型模型的速度。

因此,在处理具有高 VRAM 要求的大型模型时,通常会采用多个 GPU。 它可以有效利用资源并加速训练或推理过程。

将像 65B LLaMA 这样的大型语言模型拆分到具有模型并行性的多个 GPU 上可能会很困难,并且可能会导致通信延迟。 通过 GPU 拆分和同步模型的参数和计算需要仔细编码,并且可能并不总是能大幅提高性能。

双 GPU 设置可能不适用于某些软件。 某些机器学习框架或库可能无法完全使用多个 GPU,并且可能需要额外的工作来设置和优化系统以使用双 GPU。

这些限制意味着,将双 GPU 设置用于 30B LLaMA 的可能优势与难度和潜在问题进行比较非常重要。 有时,获得更强的单GPU或尝试其他优化方法可能是更好的方法。

7、为 LLaMA 选择 PC 硬件的技巧

  • 围绕 GPU 构建

创建一个包含主板、CPU 和 RAM 的平台。 GPU 处理训练和推理,而 CPU、RAM 和存储管理数据加载。 选择支持 PCIe 4.0(或 5.0)、多个 NVMe 驱动器插槽、x16 GPU 插槽和充足内存 DIMM 的主板。 建议使用单线程速度较高的 CPU,例如 Ryzen 5000 或 Intel 第 12/13 代。

  • 型号选择和 VRAM

为了在响应质量方面获得最佳性能,建议在具有至少 20GB VRAM 的 GPU 上运行 8 位 13B 模型或 4 位 30B 模型。 两种型号都提供相似的质量响应,VRAM 可用性应该是决定因素。 投资具有张量核心的 Nvidia GPU 以增强性能。 考虑 RTX 30 系列或 RTX 40 系列等选项,例如 RTX 3090 24GB、RTX 4090 24GB,以获得最佳性能。

  • 速度比较

就每秒生成的令牌而言,13B 模型通常比 30B 模型运行得更快。 虽然确切的速度差异可能有所不同,但与 30B 模型相比,13B 模型往往会在生成速度方面提供显着的改进。

  • 内存要求

目标是至少 1.5 倍 VRAM 容量或两倍 VRAM 以获得最佳性能。 当使用 128GB 或更多 RAM 时,主板和 CPU 的选择变得至关重要。

  • PCIe 4.0 NVMe 固态硬盘

高顺序速度 PCIe 4.0 NVMe SSD 的重要性主要在于将初始模型加载到 VRAM 中。 模型加载后,SSD 对生成速度(令牌/秒)的影响很小。

  • 足够的常规 RAM

拥有足够的常规 RAM(最好是 VRAM 容量的两倍)对于初始模型加载至关重要。 模型一旦加载,对实际生成速度的影响是有限的。 确保初始加载期间有足够的常规 RAM 对于流畅的体验至关重要。

  • CPU单线程速度

CPU 的单线程速度主要对于初始模型加载非常重要,而不是在生成期间运行模型。 CPU的作用在数据预处理、模型加载和其他不依赖GPU的操作等任务中更加突出。

  • 扩展以提高速度

如果你需要将文本生成速度从 15 个令牌/秒提高到 30 个令牌/秒,设置整个 PC 的文字克隆可能比添加第二个 3090 卡更有效。 将整体系统资源(包括 CPU 和 RAM)加倍可能会在提高文本生成速度方面产生更好的结果。

  • 单GPU性能

由于 GPU 本身的内部带宽优势,单个 GPU 通常比多 GPU 设置提供更快的性能。

  • 电源及机箱

投资具有足够容量为所有组件供电的高质量电源。 选择通风良好的宽敞机箱以获得最佳散热效果。

  • DDR5 和未来平台

虽然 DDR5 和 Zen 4 或 AM5 等未来平台具有优势,但稳定性和兼容性可能会有所不同。 考虑投资具有良好 PCIe 插槽布局和内存支持的高端主板,以实现未来的升级。

请记住,虽然这些提示和技巧提供了基于经验的见解,但各个系统配置和性能可能会有所不同。 始终建议对不同的设置进行试验和基准测试,以找到最适合你的特定需求的解决方案。

参考链接


鸿蒙应用开发:提升性能的利器——防抖与节流

为了应对频繁的事件调用所带来的性能瓶颈,我们需要引入防抖(debounce)和节流(throttle)这两个利器。

防抖:抑制不必要的高频事件

防抖是一种技术,它可以在一定时间内抑制不必要的高频事件。在鸿蒙应用开发中,防抖可以用来优化事件处理,例如按钮点击事件。

防抖的工作原理是:当一个事件被频繁调用时,防抖函数会将事件放入一个计时器中。在这个计时器中,事件将在一个指定的等待时间后执行。如果在等待时间内又收到了该事件的调用,那么计时器将被重新设置,等待时间将从头开始计算。

节流:限制事件调用的频率

节流是一种技术,它可以限制事件调用的频率。在鸿蒙应用开发中,节流可以用来优化输入框中的输入事件处理。

节流的工作原理是:当一个事件被频繁调用时,节流函数会将事件放入一个令牌桶中。在这个令牌桶中,事件将按照一个固定的速度执行。如果令牌桶已满,那么事件将被丢弃。

防抖与节流的比较

防抖和节流都是用来处理高频事件的利器,但是它们的工作方式不同。

  • 防抖: 在一定时间内只执行一次事件。
  • 节流: 以固定的速度执行事件,丢弃多余的事件。
在鸿蒙应用开发中的应用

防抖和节流可以在鸿蒙应用开发中得到以下应用:

  • 事件处理: 防抖可以用来优化按钮点击事件等高频事件的处理,避免不必要的高频调用。
  • 输入框输入: 节流可以用来限制输入框中输入事件的频率,避免不必要的多余请求。
  • 网络请求: 防抖和节流可以用来优化网络请求,避免不必要的多余请求。
  • 滚动事件: 节流可以用来限制滚动事件的频率,避免不必要的高频调用。

示例代码

总结

防抖和节流是鸿蒙应用开发中提升性能的利器。通过合理使用防抖和节流,可以有效优化事件处理、输入框输入、网络请求和滚动事件,从而提升应用的整体性能和用户体验。

参考链接