ml

_posts/Kubernetes/Object/2015-03-03-kubernetes_pod.md

@@ -155,6 +155,16 @@ type PodStatus struct {
 
 ## kubectl drain 发生了什么
 
+Pod 驱逐分为两种情况：
+1. 较安全驱逐 & 提高稳定性的良性驱逐
+   1. API  发起驱逐，典型案例：kubectl drain
+   2. Node Not Ready 时，Controller Manager 发起的驱逐
+2. 有风险的驱逐
+   1. 节点压力驱逐：节点磁盘空间不足、内存不足 或 Pid 不足， kubelet 发起驱逐；节点内存不足，内核发起 OOM
+   2. 节点打污点（NoExecute），导致 Pod 被驱逐，或者移除亲和性标签，导致 Pod 被驱逐， Controller Manager 发起的驱逐
+   3. Pod 超过自身 Limit 限制， 内核用满，临时存储用满等
+   4. 优先级抢占驱逐
+
 [Kubernetes Pod 删除操作源码解析](https://mp.weixin.qq.com/s/L-CQhYzxqxOoy9xYp6-JMA)
 
 kubectl drain 将以某种方式驱逐 Pod。drain 将向控制平面发出删除目标节点上的 Pod 的请求。通过 API 将 Pod 从集群中删除后，所有发生的事情就是该 Pod 在元数据服务器中被标记为要删除。这会向所有相关子系统发送一个 Pod 删除通知

_posts/Life/2018-09-04-technology_manage.md

@@ -75,9 +75,10 @@ keywords: technology manage
 6. 当领队，独自筹划大部分事情
 7. 不错的领队
 
-
 小伙伴若是自驱动不高的话，其实是对任务负责。而小队长是对项目负责的。项目成功跟小伙伴干完具体的活儿之间有大量的事情规划、协调、踩着石头过河。直接对结果负责的人其实最累的。
 
+晓斌：管理者需要认识、理解以及建立这些高标准，并不断和团队成员传达。各个层级各个岗位的标准和要求是什么？员工晋升是因为他 / 她的哪些行为体现了下一层的要求？就日常细节工作的高标准，什么是优秀的设计文档？什么优秀的 PRD 文档？什么是高质量的代码？什么行为体现了客户第一？定义清晰的高标准并不是一件容易的事，更常见的情况反而是作为管理者自己也不知道高标准是什么（参考彼得原理），这可能是很多员工收到负反馈就感觉是被 PUA 的核心因素（“你都是个 P7 了，你自己应该知道怎么做好”）。我建议管理在想要给下属负反馈的时候自己先回答这个问题，“我是否可以清晰地和下属表达我期望看到哪些行为的变化？用具体的事例描述。”不要模棱两可。
+
 **同理心，不是发慈悲，而是一种策略**。它要求你能了解下属的能力，并善于发挥下属的能力。
 
 [这年月只能靠手艺吃饭了](https://mp.weixin.qq.com/s/5bzJR0qlkUrMHnuIsMnnXA) 以亲身经历列出了技术管理的几个阶段。

_posts/MachineLearning/LLM/2023-10-18-meditation.md → _posts/MachineLearning/2023-10-18-meditation.md

@@ -108,6 +108,9 @@ AI和互联网最大的区别是，互联网越过0分就具有了实用价值
 
 信息平权：大模型的商业落地相比互联网目前有一个非常巨大的区别，就是**边际成本仍然非常高**。过去的互联网业务，增加一个用户对互联网厂商的基础设施而言，增加的成本几乎是可以忽略不记的。但今天大模型每增加一个用户，对基础设施增加的成本是肉眼可见的增加的，目前一个月几十美元的订阅费用都不足以抵消背后高昂的成本。而且今天的大模型要大规模商业化，在模型质量、上下文长度等方面还有进一步诉求，实际上还有可能需要进一步增加这个边际成本。今天一个日活千万的通用大模型需要一年超过100亿的收入才能支撑其背后的数据中心成本，未来如果我们希望大模型产业真正像今天的互联网产业一样服务上亿人，模型的质量可能也需要进一步上一个台阶，成本会成为很严重的问题。但对于芯片行业而言，只要适当拉长时间尺度，这些都不会是问题。在不远的未来，芯片行业就可以把上下文窗口逐渐变得和今天的内存一样非常便宜，随便一个hello world就直接吃掉MB级别的内存，随便一个应用就GB级别的内存占用。未来我们也一样可以随随便便把一个领域的全部知识装进上下文里，让大模型成为绝对意义上的领域专家，也可以让大模型拥有远超人类一辈子能接受的全部上下文，从而引发大模型走向新的质变。最近几年其实说摩尔定律放缓的观点很多，这也是实际情况，先进工艺的研发投入资金也在指数级飙升，使得维持摩尔定律逐渐变得失去经济性。但芯片行业的Scaling不只是晶体管的微缩推动的，NVidia的GPU过去十年靠架构继续推动放缓的摩尔定律持续保持非常高的增速，算力成本降低了一千倍。而今天大模型进一步打开了更多芯片的演进空间，**今天大模型对芯片的需求从算力转向了内存和互联，内存系统和互联的Scale空间更大**，除了半导体工艺的演进外，封装工艺的发展、硅光都对内存和互联的设计打开了巨大的空间。大模型今天也早已经全面走向分布式，今天不仅仅是单颗芯片的设计，也进一步扩展到服务器、机柜、网络层面，这些层面都有比原来有大得多的设计空间，未来芯片的增速不仅不会放缓，反而会比今天更快。**我们需要足够多的高带宽内存通过互联系统连接起来形成一个巨大的高带宽内存来支撑大模型的服务**。我们经常讨论的售卖Token的价格，实际上Token和Token是不一样的，一个7B模型的Token和千亿万亿模型的Token肯定不等价，一个4K上下文的Token和一个2M上下文的Token也不等价。Token的质量实际上和模型规模以及上下文窗口都是强相关的。**模型权重是模型在训练时候对整个数据集的压缩和泛化，是对世界和常识的理解，而上下文对应的KV-Cache是对上下文的理解**。而权重和KV-Cache其实也是大模型对内存最主要的需求，这部分的访存速度也决定了Token生成的速度。售卖Token对硬件系统而言实际上是售卖内存系统的访存带宽。一个容量足够大的内存系统才能提供足够高质量的Token服务，一个内存带宽性价比足够高的系统才能带来更好的服务成本。物理世界中的内存介质选择往往要带宽就没有容量、要容量就没有带宽。所以今天继要容量大又要带宽性价比高，往往需要通过足够有性价比的互联系统将大量高带宽内存连到一起，这里面是存在非常大的设计空间的。这也是中国AI芯片行业真正实现商业化的一次巨大机会，过去十年大家都是在卷算力，算力的竞争往往不只是峰值算力指标的竞争，算力和编程模型、软件都有很强的耦合性，算力指标对先进工艺也有很强的依赖性。大模型今天把芯片产品的竞争力拉到了内存和互联维度，这些维度相比算力都标准化得多，对解决产品定义问题提供了新的可能性，标准化的维度更贴近指标竞争，就像今天大家买网卡或者交换机时候只关注指标而不关注是哪家的产品，这就是标准化竞争的好处。我们如果看当下和未来两三年，其实大模型的商业探索也是在成本和Token质量上相互妥协，也逐渐分化成了两派。一派是质量优先，**用高端系统打造高质量的通用大模型，寻找超级应用来覆盖高昂的成本**。另一派是成本优先，用足够便宜的硬件上，提供基本够用的Token质量，**寻找垂直场景的落地**。今天很多人讲7B模型已经够用了，或者努力让7B或者更小的模型变得够用，其实也是一种无奈，如果能在同样的成本下买到规格大得多的芯片，跑一个百亿千亿模型，支持超长上下文，商业化的空间会比今天大得多，就像曾经的显卡和游戏行业一样，当足够便宜的显卡已经可以流程跑4k画质的时候，谁还会觉得1080p的画质也够用了呢？两三年后，随着芯片行业的发展，不会再有人需要小模型，大模型长文本的高质量Token会变得足够便宜。往更长远看，**大模型的成本模型对于商业形态都会产生巨大的变革**。PS：思维深度非常牛逼，从LLM推理特点到成本模型再到商业形态变革。[生成式AI产业经济学：价值分配与利润结构](https://mp.weixin.qq.com/s/bGFCofQ6OocjRbEL4CT7YA)
 
+1. 大模型的压缩：一个 10T的预料，可能被压缩到一个 10G 大小的模型中。
+2. LLM 不仅仅压缩了字符串，更重要的是它能够学习字符串之间的相关性，也就是抽象规律，甚至能够推理出原始数据中不存在的事物。在训练过程中，大模型通过调整其参数——包括权重和偏置——来捕捉这些复杂的模式和规律。训练完成后，这些参数就固定下来，代表了模型对数据的理解。
+
 ## 其它
 
 [ChatGPT如何成了学习的神兵利器](https://mp.weixin.qq.com/s/ECFxhRj-Dko097gukaSCTA)

_posts/MachineLearning/LLM/2023-12-16-llm_inference.md → _posts/MachineLearning/Framework/2023-12-16-llm_inference.md

@@ -80,8 +80,8 @@ $$
 
 在大语言模型推理中常会用到四个指标：Throughput（吞吐量）、First Token Latency（首字延迟）、Latency（延迟）和QPS（每秒请求数）。这四个性能指标会从四个不同的方面来衡量一个系统的服务提供能力。
 1. Throughput/吞吐量是指当系统的负载达到最大的时候，在单位时间内，能够执行多少个 decoding，即生成多少个字符。
-2. First Token Latency（首字延迟）。指的是当一批用户进入到推理系统之后，用户完成 Prefill 阶段的过程需要花多长时间。这也是系统生成第一个字符所需的响应时间。很多需求关注这一指标，希望用户在系统上输入问题后得到回答的时间小于 2~3 秒。
-3. Latency（延迟）。指的是每一个 decoding 所需要的时长。它反映的是大语言模型系统在线上处理的过程中，每生成一个字符的间隔是多长时间，也就是生成的过程有多么流畅。大部分情况下，我们希望生成的延迟小于 50 毫秒，也就是一秒钟生成 20 个字符。
+2. First Token Latency/TTFT（首字延迟 Time To First Token）。指的是当一批用户进入到推理系统之后，**用户完成 Prefill 阶段的过程需要花多长时间**。这也是系统生成第一个字符所需的响应时间。很多需求关注这一指标，希望用户在系统上输入问题后得到回答的时间小于 2~3 秒。
+3. Latency/TBT（延迟 Time between tokens）。**指的是每一个 decoding 所需要的时长**。它反映的是大语言模型系统在线上处理的过程中，每生成一个字符的间隔是多长时间，也就是生成的过程有多么流畅。大部分情况下，我们希望生成的延迟小于 50 毫秒，也就是一秒钟生成 20 个字符。
 4.  QPS（每秒请求数）。反映了在线上系统的服务当中，一秒钟能够处理多少个用户的请求。
 First Token Latency 和 Latency 这两个指标会因为用户输入的长度不同、batch size 的不同而发生非常大的变化。用户输入的长度越长，首字延迟也会越高。decoding 延迟，只要不是千亿级别的模型，decoding 的延迟都会控制在 50 毫秒以内，主要受到 batch size 的影响，batch size 越大，推理延迟也会越大，但基本上增加的幅度不会很高。吞吐量其实也会受到这两个因素的影响。如果用户输入的长度和生成的长度很长，那么系统吞吐量也不会很高。如果用户输入长度和生成长度都不是很长，那么系统吞吐量可能会达到一个非常离谱的程度。
 除了首token时延，LLM在线服务也可能会把尾token时延（即完成response的时延）作为优化目标，例如，当LLM推理服务作为中间环节时，就会希望response的尾token时延越小越好。
@@ -94,7 +94,7 @@ First Token Latency 和 Latency 这两个指标会因为用户输入的长度不
 
 在 prefill 阶段，至少要做四件事情：第一件事情是把用户的输入进行向量化，tokenize 的过程指的是将用户输入的文本转换为向量，相对于 prefill 整个阶段来说，大概要占掉 10% 的时间，这是有代价的。之后就会进行真正的 prefill 计算，这一过程会占掉大概 80% 的时间。计算之后会进行 sampling，这个过程在 Pytorch 里面一般会用sample、top p。在大语言模型推理当中会用 argmax。总而言之，是根据模型的结果，生成最后词的一个过程。这个过程会占掉 10% 的时间。最后将 refill 的结果返回给客户，这需要的时间会比较短，大概占 2% 到 5% 的时间。
 
-Decoding 阶段不需要 tokenize，每一次做 decoding 都会直接从计算开始，整个decoding 过程会占掉 80% 的时间，而后面的 sampling，也就是采样生成词的过程，也要占掉 10% 的时间。但它会有一个 detokenize 的时间，detokenize 是指生成了一个词之后，这个生成的词是个向量，需要把它解码回文本，这一操作大概会占掉 5% 的时间，最后将这个生成的词返回给用户。
+**Decoding 阶段不需要 tokenize**，每一次做 decoding 都会直接从计算开始，整个decoding 过程会占掉 80% 的时间，而后面的 sampling，也就是采样生成词的过程，也要占掉 10% 的时间。但它会有一个 detokenize 的时间，detokenize 是指生成了一个词之后，这个生成的词是个向量，需要把它解码回文本，这一操作大概会占掉 5% 的时间，最后将这个生成的词返回给用户。
 
 新的请求进来，在进行完 prefill 之后，会不断迭代进行 decoding，每一个 decoding 阶段结束之后，都会将结果当场返回给客户。这样的生成过程在大语言模型里面是很常见的，我们称这样的方式为流式传输。
 
@@ -211,6 +211,10 @@ PS：Transformer （和Attention） layer 已经支持了缓存机制 (use_cache
 
 System Prompt Caching，也称为 Prefix Sharing，其基本思想是对System Prompt部分进行一次计算，并缓存其对应的Key和Value值（例如，存放在GPU显存中），当LLM推理再次遇到相同的（甚至部分相同的）System Prompt时，则可以直接利用已经缓存的System Prompt对应的Key和Value值，这样就避免了对于System Prompt的重复计算。
 
+[Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving](https://zhuanlan.zhihu.com/p/706109023)Mooncake的核心是其以KVCache为中心的调度器，将预填充/prefill服务器与解码/decoding服务器分开，因为LLM服务的这两个阶段具有非常不同的计算特性，Prefill是计算密集，受限算力带宽用不满，Decode是访存密集性，受限带宽算力用不满。所以用同一种硬件部署两阶段往往顾此失彼，不是最有性价比。拆分Prefill/Decode之后，LLM推理系统就更像一个分布式内存系统+流处理系统，其中KVCache随着请求从预填充移动到解码服务器而转移，将KVCache和计算分离开，它将GPU集群的CPU、DRAM、SSD和RDMA资源分组组成Distributed KVCache Pool，KVCache也是分块以Paged方式管理，KVCache Blocks如何在Pool中调度，请求和复用KVCache乃精髓。这就是传统计算机系统研究者最擅长的领域，sys三板斧，batch， cache，调度都可以招呼上，比如
+1. Prefill阶段可以利用request间存在共同前缀的机会，尽可能复用KVCache。PS：比如agent 循环调用 多次请求的prompt prefix是一样的。
+2. Decode可以进一步拆成Attention和非Attention算子分离调度。
+
 ### Flash Attention
 
 [图解大模型计算加速系列：Flash Attention V1，从硬件到计算逻辑](https://mp.weixin.qq.com/s/J2i2MDv4us_GMwCyku0tnw)在矩阵分块的时候设计好一个能够充分利用高速访存HBM的分块方法，让一次搬运进HBM中的参数可以全部和该做乘加操作的算子都计算完再丢弃，达到数量单次访存利用率最大化。

_posts/MachineLearning/LLM/2023-03-25-llm.md

@@ -226,6 +226,8 @@ BERT仅使用了Transformer的编码器(Encoder)部分进行训练，而GPT-1则
 
 ## RLHF
 
+base model会“文字接龙”之后，对于每个问题，人工标注者都会比较辅助模型的多个答案，并标注出最佳答案。这一步骤称为从人类反馈中强化学习（RLHF）。
+
 [万字长文详解大模型平台技术栈](https://mp.weixin.qq.com/s/zoXxkdVj70XOuAMdkGtuEQ)经过预训练之后，我们可以获得类似于 LLaMA 这样的 **Base Model**，但这距离 ChatGPT 这种 Assistant Model 还有一段距离。Base Model 并不能像 **Assistant Model** 一样能够很好的适用于指令理解、多轮聊天和 QA 问答等场景，而只是总是倾向于去续写文本（causal language modeling）。也即是说，Base Model 并不能很好的和用户的意图对齐 (Align)，有可能会生成无用、甚至是有害的内容。为了解决这个问题，算法科学家们提出了很多的解决方案，典型代表就是以 InstructGPT 这种先经过 Supervised Finetuning，然后通过 Reward Modeling 和基于人类反馈的强化学习 RLHF。DeepSpeed 团队也发布了 DeepSpeed-Chat，开源了一个支持端到端的 RLHF 的训练和推理系统，复刻了 InstructGPT 论文中的训练模式，并确保三个阶段一一对应：监督微调SFT；奖励模型微调RM；基于人类反馈的强化学习RLHF。PS: 通过人类反馈进行模型微调。
 
 [RLHF——让大模型对齐人类偏好](https://mp.weixin.qq.com/s/UGLifcfq9SmjARYk9D3kDQ) 所谓对齐人类偏好，主要体现在以下三点：有用（遵循指令的能力）、诚实（不容易胡说八道）、安全（不容易生成不合法的，有害，有毒的信息）。因此在大模型的训练阶段，如果引入人类的偏好或者人类的反馈来对模型整体的输出结果进行进一步优化，显然是要比传统的“给定上下文，预测下一个词”的损失函数要合理的多。即使用强化学习的方法，利用人类反馈信号直接优化语言模型。