1. 从机器学习到百模大战

众所周知，目前我们实现人工智能的主要技术手段是机器学习技术，特别是其中基于深层神经网络的深度学习技术。机器学习的本质是通过具有学习能力的算法、对数据进行建模的技术。深度学习借助大规模的算力解决了机器学习中特征表示的人工干预的瓶颈，在效果上取得了巨大突破。因此，机器学习成为目前人工智能的主流技术。

深度学习和生成式大模型之间的关系，如下图右侧所示，在 2012 年至 2016 年左右，像卷积神经网络、对抗生成网络、ResNet 等经典的深度学习模型，已经在计算视觉、语音识别、自然语言处理等领域取得了显著的效果提升。这些经典深度学习模型既有判别式、也有生成式，它们往往会在 ImageNet、COCO 等有标注的数据集上进行预训练，形成带有预训练权重、可以进一步进行 Fine-tuning 的预训练模型。

在 2017 年之后，Transformer 结构在自然语言处理领域首先被成功应用，在这之后以 Transformer 为基础组件的生成式大模型逐步成为视觉、自然语言处理、跨模态理解和生成领域的主流技术。这类技术通常以 Transformer 和注意力机制作为组件，并且它可以并行地进行自监督学习，参数规模在十亿以上。其中，将生成式大模型技术应用在语言建模上的方式，被称为「大语言模型」。在经过进一步的调优之后，形成了像 ChatGPT、文心一言等被大家熟知的对话式、生成式大语言模型应用。

​

在过去的半年，我们经历了一场百模大战。尤其是在开源社区，新的大模型如雨后春笋般涌现，而大模型相关的技术也越来越标准化、同质化。在这里为大家分享一个小故事。我们可以在大模型中了解到很多「驼」系英语词汇，比如 Llama 是美洲驼，Alpaca 是羊驼，Vicuna 是小羊驼。

为什么有那么多以「驼」命名的大语言模型？因为大语言模型 Large Language Model 的缩写是 LLM，2 个 L 放在一起不方便读出来，Meta 公司为了方便大家记忆，所以选了相近的词语 Llama（美洲驼）。后来很多基于 Llama 开源模型进行调优和构建的大语言模型，都以「驼」系的名称命名。

如下图所示，我们可以看到在硅谷的大模型创业公司中，除 OpenAI 外，目前已有将近 1/3 的资金投入了 MLOps 和 LMOps 相关的平台和工具方向。接下来，我将为大家详细拆解，在百模大战的背后，为什么 MLOps 和 LMOps 平台和工具能够获得资本的青睐。

​

首先看看大模型在技术和应用层面带来了哪些变化。比如在以下 4 个技术层面：

1. 大模型训练对网络的要求

我们先来聊聊大模型训练对网络的需求。

最近半年以来大模型持续火爆。虽然关于大模型的发展与应用还有很多的争论，但可以肯定的是，大模型能力已经成为了接下来人工智能发展的基础。

和以前的小模型相比，大模型对大规模的分布式并行训练有更强的诉求。

这一方面是因为模型本身非常大。受制于今天的 GPU 显存限制，我们不得不把一个模型分拆到很多个 GPU 上来存储。比如说，百度的文心大模型有 2600 亿个参数，但是实际上一个 80G 显存的 A800，算上训练中间的计算状态，也只能存放大概 10 亿-20 亿参数。那显然光是存放 2600 亿的模型本身，就需要一两百块 GPU。这已经是一个比较大的规模了。

另一方面，因为训练更多的参数需要更多的计算量，因此我们必须得引入更大规模的 GPU 来进行加速，所以我们需要的 GPU 又要有一个数量级的提升。

在百度我们根据一个任务的 GPU 卡数来命名训练的规模。比如百卡以下我们叫小规模，百卡到千卡我们叫中规模，千卡以上我们叫大规模，超过万卡我们则以超大规模进行命名。依照这个命名方式，我们可以说，千卡以上的大规模并行训练是大模型成功的基础。

