"I don't think I've typed like a line of code probably since December, basically, which is an extremely large change."
从去年十二月起,我基本上一行代码都没写过,这是一个巨大的变化。——Andrej Karpathy,No Priors 播客,2026 年 3 月
"I don't think I've typed like a line of code probably since December, basically, which is an extremely large change."
从去年十二月起,我基本上一行代码都没写过,这是一个巨大的变化。——Andrej Karpathy,No Priors 播客,2026 年 3 月
Machine Learning Transformers LLM Neural Networks AI
本文带你走一遍 LLM 的工作原理。现代 LLM 大多是由 transformer 块反复堆叠而成的,因此理解了 transformer 机制,你就掌握了大部分。
我将覆盖现代基于 transformer 的 LLM 内部的核心机制,避开那些复杂的数学。别误会,你应该学数学,但本文可以作为一个入门。
大多数现代 LLM 共享同一套 transformer 家族的骨架。差异来自于各自的训练数据、规模和配置选择,以及在此之上的后训练。读完本文后,你应该能够阅读许多现代 LLM 论文或模型卡,并知道每个部分在讲架构中的哪个组件。
路线如下:
在 Go 1.17 之前,Go 编译器总是生成可由任何 64 位 x86 处理器执行的 x86 二进制文件。
Go 1.18 为 AMD64 引入了 4 个架构级别 。每个级别在编译器可以包含在生成的二进制文件中的 x86 指令集上有所不同:
- GOAMD64=v1(默认值):基准模式。仅生成所有 64 位 x86 处理器都能执行的指令。
- GOAMD64=v2:所有 v1 指令,加上 CMPXCHG16B、LAHF、SAHF、POPCNT、SSE3、SSE4.1、SSE4.2、SSSE3。
- GOAMD64=v3:所有 v2 指令,加上 AVX、AVX2、BMI1、BMI2、F16C、FMA、LZCNT、MOVBE、OSXSAVE。
- GOAMD64=v4:所有 v3 指令,加上 AVX512F、AVX512BW、AVX512CD、AVX512DQ、AVX512VL。
例如,设置 GOAMD64=v3 将允许 Go 编译器在生成的二进制文件中使用 AVX2 指令(这在某些情况下可能会提高性能);但是这些二进制文件将无法在不支持 AVX2 的旧 x86 处理器上运行。
Go 工具链也可能生成更新的指令,但会通过动态检查来确保它们只在支持的处理器上执行。例如,如果设置了 GOAMD64=v1,并且 CPUID 报告 POPCNT 指令可用,那么 math/bits.OnesCount 仍然会使用该指令。否则,它会回退到通用实现。
Go 工具链目前不生成任何 AVX512 指令。
不支持 SSE3 的平台不支持种族检测器。
64 位 Intel 和 AMD 处理器已经演进了几十年。当你为 64 位 Intel 或 AMD 处理器编译 Go 程序时,编译器默认面向的是一个将近 20 年前的指令集。生成的二进制文件几乎能在任何 x64 芯片上运行,但同时也放弃了自 2003 年以来添加的所有指令。
我们通常用微架构级别(microarchitecture levels)来描述这一分层。每个级别捆绑了一组可以假定存在的指令集扩展:
| 级别 | 新增内容(大致) |
|---|---|
| v1 | 原始 AMD64 基线(SSE2) |
| v2 | popcnt、SSE4.2 |
| v3 | AVX2 |
| v4 | AVX-512(F/BW/DQ/VL) |
I don't talk to an agent anymore, I talk to a loop or a routine.
——Boris Cherny
先讲一个真实的 case。
6 月 10 日下午,我把一个新工具 kuiniu(夔牛) 的 PRD 丢给 Claude Code,让它生成 8 个 issue 卡到 GitHub 仓库。然后我敲了一句 /loop-it,然后离开了。
一个小时后打开仓库一看,8 个 issue 全 closed,对应的 PR 全 merge 了。main 分支上多出了 client、server、codec、bitflip 检测、丢包统计、命令行入口、Makefile/goreleaser 集成,还顺手抽出了一个 util/rotate_writer.go。
用 Go 写 RDMA,到底能有多简单?又能有多快?这篇带你从零跑到 400 Gb/s。
如果你做过高性能网络,一定听过 RDMA 这个词。它是 AI 训练集群里 GPU 之间狂飙数据的底层、是分布式存储压榨延迟的杀手锏、是金融交易系统微秒必争的武器。
RC(可靠连接,类比 TCP):有序可靠,支持双边和单边操作
UD(不可靠数据报,类比 UDP):无连接,一对多
双边操作(Send/Recv):接收方要先挂好接收请求,双方 CPU 都参与
单边操作(RDMA Write/Read):发起方直接读写对端内存,对端 CPU 完全不参与——这是 RDMA 最"魔法"的地方
目前顶尖的云服务商都包含百万台服务器、数十甚至上百个机房、上万台网络设备、百万级网络链路。单单一个GPU集群,就有上万卡的级别。对这些网络和服务器的监控,一个分钟级别的故障,可能就是上百万资产的损失。
这不是一个ping能解决的问题。
今天,我们将百度物理网络黑盒监控方向的工具集 nettools 开源了(https://github.com/baidu/nettools),第一批放出的是 bitflip 和 bitflip6,用于检测网络丢包和比特翻转,在百度内部跑了很长时间了。
上一个工具 bitflip/baize 解决的是丢包和改包持续检测,在百度baize常常用在点到点之间的常态检测中,比如机房内集群间的监控,专线的检测, 新网络方案测试和灰度观察、核心网络设备的切回前检测等场景。
今天介绍的lidar工具,区别于传统的pingmesh探测方案,是我来百度后创造的第一个特殊的底层网络方案,我将其称之为lidar(激光扫描)方案,是一个很形象的比喻,我会话专门一节详细介绍它的优缺点,在这之前,我们介绍传统的赫赫有名的机房大规模的网络监控方案 pingmesh。
PingMesh("Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis")是微软在SIGCOMM 2015上发表的论文。作者团队来自微软研究院和Azure网络部门。
5000 包/秒高频探测 + 无需时钟同步的单向丢包检测 + 全路径覆盖。内部跑了多年,现在开源了。
先讲一个实际case。
线上服务突然超时,用户投诉电话打爆了。打开监控大盘,一切正常——没有任何告警。折腾两小时,最后发现是某条链路间歇性轻微丢包,丢包率 0.3‰,传统监控压根抓不到。
百度内部,baize 跑了多年:
baize 是百度 nettools 工具集的第二个开源工具,MIT 协议。
内部版还支持从数据库拉配置、推数据到 Kafka 聚合,开源版做了简化,但留了可插拔的 Sender 接口——你可以自己实现,把数据发到 ClickHouse、Prometheus 或者任意后端。
网络监控这件事,不是能不能做的问题,是做得够不够细的问题。
每一条链路、每一个端口、每一个比特,都值得被监控。 这是我们在百度内部坚持的标准,今天开源出来,希望对你有用。
被间歇性轻微丢包折磨过的话,去 GitHub 点个 Star,试试 baize。