微服务性能调优03

近期遇到一些技术问题,记录如下:

1、NAS引起的惨案一
上次说到,大家都在降本,于是我们做了一系列调整工作。但降本总有一个永恒不变的主题:降配。
于是我们和集团的科技,同时开始了惨无人道的降配工作。
在一顿神奇操作后,系统终于区域稳定,好景不长,突然间又出问题了。

表现:
系统部分服务的部分节点,在服务高峰期之后,总是会出现时不时的系统卡顿。
关键这个卡顿很有规律,总是上午10点,下午4点出现,完美错过我们的上下午业务高峰。
原因:
经过技术委员会小伙伴通力排查,大家最终定位到是应用日志写入到归档NAS时,NAS性能十分不稳定,IO时间有时会高达几秒。
一旦遇到NAS卡顿,会阻塞日志,进而阻塞服务。
而且,当前NAS是和兄弟公司公用的,NAS卡顿时,正值他们的业务高峰期。
解决:
应用日志不再输出到NAS,而是输出到日志云。

2、NAS引起的惨案二
平稳度过了几天,周五,问题又来了。
表现:
系统时不时卡顿,没有任何规律,和业务高峰没有任何关系,一切监控都正常。
原因:
经过N个小时排查,我们的小伙伴,终于发现问题还是出现在日志上,只不过这一次,是GC日志。
GC日志同样是在归档NAS上,此时归档NAS更加不稳定,minor gc日志写入,偶尔会遇到NAS IO延时,引起系统卡顿。
解决:
应用日志不再输出到归档NAS,而是输出到中端闪存NAS,花钱买平安。
进一步:
针对当前遇到的情况,重新制定日志规范,尽快推广落地。

3、一次RefreshScope引发的惨案
表现:
使用nacos动态刷新了一个配置,但相关服务突然越来越慢,并有大量的锁等待:sun.misc.Unsafe.park

原因:
初步分析,nacos更新配置后,对应RefreshScope的类需要重新加载配置,从而调用了GenericScope类的destroy方法,在该方法中加了writelock
同时,业务代码在处理请求的时候,同样的用到了GenericScope::LockedScopedProxyFactoryBean的invoke方法,在该方法中加了readlock
先是读锁(多个),再写锁(一个),再读锁(多个),最后死锁了,都无法获取锁,服务就卡住了。问题是,一开始的锁为何不释放呢?

进一步分析,发现是在服务业务代码中,用到了HttpClient的org.apache.http.impl.io.SessionInputBufferImpl.streamRead方法
该方法调用了java.net.SocketInputStream.socketRead,该方法触发了jdk8的一个bug,该native方法无法返回

解决:
升级JDK版本,同时代码改造缩小RefreshScope的范围

4、一次redis引发的惨案
表现:
几分钟内redis内存飙高,直接爆掉。
查看了业务系统日志,没有出现业务激增的情况。
查看redis日志,发现AOF日志不断增大,重写的时候缓存爆掉,导致主备切换。
监控日志反馈存在大量setex操作。

原因:
reids集群出现大量setex操作,导致AOF日志激增,日志重写时落盘速度缓慢(出现了short write),结果AOF日志缓存爆掉,主从切换

解决:
临时升级了内存,后续将日志盘从NAS改为SSD,并好服务的redis主从切换配置
但setex激增的原因暂时还没有查到,补充了一些防御性代码

5、一次jdk引发的惨案
表现:
一个生成表单PDF的微服务会产生大量的临时文件,而且不会自行清理。

原因:
在用到的一个第三方Jar包中,用到了java.awt.Font类,该类用到了createFont方法

//不会产生大量临时文件
static Font createFont(int fontFormat, File fontFile)
//会产生大量临时文件,初步判断是JDK的问题
static Font createFont(int fontFormat, InputStream fontStream)

解决:
重写了改Jar包的类,从InputStream切换到了File

6、一次防火墙引发的惨案
表现:
部分用户反馈,无法正常加载微信小程序,需要点击右上角进行刷新才行

原因:
从腾讯后台可以看到,有大约18%的请求会超过60S,其余正常
然后到微服务层,发现有一些请求,在返回数据包的时候,会收到“连结已断开”的反馈,与腾讯后台表现较为一致
然后向前一点儿一点儿的捋,最后发现,需要访问的腾讯IP有5个,之前开墙只开了4个,第5个IP数据返回时就被防火墙直接拦截了。

解决:
提单,开墙,解决问题

【转载】理解编码器式与解码器式大语言模型

原文地址:Understanding Encoder And Decoder LLMs, by Sebastian Raschka, on 2023-06-17

理解编码器式与解码器式大语言模型

不少人希望我更深入地讲解大语言模型(LLM)的行业术语,解释一些如今我们习以为常的技术名词,其中就包括“编码器式”与“解码器式”大语言模型。这些术语究竟是什么意思?

我们进入正题:基于编码器的语言Transformer与基于解码器的语言Transformer有何区别?

编码器式与解码器式Transformer

从根本上说,编码器式与解码器式架构都使用相同的自注意力层对词元进行编码。但二者的核心区别在于:编码器的设计目标是学习嵌入表示,可用于分类等各类预测建模任务;与之相对,解码器的设计目标是生成新文本,例如回答用户查询。

原始Transformer