​

分布式并行训练有多种策略，我们这里列举出常用的三种。

NLP的技术原理

首先，我们要弄明白，NLP任务（自然语言处理，AI的一个技术领域，即文本类的AI任务）的核心逻辑是一个“猜概率”的游戏。

比如说，“我今天被我朋友___”，经过大量的数据训练后，AI预测空格出会出现的最高概率的词是“放鸽子了”，那么CPU就会被填到这个空格中，从而答案产生——“我今天被我朋友放鸽子了”

虽然非常不可思议，但事实就是这样，现阶段所有的NLP任务，都不意味着机器真正理解这个世界，他只是在玩文字游戏，进行一次又一次的概率解谜，本质上和我们玩报纸上的填字游戏是一个逻辑。只是我们靠知识和智慧，AI靠概率计算。

在近几年的自然语言处理领域中，BERT和GPT是两个引起广泛关注的语言模型。特别是在GPT3.5的基础上进行微调的chatGPT，持续出圈和火爆。chatGPT的火爆表明了预训练语言模型在自然语言处理领域具有巨大的潜力，并且在提高自然语言理解和生成能力方面取得了显著的进展。这可能会带来更多的应用和更广泛的接受。

BERT和GPT也都是基于预训练语言模型的思想，通过大量的语料训练而得到的高效率的语言模型。为了帮助大家更好的理解和选择不同的技术和模型，本文将着重比较BERT和GPT这两个语言模型之间的区别，为大家提供一个全面的认识。

在设计系统时，应该多考虑 墨菲定律：

• 任何事物都没有表面看起来那么简单。
• 所有的事都会比你预计的时间长。
• 可能出错的事总会出错。
• 如果你担心某种情况发生，那么他就更有可能发生。

在划分系统时，应该多考虑 康威定律：

• 系统架构是公司组织架构的反映。
• 应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本。
• 如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。
• 在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。

copy from: https://www.zybuluo.com/TryLoveCatch/note/1809593

研发工程师的基本功

1. 需求的交付能力；
2. 系统的设计与架构能力；
3. 行业对标与演化改进能力；

想要系统化的提升基本功，首先要全面的对我们所接触到的技术要素做分解，站在全局进行思考。

规划

• 为什么要做？
  以客户为中心，从业务角度出发，业务最关心什么，我们不做会不会影响业务的核心指标
• 为什么现在做？
  时间上 dead line
• 为什么是我们做？
• 怎么做
  拆解

一个规划应该主要分为：

• 背景
  业务理解，内部现状、业务影响、外部变化、背景总结
• 目标
  根据背景要能推出来目标，也可分短期和长期目标，或者业务目标和技术目标，或者定性目标和定量目标
• 方案
  方案是要解决背景中遇到的问题
• 指标
  如果衡量结果的好坏呢
• 规划
  具体的方案拆解，子任务拆解，具体到人和时间，每一个子任务应该是里程碑
• 风险以及应对
  技术风险、资源风险、质量风险等或者业务维度（抓重点解决核心问题）、技术维度（难度）、组织维度（资源不足）、流程维度

技术要素拆分法（BeafQPS）

组成

1. 行业对标 Benchmark
2. 效率 Efficiency
3. 架构 Architecture
4. 功能 Feature
5. 质量 Quality
6. 性能 Performance
7. 安全 Security

1.监控

1.1 监控的目的

• 了解业务量级增长
• 感知系统健康度
• 告警 -> 及时发现问题

可用性量化： MTTF， MTTR， SLA， SLO

1.2 好的监控体系应该做到哪些？

• 指标全面，但不冗余.
• 报警敏感，但不误报
• 自动发现问题，以及分析原因

1.3 监控指标

