一个 Token 的旅程

一个 Token 的旅程 并发编程回顾CPU 并行技术Token 旅程从用户请求到网络传输数据中心C10K/C10M 问题与并发编程演进CAP 定理与分布式系统分布式计算从把数据带到计算到把计算带到数据Serverless无服务器的编程范式大语言模型的本质Transformer 与 Self-AttentionGPU 优化技术硬件加速器与 BLAS系统发展的历史规律产业视角与职业发展1. 并发编程知识1.1 多处理器编程基础从pthreadAPI 入门打开了魔鬼的盒子线程创建pthread_create/pthread_join同步原语互斥锁、条件变量、信号量编程模型本质上都是某种sync/await理论上只要有spawn和join就可以实现任何计算图。1.2 轻量级线程当对传统线程不满意时可以实现更轻量级的方案技术特点Coroutine用户态协作式多任务Non-blocking I/O不阻塞等待 I/OGoroutine既轻量又能在多核并行Promise/async-awaitJavaScript 的方案描述计算图1.3 计算图的本质所有并发编程模型本质上都是描述一个计算图computation graph。关键在于这个图怎么并行执行由运行时框架负责调度2. CPU 并行技术2.1 SMT (Simultaneous Multi-Threading) - 超线程一个物理核心两个逻辑线程共享寄存器但 PC 独立每个线程有自己的index寄存器比如 index.x, index.y可以用同一指令对不同数据操作// SMT 的典型场景for each pixel on screen// 所有线程执行同一指令但 index 不同// 这样可以实现 burst read/write非常高效2.2 SIMD (Single Instruction Multiple Data)单指令多数据一条指令操作多个数据例AVX-512 可操作 512 位64字节适合向量运算inner product multiply accumulate; FMA (Fused Multiply-Add) 指令 ; 同时完成乘法和加法 vfmadd231ps ymm0, ymm1, ymm22.3 SIMT (Single Instruction Multiple Threads) - GPU 模型大量线程共享一个 PC每个线程有独立寄存器分支时执行 A 的线程激活执行 B 的等待高并行度的秘密依赖每个寄存器的不同值2.4 演进路径单核 → 多核摩尔定律 → SIMD → SMT → SIMT (GPU)目标是让计算部件的能耗趋于零3. Token 旅程从用户请求到网络传输3.1 示例用 curl 调用 APIexportOPENAI_API_KEY...curlhttps://api.openai.com/v1/chat/completions\-HContent-Type: application/json\-d{model: ..., messages: [...]}3.2 环境变量的继承export设置的环境变量通过ENVP在进程加载时加载到栈上并在子进程间继承——这是操作系统课的基础知识。3.3 用 strace 分析网络请求strace-f-etracenetwork,desc ./chat.py典型流程来自 AI 分析步骤说明1. DNS 解析端口 53获取域名对应的 IP2. TCP 连接connect系统调用443 端口HTTPS3. TLS 握手建立加密通道4. 发送请求send系统调用5. 接收响应recv系统调用3.4 DNS 的复杂性一个域名可能有多个 IP如 CDN 负载均衡不同地理位置看到不同的 IP例api.deepseek.com可能返回 58.49.xxx.x 或 218.92.xxx.x3.5 观察工具digapi.deepseek.com# 查看 DNS 解析结果tracerouteapi.deepseek.com# 查看路由路径通过 TTL 探测4. 数据中心A data center is a facility that houses computing and storage resources that enable delivery of shared applications.4.2 两个半场上半场传统 Web 应用1999 - 2021静态网页 → Facebook → 微信、淘宝主要操作CRUD增删改查用户数据在云端手机、电脑消息完全同步代价隐私的牺牲下半场AI 推理2022 - 至今模型参数Active 计算量GPT-4 Flash284B13BGPT-4 Pro1.6T49B这是prefill的计算量不包括decode逐 token 生成新的硬件需求H200/升腾 950 等 GPU4.3 数据中心的产业链土地、水、电、人力、保洁需要供应链管理、股权结构等商业知识技术总有一天会过时但驱动技术发展的市场需求永远存在5. C10K/C10M 问题与并发编程演进5.1 C10K Problem (1999)Dan Kegel 提出如何让一个 Web 服务器同时服务 1 万个客户端5.2 解决方案演进技术说明select监听多个文件描述符但有性能问题epoll更高效的 I/O 多路复用事件驱动架构单线程处理大量连接Goroutine轻量级线程 事件驱动5.3 C10M 问题从 1 万到 1000 万并发规模变了性质也变了5.4 数据中心的并发挑战高吞吐、低延迟是生命线一个下单请求可能涉及 1000 个模块问题P99 latencyP99 指 99% 请求的延迟每增加 100ms用户流失翻倍5.5 真实案例小爱同学事件小米汽车发布会上演讲者喊小爱同学全国所有小米设备同时唤醒导致服务**分布式拒绝服务DDoS**式瘫痪。5.6 弹性与可靠性弹性用户突增时系统能接住峰值过去后释放资源可靠性聊天记录不能丢QQ/微信永不丢失数据6.CAP 定理与分布式系统6.1 CAP 定理在一个分布式系统中Consistency一致性、Availability可用性、**Partition Tolerance分区容错**三者不可兼得。6.2 以发朋友圈为例场景你不想让你妈看到你发的朋友圈先拉黑发请求到数据库屏蔽你的妈再发朋友圈手机从校园网切到 5G朋友圈发到另一个数据中心问题如果南京和杭州的数据中心之间有延迟你妈可能先看到朋友圈再被拉黑。6.3 三种权衡组合含义C A单机系统假设可信A P大规模分布式牺牲一致性最终一致性C P需要等待确认牺牲可用性6.4 现实中的处理实际系统花 10 年时间让用户感受不到CAP 的存在计费有延迟API 调用完成但计费可能要等几秒到一分钟API key 可以随时 disable这些都是 CAP 的体现但通过各种手段优化用户体验7. 分布式计算从把数据带到计算到把计算带到数据7.1 Unix 的成功Unix 的编程抽象管道pipe组合composition复用reuse核心思想program 携带语义把数据带到程序7.2 分布式计算的挑战在分布式系统中程序随时可能消失机器 crash、网络分区7.3 范式转变旧范式新范式把数据带到计算把计算带到数据program 中心filesystem 中心open/read/write更高级的抽象7.4 Google 的解决方案GFS (Google File System) ↓ BigTable (KV database) ↓ MapReduce (分布式计算)GFS分布式文件系统文件切成多个 chunk存储在不同机器上不让你看到机器的存在编程时看到的只是文件MapReduce分布式计算框架开发者只需要写map和reduce函数实现细节留给分布式系统每台机器上依然是 Linux7.5 “Everything is a file” 的延续这个思想在分布式时代依然成功一切以文件为中心在文件基础上构建数据库数据库解决 CRUD 问题8. Serverless无服务器的编程范式8.1 传统模式 vs Serverless传统模式Serverless租一台服务器有固定 IP没有服务器概念以计算为中心以数据/事件为中心需要管理服务器云厂商负责扩缩容8.2 事件驱动编程// 示例Amazon Lambda / 阿里云函数计算exports.handlerasync(event){// 从 HTTP header 获取 API keyconstapiKeyevent.headers.authorization;// 校验 API keyconstvalidawaitcheckApiKey(apiKey);if(!valid){return{statusCode:401,body:Unauthorized};}// 调用 LLM inferenceconstresponseawaitcallLLM(event.body);// 返回结果return{statusCode:200,body:response};};8.3 幂等性IdempotencyServerless 函数必须幂等因为函数可能随时消失并重试。非幂等示例loadsumread_from_memory()sumsum1write_to_memory(sum)# 如果函数重跑账会记两次幂等示例✓# 生成唯一 request IDrequest_idgenerate_uuid()# 往集合里加入 request IDss.add(request_id)# 获取大小作为计数counts.size()8.4 云厂商的保障自动扩缩容流量突增时自动分配更多服务器自动副本存储数据自动多副本备份按需计费按实际调用次数收费“Write once, planet scale”9. 大语言模型的本质大语言模型 从一个学习到的巨大数学函数上采样9.2 GPT 的核心代码// 来自 GPT-2 的实现// 核心就是一个循环for(intlayer0;layerNUM_LAYERS;layer){// 每一层 transformer// 就是一堆数学计算// 一堆参数矩阵乘法、attentionmatmul_forward(...);// 矩阵乘法attention_forward(...);// attention}9.3 Transformer 层每一层 一个函数输入一大堆数字输出一大堆数字然后写到内存再传给下一层9.4 参数规模GPT-2 有124M 参数每层都有大量参数。9.5 计算瓶颈matmul_forward矩阵乘法最耗时之一attention_forward自注意力最耗时之二优化这两个函数就够了10. Transformer 与 Self-Attention10.1 类比每一层 Transformer 是一本书概念类比说明Q (Query)问题动态的每次都不同K (Key)书的目录静态的描述内容V (Value)书的内容具体的文字10.2 Self-Attention 的工作流程1. Q × K → softmax → 权重 2. 权重 × V → 输出用 Q 在 K 中查找相关内容把 V 中相关内容**加权取出**通过 Dense 层做复杂计算传给下一层 Transformer10.3 逐层理解第 0 层看到的是 token 本身越往后层信息越抽象越接近最终的 next token 预测每过一层 思考了一层最终得到短时记忆类似于消化后的理解10.4 有趣的发现架构的潜力还没有到头可能不是最优解。11. GPU 优化技术11.1 分块Tiling问题内存访问不连续解决方案把矩阵分成小块tile每块都能放入 cache// 分块矩阵乘法for(inti0;iM;iBLOCK_SIZE){for(intj0;jN;jBLOCK_SIZE){// 每个 block 都能放入 cachegemm_block(A,B,C,i,j);}}11.2 Flash Attention问题多个 CUDA kernel 顺序执行最后几个线程会拖慢整体利用率解决把多个 kernel打包成一个减少调度开销11.3 矩阵布局优化存储方式说明Row-major按行存储Column-major按列存储一个矩阵行优先另一个列优先才能高效做 inner product现代 GPU 有硬件转置支持cp.async, zero-overhead transpose11.4 Kernel Fusion把多层计算打包成一个计算图减少内存带宽压力。12. 硬件加速器与 BLAS12.1 Tensor Core问能不能在SMT 里引入 SIMD答可以 →Tensor Core本质矩阵乘法Matrix Multiply一条指令完成 GEMMGeneral Matrix Multiplication名字历史MMX→SSE→AVX→Tensor Core12.2 BLAS (Basic Linear Algebra Subprograms)基础线性代数子程序库Level操作说明BLAS-1向量-向量dot productBLAS-2矩阵-向量matrix-vector productBLAS-3矩阵-矩阵GEMM (最关键)12.3 cuBLAS / cuDNNNVIDIA 的 GPU 线性代数库持续更新跟随 GPU 架构编译器为不同 GPU 生成最优代码12.4 生态层次CUDA (基础算子) ↓ cuBLAS / cuDNN (线性代数 / NN 算子) ↓ PyTorch / TensorFlow (训练框架) ↓ LangChain / vLLM (推理框架) ↓ ChatGPT / Claude (应用)类比Unix 系统调用 → libc → 各种应用13. 系统发展的历史规律Unix 时代GPU 时代系统调用CUDA kernellibccuBLAS管道、文件计算图man page官方文档如果要理解现代 GPU 生态可以回到 1997 年看 Intel 的 MMX经验教训是什么怎么让开发者用好新指令集内存布局和访问模式如何优化历史是惊人的相似。13.3 从 system call 到 everythingSystem call → libc → ... ↓ CUDA → cuBLAS → ...14. 产业视角14.1 数据中心产业链10 万亿美元规模的产业底层GPU、芯片、存储上层框架、应用、服务14.2 DeepSeek 的架构组件说明api.deepseek.com可能走 CDNCloudflareopenai.comOpenResty API 网关KV Cache有 cache hit / miss 价格计费系统有延迟异步更新14.3Prefill-Decode分离大模型推理分为两个阶段阶段说明资源Prefill处理输入 prompt构建 KV Cache计算密集Decode逐 token 生成输出内存带宽密集KV Cache 需要大量显存1.6T 参数的模型需要多卡并行14.4 成为超级个体如果不是超级个体一瞬间就被淘汰了AI 时代会用 Google 10x 生产力差距会用 AI 工具 100x ~ 1000x 生产力差距14.5 不要做学术裁缝从first principle思考生态系统里还有很多空缺不要只是 ABCD 的缝合每年 AI 会议几万篇投稿绝大部分对学术界有害大胆去想、大胆去做这个世界一直在进步Unix 时代 → 云计算时代 → AI 时代每一次范式转变都有新的机会总有一天现在的东西都会过时所以你可以安全地假设现在全世界都错了。参考: jyy老师 2026os一个 Token 的完整旅程用户输入 Hello ↓ DNS 解析 → IP 地址 ↓ TCP TLS 连接 ↓ 负载均衡多地域 ↓ API 网关鉴权、计费 ↓ CRUD 操作数据库 ↓ LLM Inference ├── Prefill计算 KV Cache └── Decode逐 token 生成 ↓ 审计、记账、更新 Dashboard ↓ HTTP 响应JSON ↓ 用户看到 token