最初为英翻法、英翻德任务开发的Transformer架构(https://arxiv.org/abs/1706.03762)同时采用了编码器与解码器,如下图所示。

figure01

图注:https://arxiv.org/abs/1706.03762 中提出的原始Transformer架构示意图

在上图中,输入文本(即待翻译的句子)首先被分词为独立的词元,随后经过嵌入层编码,再进入编码器部分。接着,在为每个嵌入后的词元加上位置编码向量后,这些嵌入表示会经过一层多头自注意力层。多头注意力层之后是“相加与归一化”步骤:执行层归一化,并通过跳跃连接(也称为残差连接或捷径连接)加上原始嵌入。最后,经过“全连接层”(由两层全连接层、中间夹一个非线性激活函数组成的小型多层感知机)后,输出会再次进行相加与归一化,再传入解码器部分的多头自注意力层。

上图中解码器部分的整体结构与编码器部分类似,关键区别在于输入与输出不同。编码器接收待翻译的输入文本,解码器则生成翻译后的文本。

编码器

前文图中原始Transformer的编码器部分,负责从输入文本中理解并提取相关信息,随后输出输入文本的连续表示(嵌入),并传递给解码器。最终,解码器根据从编码器接收到的连续表示生成翻译后的文本(目标语言)。

多年来,基于上述原始Transformer模型的编码器模块,研究者开发出了多种仅编码器架构。其中代表性的例子包括BERT(https://arxiv.org/abs/1810.04805)与RoBERTa(https://arxiv.org/abs/1907.11692)。

BERT(Bidirectional Encoder Representations from Transformers,基于Transformer的双向编码器表示)是一种基于Transformer编码器模块的仅编码器架构。BERT模型在大规模文本语料上进行预训练,采用的预训练任务包括掩码语言建模(如下图所示)和下一句预测。

figure02

图注:BERT式Transformer所采用的掩码语言建模预训练目标示意图

掩码语言建模的核心思想是:将输入序列中的随机词元进行掩码(或替换),然后训练模型根据周围的上下文预测被掩码的原始词元。

除了上图所示的掩码语言建模预训练任务之外,下一句预测任务会要求模型判断:原始文档中两个被随机打乱顺序的句子,其语序是否正确。例如,两个随机顺序的句子通过 分隔:

  Toast is a simple yet delicious food [SEP] It’s often served with butter, jam, or honey.
  It’s often served with butter, jam, or honey. [SEP] Toast is a simple yet delicious food.

标记是模型的占位标记,用于让模型输出“真”或“假”标签,表明两个句子的顺序是否正确。

掩码语言建模与下一句预测预训练目标(属于自监督学习的一种,第2章会展开讨论)让BERT能够学习输入文本的丰富上下文表示,这些表示随后可以通过微调,用于情感分析、问答、命名实体识别等各类下游任务。

RoBERTa(Robustly optimized BERT approach,鲁棒优化版BERT方法)是BERT的优化版本。它保留了与BERT相同的整体架构,但在训练与优化上做了多处改进,例如使用更大的批次规模、更多的训练数据,以及取消了下一句预测任务。这些改动使得RoBERTa在各类自然语言理解任务上的表现优于BERT。

解码器

回到本节开头介绍的原始Transformer架构,解码器中的多头自注意力机制与编码器中的类似,但它会进行掩码处理,防止模型关注未来位置,确保第i个位置的预测仅依赖于位置小于i的已知输出。如下图所示,解码器会逐词生成输出。

figure03

图注:原始Transformer中采用的下一句预测任务示意图

这种掩码(在上图中被明确展示出来,不过它实际是在解码器的多头自注意力机制内部完成的)对于在训练与推理阶段维持Transformer模型的自回归特性至关重要。自回归特性确保模型逐个生成输出词元,并将之前生成的词元作为上下文,用于生成下一个词元。

多年来,研究者在原始编码器-解码器Transformer架构的基础上不断拓展,开发出了多种仅解码器模型,这些模型在各类自然语言处理任务中表现出了极佳的效果。其中最具代表性的模型包括GPT系列。

GPT(Generative Pre-trained Transformer,生成式预训练Transformer)系列是仅解码器模型,在大规模无监督文本数据上进行预训练,并针对文本分类、情感分析、问答、摘要等特定任务进行微调。GPT模型(包括GPT-2、GPT-3(https://arxiv.org/abs/2005.14165)以及更新的GPT-4)在各类基准测试中展现出了卓越的性能,是目前自然语言处理领域最流行的架构。

GPT模型最引人注目的特点之一是其涌现能力。涌现能力指的是模型凭借下一词预测预训练而发展出的能力与技能。尽管这些模型仅被训练用于预测下一个词,但预训练后的模型已经能够完成文本摘要、翻译、问答、分类等诸多任务。此外,这些模型还能通过上下文学习执行新任务,而无需更新模型参数,第18章会对此进行更详细的讨论。

编码器-解码器混合模型

除了传统的编码器与解码器架构之外,新型编码器-解码器模型的研发也取得了进展,这类模型能够同时利用两种组件的优势。它们通常会引入新颖的技术、预训练目标或架构修改,以提升在各类自然语言处理任务中的表现。这类新型编码器-解码器模型的代表性例子包括:

编码器-解码器模型通常用于涉及“理解输入序列+生成输出序列”的自然语言处理任务,且输入与输出的长度、结构往往不同。它们尤其擅长处理输入序列与输出序列之间存在复杂映射关系、且捕捉两个序列中元素之间的关联至关重要的任务。编码器-解码器模型的常见应用场景包括文本翻译与摘要。

术语与行话

以上所有方法——仅编码器、仅解码器以及编码器-解码器模型——都属于序列到序列模型(通常缩写为seq2seq)。需要注意的是,虽然我们将BERT式方法称为仅编码器,但“仅编码器”的说法可能会造成误解,因为这类方法在预训练过程中也会将嵌入解码为输出词元或文本。

换句话说,仅编码器与仅解码器架构都在进行“解码”。但与仅解码器和编码器-解码器架构不同,仅编码器架构的解码并非以自回归的方式进行。自回归解码指的是逐个生成输出序列,每个词元的生成都以之前生成的词元为条件。仅编码器模型不会以这种方式生成连贯的输出序列,相反,它们专注于理解输入文本,并生成特定于任务的输出,例如标签或词元预测结果。

结论

简而言之,编码器式模型广泛用于学习分类任务所需的嵌入表示;编码器-解码器式模型用于输出高度依赖输入的生成类任务(例如翻译与摘要);仅解码器模型则用于问答等其他类型的生成类任务。自首个Transformer架构诞生以来,已经发展出了数百种仅编码器、仅解码器以及编码器-解码器混合模型,如下图总结所示。

figure04

图注:按架构类型与开发者分类的部分主流大语言Transformer概览

仅编码器模型的热度逐渐下降,而GPT等仅解码器模型凭借GPT-3、ChatGPT与GPT-4带来的文本生成技术突破,迎来了爆发式增长。不过,对于基于文本嵌入训练预测模型(而非生成文本)的场景,仅编码器模型仍然具有很高的实用价值。

本专栏是一个个人兴趣项目,无直接商业报酬。如果您愿意支持我,欢迎考虑购买https://sebastianraschka.com/books上的书籍。如果您觉得这些内容富有洞见、有所帮助,也欢迎推荐给您的朋友与同事。

figure05

https://www.amazon.com/Machine-Learning-PyTorch-Scikit-Learn-scikit-learn-ebook-dp-B09NW48MR1/dp/B09NW48MR1/ , https://nostarch.com/machine-learning-and-ai-beyond-basics , 以及 http://mng.bz/M96o

你的支持意义重大!谢谢你!

微服务性能调优02

在各项目组努力下,终于达成了几个目标:
1、springboot升级到2.x
2、干掉了老技术中台,全部系统对接到新技术中台,实现了技术中台统一
3、填了一波史前巨坑

今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及,实现动态扩缩容
4、日常,继续填历史的技术坑

1、redis调优
数据流:
数据库查询结果-》缓存到redis-》缓存使用者
表现:
bigkey一大堆,单个key存放数据3M多(你咋不把整个JVM塞到redis里去呢),redis服务器所需内存、带宽都特别高
原因:
分析后发现,之前架构确定的技术方案有问题
解决:
a、改变序列化方式,从jvm序列化,调整为protobuff,调整后,带宽瞬间大幅下降
b、减少序列化的数据内容,只保存真正需要的,调整后,redis内存大幅下架,带宽大幅下降
c、对redis进行拆分,将一个大redis,按领域拆分为多个小redis,性能提升明显
d、对于热数据不明显的低频访问场景,不缓存到redis,大家慢慢优化去吧

2、网关调优
数据流:
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现:
外网网关和内网网关功能一样,而且逻辑超级复杂,性能垃圾的一塌糊涂
原因:
分析后发现,之前架构确定的技术方案有问题
解决:
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升

3、数据流优化
数据流(大幅简化后):
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现:
业务逻辑分散到各业务系统,数据来回传递多次,多个系统加工同一批数据,一旦出问题,要多个系统联查,花费很长时间才能定位到问题
原因:
分析后发现,之前架构确定的技术方案有问题
解决:
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰,用户自己都能初步定位到问题

4、数据修改请求超级多
数据流:
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现:
数据质量差,任务都给到了IT,管理方没有管理动力,数据质量持续差,修改量逐年上升
原因:
分析后发现,各业务条线管控要求很多,不放权,与各地执行机构有轻度脱节
数据生产者,不承担数据质量差的职责,没有提升数据质量动力
总部管理部门,不承担数据质量差的职责,不清楚数据质量哪里差,没有工作重点
解决:
a、分析数据修改工单,归纳前几类修改请求
b、与业务方沟通,对分支机构可以修改的数据,将功能开放给各分支结构,定期公示修改量、业务影响程度等数据,作为总部管理部门的管理抓手
c、对于分支结构不可以修改的,开放数据修改功能给总部管理部门,进行统一管控,定期公示修改量、业务影响程度等数据,作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升,工单量大幅下降

5、降本
数据流:
应集团要求,降本压力巨大,科技承接了600万降本指标
表现:
科技方压力山大
原因:
一开始几年,没有这么大的压力,大家手都比较松,各条线都存在较大浪费,科技也是如此
最近几年,都是在之前资源上,不断的挤压资源,来满足每年业务快速增长的需要
今年,一方面业务继续快速增加,另一方面要大幅降本,压力山大
解决:
a、第一轮,运维小伙伴拉流量,无流量服务应关尽关,应下尽下,应合尽合
b、第二轮,运维小伙伴拉各类峰值,先统一砍一刀(网络、数据库、主机)
c、第三轮,运维小伙伴看账单,按账单大头,如网络、数据库、主机等逐条应用降本方案
d、第四轮,运维小伙伴看账单,对于不合理的条目逐条检视,逐个逐个扣
e、第五轮,各项目组,结合业务实际情况,各自制定降本方案,限时落地
f、第六轮,技术委员会,对于20%的关键业务进行性能优化,逐步降本
g、第七轮,在运维小伙伴推动下,实现自动扩缩容,继续降本

【转载】长输入与少训练数据场景下的Transformer

原文地址:
Transformers for Long Inputs and Less Training Data,by Sebastian Raschka, on 2023-05-13

长输入与少训练数据场景下的Transformer

本文精选并汇总了22项人工智能研究亮点。当前,自然语言处理与计算机视觉领域正涌现出大量令人振奋的技术进展!

当然,我无法将所有前沿且具潜力的研究论文都纳入每月一期的《Ahead of AI》通讯。因此,下文列出了过去几周我精读或泛读过的、未入选主通讯的优质论文补充清单。

祝阅读愉快!

大语言模型

借助循环记忆Transformer(RMT)将Transformer上下文扩展至100万令牌及以上

https://arxiv.org/abs/2304.11062,2023年4月19日

研究人员提出利用循环记忆机制,将输入上下文长度扩展至200万令牌。作为对比,ChatGPT搭载的GPT-4模型当前最多支持8192令牌。该论文的核心思路是:将上一段的输出作为记忆,与下一段的输入序列嵌入一同递归传入模型。

figure01

Unlimiformer:支持无限长度输入的长程Transformer

https://arxiv.org/abs/2305.01625,2023年5月2日

该方法是现有预训练大语言模型的一层封装框架,无需额外微调权重,提出将自注意力机制卸载为k近邻(k-NN)检索操作。其核心思路是:将长输入编码为多个更小的文本块并存储在数据库中,随后针对每个注意力头,通过k近邻检索调取对应的文本块。

figure02
图示注解来源:https://arxiv.org/abs/2305.01625

分步蒸馏!用更少训练数据、更小模型尺寸超越大语言模型

https://arxiv.org/abs/2305.02301,2023年5月3日

研究人员提出了一种蒸馏机制,用于定制面向特定任务的小模型;与标准微调相比,该机制只需更少训练数据,就能实现更优的模型性能。首先,通过大语言模型提取推理依据(一种经过重述的提示),再将这些推理依据与类别标签用于有监督训练更小的任务专属模型。

figure03
图示注解来源:https://arxiv.org/abs/2305.02301

规模化语言反馈下的语言模型训练

https://arxiv.org/abs/2303.16755,2023年4月9日

现有的大语言模型微调方法(例如ChatGPT采用的基于人类反馈的强化学习),在微调过程中需要对模型生成的成对输出进行比较(例如用于训练奖励模型)。在该研究中,研究人员提出了一种名为“语言反馈模仿学习(ILF)”的替代方案:(1)用户让模型生成回复;(2)用户对回复提出修改要求;(3)基于修改后的最终回复对大语言模型进行微调。

figure04
图示注解来源:https://arxiv.org/abs/2303.16755

ResiDual:具备双残差连接的Transformer

https://arxiv.org/abs/2304.14802,2023年4月28日

自《Attention Is All You Need》提出原始Transformer架构以来,层归一化的放置位置一直是学界讨论的焦点(可参考:https://arxiv.org/abs/2002.04745 )。层归一化前放置残差连接(Pre-LN)易导致表示坍缩,层归一化后放置残差连接(Post-LN)则易出现梯度消失问题。该论文中,研究人员提出融合Post-LN与Pre-LN的连接方式,兼具二者优势的同时规避各自缺陷。

figure05
图示注解来源:https://arxiv.org/abs/2304.14802

有观点指出,NormFormer论文中已提出过类似思路,且架构更简洁(http://arxiv.org/abs/2110.09456)。

利用摘要令牌学习提示压缩

https://arxiv.org/abs/2304.08467,2023年4月17日

近来提示工程备受关注(此处无双关含义),但让大语言模型重复运行相似的提示难道不是一种算力浪费吗?研究人员设计了“摘要(gist)”令牌,将任务压缩为特殊令牌以节省算力。该思路与软提示微调类似(相关介绍见https://magazine.sebastianraschka.com/p/understanding-parameter-efficient ),同时还能泛化到全新的提示场景。

figure06
图示注解来源:https://arxiv.org/abs/2304.08467

大语言模型的涌现能力是海市蜃楼吗?

https://arxiv.org/abs/2304.15004,2023年4月28日

在大语言模型领域,“涌现能力”指的是训练过程中未被明确教授、却随着模型接触海量信息后理解与生成文本的能力提升而自然产生的能力(例如摘要、翻译等)。在这项最新分析中,研究人员发现有力证据表明,这些涌现能力并非单纯由模型规模扩大带来。研究人员认为,涌现能力是选取特定性能指标后产生的错觉,因此“可能是研究者选择指标后的人为产物”。

论AI生成文本检测的可行性

https://arxiv.org/abs/2304.04736,2023年4月10日

随着大语言模型与AI生成文本日益普及,研究人员重新探讨了“AI生成文本能否被可靠检测”这一饱受争议的话题。该研究表明,答案是肯定的。基于信息论边界,在大多数场景下,只要样本量足够,就能够检测出AI生成的文本。

最少人工监督下、从零开始的原则驱动型语言模型自对齐

https://arxiv.org/abs/2305.03047,2023年5月4日

研究人员推出了Dromedary模型,性能优于同级别Alpaca模型(Alpaca本身是基于LLaMA微调的模型)。与ChatGPT不同,Dromedary未采用基于人类反馈的强化学习;也不像Alpaca那样需要提取ChatGPT的提示-回复对。取而代之的是,研究人员提出了一种全新的自对齐方法:在指令提示后附加行为准则即可实现对齐。

大语言模型对齐的固有局限性

https://arxiv.org/abs/2304.11082,2023年4月19日

自2022年11月ChatGPT发布以来,大语言模型研究大量聚焦于指令微调与对齐,让模型对用户更有帮助、更低风险。该论文提出了名为“行为期望边界(BEB)”的理论框架,证明对齐只能减少、无法彻底消除不良与有害行为。结论是:经过对齐的大语言模型仍无法抵御对抗性提示攻击。

生成式搜索引擎的可验证性评估

https://arxiv.org/abs/2304.09848,2023年4月19日

基于大语言模型的生成式搜索引擎正快速兴起。研究人员对Bing Chat、NeevaAI、Perplexity AI和YouChat进行了审计,结果显示:尽管回复看起来信息丰富、行文流畅,但生成的句子中仅有51.5%完全有引用支撑,而引用中也仅74.5%确实能佐证对应句子。

figure07
图示注解来源:https://arxiv.org/abs/2304.09848

StarCoder:愿源码与你同在!

https://arxiv.org/abs/2305.06161,2023年5月9日

研究人员基于GitHub爬取的1万亿令牌开源代码(来自The Stack数据集),训练了一个参数量155亿、上下文宽度8k的大语言模型。在构建出StarCoderBase基础模型后,研究人员又用350亿Python令牌对其进行微调,最终得到的StarCoder模型性能超越了当前所有代码大语言模型。

大语言模型涌现出的自主科研能力

https://arxiv.org/abs/2304.05332,2023年4月11日

作者将多个大语言模型串联,构建了一个基于多模型的智能体,能够设计和规划化学实验,包括使用工具、浏览互联网开展实验。从技术角度看,多个大语言模型的串联方式能达到如此好的效果颇具亮点。但尽管标题吸睛,该系统尚无法替代科研人员提出原创假设与实验设计。

scGPT:利用生成式AI构建单细胞多组学基础模型

https://www.biorxiv.org/content/10.1101/2023.04.30.538439v1,2023年5月1日

看到Transformer等通用方法被应用到其他领域总是很有意思。该研究中,研究人员借鉴大语言模型的生成式预训练思路,在基因等单细胞测序数据上预训练基础模型。最终得到的预训练模型具备基因网络的零样本学习与聚类能力。

PMC-LLaMA:基于医学论文对LLaMA进行进一步微调

https://arxiv.org/abs/2304.14454,2023年4月27日

这是大语言模型在领域专属数据上的又一应用,不过采用的是微调而非预训练范式。研究人员发现,在医学数据上微调后的LLaMA模型,在医学任务上的表现优于预训练基础模型,也超过了ChatGPT。这一结果符合预期,同时也再次印证:随着企业追求优化大语言模型的任务表现,模型微调将变得越来越重要。

计算机视觉

作为掩码自编码器的扩散模型

https://arxiv.org/abs/2304.03283,2023年4月6日

与大语言模型不同,扩散模型的预训练无法生成可用于其他下游任务的强特征表示。为此,研究人员将扩散模型重构为掩码自编码器形式。该研究有望催生图像任务中扩散基础模型的全新前沿方向。

figure08
图示注解来源:https://arxiv.org/abs/2304.03283

分割一切

https://arxiv.org/abs/2304.02643,2023年4月5日

Meta的“分割一切(Segment Anything)”项目提出了全新的图像分割任务、模型与数据集。配套的图像数据集是目前规模最大的分割数据集,涵盖1100万张图像、超10亿个掩码。尤其值得称赞的是,研究人员使用的是获得授权、符合隐私规范的图像,因此模型可以开源,且无重大版权风险。

figure09
图示注解来源:https://arxiv.org/abs/2304.02643

一次性全场景全域分割

https://arxiv.org/abs/2304.06718,2023年5月13日

与上文提到的Segment Anything思路类似,该论文提出了一种支持提示交互的图像分割模型。但相比Segment Anything,该项目支持更多交互类型,且能完成更复杂的语义任务。研究人员表示,Segment Anything的提示仅支持点、框和文本,而他们的模型还支持其他形式的提示,并且能够完成全景分割与实例分割。

figure10
图示注解来源:https://arxiv.org/abs/2304.06718

Generative Disco:面向音乐可视化的文本生成视频技术

https://arxiv.org/abs/2304.08551,2023年4月17日

正如《Ahead of AI》第7期(https://magazine.sebastianraschka.com/p/ahead-of-ai-7-large-language-models )中提到的,未来几个月将涌现更多创意多模态研究,这便是其中之一:研究人员可根据用户的音乐描述提示生成视频片段。该论文提出的文本生成图像模型能够生成丰富多样的视频,输出示例包括抽象动画,以及看起来像在跟唱的动画角色。

对齐你的潜变量:基于潜扩散模型的高分辨率视频合成

https://arxiv.org/abs/2304.08818,2023年4月18日

该研究将扩散模型的文本生成图像思路拓展到了视频生成领域。有意思的是,研究人员能够直接复用现成的预训练图像扩散模型来完成这个文本生成视频项目。

figure11>
图示注解来源:https://arxiv.org/abs/2304.08818

大规模视觉-语言模型的稳定低精度训练

https://arxiv.org/abs/2304.13013,2023年4月25日

目前bfloat16(混合精度)已是各类模型的常用训练精度,而随着NVIDIA新款H100 GPU推出,8位浮点数也开始得到支持。那么量化训练的表现如何?研究人员提出了Switch-Back——一种用于int8量化训练的线性层,性能优于现有LLM.int8()基线,精度与bfloat16持平,同时训练速度提升约20%。

figure12
图示注解来源:
https://arxiv.org/abs/2304.13013

Patch Diffusion:更快、数据效率更高的扩散模型训练方法

https://arxiv.org/abs/2304.12526,2023年4月25日

Patch Diffusion通过提升数据效率,将扩散模型的训练速度提升了2倍,同时保持图像质量不变。在该研究的实验中,研究人员仅用5000个训练样本就训练出了具备竞争力的模型。该方法的核心思路是:引入随机裁剪图像块的块级信息参与训练。

本通讯是个人兴趣驱动的项目,无直接商业报酬。如果您愿意支持我,欢迎购买我的书籍(https://sebastianraschka.com/books)。如果您觉得内容有启发、有帮助,也欢迎推荐给身边的朋友和同事。

figure13
https://www.amazon.com/Machine-Learning-PyTorch-Scikit-Learn-scikit-learn-ebook-dp-B09NW48MR1/dp/B09NW48MR1/ , https://nostarch.com/machine-learning-and-ai-beyond-basics , and http://mng.bz/M96o

您的支持对我意义重大!非常感谢!

几个硬件问题导致的故障

1、更换服务器后,出现网络风暴
表现:
老服务器下架,新服务器上线后,出现网络风暴

原因:
逐步排查网口,猜测一根光纤出现问题

解决:
更换了一根光纤

2、老服务器下架后,新服务器重启后,VM集群无法启动
表现:
三台ESXI主机组了VSAN,重启后,网络互通,但服务器2被独立,无法加入1、3集群
VCSA也在VSAN上,同样无法启动。

原因:
故障时,只知道出现了脑裂,三台主机无法

解决:
重启了VPXA、重启了ESXI,没有解决问题
重建VSAN,然后把三个节点加入,问题就修复了
后续发现,其实时服务器1和服务器3出现了问题,自己组成了一个新的集群

导致惨重代价的运维事故2023

2023年12月:谷歌云新加坡区域故障
事件经过:因网络配置错误,导致谷歌云新加坡区域服务中断超3小时,影响大量企业客户。
事故原因:内部网络配置失误。
造成损失:客户业务中断,谷歌云赔付客户,市场竞争力受影响。

2023年11月:阿里云全线产品故障
事件经过:11月12日下午,阿里产品全线崩溃,波及全球多个地域全部云用户,持续事件达3.5小时。
事故原因:具说是鉴权服务出了问题。
造成损失:凸显云计算集中化部署风险,影响全球多地客户业务。
小插曲:两周后,在2023年11月27日,阿里云再次遭遇了近两小时的中断,影响到中国和美国的客户。然后当天晚上,滴滴就来了个大的。

2023年11月:滴滴崩溃
事件经过:11月27日晚间,滴滴崩溃,致APP地图无法加载、无法叫车,持续约12小时,影响多地用户。
事故原因:底层系统软件故障。
造成损失:订单流失,品牌形象和用户信任度下降。

2023年10月:新加坡Equinix数据中心制冷故障
事件经过:新加坡Equinix数据中心承包商误关闭冷冻水阀门,导致制冷系统误操作,造成2.5万笔银行交易失败、8.1万次登录失败。
事故原因:承包商操作失误,误关冷冻水阀门。
造成损失:金融交易及用户登录受严重影响,暴露运维管理漏洞。

2023年10月:语雀重大服务故障
事件经过:10月23日14时左右,语雀发生重大服务中断,在线文档和官网无法访问,当晚22时完全恢复,持续近8小时。
事故原因:内部运维工具缺陷,新上线升级工具bug导致华东生产环境存储服务器误下线,造成大面积服务中断。
造成损失:定性为P0级重大事故,影响数千万用户工作与知识管理,引发对运维自动化工具安全性的反思。

2023年6月:中国电信广东网络故障
事件经过:6月8日中国电信广东区域遭遇大规模网络服务中断,用户普遍无信号、无法通话上网,故障约4小时后恢复。
事故原因:网络设备故障。
造成损失:影响广东省内商务活动和民众生活,具体损失数据未公布。

2023年5月:苹果iCloud全球服务中断
事件经过:5月11日,苹果全球服务遭遇“史诗级”宕机,持续约55分钟。大量用户的Apple ID突然登出,无法访问iCloud照片、文件和备忘录等关键数据。
事故原因:数据中心严重故障。虽然苹果未详细披露,但此类核心服务中断通常源于数据中心底层存储或认证服务的配置错误或硬件集群故障。
造成损失:数千万苹果用户数据访问受阻,打破了苹果生态“稳定可靠”的神话,引发了对苹果云服务能力的广泛质疑。

2023年5月:微软Azure故障
事件经过:5月24日,微软Azure DevOps在巴西的一处scale-unit发生故障,导致宕机约10.5个小时。
事故原因:导致该中断的原因为一个简单的拼写错误,最终导致17个生产级数据库被删除。
造成损失:大量用户无法使用云服务。

2023年4月:中信证券APP交易阻塞
事件经过:4月期间,中信证券APP出现严重的交易阻塞现象,客户无法正常下单或撤单。
事故原因:系统软件缺陷与容量规划不足。在市场交易活跃期,系统未能有效处理高并发请求,暴露出软件逻辑缺陷和灾备能力的不足。
造成损失:直接影响客户交易,导致客户资金错失交易时机,引发大量客户投诉,对券商的声誉造成了直接的负面影响。

2023年3月:推特全球大规模宕机
事件经过:平台代码更新错误,导致全球用户无法登录或使用推特功能,持续超5小时。
事故原因:内部代码更新失误。
造成损失:用户体验差,广告收入受损,平台声誉下滑。

2023年3月:广州某电信机房制冷故障
事件经过:广州某电信机房水冷系统破裂引发制冷故障,微信、QQ及政务云系统瘫痪,机房被迫采用冰块临时降温。
事故原因:水冷系统破裂,制冷功能失效。
造成损失:国民级应用及政务服务中断,影响范围广、社会影响大。

2023年3月:腾讯云机房事故
事件经过:23年3月29日凌晨,腾讯云广州五区部分云服务异常,导致微信、QQ、支付等核心功能受到影响,故障在当天中午基本恢复。
事故原因:官方反馈为“本次事故由广州电信机房冷却系统故障导致”。
造成损失:核心应用不可用。

2023年3月:B站双重崩溃
事件经过:2023年B站经历了两次较为严重的全站级宕机。一次是3月5日,用户无法访问视频详情页、收藏夹;另一次是8月4日,视频封面无法加载、视频缓冲失败。
事故原因:底层服务依赖故障与机房电力问题。虽然具体细节未完全公开,但此类大型视频平台的崩溃通常源于核心微服务依赖失效或机房电力/网络架构的单点故障。
造成损失:数亿用户无法正常观看视频,严重影响用户体验和社区活跃度,尤其在流量高峰期的崩溃对品牌形象损害较大。

2023年3月:唯品会P0级宕机事故
事件经过:3月29日凌晨00:14至中午12:01,唯品会南沙IDC冷冻系统故障,机房温度骤升导致大规模宕机,线上商城停服12小时。
事故原因:制冷设备故障。
造成损失:影响800万人次客户,直接业绩损失超亿元,定性为最高级别P0级故障。
小插曲:事故后,对基础平台部负责人予以免职。

2023年2月:甲骨文多日长故障
事件经过:2月13日至15日,甲骨文云基础设施(OCI)遭遇持续长达数天的服务中断,这是OCI历史上罕见的长时间故障。同时,其子公司NetSuite也因关联故障停摆。
事故原因:DNS后端基础设施性能问题。支持OCI公共域名系统的后端API基础设施出现性能瓶颈,导致无法处理传入的服务请求;此外,NetSuite的故障还叠加了合作伙伴数据中心(Cyxtera)的物理电力故障。
造成损失:客户业务连续数天无法使用云资源,甲骨文“永不宕机”的宣传口号受挫,大量依赖其数据库服务的企业陷入停滞。

2023年1月:美国民航系统瘫痪
事件经过:1月11日美国联邦航空管理局飞行任务通知系统因关键文件损坏瘫痪,备份系统也检测到相同损坏,重启系统导致全美航班禁飞。
事故原因:系统文件损坏。
造成损失:超4000架次航班延误,698架次取消,数十万旅客受阻,经济损失巨大,暴露单点故障风险。

如何通俗解释数字化转型

咱们做技术的人,都喜欢起名字:信息化、数字化、数字平台、数字化转型、数智平台等,让很多人一开始觉得好高大上,然后又开始发懵,这些词之间有什么区别呢?试着通俗解释一下:

1、信息化
把组织线下业务流程,放到线上的过程。
比如,咱们学校上线了考勤系统、选课系统,这就是一个信息化的过程

2、数字化赋能阶段一:数字报表
在信息化的过程中,产生了部分的数据,对这部分数据进行挖掘提炼,得到一些报表,对组织经营起到了一定的提升作用。
比如,大家经常能看到的各类系统报表,通过经营分析报表,指导管理经营行为。

3、数字化赋能阶段二:数字平台
信息化建设后,各个系统之间是割裂的,各系统之间数据是互不相通的。
如何将数据打通,让组织运营者,可以对企业状况一览无余。
比如各类数据平台项目、数字平台项目,一般都会为运营者提供各类“驾驶舱”或Dashboard。
其实就是为管理者开了天眼,有了全局视角。

4、数字化赋能阶段三:自动化平台
当企业数字化建设到一定程度的时候,很多管理规则可以抽象并固化为系统规则,不需要人干预即可处理事情。
比如自动化制造、自动化质控、自动化风控、甚至量化交易等等。

5、数字化赋能阶段四:智能数字化平台,或数智平台
在3的基础上,引入了一些物联网技术、智能终端技术等,一方面让运营者可以快速感知一线情况,一方面可以快速决策反馈。
比如电商平台发现交易异常的时候,会触发智能平台的规则,自动止血;或者一些智能可穿戴设备,实时监控患者病情,及时进行干预。

6、数字化转型
但组织到了一定的发展阶段,传统的运营方式,已经无法支撑组织进一步的快速发展。
需要自上而下的去调整思路,用数字化运营的方式,重塑组织的运营方式,这其中数字化技术只是一个手段。
以华为为例,他们建立了基础IT架构(华为云),打造了统一的数据底座,提供了统一的数字服务,使用了大数据、AI、IoT等技术,最终通过数字化重构了业务运营方式,包括数字化作业、数字化交易、数字化运营、数字化办公等,从而造就了了华为近10年的飞速发展。
对于咱们老年人慢病管理,我们同样需要技术架构,同样需要统一的数据底座,同样需要封装统一的数字服务,同样可以使用大数据、AI、IoT等技术,但最终要重构哪些业务的运营方式,要重构成什么样子,就是咱们课题组要考虑的了。
比如,我们通过数据分析,可以主动为各类患者提供各类服务(比如糖尿病患者),比如:量身定制适合各自的治疗及追踪方式,量身匹配到不同的家庭医生,提前把患者需要的药帮患者准备好,提前把社区医院的耗材准备好等等等等。

7、数字化赋能与数字化转型的区别
7.1、数字化赋能
业务V1.0+数字技术=》业务A V1.1
7.2、数字化转型
业务 V1.0+自上而下的数字化运营体系+技术体系支持=》业务 V2.0

微服务性能调优01

近期遇到一些技术问题,记录如下:

1、kafka并发处理量上不去
数据流:
数据生产服务-》kafka-》数据消费服务
表现:
数据消费服务加了很多个实例,但总感觉多数实例不工作
原因:
分析后发现,原来开发小伙伴把所有消息都扔到了同一个topic中,而分区只有3,消费者再多这并发量也上不去啊
解决:
按不同业务,拆分topic,同时增加分区数
同时,建议把一堆操作拆分为多个步骤进行,不要都放到一个方法里全部做掉,宁可多流转几次各司其职

2、数据上报并发处理量上不去
数据流:
DB-》轮询-》HTTP提交数据到数据上报网站【ZF】
表现:
要求4小时上传60W,实际1小时上传5K
原因:
问题很多,主要有两个,一是每次只上传一条数据,二是没有做并发
解决:
一开始准备做很大的调整,但后面项目组怕把开并发把数据上报网站压挂,最后没敢使用
最后,只是改造为批量上传数据,轮询时根据id做了一下简单的并发
数据上报网站,各地接口及要求各不一样,也是各种不容易吧

3、莫名奇妙的403
数据流:
浏览器-》网关-》鉴权服务
表现:
网关偶尔返回403
原因:
一开始日志输出太少,都没有定位到哪里的问题,只能临时在网关补充了一些日志【建议加了开关,定位问题后关闭】
加日志后,发现是一段上古代码,使用信号量进行了并发控制,超出了并发就获取不到用户权限。
而这个Bug暴漏出来,据反馈,居然是升级组件导致的。
遗留系统都是坑啊。
解决:
优化鉴权服务,定位到问题,问题也就解决了

4、无法提升的微服务性能
数据流:
浏览器-》网关-》N个服务来回调用
表现:
服务性能差,有时要几十秒才返回,一堆告警邮件
原因:
微服务拆分粒度太细,形成环状调用链路
开发同学无脑调用微服务,能调用一次的,居然会循环调用N次
解决:
重构,按业务领域合并微服务,微服务数量少了60%,同时干掉环状调用链
评审,找到不合理的循环调用,抓典型,整改

5、批量导出
数据流:
浏览器-》网关-》导出服务-》DB
表现:
批量查询、批量导出性能很差,要按分钟返回的,一堆告警邮件
原因:
数据量太大,DB拉取速度慢,数据回传也慢
解决:
根据业务情况,部分批量查询功能改到只读库查询,大批量导出功能迁移到了数据中台

6、数据批量下发
数据流:
数据中台-》kafka-》数据下发接收服务
表现:
数据中台下发数据,无法更新到下游业务系统
原因:
因安全需求,上游业务系统批量刷新数据库,导致数据中台下发大量数据,数据下发服务处理不及时,积累了大量数据待处理
下游业务系统把一堆业务逻辑放到了接收服务中,处理单条业务数据要按秒计算,数据越积越多
你没想错,kafka并发上不去,和之前原因一样一样的
解决:
接收服务简化,拆分不必要的业务逻辑,服务性能提高了几百倍
优化kafka配置
制定了批量刷新数据库的相关流程,都是泪
历史数据咋处理?和上游系统沟通后,99.9%的数据不必处理,于是忽略了历史积累数据,晚上将0.1%的数据进行了重推,解决了问题

7、Kafka卡顿
数据流:
系统A-》kafka-》系统B
表现:
kafka在半夜性能下降明显,从日志上看,就是工作2分钟,卡5分钟
原因:
kafka的消费者每次取了太多消息去消费,半夜为业务高峰期,部分消费者获取消息无法及时处理完毕,导致kafka会出发rebalance,你懂的
解决:
每次少取一些数据

8、HTTPS通讯失败
数据流:
前置系统A-》云-》云上系统B
表现:
有两家用户的数据无法连通云服务,HTTPS通讯失败
原因:
前置服务的服务器器时间错误,数据包被云的安全策略直接丢弃,被当成重放攻击了
解决:
开启前置服务自动时间同步服务

9、组件升级导致服务性能下降
表现:
系统组件升级后,系统整体服务性能下降,会有部分请求阻塞5S以上
CPU、内存、IO看起来都比较正常
生产环境才有问题,测试环境下无法复现
原因:
通过打印线程信息,发现存在大量网络IO阻塞
后定位到了一个可疑的点,日志同时输出到log文件和命令行时,命令行也发送到了log文件,会有阻塞
解决:
只输出到命令行,有待观察

整体经验:
1、微服务粒度不能太细,也不能一个服务啥都干,最好按业务领域进行拆分。业务量小的领域可以适当合并,业务逻辑复杂的考虑拆分。
2、微服务也应该分层次,不要出现环状调用链路
3、日志要足够判断问题所在,太多影响性能,太少没啥用
4、中间件不能熟练配置,不要随便上生产
5、批量操作要用特殊处理方式,没事别刷库

导致惨重代价的运维事故2022

2022年12月:阿里云香港Region大规模宕机
事件经过:12月18日,阿里云香港Region可用区C发生大规模服务中断,持续数小时,为其运营十多年来最长大规模故障,新购ECS等管控操作全部失败,整个处置过程超过15小时。
事故原因:机房冷却系统失效,现场包间温度逐渐升高,导致一机房包间温度达到临界值触发消防系统喷淋,电源柜和多列机柜进水,部分机器硬件损坏。
造成损失:严重影响香港及澳门客户业务,品牌信誉受损,事后发布事故说明及改进措施。
小插曲:事故后,阿里云总裁、CTO都被更换。

2022年12月:达美航空(Delta)行李系统故障
事件经过:12月28日,达美航空的行李处理系统突发严重故障,导致全球多个主要机场的行李传送带停摆,大量行李无法被正确分拣和装载。
事故原因:硬件维护不当与软件集成失效。由于行李处理系统的物理传感器和分拣机械臂出现故障,且后台管理系统未能及时切换至备用模式,导致系统“死锁”。
造成损失:数千名旅客的行李丢失或延误,圣诞节假期返程高峰受阻,达美航空被迫手动处理行李,运营陷入混乱。

2022年12月:腾讯云北京地域部分服务器故障
事件经过:因网络设备故障,导致北京地域部分云服务器、数据库等服务访问异常,持续约3小时。
事故原因:网络设备故障引发的运维事故。
造成损失:部分企业业务中断,腾讯云紧急修复并赔付客户。

2022年8月:谷歌爱荷华州数据中心电气爆炸
事件经过:谷歌美国爱荷华州数据中心发生电气爆炸,造成3名电工严重烧伤,全球1338台服务器中断,谷歌地图、搜索服务宕机。
事故原因:电弧闪光引发爆炸。
造成损失:人员受伤,设施损毁,核心服务中断影响全球用户。

2022年7月:Twitter全球大规模宕机
事件经过:7月14日上午8:10左右开始,Twitter突发全球性大规模服务中断,持续约1小时。
事故原因:内部系统配置与软件故障,引发了连锁反应。
造成损失:全球数万用户受影响。
小插曲:正值Twitter起诉马斯克违约的敏感时期,加剧了外界对其内部管理混乱的猜测。

2022年7月:B站713事故
事件经过:2022年7月13日,B站崩了5个小时。
事故原因:根据B站的事故分析报告,是SLB故障导致。本次SLB故障,是OpenResty中,计算gcd的lua代码传入了0值,被lua判定为nan,陷入了死循环。这段lua代码已经稳定运行了一段事件,但一个新发布模式,却触发了这个bug。
造成损失:B站核心业务中断。

2022年7月:Oracle Cloud(甲骨文)核心故障
事件经过:7月19日,甲骨文云服务(Oracle Cloud Infrastructure, OCI)发生严重故障,导致其核心金融、ERP等SaaS服务在全球范围内无法访问。
事故原因:关键配置错误。运维人员在对核心网络基础设施进行配置更新时,引入了错误的路由策略,导致控制平面(Control Plane)瘫痪,客户无法管理或访问其云端资源。
造成损失:依赖甲骨文系统的大型企业财务和运营流程中断,凸显了传统企业级云服务在运维操作上的风险。

2022年3月~5月:招商证券交易系统连环崩溃
事件经过:3月14日开盘后系统突发故障,用户无法成交、撤单;5月16日系统再次崩溃,电脑端、手机端均无法登录。
事故原因:交易系统技术缺陷。
造成损失:严重扰乱交易秩序,引发投资者不满和监管关注,母公司对相关负责人问责,质疑券商IT系统稳定性。

2022年3月:富途证券(Futu)全球大宕机
事件经过:3月14日,互联网券商富途证券(牛牛APP)发生全球范围内的服务中断。用户无论是通过网页端还是手机APP,都无法登录交易系统,也无法查看持仓和进行交易,故障持续了数小时。
事故原因:底层架构扩容引发的连锁故障。在进行系统扩容升级时,运维团队对流量预估不足,且核心网关组件未能正确处理扩容带来的配置变更,导致负载均衡失效,流量无法分发至后端服务器。
造成损失:正值美股交易时段,大量投资者无法操作,引发用户强烈不满和投诉,对券商口碑造成负面影响。