USE (Utilization Saturation and Errors）： 将注意力集中在处理工作负载的资源上。目标是了解这些资源在存在负载时的行为方式。

• 使用率，表示资源用于服务的时间或容量百分比。100% 的使用率，表示容量已经用尽或者全部时间都用于服务。
• 饱和度，表示资源的繁忙程度，通常与等待队列的长度相关。100% 的饱和度，表示资源无法接受更多的请求。
• 错误数表示发生错误的事件个数。错误数越多，表明系统的问题越严重。

RED（Request Throughput，Error Rate, Duration Time）: 它是由资源提供服务的工作负载行为的外部可见视图

四个黄金信号: 延迟（Latency），流量（Traffic），错误（Errors）和 饱和度（Saturation）

前言

翻开2020的总结，突然发现，这一年与之前计划变化较大，中途未能及时的根据规划进行调整。时间过得很快，一晃就是一年，很多直接目标，现在看来完成的都不尽人意。中途还有一些重大的变化，如去了另外一个事业部，做着和之前很不同的工作，回到了成都工作等。总结还是需要经常得回顾，不然就会忘却之前的计划。

一、 2021年总结

请重点回顾在本人在周期内的关键策略进展、重要进展、目标达成等。

1、个人目标

上阶段有什么个人目标

2、目标完成情况及工作成果

上阶段目标完成情况，取得了什么亮点/成果（如有对标情况，请列举），有什么认知迭代

认知迭代

工作上：换了一个事业部，工作从头开始，不能直接将原来团队的模式作用在这边，特别在对团队文化，节奏还未完全摸清，外加领导不怎么管事的情况下。如何处理好团队关系和领导关系，是接下来需要去摸索和学习的。

投资上：摒弃了频繁交易，做长期主义者，重点关注未来大趋势的行业。另外从这两个月就亏掉之前的盈利来看，长期主义要忍受回调带来的痛楚，另外也要关注估值，高估值一定会回调，但又担心错失后面的涨，如何把握这节奏，是后面需要去提炼的。

晋升答辩：今年参加了下美团的晋升答辩，最终结果不甚满意，其中暴露了自身很多问题，首先PPT思路，另外讲也没讲好，在内容上，未能做好调研和对标，工作细节不突出。

前面两章，讲解了秒杀系统在性能上面的优化，以及如何处理瞬时流量巨大下系统的稳定性，但对于秒杀系统，还有一个核心问题：如何保障在秒杀时，不出现库存超卖的情况。

另外秒杀系统针对流量巨大的考验，我们也需要如果系统扛不住了，如何最低损失的去保障服务的可用，对于服务的高可用，需要考虑到系统建设的各个阶段。

库存设计

减库存有哪几种方式

在正常的电商平台购物场景中，用户的实际购买过程一般分为两步：下单和付款。你想买一个商品，在商品页面点了“立即购买”按钮，核对信息之后点击“提交订单”，这一步称为下单操作。下单之后，你只有真正完成付款操作才能算真正购买。

那么你会在哪个环节完成减库存的操作呢？总结来说，减库存操作一般有如下几个方式：

• 下单减库存，即当买家下单后，在商品的总库存中减去买家购买数量。下单减库存是最简单的减库存方式，也是控制最精确的一种，下单时直接通过数据库的事务机制控制商品库存，这样一定不会出现超卖的情况。但是你要知道，有些人下完单可能并不会付款。
• 付款减库存，即买家下单后，并不立即减库存，而是等到有用户付款后才真正减库存，否则库存一直保留给其他买家。但因为付款时才减库存，如果并发比较高，有可能出现买家下单后付不了款的情况，因为可能商品已经被其他人买走了。
• 预扣库存，这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 10 分钟），超过这个时间，库存将会自动释放，释放后其他买家就可以继续购买。在买家付款前，系统会校验该订单的库存是否还有保留：如果没有保留，则再次尝试预扣；如果库存不足（也就是预扣失败）则不允许继续付款；如果预扣成功，则完成付款并实际地减去库存。

以上这几种减库存的方式都会存在一些问题，下面我们一起来看下。

减库存可能存在的问题

由于购物过程中存在两步或者多步的操作，因此在不同的操作步骤中减库存，就会存在一些可能被恶意买家利用的漏洞，例如发生恶意下单的情况。

假如我们采用“下单减库存”的方式，即用户下单后就减去库存，正常情况下，买家下单后付款的概率会很高，所以不会有太大问题。但是有一种场景例外，就是当卖家参加某个活动时，此时活动的有效时间是商品的黄金售卖时间，如果有竞争对手通过恶意下单的方式将该卖家的商品全部下单，让这款商品的库存减为零，那么这款商品就不能正常售卖了。要知道，这些恶意下单的人是不会真正付款的，这正是“下单减库存”方式的不足之处。

上一篇介绍了秒杀系统整体架构可以概括为“稳、准、快”几个关键字，其中讲解了通过动静分离来实现高性能。这一篇会讲解秒杀系统相对于其他系统很不同的特点，就是“热点”问题和瞬时请求量巨大问题。

热点问题

热点带来的影响

首先，热点请求会大量占用服务器处理资源，虽然这个热点可能只占请求总量的亿分之一，然而却可能抢占 90% 的服务器资源，如果这个热点请求还是没有价值的无效请求，那么对系统资源来说完全是浪费。

其次，即使这些热点是有效的请求，我们也要识别出来做针对性的优化，从而用更低的代价来支撑这些热点请求。

“热点”包含哪些

热点分为热点操作和热点数据。所谓“热点操作”，例如大量的刷新页面、大量的添加购物车、双十一零点大量的下单等都属于此类操作。对系统来说，这些操作可以抽象为“读请求”和“写请求”，这两种热点请求的处理方式大相径庭，读请求的优化空间要大一些，而写请求的瓶颈一般都在存储层，优化的思路需要根据 CAP 理论做平衡。

而“热点数据”比较好理解，那就是用户的热点请求对应的数据。而热点数据又分为“静态热点数据”和“动态热点数据”。

所谓“静态热点数据”，就是能够提前预测的热点数据。例如，我们可以通过卖家报名的方式提前筛选出来，通过报名系统对这些热点商品进行打标。另外，我们还可以通过大数据分析来提前发现热点商品，比如我们分析历史成交记录、用户的购物车记录，来发现哪些商品可能更热门、更好卖，这些都是可以提前分析出来的热点。

所谓“动态热点数据”，就是不能被提前预测到的，系统在运行过程中临时产生的热点。例如，卖家在抖音上做了广告，然后商品一下就火了，导致它在短时间内被大量购买。

由于热点操作是用户的行为，我们不好改变，但能做一些限制和保护，所以本文我主要针对热点数据来介绍如何进行优化。

随着互联网流量的增大，秒杀瞬时流量达到百万甚至千万OPS，秒杀系统也从商品详情系统独立出来成为一个独立的系统。

那么，如何才能更好地理解秒杀系统呢？在我看来，秒杀其实主要解决两个问题，一个是并发读，一个是并发写。并发读的核心优化理念是尽量减少用户到服务端来“读”数据，或者让他们读更少的数据；并发写的处理原则也一样，它要求我们在数据库层面独立出来一个库，做特殊的处理。另外，我们还要针对秒杀系统做一些保护，针对意料之外的情况设计兜底方案，以防止最坏的情况发生。

而从一个架构师的角度来看，要想打造并维护一个超大流量并发读写、高性能、高可用的系统，在整个用户请求路径上从浏览器到服务端我们要遵循几个原则，就是要保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。

其实，秒杀的整体架构可以概括为“稳、准、快”几个关键字。

所谓“稳”，就是整个系统架构要满足高可用，流量符合预期时肯定要稳定，就是超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。

然后就是“准”，就是保证库存的准确。一旦库存不对，那平台就要承担损失，所以“准”就是要求保证数据的一致性。

最后再看“快”，“快”其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。