白话大模型原理

近几年以 ChatGPT 为代表的 AI 模型大火，日常使用中大模型仿佛“无所不知、无所不能”，有任何问题直接询问 GPT 就能得到答案，但在服务端开发者眼里，它不应是魔法，而是一个能够进行数值运算的复杂系统。本文将以服务端技术视角对其架构进行链路分析，包含以下三个步骤

输入 -> 处理：由“静态查表的局限性”引出“动态计算的必要性”，解析 token 是什么、为什么需要token。
处理 -> 输出：由“机器懂了”转折到“如何让人懂”，白话分析大模型的核心处理过程。
输出 -> 优化：由“原理上的低效”引出“工程上的优化”，分析模型在工程层面做了哪些优化。

这篇文章可能会解答一些疑惑如：

• 模型都训练完拿到最终参数了为什么使用的时候还要依赖显卡进行计算？
• 为啥提示词会显著影响模型的返回？
• 大模型知道那么多内容，为啥有时候会胡编乱造，只有在用户指出错误后它才能发现？
• 大模型为啥一个字一个字的进行输出？
• DeepSeek 是怎么带来一场革命的？

基本概念

ES 是一个分布式数据库，它和关系型数据库存在明显差异，其基本概念如下：

节点

每一个 ES 节点就是一个 Java 进程，其中每个节点启动后默认是 Master eligible节点(候选主节点)，只有 Master eligible节点能够参与选主流程、成为 master 节点。
每个节点都会保存该集群的状态数据，如分片信息、索引信息、不同的节点信息，这样请求不管打到哪个节点上都能进行转发。但是只有master 节点具有修改集群状态数据的权限。
每个节点按照类型可以分为：

什么是线程缓存以及为什么要用到线程缓存？

每个线程都有独立的存储空间，使得相同的变量在不同线程中能够有不同的值，互不影响，每个变量只在当前线程中使用。简单来说就是多线程环境下解决线程安全问题的工具。

线程缓存相比于其他缓存，具有以下优点：

• 性能更优，直接存于线程变量副本中，没有其他 IO 开销，同时避免了锁同步的开销
• 数据隔离，多线程中天然不存在竞争，保证每个线程对数据的修改不会影响其他线程中的变量
• 简化代码，需要在多个层次的调用中传递数据的场景中，使用线程缓存可以简化参数传递逻辑，避免在方法调用中显式传递参数，从而提高代码的可读性（双刃剑）。

线程缓存典型的使用场景：

RPC 的定义

RPC 的全称是 Remote Procedure Call，即远程过程调用，实现了跨网络调用其他服务就像调用本地服务一样的模式。简单来说 RPC 替我们封装了网络层繁琐的开发开发，通过增强代理的方式嵌入进去，这样我们只需要编写业务逻辑即可调用远程服务。RPC 的使用范围非常广泛，不仅仅约束在接口维度，包括MQ Client 和 MQ Server 间的通信、Redis Client 和 Redis Server 间的通信、JDBC 和 MySQL 间的通信都属于 RPC 通信。

协议

由于跨网络的特性，一次 RPC 调用通常要经过序列化、协议编码、解码、反序列化的过程。当被调用者接收到一堆二进制字节后首先要对这些二进制进行解码和反序列化，这样才能定位到本次调用的具体方法。基于性能的考虑，RPC 调用通常是基于 TCP 层，TCP 接收到的二进制数据是没有分隔的，TCP 窗口可能会对多次调用进行合并，下游必须解析出合并前的数据边界，这就需要指定的协议格式了。也就是说 RPC 协议是为了避免语义不一致的事情发生，需要在发送请求的时候设定一个边界，然后在收到请求的时候按照这个设定的边界进行数据分割。这个边界语义的表达，就是所说的协议。

选择分布式数据库

以实际使用场景来看，假设有一个广告系统记录了所有用户在任何时刻触发不同广告的消耗明细，每天大约能产生 5000W 条用户消耗数据明细。现在需要实现一个供流量主可以实时查询这些数据的功能，此时应该选用哪种类型的数据库，在这个应用场景下数据库需要满足以下特点：

1. 数据量巨大，且面向 C 端用户查询。
2. 频繁写入且频繁查询，要支持范围查询，且查询性能需要在毫秒级。
3. 数据存在倾斜的可能性。

传统数据库的瓶颈

MySQL 数据库天生是单机数据库，即它只能运行在一台物理机器实例上，我们没有办法把他拆分开让同一个数据库同时运行在多台机器上。因此它的性能和物理机器实例的配置呈正相关，受到机器配置的制约，机器的天花板上限较低。但是它的好处就是架构较为简单，使用起来更加方便。

为什么要使用缓存

在互联网的高流量、高并发场景下，MySQL 集群能够扛住的 QPS 通常在 1W 量级，数据库在达到压力瓶颈时会明显出现慢尾效应，即原有执行速度很快的 sql 耗时也会显著增加，拖累使用了此集群的所有服务，最终导致整个数据库集群的崩溃。

相比于 redis 缓存来说，MySQL 集群的资源更加珍贵，为了保护数据库集群且让服务能够承受更高的流量，我们通常使用缓存来减少数据库的压力，对那些热点数据进行缓存来分担 MySQL 的压力。对于 redis 集群来说，可以轻松承担 10 W+的 QPS，并且可以很方便的进行扩容。

缓存可能出现的问题

只读缓存

服务端开发离不开和 http 打交道，无论是 API 请求、RPC 请求，都有可能使用 http 协议。http 太常见了， spring 提供的注解开发可能让我们忽略了协议内不同内容是如何存放，header、body、表单都如何使用。参考极客时间-透视 http 协议，从头到尾梳理一遍 http 的详细知识。

http 是什么

http 全称超文本传输协议，拆分为三个名词详细理解：

• 超文本：普通的文本指的是文字数据，超文本不但包含了文字，它也包括了语音、图片、视频等数据，是一切资源的泛称。同时它含有超链接，可以从一个超文本跳转到另外一个超文本，形成复杂的网状结构。
• 传输：数据在双方的流动叫为传输，http 是一个双向传输协议，一般情况下把发起数据传输的称为请求方，接受数据的称为响应方。
• 协议：首先协议可以分为两个部分，它需要最少两个参与者，参与者要想互相理解对方传输的内容，这离不开规范。简单来说协议就是规定了双方使用同样可以理解的语音进行交流

作为一种协议规范，它本身不是一种程序或软件，HTTP 通常跑在 TCP/IP 协议栈之上，依靠 IP 协议实现寻址和路由、TCP 协议实现可靠数据传输、DNS 协议实现域名查找、SSL/TLS 协议实现安全通信。

简单来说，OAuth2.0是一种授权协议，它通过颁发访问令牌的机制而不是使用用户名和密码来请求交互，保证第三方应用只有在成功获取授权之后才可以访问授权者的数据。通过这套协议，用户仅仅通过授权操作就可以免去重复注册的流程，是目前web上重要的安全手段。

OAuth2.0提供了四种许可类型：

• 授权码许可（Authorization Code）
• 隐式许可（Implicit）
• 客户端凭据许可（Client Credentials）
• 资源拥有者凭据许可（Resource Owner Password Credentials）

OAuth2.0的基本流程

OAuth2.0里有4种角色，分别是资源所有者、三方软件、授权服务和受保护资源，授权码许可的流程如下。

kafka介绍

Apache Kafka 是消息引擎系统，也是一个分布式事件流处理平台，企业利用它可以在A、B两个系统之间传递消息，实现松耦合的异步数据传输。总的来说，消息引擎具有两个重要能力：

• 消息引擎传输的对象是消息
• 定义了传输消息的规范

消息引擎不在乎A、B两个系统是否相同，它可以在不同系统间传递消息，因此消息的通用格式以及如何传输消息至关重要。kafka的消息格式化使用的是二进制字节序列，消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。kafka支持两种常用的消息引擎模型：

• 点对点模型：也叫消息队列模型，消息只能由A系统发出，由B系统接收，其他模型无权生产与消费消息，简单来说是一对一的模型。
• 发布 / 订阅模型：有一个topic的概念，可以有多个生产者向topic中生产消息，同时允许多个消费者订阅topic进行消费，简单来说就是一种多对多的模型。

NIO

三大组件

1. Channel & Buffer

channel是读写数据的双向通道，连接要读取的文件和内存，可以从channel把数据读入buffer，也可以将buffer的数据写入channel，而stream是单向的，channel比stream更加底层。

简而言之，通道负责传输，缓冲区负责存储