行业分类:
加载中...
头条分类:
加载中...
斯坦福华人天团意外爆冷!AI用纯CUDA-C编内核,竟干翻PyTorch?
【新智元导读】本想练练手合成点数据,没想到却一不小心干翻了PyTorch专家内核!斯坦福华人团队用纯CUDA-C写出的AI生成内核,瞬间惊艳圈内并登上Hacker News热榜。团队甚至表示:本来不想发这个结果的。 就在刚刚,斯坦福HAI华人大神团队又出惊人神作了。 他们用纯CUDA-C语言编写的快速AI生成内核,竟然超越了PyTorch! 在这个过程中,完全不用借助CUTLASS和Triton等库和领域特定语言(DSL),就能让性能表现接近PyTorch内置的、经过专家优化的标准生产级内核,甚至在某些情况下还更胜一筹。 作者团队都是我们熟悉的名字——Anne Ouyang、Azalia Mirhoseini和Percy Liang,有趣的是,他们甚至直言,这个结果其实本不想拿出来发布。 一经发布,这个发现就引爆了技术圈,现在已经登顶Hacker News总榜第二。 说起来,这个发现还有很多意外的成分。 本来,他们的目标是生成合成数据,来训练更好的内核生成模型,合成数据生成的设计也十分简单。 然而,意想不到的事情发生了,仅用于测试的合成数据生成本身,竟开始生成非常优秀的内核,甚至超越了人类专家优化的PyTorch基线,而且还利用了高级优化和硬件特性。 而在此前,这是一项很艰难的挑战。 由此,研究者们决定提前撰写博文,把自己的发现分享出来。 总结来说,研究的亮点成果如下: 矩阵乘法(Matmul, FP32):性能达到PyTorch FP32 torch.matmul的101.3% 二维卷积(Conv2D, FP32):性能达到PyTorch FP32 torch.nn.Conv2D的179.9% Softmax(FP32):性能达到PyTorch FP32 torch.softmax的111.8% 层归一化(LayerNorm, FP32):性能达到PyTorch FP32 torch.nn.LayerNorm的484.4% 二维卷积 + ReLU + 最大池化(Conv2D + ReLU + MaxPool, FP32):性能达到PyTorch FP32参考实现的 290.1%,达到PyTorch FP32 torch.compile()参考实现的189.0% 以上结果在英伟达L40S GPU上进行了基准测试,性能百分比定义为参考时间除以生成的内核时间。 网友:强制LLM推理,实在太有趣了 在Hacker News上,网友们也对此展开了热烈讨论。 比如为什么使用FP32内核会比PyTorch更容易实现性能提升,理由就相当有趣。 如果AI真的能以更低成本,实现更优化的内核,的确潜力巨大。 最令人震撼的就是,无论是最近谷歌的AlphaEvolve,还是o3在Linux内核中发现了零日漏洞,都在提醒我们—— Gemini Pro 2.5和o3已经达到了一个全新的能力水平,那些曾经在其他模型上尝试失败的想法,现在突然奏效了。 可以说,我们已经到达了一个节点,LLM能比用人类快得多的速度进行迭代和测试,信息组合、进步和智能应用的蛮力,似乎正在成功! 接下来,我们来看看斯坦福研究者们博客中的具体内容。 博客全文 在博客中,研究者分享了具体方法、五个优化后的内核(包括4个基础机器学习算子和1个AlexNet模块的融合内核)、一个优化过程的实例,以及一些思考,关于这些发现对高性能内核生成可能意味着什么。 可以说,这些内容将是他们后续探索的第一步。 方法 研究者们采用了KernelBench的任务设置(这是他们在2024年12月发布的一款基于AI的内核生成基准测试)。 具体来说,给定一段torch代码,LLM会编写自定义内核来替换原有的torch算子,目标是实现加速。 依照KernelBench最初的设计,参考代码默认使用FP32精度;在给定的容差阈值(1e-02)下,采用较低精度的解决方案也是被允许的。 此外,由于存在大量针对特定规模的优化手段,KernelBench中的每个问题都设定了具体的输入大小。 因此,该基准测试旨在找出针对特定问题规模的最快内核,而非一个适用于任意问题规模的高速内核。 而且,研究者会同时运行torch参考代码和生成的代码,并通过在多种随机输入下比较两者输出的数值是否一致,来检验其正确性。 当前,在优化内核这个问题上,业界扩展测试时计算资源最常用的方法是顺序修订(sequential revision)。 这是一种多轮迭代的循环:模型首先对内核进行增量式修改,接着检查其正确性和性能,然后根据结果再次尝试。 也就是说,要么修复有问题的内核,要么进一步提升现有内核的性能。 这个循环过程非常直观,也容易实现。模型会修复失效的内核,微调可用的内核,一步步优化出性能更佳的版本。 这种方法的主要局限,在于优化思路缺乏多样性。 顺序循环往往容易陷入局部最优的困境,比如反复尝试同类型的转换,或是在缺乏潜力的优化路径上无休止地调整。 其结果便是测试时计算资源的低效利用,并且难以促使模型产生具有根本性创新的优化思路。 为解决这一问题,研究者引入了两项关键改变: 运用自然语言对优化思路进行推理 他们不再于每一步直接生成新的内核,而是以先前尝试过的思路为条件,用自然语言生成优化思路,随后将这些思路具化为新的代码变体。 在每个优化步骤进行分支扩展 他们不是每步只改进一个候选方案,而是进行分支扩展,让每个思路都能派生出多种实现版本,其中性能最佳的内核将作为下一轮优化的种子。 (研究者也会保留一个表现优异的现有内核库,用于提供种子)。 这种方式解锁了大规模的并行处理能力,使他们能够在每一轮探索截然不同的优化方向,避免陷入狭窄的优化路径。 其结果是,这种测试时循环不再像顺序修订那般,仅仅是与编译器「对话」,而是更接近一种结构化的探索性搜索。 这种搜索由明确的优化假设指导,并采用大规模并行评估的方式进行。 研究者运行了KernelBench第1级的10个问题,以进行测试。 他们调整了问题规模,以确保内核启动开销相对于问题的整体运行时间而言可以忽略不计。 然后,使用OpenAI o3和Gemini 2.5 Pro模型进行了5轮实验。 下图展示了首次发现性能最佳内核所在的轮次分布情况。 可以看到,大多数最优结果出现在靠后的轮次(总共5轮),其中绝大部分出现在第4轮或第5轮。 随着扩大搜索范围,研究者还发现:许多高性能内核的优化策略高度相似,集中在少数几种常见的模式上,这与他们手动编写内核的经验也是一致的。 主要的优化类别归纳如下—— 内存访问优化:提升不同内存层级(全局内存、共享内存、寄存器)之间数据迁移的效率,并确保数据访问方式能够最大化带宽、最小化冲突。 异步操作与延迟隐藏:通过将耗时较长的操作(例如全局内存访问)与计算或其他内存传输重叠执行,来隐藏其带来的延迟。 数据类型与精度优化:在允许的条件下,尽可能使用较低精度的数据类型(如FP16或BF16),以降低内存带宽需求,提升缓存效率,并有望利用专门的硬件加速单元。 计算与指令优化:提升算术运算本身的效率,削减指令数量,或利用专门的硬件指令。 并行性与占用率增强:最大化流式多处理器(SM)上活跃线程束(warp)的数量,以便更好地隐藏延迟,提高整体吞吐率。 控制流与循环优化:减少由循环、分支及索引计算等引入的额外开销。 总结 这次研究者采用的方法,与AI研究中一个日益显著的趋势不谋而合—— 将强大的推理能力与对多个假设的并行探索相结合,能够带来性能的提升。 正如一些近期研究(例如AlphaEvolve、Gemini 2.5 Pro Deep Think)所强调的,我们并不总是需要大规模的重新训练。 论文地址:https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/AlphaEvolve.pdf 有时,巧妙的搜索和分支策略便足以催生科学创新、攻克复杂难题,而借助验证器进行广泛搜索,则可能带来更大的收益。 然而,这并不意味着我们不需要进一步的训练。 恰恰相反,研究者的这种方法,也有助于生成更优质的合成数据,用以改进未来的模型训练(这需要更多的问题实例)。 因此,它既是一种强大的测试时扩展方法,也是我们迈向更智能、数据效率更高的模型开发之路的一步。 而且,这次研究者展现的仅仅是初步的成果。这些优化结果的质量看起来相当可观,但仍有广阔的提升空间,例如产生更优的优化思路、生成更高质量的最终代码,以及将此方法应用于日益复杂的内核。 目前,研究者仍在积极改进的两个具体例子包括: FP16 Matmul:性能达到torch.matmul的52% FP16 Flash Attention:性能达到torch.nn.functional.scaled_dot_product_attention的9% 在现代机器学习任务中,FP32的应用不如FP16或BF16普遍,并且在较新的硬件上,针对FP32的优化往往也更少。 这或许能部分解释,为何基于FP32的内核更容易在性能上超越PyTorch。 作者介绍 Anne Ouyang Anne Ouyang目前是斯坦福大学计算机科学(CS)博士生,在Scaling Intelligence Lab(可扩展智能实验室)进行研究。 她的研究兴趣主要集中在可扩展的自我改进机器学习系统,同时也广泛关注实证机器学习(empirical ML)和性能工程(performance engineering)。 此前,她在MIT获得学士和硕士学位,并曾在NVIDIA cuDNN团队工作,负责编写CUDA内核,用于加速GPU上的深度学习工作负载。 Azalia Mirhoseini Azalia Mirhoseini是斯坦福大学计算机科学助理教授,也是Scaling Intelligence Lab(可扩展智能实验室)的创始人,并在Google DeepMind兼任高级研究科学家。 她的实验室致力于开发可扩展的自主演进人工智能系统与方法论,以期推动通用人工智能的发展。 在加入斯坦福大学之前,她曾在Google Brain和Anthropic等业界顶尖的人工智能实验室工作多年。 她过往的卓越成就包括: 提出混合专家(MoE)神经架构——目前已被前沿的AI模型广泛应用; 领导AlphaChip项目——一项将深度强化学习用于布局优化的开创性工作,并成功应用于谷歌AI加速器(TPU)及数据中心CPU等先进芯片的设计中; 在测试时计算的Scaling方面有深入的研究 Percy Liang Percy Liang是斯坦福大学计算机科学副教授,兼任基础模型研究中心(CRFM)主任。同时也是CodaLab Worksheets的创建者,并借此坚定倡导科研工作的可复现性。 他目前专注于通过开源和严格的基准测试,提升基础模型(特别是大语言模型)的可及性与可理解性。 他曾围绕机器学习和自然语言处理领域进行了广泛研究,具体方向包括鲁棒性、可解释性、人机交互、学习理论、知识落地、语义学以及推理等。 此前,他于2004年在MIT获得学士学位,并于2011年在UC伯克利获得博士学位。 内核优化过程 最后,展示一个Conv2D自动生成思路的优化轨迹示例,torch参考基准时间为1.41毫秒。 第0轮:7.02毫秒,达到参考性能的20.1% 思路:给定pytorch代码,用CUDA Kernel替换操作。 第1轮:7.54毫秒,达到参考性能的18.8% 思路:通过使用__ldg加载不变的张量来利用只读缓存。 第2轮:3.46毫秒,达到参考性能的41.0% 思路:将卷积转换为FP16 Tensor-Core GEMM。 作者评论:这是一种算法优化,将卷积转换为隐式GEMM,这对于在Tensor Core上高效运行卷积至关重要 第3轮:3.67毫秒,达到参考性能的38.7% 思路:采用双缓冲cp.async管线,使全局内存加载与Tensor-Core计算重叠。 第4轮:3.46毫秒,达到参考性能的41.0% 思路:给定pytorch代码,使用隐式矩阵乘法(implicit matmul)的CUDA Kernel替换操作。给定的GEMM内核可能会有帮助。 作者评论:因为优化涉及到使用GEMM,所以在这一轮开始时,使用了一个之前生成的现有优秀GEMM内核作为种子,这个思路是手动编写的 第5轮:1.91毫秒,达到参考性能的74.9% 思路:在每个K-tile循环内部,预计算k_idx分解的内核/输入索引并在共享内存中重用,以避免冗余算术运算。 第6轮:1.37毫秒,达到参考性能的103.6% 思路:在共享内存中预计算并缓存N维GEMM索引,以减少输入数据加载循环内的冗余算术运算。 第7轮:1.38毫秒,达到参考性能的102.9% 思路:通过使用专用的每warp共享内存缓冲区来并行化CUDA内核输出,以消除写入全局内存时的warp级串行化。 第8轮:1.37毫秒,达到参考性能的103.6% 思路:在共享内存中预计算并缓存基础输入坐标,以减少输入数据加载过程中的冗余算术运算。 第9轮:1.36毫秒,达到参考性能的105.1% 思路:对B-fragment加载进行软件流水线处理,使下一个B-tile的共享内存读取与当前B-tile的WMMA计算重叠。 第10轮:1.07毫秒,达到参考性能的133.6% 思路:重用共享内存中预计算的N维GEMM分解来进行输出地址计算,避免冗余且高成本的除法/模运算。 第11轮:1.21毫秒,达到参考性能的117.4% 思路:在half WMMA运算中移除hi/lo分解,如果最终精度可接受,则依赖标准的FP16累积来提高性能。 第12轮:1.01毫秒,达到参考性能的141.2% 思路:通过在流水线的加载阶段动态计算K维索引,使用双缓冲使Asub(权重)和Bsub(输入)的K循环全局内存加载与MMA计算重叠。 第13轮:0.795毫秒,达到参考性能的179.9% 思路:通过使用像half2这样的更宽数据类型,为加载Asub_pipe和Bsub_pipe实现向量化的共享内存写入。 最终代码 最终生成的Conv2D内核代码,使用了先进的CUDA技术,就是人类自己写起来都很有挑战性的那种! import torchimport torch.nn as nnimport torch.nn.functional as Ffrom torch.utils.cpp_extension import load_inlineconv2d_implicit_gemm_cuda_source = r"""#include <torch/extension.h>#include <ATen/cuda/CUDAContext.h> // For at::cuda::getCurrentCUDAStream()#include <mma.h>#include <cuda_fp16.h>using namespace nvcuda;// WMMA tile dimensions#define WMMA_M 16#define WMMA_N 16#define WMMA_K 16// Skew padding for shared memory to avoid bank conflicts#define SKEW_HALF 8 // 8 half elements (16 bytes)// CUDA built-in warpSize is 32 for supported architectures (sm_70+)// This constant is used for host-side configuration (e.g. blockDim)#define CUDA_WARP_SIZE_CONST 32// Threadblock configuration#define WARPS_PER_BLOCK 8// THREADS_PER_BLOCK must be evaluatable by host compiler for blockDim configuration#define THREADS_PER_BLOCK (WARPS_PER_BLOCK * CUDA_WARP_SIZE_CONST)// Macro-tile dimensions computed by a threadblock// BLOCK_M_TILES_WMMA * WMMA_M = output channels processed by a block// BLOCK_N_TILES_WMMA * WMMA_N = output spatial elements processed by a block#define BLOCK_M_TILES_WMMA 8#define BLOCK_N_TILES_WMMA 8#define TILE_M_PER_BLOCK (BLOCK_M_TILES_WMMA * WMMA_M) // e.g., 8 * 16 = 128 (for C_out dimension)#define TILE_N_PER_BLOCK (BLOCK_N_TILES_WMMA * WMMA_N) // e.g., 8 * 16 = 128 (for N_batch * H_out * W_out dimension)// Vector size for shared memory writes (half2)#define VECTOR_SIZE_H2 2// Struct to hold precomputed N-dimension GEMM indicesstruct NDecomposed {int ow_eff;int oh_eff;int n_batch_idx;bool isValidPixel; // True if this pixel_idx is within N_gemm boundsint h_in_base;int w_in_base;};__global__ void conv2d_implicit_gemm_wmma_kernel(const float* __restrict__ input_ptr, // Input: (N, Cin, Hin, Win)const float* __restrict__ weight_ptr, // Weights: (Cout, Cin, Kh, Kw)const float* __restrict__ bias_ptr, // Bias: (Cout) or nullptrfloat* __restrict__ output_ptr, // Output: (N, Cout, Hout, Wout)const int N_batch, const int C_in, const int H_in, const int W_in,const int C_out, const int K_h, const int K_w,const int stride_h, const int stride_w,const int pad_h, const int pad_w,const int H_out, const int W_out,const int M_gemm, // C_outconst int N_gemm, // N_batch * H_out * W_outconst int K_gemm // C_in * K_h * K_w) {// Thread identificationconst int warp_id = threadIdx.x / warpSize; // 0 .. WARPS_PER_BLOCK-1const int lane_id = threadIdx.x % warpSize; // 0 .. 31 (or warpSize-1)// Top-left corner of the macro-tile this block is responsible for in GEMM termsconst int block_row_gemm_start = TILE_M_PER_BLOCK * blockIdx.y;const int block_col_gemm_start = TILE_N_PER_BLOCK * blockIdx.x;// Shared memory for tiles of A (weights) and B (input/im2col) - Double Buffered for K-loop pipelining__shared__ half Asub_pipe[2][TILE_M_PER_BLOCK][WMMA_K + SKEW_HALF];__shared__ half Bsub_pipe[2][TILE_N_PER_BLOCK][WMMA_K + SKEW_HALF];// Shared memory for precomputed N-indices__shared__ NDecomposed n_params_sh[TILE_N_PER_BLOCK];// Shared memory for output stage (per-warp buffers)__shared__ float C_shmem_output_buffers[WARPS_PER_BLOCK][WMMA_M][WMMA_N];// Accumulator fragments per warp.wmma::fragment<wmma::accumulator, WMMA_M, WMMA_N, WMMA_K, float> acc_frag[BLOCK_N_TILES_WMMA];#pragma unrollfor (int i = 0; i < BLOCK_N_TILES_WMMA; ++i) {wmma::fill_fragment(acc_frag[i], 0.0f);}// Populate n_params_sh once at the beginning of the kernelif (threadIdx.x < TILE_N_PER_BLOCK) {int r_b_tile_idx = threadIdx.x;int current_pixel_idx = block_col_gemm_start + r_b_tile_idx;if (current_pixel_idx < N_gemm) {n_params_sh[r_b_tile_idx].ow_eff = current_pixel_idx % W_out;int temp_div_wout = current_pixel_idx / W_out;n_params_sh[r_b_tile_idx].oh_eff = temp_div_wout % H_out;n_params_sh[r_b_tile_idx].n_batch_idx = temp_div_wout / H_out;n_params_sh[r_b_tile_idx].isValidPixel = true;n_params_sh[r_b_tile_idx].h_in_base = n_params_sh[r_b_tile_idx].oh_eff * stride_h - pad_h;n_params_sh[r_b_tile_idx].w_in_base = n_params_sh[r_b_tile_idx].ow_eff * stride_w - pad_w;} else {n_params_sh[r_b_tile_idx].isValidPixel = false;n_params_sh[r_b_tile_idx].ow_eff = 0;n_params_sh[r_b_tile_idx].oh_eff = 0;n_params_sh[r_b_tile_idx].n_batch_idx = 0;n_params_sh[r_b_tile_idx].h_in_base = 0;n_params_sh[r_b_tile_idx].w_in_base = 0;}}__syncthreads();// Constants for vectorized shared memory loading// Number of half2 elements along K-dim for a shared memory tile rowconst int NUM_H2_ELEMENTS_IN_K_DIM = WMMA_K / VECTOR_SIZE_H2;// Number of thread groups, where each group has NUM_H2_ELEMENTS_IN_K_DIM threads.// Each group is responsible for loading the K-dimension for one M-row (for A) or N-row (for B) at a time,// iterating over M-rows or N-rows with this step size.const int NUM_ROW_PROCESSING_GROUPS = THREADS_PER_BLOCK / NUM_H2_ELEMENTS_IN_K_DIM;// --- K-Loop Pipelining ---int num_k_tiles = (K_gemm + WMMA_K - 1) / WMMA_K; // --- Prologue: Load first k-tile (k_tile_iter = 0) into pipe_idx = 0 ---if (num_k_tiles > 0) {int k_tile_start_prologue = 0;int current_pipe_idx_prologue = 0;// Load Asub_pipe[0] for k_tile_iter = 0{// This thread is responsible for the 'h2_idx_in_k_dim_A'-th half2 element// in the K-dimension of the shared memory tile.int h2_idx_in_k_dim_A = threadIdx.x % NUM_H2_ELEMENTS_IN_K_DIM;// Starting 'half' index in shared memory for this half2 write.int shmem_k_start_for_h2_A = h2_idx_in_k_dim_A * VECTOR_SIZE_H2;// Global k-indices for the two half elements.int k_global_A_0 = k_tile_start_prologue + shmem_k_start_for_h2_A;int k_global_A_1 = k_tile_start_prologue + shmem_k_start_for_h2_A + 1;// Decompose k_global_A_0int kw_eff_reg_A_0 = 0, kh_eff_reg_A_0 = 0, ic_eff_reg_A_0 = 0;bool is_valid_k_A_0 = (k_global_A_0 < K_gemm);if (is_valid_k_A_0) {kw_eff_reg_A_0 = k_global_A_0 % K_w;int temp_div_kw_A_0 = k_global_A_0 / K_w;kh_eff_reg_A_0 = temp_div_kw_A_0 % K_h;ic_eff_reg_A_0 = temp_div_kw_A_0 / K_h;}// Decompose k_global_A_1int kw_eff_reg_A_1 = 0, kh_eff_reg_A_1 = 0, ic_eff_reg_A_1 = 0;bool is_valid_k_A_1 = (k_global_A_1 < K_gemm);if (is_valid_k_A_1) {kw_eff_reg_A_1 = k_global_A_1 % K_w;int temp_div_kw_A_1 = k_global_A_1 / K_w;kh_eff_reg_A_1 = temp_div_kw_A_1 % K_h;ic_eff_reg_A_1 = temp_div_kw_A_1 / K_h;} // This thread belongs to 'm_row_group_id_A'-th group of threads.// This group iterates over M-rows of the Asub_pipe tile.int m_row_group_id_A = threadIdx.x / NUM_H2_ELEMENTS_IN_K_DIM;for (int r_a_tile_base = m_row_group_id_A; r_a_tile_base < TILE_M_PER_BLOCK; r_a_tile_base += NUM_ROW_PROCESSING_GROUPS) {int oc_idx = block_row_gemm_start + r_a_tile_base;float weight_val_0 = 0.0f;if (oc_idx < C_out && is_valid_k_A_0) {weight_val_0 = weight_ptr[oc_idx * C_in * K_h * K_w +ic_eff_reg_A_0 * K_h * K_w +kh_eff_reg_A_0 * K_w +kw_eff_reg_A_0];}float weight_val_1 = 0.0f;if (oc_idx < C_out && is_valid_k_A_1) {weight_val_1 = weight_ptr[oc_idx * C_in * K_h * K_w +ic_eff_reg_A_1 * K_h * K_w +kh_eff_reg_A_1 * K_w +kw_eff_reg_A_1];}half2* smem_ptr_h2_A = reinterpret_cast<half2*>(&Asub_pipe[current_pipe_idx_prologue][r_a_tile_base][shmem_k_start_for_h2_A]);*smem_ptr_h2_A = make_half2(__float2half(weight_val_0), __float2half(weight_val_1));}}// Load Bsub_pipe[0] for k_tile_iter = 0{int h2_idx_in_k_dim_B = threadIdx.x % NUM_H2_ELEMENTS_IN_K_DIM;int shmem_k_start_for_h2_B = h2_idx_in_k_dim_B * VECTOR_SIZE_H2;int k_global_B_0 = k_tile_start_prologue + shmem_k_start_for_h2_B;int k_global_B_1 = k_tile_start_prologue + shmem_k_start_for_h2_B + 1;int kw_eff_reg_B_0 = 0, kh_eff_reg_B_0 = 0, ic_eff_reg_B_0 = 0;bool is_valid_k_B_0 = (k_global_B_0 < K_gemm);if (is_valid_k_B_0) {kw_eff_reg_B_0 = k_global_B_0 % K_w;int temp_div_kw_B_0 = k_global_B_0 / K_w;kh_eff_reg_B_0 = temp_div_kw_B_0 % K_h;ic_eff_reg_B_0 = temp_div_kw_B_0 / K_h;}int kw_eff_reg_B_1 = 0, kh_eff_reg_B_1 = 0, ic_eff_reg_B_1 = 0;bool is_valid_k_B_1 = (k_global_B_1 < K_gemm);if (is_valid_k_B_1) {kw_eff_reg_B_1 = k_global_B_1 % K_w;int temp_div_kw_B_1 = k_global_B_1 / K_w;kh_eff_reg_B_1 = temp_div_kw_B_1 % K_h;ic_eff_reg_B_1 = temp_div_kw_B_1 / K_h;}int n_row_group_id_B = threadIdx.x / NUM_H2_ELEMENTS_IN_K_DIM;for (int r_b_tile_base = n_row_group_id_B; r_b_tile_base < TILE_N_PER_BLOCK; r_b_tile_base += NUM_ROW_PROCESSING_GROUPS) {float input_val_0 = 0.0f;if (n_params_sh[r_b_tile_base].isValidPixel && is_valid_k_B_0) {const NDecomposed& current_n_params = n_params_sh[r_b_tile_base];int h_in_eff_0 = current_n_params.h_in_base + kh_eff_reg_B_0;int w_in_eff_0 = current_n_params.w_in_base + kw_eff_reg_B_0;if (h_in_eff_0 >= 0 && h_in_eff_0 < H_in && w_in_eff_0 >= 0 && w_in_eff_0 < W_in) {input_val_0 = input_ptr[current_n_params.n_batch_idx * C_in * H_in * W_in +ic_eff_reg_B_0 * H_in * W_in +h_in_eff_0 * W_in +w_in_eff_0];}}float input_val_1 = 0.0f;if (n_params_sh[r_b_tile_base].isValidPixel && is_valid_k_B_1) {const NDecomposed& current_n_params = n_params_sh[r_b_tile_base];int h_in_eff_1 = current_n_params.h_in_base + kh_eff_reg_B_1;int w_in_eff_1 = current_n_params.w_in_base + kw_eff_reg_B_1;if (h_in_eff_1 >= 0 && h_in_eff_1 < H_in && w_in_eff_1 >= 0 && w_in_eff_1 < W_in) {input_val_1 = input_ptr[current_n_params.n_batch_idx * C_in * H_in * W_in +ic_eff_reg_B_1 * H_in * W_in +h_in_eff_1 * W_in +w_in_eff_1];}}half2* smem_ptr_h2_B = reinterpret_cast<half2*>(&Bsub_pipe[current_pipe_idx_prologue][r_b_tile_base][shmem_k_start_for_h2_B]);*smem_ptr_h2_B = make_half2(__float2half(input_val_0), __float2half(input_val_1));}}}// Loop over the K_gemm dimension in tiles of WMMA_Kfor (int k_tile_iter = 0; k_tile_iter < num_k_tiles; ++k_tile_iter) {__syncthreads(); // Sync point for pipeliningint compute_pipe_idx = k_tile_iter % 2;int load_pipe_idx = (k_tile_iter + 1) % 2;// --- Load Stage for next k-tile (k_tile_iter + 1) into load_pipe_idx ---int k_tile_start_for_load = (k_tile_iter + 1) * WMMA_K;if (k_tile_start_for_load < K_gemm) {// Load Asub_pipe[load_pipe_idx]{int h2_idx_in_k_dim_A = threadIdx.x % NUM_H2_ELEMENTS_IN_K_DIM;int shmem_k_start_for_h2_A = h2_idx_in_k_dim_A * VECTOR_SIZE_H2;int k_global_A_0 = k_tile_start_for_load + shmem_k_start_for_h2_A;int k_global_A_1 = k_tile_start_for_load + shmem_k_start_for_h2_A + 1;int kw_eff_reg_A_0 = 0, kh_eff_reg_A_0 = 0, ic_eff_reg_A_0 = 0;bool is_valid_k_A_0 = (k_global_A_0 < K_gemm);if (is_valid_k_A_0) {kw_eff_reg_A_0 = k_global_A_0 % K_w;int temp_div_kw_A_0 = k_global_A_0 / K_w;kh_eff_reg_A_0 = temp_div_kw_A_0 % K_h;ic_eff_reg_A_0 = temp_div_kw_A_0 / K_h;}int kw_eff_reg_A_1 = 0, kh_eff_reg_A_1 = 0, ic_eff_reg_A_1 = 0;bool is_valid_k_A_1 = (k_global_A_1 < K_gemm);if (is_valid_k_A_1) {kw_eff_reg_A_1 = k_global_A_1 % K_w;int temp_div_kw_A_1 = k_global_A_1 / K_w;kh_eff_reg_A_1 = temp_div_kw_A_1 % K_h;ic_eff_reg_A_1 = temp_div_kw_A_1 / K_h;} int m_row_group_id_A = threadIdx.x / NUM_H2_ELEMENTS_IN_K_DIM;for (int r_a_tile_base = m_row_group_id_A; r_a_tile_base < TILE_M_PER_BLOCK; r_a_tile_base += NUM_ROW_PROCESSING_GROUPS) {int oc_idx = block_row_gemm_start + r_a_tile_base;float weight_val_0 = 0.0f;if (oc_idx < C_out && is_valid_k_A_0) {weight_val_0 = weight_ptr[oc_idx * C_in * K_h * K_w +ic_eff_reg_A_0 * K_h * K_w +kh_eff_reg_A_0 * K_w +kw_eff_reg_A_0];}float weight_val_1 = 0.0f;if (oc_idx < C_out && is_valid_k_A_1) {weight_val_1 = weight_ptr[oc_idx * C_in * K_h * K_w +ic_eff_reg_A_1 * K_h * K_w +kh_eff_reg_A_1 * K_w +kw_eff_reg_A_1];}half2* smem_ptr_h2_A = reinterpret_cast<half2*>(&Asub_pipe[load_pipe_idx][r_a_tile_base][shmem_k_start_for_h2_A]);*smem_ptr_h2_A = make_half2(__float2half(weight_val_0), __float2half(weight_val_1));}}// Load Bsub_pipe[load_pipe_idx]{int h2_idx_in_k_dim_B = threadIdx.x % NUM_H2_ELEMENTS_IN_K_DIM;int shmem_k_start_for_h2_B = h2_idx_in_k_dim_B * VECTOR_SIZE_H2;int k_global_B_0 = k_tile_start_for_load + shmem_k_start_for_h2_B;int k_global_B_1 = k_tile_start_for_load + shmem_k_start_for_h2_B + 1;int kw_eff_reg_B_0 = 0, kh_eff_reg_B_0 = 0, ic_eff_reg_B_0 = 0;bool is_valid_k_B_0 = (k_global_B_0 < K_gemm);if (is_valid_k_B_0) {kw_eff_reg_B_0 = k_global_B_0 % K_w;int temp_div_kw_B_0 = k_global_B_0 / K_w;kh_eff_reg_B_0 = temp_div_kw_B_0 % K_h;ic_eff_reg_B_0 = temp_div_kw_B_0 / K_h;}int kw_eff_reg_B_1 = 0, kh_eff_reg_B_1 = 0, ic_eff_reg_B_1 = 0;bool is_valid_k_B_1 = (k_global_B_1 < K_gemm);if (is_valid_k_B_1) {kw_eff_reg_B_1 = k_global_B_1 % K_w;int temp_div_kw_B_1 = k_global_B_1 / K_w;kh_eff_reg_B_1 = temp_div_kw_B_1 % K_h;ic_eff_reg_B_1 = temp_div_kw_B_1 / K_h;}int n_row_group_id_B = threadIdx.x / NUM_H2_ELEMENTS_IN_K_DIM;for (int r_b_tile_base = n_row_group_id_B; r_b_tile_base < TILE_N_PER_BLOCK; r_b_tile_base += NUM_ROW_PROCESSING_GROUPS) {float input_val_0 = 0.0f;if (n_params_sh[r_b_tile_base].isValidPixel && is_valid_k_B_0) {const NDecomposed& current_n_params = n_params_sh[r_b_tile_base];int h_in_eff_0 = current_n_params.h_in_base + kh_eff_reg_B_0;int w_in_eff_0 = current_n_params.w_in_base + kw_eff_reg_B_0;if (h_in_eff_0 >= 0 && h_in_eff_0 < H_in && w_in_eff_0 >= 0 && w_in_eff_0 < W_in) {input_val_0 = input_ptr[current_n_params.n_batch_idx * C_in * H_in * W_in +ic_eff_reg_B_0 * H_in * W_in +h_in_eff_0 * W_in +w_in_eff_0];}}float input_val_1 = 0.0f;if (n_params_sh[r_b_tile_base].isValidPixel && is_valid_k_B_1) {const NDecomposed& current_n_params = n_params_sh[r_b_tile_base];int h_in_eff_1 = current_n_params.h_in_base + kh_eff_reg_B_1;int w_in_eff_1 = current_n_params.w_in_base + kw_eff_reg_B_1;if (h_in_eff_1 >= 0 && h_in_eff_1 < H_in && w_in_eff_1 >= 0 && w_in_eff_1 < W_in) {input_val_1 = input_ptr[current_n_params.n_batch_idx * C_in * H_in * W_in +ic_eff_reg_B_1 * H_in * W_in +h_in_eff_1 * W_in +w_in_eff_1];}}half2* smem_ptr_h2_B = reinterpret_cast<half2*>(&Bsub_pipe[load_pipe_idx][r_b_tile_base][shmem_k_start_for_h2_B]);*smem_ptr_h2_B = make_half2(__float2half(input_val_0), __float2half(input_val_1));}}}// --- Compute Stage for current k-tile (k_tile_iter) using compute_pipe_idx ---int a_row_start_in_tile = warp_id * WMMA_M;wmma::fragment<wmma::matrix_a, WMMA_M, WMMA_N, WMMA_K, half, wmma::row_major> a_frag;wmma::load_matrix_sync(a_frag, &Asub_pipe[compute_pipe_idx][a_row_start_in_tile][0], WMMA_K + SKEW_HALF);wmma::fragment<wmma::matrix_b, WMMA_M, WMMA_N, WMMA_K, half, wmma::col_major> b_frag_inner_pipe[2];if (BLOCK_N_TILES_WMMA > 0) {int b_col_start_in_tile_current = 0 * WMMA_N;wmma::load_matrix_sync(b_frag_inner_pipe[0], &Bsub_pipe[compute_pipe_idx][b_col_start_in_tile_current][0], WMMA_K + SKEW_HALF);} int current_inner_pipe_idx = 0;#pragma unrollfor (int n_tile = 0; n_tile < BLOCK_N_TILES_WMMA; ++n_tile) {int next_inner_pipe_idx = 1 - current_inner_pipe_idx;if (n_tile < BLOCK_N_TILES_WMMA - 1) {int b_col_start_in_tile_next = (n_tile + 1) * WMMA_N;wmma::load_matrix_sync(b_frag_inner_pipe[next_inner_pipe_idx], &Bsub_pipe[compute_pipe_idx][b_col_start_in_tile_next][0], WMMA_K + SKEW_HALF);}wmma::mma_sync(acc_frag[n_tile], a_frag, b_frag_inner_pipe[current_inner_pipe_idx], acc_frag[n_tile]); current_inner_pipe_idx = next_inner_pipe_idx;}}__syncthreads();// Store results from accumulator fragments to global memory#pragma unrollfor (int n_tile = 0; n_tile < BLOCK_N_TILES_WMMA; ++n_tile) {wmma::store_matrix_sync(&C_shmem_output_buffers[warp_id][0][0], acc_frag[n_tile], WMMA_N, wmma::mem_row_major);for (int elem_idx_in_frag = lane_id; elem_idx_in_frag < WMMA_M * WMMA_N; elem_idx_in_frag += warpSize) {int r_frag = elem_idx_in_frag / WMMA_N;int c_frag = elem_idx_in_frag % WMMA_N;int oc_idx = block_row_gemm_start + (warp_id * WMMA_M) + r_frag; int offset_in_block_N_processing = (n_tile * WMMA_N) + c_frag;if (oc_idx < C_out && offset_in_block_N_processing < TILE_N_PER_BLOCK &&n_params_sh[offset_in_block_N_processing].isValidPixel) {const NDecomposed& current_n_params = n_params_sh[offset_in_block_N_processing];int ow_eff = current_n_params.ow_eff;int oh_eff = current_n_params.oh_eff;int n_batch_idx = current_n_params.n_batch_idx;float val = C_shmem_output_buffers[warp_id][r_frag][c_frag];if (bias_ptr != nullptr) {val += bias_ptr[oc_idx];}output_ptr[n_batch_idx * C_out * H_out * W_out +oc_idx * H_out * W_out +oh_eff * W_out +ow_eff] = val;}}}}torch::Tensor conv2d_implicit_gemm_cuda(torch::Tensor input, torch::Tensor weight, torch::Tensor bias,int N_batch, int C_in, int H_in, int W_in,int C_out, int K_h, int K_w,int stride_h, int stride_w, int pad_h, int pad_w,int H_out, int W_out) {TORCH_CHECK(input.device().is_cuda(), "Input must be a CUDA tensor");TORCH_CHECK(weight.device().is_cuda(), "Weight must be a CUDA tensor");TORCH_CHECK(input.dtype() == torch::kFloat32, "Input must be float32");TORCH_CHECK(weight.dtype() == torch::kFloat32, "Weight must be float32");if (bias.defined()) {TORCH_CHECK(bias.device().is_cuda(), "Bias must be a CUDA tensor");TORCH_CHECK(bias.dtype() == torch::kFloat32, "Bias must be float32");TORCH_CHECK(bias.dim() == 1 && bias.size(0) == C_out, "Bias has wrong shape");}TORCH_CHECK(input.dim() == 4, "Input must be 4D");TORCH_CHECK(weight.dim() == 4, "Weight must be 4D");TORCH_CHECK(input.size(0) == N_batch, "Input N_batch mismatch");TORCH_CHECK(input.size(1) == C_in, "Input C_in mismatch");TORCH_CHECK(input.size(2) == H_in, "Input H_in mismatch");TORCH_CHECK(input.size(3) == W_in, "Input W_in mismatch");TORCH_CHECK(weight.size(0) == C_out, "Weight C_out mismatch");TORCH_CHECK(weight.size(1) == C_in, "Weight C_in mismatch");TORCH_CHECK(weight.size(2) == K_h, "Weight K_h mismatch");TORCH_CHECK(weight.size(3) == K_w, "Weight K_w mismatch");auto output = torch::zeros({N_batch, C_out, H_out, W_out}, input.options());const int M_gemm = C_out;const int N_gemm = N_batch * H_out * W_out;const int K_gemm = C_in * K_h * K_w;if (M_gemm == 0 || N_gemm == 0) {return output;}if (K_gemm == 0) {if (bias.defined()) {output = output + bias.reshape({1, C_out, 1, 1});}return output;}dim3 block_dim(THREADS_PER_BLOCK);dim3 grid_dim((N_gemm + TILE_N_PER_BLOCK - 1) / TILE_N_PER_BLOCK,(M_gemm + TILE_M_PER_BLOCK - 1) / TILE_M_PER_BLOCK);const float* bias_ptr_data = bias.defined() ? bias.data_ptr<float>() : nullptr;cudaStream_t stream = at::cuda::getCurrentCUDAStream();conv2d_implicit_gemm_wmma_kernel<<<grid_dim, block_dim, 0, stream>>>(input.data_ptr<float>(),weight.data_ptr<float>(),bias_ptr_data,output.data_ptr<float>(),N_batch, C_in, H_in, W_in,C_out, K_h, K_w,stride_h, stride_w, pad_h, pad_w,H_out, W_out,M_gemm, N_gemm, K_gemm); AT_CUDA_CHECK(cudaGetLastError());return output;}"""conv2d_implicit_gemm_cuda_declaration = r"""torch::Tensor conv2d_implicit_gemm_cuda(torch::Tensor input, torch::Tensor weight, torch::Tensor bias,int N_batch, int C_in, int H_in, int W_in,int C_out, int K_h, int K_w,int stride_h, int stride_w, int pad_h, int pad_w,int H_out, int W_out);"""# JIT compile the CUDA kernelcustom_conv2d_wmma_ops = load_inline(name="custom_conv2d_wmma_ops_optimized_k_pipe_vec_smem", # Changed name to avoid collisioncpp_sources=conv2d_implicit_gemm_cuda_declaration,cuda_sources=conv2d_implicit_gemm_cuda_source,functions=["conv2d_implicit_gemm_cuda"],verbose=True,extra_cuda_cflags=["-arch=sm_70", "--use_fast_math", "-std=c++17"])class ModelNew(nn.Module):def __init__(self, num_classes=1000): # num_classes is part of original signature, kept for consistencysuper(ModelNew, self).__init__() # Define Conv1 parameters (matching the original model)self.in_channels = 3self.out_channels = 96self.kernel_size_val = 11 # Assuming square kernelself.stride_val = 4 # Assuming square strideself.padding_val = 2 # Assuming square padding# Create a temporary Conv2d layer to initialize weights and biastemp_conv = nn.Conv2d(in_channels=self.in_channels,out_channels=self.out_channels,kernel_size=self.kernel_size_val,stride=self.stride_val,padding=self.padding_val,bias=True # nn.Conv2d has bias=True by default)self.conv1_weight = nn.Parameter(temp_conv.weight.detach().clone())if temp_conv.bias is not None:self.conv1_bias = nn.Parameter(temp_conv.bias.detach().clone())else:# Correctly register 'conv1_bias' as None if not presentself.register_parameter('conv1_bias', None)self.custom_conv_op = custom_conv2d_wmma_ops.conv2d_implicit_gemm_cudadef forward(self, x):N_batch = x.size(0)# C_in_runtime = x.size(1) # Should match self.in_channelsH_in = x.size(2)W_in = x.size(3)# Calculate output dimensionsH_out = (H_in + 2 * self.padding_val - self.kernel_size_val) // self.stride_val + 1W_out = (W_in + 2 * self.padding_val - self.kernel_size_val) // self.stride_val + 1 # Bias tensor handling: pass an undefined tensor if bias is None.# The C++ TORCH_CHECK(bias.defined()) handles this by providing nullptr to kernel.bias_tensor = self.conv1_bias if self.conv1_bias is not None else torch.Tensor()x = self.custom_conv_op(x, self.conv1_weight, bias_tensor,N_batch, self.in_channels, H_in, W_in,self.out_channels, self.kernel_size_val, self.kernel_size_val, # K_h, K_wself.stride_val, self.stride_val, # stride_h, stride_wself.padding_val, self.padding_val, # pad_h, pad_wH_out, W_out)return x 参考资料: https://crfm.stanford.edu/2025/05/28/fast-kernels.html https://news.ycombinator.com/item?id=44139454
斯坦福意外用AI生成超强CUDA内核,性能比人类专家优化得还要好!翻倍碾压原生PyTorch,华人主创
好家伙,AI意外生成的内核(kernel),性能比人类专家专门优化过的还要好! 斯坦福最近披露了一组新发现,结果真的太亮眼了。 由AI优化的内核,在常见深度学习操作上,翻倍超越原生PyTorch,性能至多可以提升近400%—— 矩阵乘法(Matmul,FP32):性能达到PyTorch torch.matmul的101.3%。 二维卷积(Conv2D):性能达到 torch.nn.Conv2D的179.9%。 Softmax:性能达到 torch.softmax的111.8%。 层归一化(LayerNorm):性能达到torch.nn.LayerNorm的484.4%。 Conv2D+ReLU+MaxPool组合操作:性能达到PyTorch参考实现的290.1%,以及torch.compile()参考实现的189.0%。 (在NVIDIA L40S GPU上进行基准测试,性能百分比定义为参考时间除以生成的kernel_size时间) 更惊人的是,这一切都是意外实现的。 研究团队本来的目标是生成合成数据以训练内核生成模型。 结果发现,仅在测试阶段生成的合成数据本身,竟然可以生成性能非常优秀的内核。 围观网友:没想到AI也要取代内核工程师了。 还有人发现,除了性能大幅提升外,研究团队采用的方法也非常有趣: 他们没有简单的在操作上逐步优化(类似于爬坡算法),而是在每次迭代之间加入了一个语言推理的步骤,通过这种方式鼓励搜索过程更加多样化。 也就是说,他们是让系统在每次改进时通过类似“思考”的方式产生更多想法,从而找到更好的解决方案。 具体如何实现,一起来看。 改代码前先生成自然语言优化思想 按照斯坦福团队博客的描述,这种内核生成的思路非常简单——给定torch代码,然后告诉都能写编写自定义内核来替换torch算子。 这些内核是用纯CUDA-C编写,无需使用CUTLASS和Triton等库和DSL(Domain-Specific Language,领域专用语言)。 不同于传统方法的是,模型并不是一上来就直接改代码,而是先用自然语言生成优化思想,然后再将这些思想转化为新的代码变体。 团队这样做的理由是,“按顺序修改”式的优化思路缺乏多样性,导致陷入局部极小值,重复访问同一类转换或无休止地优化没有前景的轨迹。 为了进一步增强思路多样性,斯坦福团队还使用了多分支的探索模式。 具体来说,他们的方法并非每一步都只优化一个候选方案,而是将每个想法分散开来,使其衍生出多个实现,并使用性能最高的内核作为下一轮的种子。 团队使用OpenAI o3和Gemini 2.5 Pro挑战KernelBench 1级中的10个问题,运行多轮后,最佳内核开始出现。 其中大多数最佳结果出现在后续轮次(总共5轮),并且主要是第4轮或第5轮。 KernelBench是斯坦福团队自己提出的一套AI生成内核测试基准,基准中的任务分为3个级别,其中1级是指单一原始操作(Single primitive operation),包括AI的基础构建块(例如卷积、矩阵-向量与矩阵-矩阵乘法、损失函数、激活函数以及层归一化)。 这一发现再加上之前DeepMind的AplhaEvolve,以及o3发现Linux的0day漏洞等一系列事件,让网友们认为Gemini 2.5Pro和o3的能力水平已经达到了新的层级。 回到斯坦福的项目,在生成过程当中,可以看到模型的生成思路开始显现出与人类的经验相似之处—— 内存访问优化: 提高不同内存层次结构(全局内存、共享内存、寄存器)之间数据移动的效率,并确保以最大化带宽和最小化冲突的方式访问数据; 异步操作和延迟隐藏: 通过将慢速操作(如全局内存访问)与计算或其他内存传输重叠,“隐藏”慢速操作的延迟; 数据类型和精度优化: 尽可能使用低精度数据类型(如 FP16 或 BF16)以减少内存带宽要求、提高缓存效率; 计算和指令优化:提高算术计算本身的效率,减少指令数量,或利用专门的硬件指令; 并行性和占用率增强:最大化流多处理器(SM)上的活动线程数量,以更好地隐藏延迟并提高整体吞吐量; 控制流和循环优化:减少与循环、分支和索引计算相关的开销。 并且斯坦福团队还展示了一组具体的优化轨迹,从中可以看出,并不是每一步优化都一定能让速度更快,但经过多个步骤的组合,内核的速度能够得到大幅提升,并最终超越PyTorch。 在具体实现上,有人询问AI生成CUDA内核时的优化建议,是否可以被转化为对应代码实现、还是说只是触发了随机探索? 作者回应说,尽管还没有进行更严谨的系统验证,但是手动检查的案例中,生成的CUDA视线与提出的优化建议是大致匹配的。 即AI并不是在完全随机做优化,而是确实在尝试实现它自己提出的策略。 华人主创团队意外发现 这项研究共有三位作者:Anne Ouyang、Azalia Mirhoseini和Percy Liang。 Ouyang目前是斯坦福大学扩展智能实验室的博士生,她本硕毕业于麻省理工,曾在英伟达cuDNN团队工作。 Percy Liang是斯坦福大学计算机科学副教授兼统计学助理教授,目前担任斯坦福基础模型研究中心主任。 曾和李飞飞一起发布、推进了多项研究工作。 Azalia Mirhoseini是斯坦福大学计算机科学助理教授、斯坦福扩展实验室创始人。她曾在DeepMind、Google Brain以及Anthropic工作过。 她此前参与的研究包括MoE、芯片设计算法AlphaChip等。 本次研究,本来是希望生成数据来训练内核生成模型。 但是在过程中却出现了意想不到的结果,仅在测试阶段生成的合成数据本身,竟然可以生成性能非常优秀的内核。 因为这些内核利用了此前被认为很难实现的高级优化和硬件特性,所以团队决定以博客形式分享此次成果。 不过具体是如何生成数据的,研究团队暂时不对外发布,只是提到了这种设计理念也很简单。 最关键的还是,它已经展示出了巨大潜力。 此外,研究团队也认为此次发现也与最近的一些趋势相呼应——大规模再训练已不是必需。 有时,聪明的搜索和分支策略,可以解锁科学创新并解决复杂问题,通过verifier进行广泛搜索还能有更多收获。 将强大推理能力与同时探索多个假设结合起来,能带来更好结果。就像AlphaEvolve、AlphaEvolution、 Gemini 2.5 Pro深度思考一样。 最后,团队表示这项研究还有很多可优化的空间。比如他们手头上就还在优化两个维度: FP16 Matmul:52% performance of torch.matmul FP16 Flash Attention::9% performance of torch.nn.functional.scaled_dot_product_attention 与FP16或BF16相比,FP32在新推出硬件上的优化程度通常比较低,这也是为何使用FP32内核比PyTorch更容易实现性能提升。 他们表示,虽然现在还有不少限制,但是对于未来前景还是很乐观的。 毕竟最开始,他们连能正常运行的内核都生成不了,但是通过不断优化搜索方法,已经能让flash attention的性能提升到了一个不错的水平。 值得一提的是,搜索使用的资源也很少,大概只用了300万token输入和400万token输出。 One More Thing 实际上,不只是一个团队在尝试开发内核大模型。 就在5月,开发了Devin的Cognition开源了首个通过强化学习即可编写CUDA内核的大模型Kevin-32B。 它基于QwQ-32B在KernelBench数据集上使用GRPO,实现了多轮强化学习,性能优于o3、o4-mini。 参考链接: [1]https://crfm.stanford.edu/2025/05/28/fast-kernels.html [2]https://x.com/anneouyang/status/1928124885567467768 [3]https://x.com/cognition_labs/status/1919835720493236295 — 完 —
无人再谈AI六小龙
2025年行将过半,之前还热闹非凡的AI六小龙,几乎从舆论场中消失:再没有人特意提起这个称号。 DeepSeek的冲击只是一方面。更重要的是,原本被冠以六小龙称号的队伍中,已经有人明显掉队:零一万物将超大模型交给了阿里训练,明确不再追逐AGI,放弃预训练转向应用。“大家都看得很清楚,只有大厂能够烧超大模型。”李开复在接受《智能涌现》的采访时这样表示。 百川智能则专注医疗垂类赛道,在字节、阿里、腾讯等大厂争相上新基础模型时,其创始人王小川曾提出百川智能的底层模型将对标OpenAI,但如今其基础大模型进入了静默期,不再更新。 剩下的智谱AI、MiniMax、月之暗面和阶跃星辰,也失去了如一条过江龙般,足以挑战乃至对抗大厂的资本和技术底气。曾经的AI六小龙,已经在新一轮大模型竞赛中滑落成了新的“AI四小强”。 它们一面成了固守AI创业赛道的最后一道屏障,一面又试图像打不死的小强般,在DeepSeek掀起的新一轮大模型竞赛中,重新找到自己的定位和出路。 从六小龙到四小强的变化背后,是部分玩家在大模型头部阵营中掉队的现实。 随着ChatGPT 在2022年底掀起大模型热,零一万物于2023年5月成立后,作为六小龙中最后一家成立的公司,行业就此开始流传起“AI六小龙”的叫法。 有行业知名大佬或顶尖人才带队,技术团队能力出众,首轮融资就突破为独角兽级别,以及要争夺国产OpenAI的位置,这些都是跻身“AI六小龙”的准入门槛。 在彼时科技大厂如腾讯、字节并未all in 的大模型领域,六小龙冲劲十足。 作为月之暗面的首批员工,张磊(化名)的工位从6楼的循环智能搬到16楼的月之暗面时,他记得联合创始人张宇韬对他们解释了这个名字的由来,“我们永远看不到月亮的背面,所以才要去探索。” 随后,月之暗面完成两轮共计近20亿元的融资,更是凭借首个实现“200万上下文”的技术突破,引来了阿里、字节等大厂的跟进模仿。2023年10月,智谱AI也宣布完成超25亿元融资(估值过百亿元);同一时期,百川智能新一轮融资金额超3亿美元;在去年上半年齐追Sora的追逐战中,MiniMax也领先字节等大厂,率先推出了视频大模型。 “AI不是我在接下来一两年找到什么PMF(产品市场匹配),而是接下来十到二十年如何改变世界。” 杨植麟在去年接受媒体人张小珺采访时的发言,映照的正是六小龙的技术野心。 智谱AI、MiniMax、月之暗面、阶跃星辰、百川智能和零一万物,都离不开以上几大共同评判标准。 以上述四大标准来看,频频由于高管团队分崩离析冲上热搜的零一万物和百川智能,已经失去了并列其中的资格。 在DeepSeek开启的2025年,零一万物辛辛苦苦拉起的技术团队分崩离析。包括曹大鹏、戴宗宏等负责核心技术和产品方向的高管接连出走,最近一次是模型预训练负责人谷雪梅宣布离职。 王小川创建的百川智能也面临技术团队的动荡。今年3月,作为王小川在搜狗时期的老部下,在百川智能负责大语言模型技术开发的联创陈炜鹏宣布离职,同一时期离开的还有另一位联创焦可。 “去年每个月还能拿出几百万到千万做投流,让月活不那么难看,今年都转向做海外投流了,” 作为某个六小龙的市场人员,黄嘉(化名)告诉字母榜(ID:wujicaijing),去年单月投流过亿的月之暗面,今年2月停止了投流,而他所在的某个小龙,去年就已经停止了投放,纯粹依靠自然流量之下,AI 原生APP的月活数据也就掉到了百万级别。 萧条之下,剩下的智谱AI、MiniMax、月之暗面、阶跃星辰四家,尽管没有公开爆出放弃预训练的消息,但其在追赶OpenAI的进度上都有了明显的下滑。 出身学院派,同属清华系,智谱AI基础大模型最后一次更新停止在2024年12月发布深度推理模型GLM-Zero-Preview。进入2025年,智谱的新动作只有发布了开源的GLM-4-32B-0414系列模型。月之暗面1月20号发布的Kimi1.5推理模型热度被 DeepSeek R1 压过,随后再无更新。跃阶星辰2025年1月一周内集中更新6款模型后,再无新迭代。 即便是还在迭代的MiniMax,其5月更新的MiniMax Speech - 02选择的也是文本转语音的场景。 而OpenAI在2月以来先是推出了GPT-4.5,随后将推理模型从o1迭代到o3,同时推出了o4 mini。对于四小强来说,如今成为国产OpenAI,甚至超越OpenAI,似乎已经成了难以到达的远方。 更糟糕的是,从2024年下半年开始,智谱之外,它们也几乎再无融资消息传出。 如果它们也抵挡不住大厂的冲击,那么,AI 1.0时代“四小龙”(商汤,旷视,依图,云从)的昨天,恐怕便是AI四小强的今日之鉴。 更糟糕的是,这也将向外界明确传递一个信号:基础大模型赛道,将再无创业公司的立身之地。 AI六小龙风光不再,最直接的原因正是商业化。 根据《智能涌现》报道,2024年12月底,零一万物的预训练团队收到阿里“通义”的offer,Infra团队则收到了阿里云团队的offer。“阿里收编”的背后,源自零一万物的判断:初创公司投入超大模型预训练的性价比,太低了。 在采访中,李开复则反复提及他理想化的“预训练”是做务实的、小而快的,然后以商业性价比来评估的模型。 而提到商业化,相比起OpenAI的ChatGPT商业版本付费用户达到100万,预计2025年收入将达到127亿美元,同比增长200%,六小龙对营收却都默契的三缄其口。 外部来看,大厂的快速入局又步步紧逼。 作为小而美的团队,六小龙此前凭借技术大牛坐镇和快速切入,被视为领先大厂一步的AI明星创企:Kimi创新性地以200万字上下文提升了语言大模型的技术门槛;MiniMax用星野率先攻占了AI+社交的垂类领域,更在视频大模型上一度领先字节等大厂。 不过,随着字节、阿里、腾讯今年积极布局AI,拿出动辄百亿的资金扶持自家的AI APP,美团、小红书等也都在自建大模型团队,六小龙的先发优势已经被完全赶超。 原本就被用以对抗大厂而叫响的“AI六小龙”称号,正逐步失去现实的意义。 同时,DeepSeek所代表的开源模型,更是加速了外界对六小龙们的技术拷问。 在去年开源与闭源孰优孰略的争议中,杨植麟曾经在采访中表示“开源落后于闭源”,李彦宏也曾肯定地表示,闭源模型将持续保持对开源模型的优势,商业化闭源模型一定能在市场中胜出。 彼时,六小龙们还可以凭借赶超开源模型一步的技术优势,输出自己的美好故事。 但当免费开源且技术更为强大的DeepSeek出现后,开源成了新潮流,六小龙最后的堡垒也迎来炮击。 而同样作为此前坚持闭源生态的创企,OpenAI在开源生态竞争下,却在3月宣布完成新一轮400亿美元融资,投后估值达到3000亿美元。这一估值不仅超过了英特尔和AMD的市值总和,也超过了阿里巴巴的市值,成为全球估值最高的私营科技公司之一。 从2023年10月的860亿美元估值,到去年10月完成66亿美元融资后,估值增至1570亿美元,再到如今的3000亿美元,OpenAI坐火箭式的估值增长,正是基于资本市场对OpenAI在大模型领域领先地位的认可。 面对DeepSeek的冲击,OpenAI持续推动模型迭代,新上线的“吉卜力风格”AI绘图功能掀起热潮,仍是当前行业最先进模型的代表。 反观六小龙,在技术迭代上硬通货不足,其存在的价值和发展空间被质疑,也就成了难以避免的残酷现实。 从能与大厂一较短长的六小龙到颇显落寞的四小强,AI创企的含金量也大幅缩减。 去年11月,根据“晚点LatePost”报道,月之暗面从字节手里抢到了新技术负责人——华为诺亚方舟实验室原 AI 基础理论团队研究员刘征瀛。 尽管这位技术大牛也曾被字节高层邀请加入字节大模型团队,但他还是选择了加入创业公司。 “与其去大厂里当螺丝钉,不如进创企,职级高是一方面,最重要的是有很快的迭代,更自由,而且初创公司也能给到和大厂差不多的薪资包。” 某头部985高校的具身智能相关领域在读博士生告诉字母榜,今年火热的具身智能正如去年的大模型,创企的吸引力不比大厂小。 而如今,六小龙的联创出走已经不是什么新鲜事,曾是零一万物核心成员的黄文灏加入了字节,而最近前零一万物联创谷雪梅被爆离职,正在筹备创业。 核心高管们或回流大厂,或出走创业,都投射出AI六小龙对顶尖人才吸引力的下降。 根据Z Finance统计,除了阶跃星辰暂未出现高管离职外,六小龙中其余几家都有核心高管离职。其中智谱AI原视频模型负责人加入字节,月之暗面前大模型产品负责人独立创业。 在“投项目前先看人”的大模型创投界,对希望用技术改变世界的六小龙来说,技术团队核心高管的出走,不仅会在短期内影响其模型迭代速度,也会减少其和投资人“推拉”的砝码。 图注:六小虎高管离职情况 随着2025年市场热度由基础大模型转向具身智能领域及Agent等AI应用领域,曾经作为技术引领者的智谱AI、MiniMax、月之暗面、阶跃星辰,几乎无一例外都转变成了追随者。 Manus引发关注之下,除了智谱选择跟进通用Agent之外,其余几家暂未有动作。 即便现在还能以四小强立身的智谱AI、MiniMax、月之暗面、阶跃星辰,前路也仍然挑战重重。 这方面,曾在AI 1.0时代被称为AI四小龙的商汤、旷视、云从、依图,殷鉴在前。 2016年,AlphaGo横空出世带火了AI,那时技术领先的上述四家创业公司被并称为“AI四小龙”。其中商汤于2021年港股上市,云从在2022年成功科创板上市。 但高研发投入之下,商业化却迎来惨淡局面。随着OpenAI出现,大模型成为AI主流,拿不到融资的四家公司,被迫开启大裁员。 作为六小龙中最早掉队的零一万物的创始人,李开复3月曾直接回应,中国市场最终可能只有三家能够真正站稳脚跟的大模型提供商,分别是DeepSeek、阿里巴巴和字节跳动。 在技术领先决定一切的AI赛道,四小强面临着空前的险境,在融资几乎中断情况下,如何继续推动自家模型迭代,追赶全球最先进水平?
三星在美国被控侵犯Maxell三项专利,被罚8.48亿元
IT之家 5 月 31 日消息,《韩国先驱报》昨日(5 月 30 日)发布博文,报道称三星电子被控侵犯 Maxell 公司的三项专利技术,被美国联邦陪审团裁定需支付 1.177 亿美元(现汇率约合 8.48 亿元人民币)的巨额罚款。 这起案件在美国得克萨斯州东区地方法院审理,陪审团认定三星的 Galaxy 智能手机、平板电脑及其他设备未经许可使用了 Maxell 公司的三项专利技术。 这些技术涵盖设备解锁方式、数字数据处理方法以及图像和视频的重现功能,直接影响用户体验和产品核心性能。 IT之家注:Maxell 公司曾以“Blown Away Guy”磁带广告闻名,是录音介质领域的佼佼者。其名称源于“Maximum capacity dry cell”(最大容量干电池),最初以电池起家,后来扩展到磁带和软盘业务。Maxell 如今更多聚焦工业组件,同时仍生产电池和投影仪等消费电子产品。 Maxell 于 2023 年 9 月正式起诉三星,指控其在 SmartThings 设备、多款智能手机、笔记本电脑甚至家用电器中侵犯了七项专利技术。 值得一提的是,三星与 Maxell 的关系并非一直紧张。2011 年,三星曾与 Maxell 的前身日立消费电子公司签订为期十年的专利许可协议,涵盖十项专利技术。 然而,该协议于 2021 年到期后,Maxell 指控三星继续使用相关技术,并拒绝协商新的许可协议。
饿了么的行业新战事:向一家AI公司进化
外卖行业战火重燃迄今已逾百日,从美团京东的对垒,到饿了么挺进、行业变阵为“三国杀”,变数横生,入局最晚者却提速最快。 饿了么联合淘宝闪购虽然姗姗来迟,却跑得更快。在不到一个月的时间内取得了超过4000万单的日单量,成为外卖大战至今最引人瞩目的战报之一。 正在被悄然重塑的外卖市场格局背后,一个出人意料的重要角色开始被注意到,那就是AI。 这个能大幅提升外卖行业当下和未来效率的创新杠杆,正在成为这场争夺战的关键胜负手。 01 外卖的“含AI量”大幅提升 对外卖骑手来说,夏天一年之中最辛苦的几个月,不仅要在持续高温下奔波送餐,还要时常面对因天气原因带来的设备问题。 饿了么骑手黄晓琴发现,每到天气炎热时,自己的智能手机就容易出现卡顿,原因是在配送路途中长时间被暴晒而导致电池温度升高。夏天还会时常下雨,打湿手机屏幕,不仅操作不方便,还影响骑手接单、点送达等。 为了帮助骑手解决这些痛点,饿了么上线了一款AI助手“小饿”,这是国内首个基于大模型技术打造的骑手端智能体。骑手原本需要自己操作手机界面,现在可以通过语音“小饿小饿”唤醒,“接、取、送、达”都可以通过语音确认来完成。 除了语音交互功能,“小饿”还可以通过实时分析骑手位置、订单状态及环境数据,主动推送权益提醒、天气预警、路线封路提示等,降低配送风险。“小饿”的个性化智能分析功能,还可以基于骑手历史数据与周边订单热力图,提供“哪里订单多”“当前收入预估”等智能分析,帮助骑手优化接单策略。 黄晓琴是第一批用上“小饿”的骑手,有了语音交互功能后,不仅解放了双手,还可以将手机放进口袋里,避免高温曝晒造成卡顿。 在商家侧,饿了么也在积极拥抱AI。 今年4月初,饿了么面向平台新入驻商家,发布了“AI入驻店铺助手”。这是一款基于AI开发的智能助手,不仅支持自然语言对话服务,还可以一站式引导商家完成所有入驻流程,全过程最快只需5分钟。 据饿了么官方介绍,目前饿了么的智能化商家经营体系还包括智能店装、智能发品、智能选品托管、智能美图、经营诊断、营销智投等在内的一揽子AI产品工具。借助这些工具,平台上数十万商家的经营效率已有显著提升。 此外,平台也能在AI技术的帮助下,迅速识别和处置有问题和风险的商家,让好商家经营得更好,形成良性竞争。 外卖是典型的三方市场,消费者是其中重要的一环。AI功能的介入,也让消费者点餐变得越来越方便。 几个月前,智己、斑马智行和饿了么联合发布“AI外卖”。用户只需说出想点的产品,系统就可以识别模糊语义并下单,在点餐过程中,用户可以用语音添加菜品、修改口味或备注要求等。系统还可以根据用户饮食习惯以及身体变化主动推荐合适餐品。 饿了么还在积极打造AI生态、招揽AI人才,通过举办各类AI算法大赛,探索AI改变外卖行业的更多可能性。 今年3月,饿了么宣布启动首届AI算法大赛,来自全国287所高校的学生参赛,作品聚焦智慧养老、智慧骑士、智慧营销等AI应用场景。 发生在饿了么平台上的故事是一个缩影。随着AI的深度参与,外卖行业正在加速向下一个阶段奔跑。 02 行业来到新赛点 传统的外卖是一个十分讲究“人效”的行业。 要依靠大量地推人员撬动全国上百座城市中的上千万餐饮商家入驻平台,还要组建一支庞大且高效的配送团队,用每一单的“微利”来维系整个平台的运转。 正因为此,人们习惯于将外卖称为“水电煤”的生意。 当行业发展进入成熟阶段,对人效的挖掘已接近极限,此时就需要引入新的生产要素。饿了么的新“武器”,就是AI加持与生态协同。 今年2月,新玩家高调入局,打响了外卖大战的第一枪。随之而来的是熟悉的烧钱大战:新玩家大幅降价,老牌巨头跟进补贴。此时,饿了么按兵不动,并没有急于参与混战。 4月30日,五一假日前一天,淘宝宣布旗下即时零售业务“小时达”正式升级为“淘宝闪购”,在淘宝App首页标签栏以“闪购”一级流量入口展示,首日上线50个城市,在数日内推广至全国。 同一天,饿了么发布“饿补超百亿”补贴计划,与淘宝闪购联手入局外卖大战,以免单、大额优惠券等方式吸引用户,并将供给向淘宝闪购全部开放。 补贴开启后不久,“饿了么害我一天三杯奶茶”的相关话题登上微博热搜。 饿了么官方数据显示,五一小长假期间,奶茶、冰粉、饮料冰品、咖啡等多品类外卖单量均同比增长超过100%。一系列优惠活动,拉动游客外卖单量环比增长110%,在秦皇岛、连云港等地环比增长超过260%,五一被饿了么补贴成了“美食节”。 截至5月6日,饿了么在63个城市的单日物流订单创历史新高,带动全国订单突破历史峰值。此前一天,上线仅6天的淘宝闪购单日订单量也突破了1000万单。 值得注意的是,在饿了么与淘宝闪购最新的4000万单战报中,非茶饮订单占比达到75%,非餐品类订单增长也远超预期。 茶饮是外卖行业的热门品类。一位长期关注外卖行业的分析人士告诉雪豹财经社,在平日时段,茶饮通常在外卖订单中的占比大约在10%~20%之间。而在节假日或平台补贴期间,茶饮在整体单量中的占比会翻一倍甚至数倍。 从这个角度来看,饿了么联合淘宝闪购所带来的订单量增长更加全面且健康。 饿了么能在短时间内取得这样的成绩,一方面得益于与阿里生态的高度协同所撬动的即时零售市场增量,另一方面也与长期坚持AI化战略不无关系。 2023年底,阿里巴巴集团CEO吴泳铭就曾为以饿了么和高德为核心的阿里本地生活定调:发展到目的地和到家的科技服务,把握AI发展机遇。 随后,饿了么内部提出以科技创新能力为基底的AI技术是公司长期发展的想象力之一,并开始加速推进AI在外卖业务上的应用和落地。 据雪豹财经社了解,饿了么管理层近期在内部分享时表示,2026财年(自然年2025年Q2到2026年Q1)是AI技术变革的战略窗口期,饿了么将继续加快AI应用产品的推出和迭代速度,通过技术助力生态各方都能更好地“升维”解决问题、提升效率。 饿了么的目标,是成为第一波全面AI化的公司。 03 乘着风,才能跑得更快 之所以要全面推进AI化,与当前外卖行业的竞争态势密不可分。 作为一家平台型企业,饿了么要同时服务好骑手、商家和用户三方,但这三方的利益并不完全统一:消费者希望买到更优惠的产品,骑手希望获得更高的收入,商家希望维持合理的利润水平。 在这种背景下,打价格战、打嘴仗所带来的仅仅是短期增长,是否可持续需要看是否从根本上解决行业的效率问题。 一个正向的思考逻辑应该是:骑手通过优化配送路线和接单策略,更高效、更安全地进行配送;商家通过简化流程,节省更多成本;消费者则在支付合理费用的同时,获得更好的用户体验。 同时实现这些,需要大量数据和强大计算能力的支持。饿了么的优势在于,它背后是整个阿里集团的商业生态与技术底座。 在生态方面,阿里拥有丰富的零售商品货盘及丰富的品牌资源,截至目前,已有300多万家线下门店开通了淘宝小时达服务,优势品类主要是3C数码、服饰、快消(母婴亲子)、鲜花绿植、食品生鲜、宠物、玩具等。 依托淘宝闪购成熟的品牌商家供给,饿了么获得了在即时零售领域更大施展拳脚的空间。 饿了么管理层在内部分享中指出,阿里集团生态优势让饿了么具备更强的竞争力,一体化参战,更可以高效集中优势资源,快速拿到战役结果。 在AI能力上,阿里集团拥有成熟的“三位一体”AI生态:AI算力基建阿里云、以通义大模型为主的模型研发,以及一系列AI应用产品。 阿里最新发布的新一代开源模型Qwen 3(千问 3),参数量仅为DeepSeek-R1 的三分之一,成本大幅下降的同时,性能超越R1、OpenAI-o1等全球顶尖模型,登顶全球最强开源模型。截至目前,阿里通义已开源超过200个模型,全球下载量超过3亿次。 在饿了么近期发布的多个AI产品中,都能看到阿里集团AI的影子。例如,“AI外卖”功能就是基于通义千问等大模型,通过蒸馏技术协同工作所实现。 在商家体验上,饿了么也早在数年前就借助阿里云的通用计算能力,实时识别和防控新出现的无效评论,确保评论内容真实客观,降低恶意评价对店铺经营的影响。 阿里巴巴集团CEO吴泳铭此前表示,今年将以饱和式投入的打法,聚焦几大核心战役。这几个关键战役将由多个业务方参与,发挥各自优势和长项,以全局价值最优来制定各项业务的协同策略。显然,“AI味儿”越来越浓的饿了么在这场协同作战中扮演了重要角色。 外卖大战归根到底,拼的是效率,而效率并不能通过补贴、内卷来提升。用技术让骑手配送更安全,商家经营更简单,用户下单更省心,推动科技向善才是外卖大战的意义所在。 正如马云所说,未来不是让AI取代人类,而应该是让AI解放人类,更懂人类,服务好人类。
ABB中国工厂智能化升级:AI技术让千余工序“打螺丝”零失误
快科技5月31日消息,据媒体报道,上海浦东的ABB超级机器人工厂通过引入AI技术,成功将生产线上的"拧紧螺丝"操作成功率从80%提升至近100%。这一突破性进展标志着全球制造业智能化转型进入新阶段。 在传统制造环境中,图像识别技术准确率仅约20%。ABB通过深度学习技术的应用,经过一年多的模型训练,现已能够有效应对工厂环境中的光线变化、零件差异甚至缺陷等问题。这项创新技术已在ABB瑞典工厂成功应用,并即将在上海超级工厂复制落地。 AI技术的深度应用正在重塑工业生产模式。以焊接检测为例,ABB的智能焊缝质量检测效率较人工提升20倍,实现了"边焊接边检测"的流程整合。目前,ABB正与英伟达等科技企业合作开发数字孪生平台,通过问题数据溯源分析提升产线管理水平。 预测性维护是AI改造传统制造的又一典型案例。ABB基于海量历史数据开展的电机停机预测研究,吸引了50多所高校、300多名研究者参与。该公司运动控制事业部负责人表示,正在推进西安交大团队研究成果的产品化进程。 数据显示,ABB全球AI项目数量在过去一年实现翻倍增长,达到250余个。这些项目涵盖工作流程优化和客户合作开发等多个领域。在中国市场,ABB的AI应用已取得显著成效:厦门工业中心通过屋顶光伏智能调控实现年减碳13400吨;青岛特钢的高速线材生产线借助AI图像识别系统实现了异常状态预警与数字控制的智能联动。 随着AI技术在工业领域的深入应用,制造业正迎来效率提升和质量控制的革命性变革。ABB的实践表明,智能化转型已成为全球制造业发展的必然趋势。
苹果头显市场受挫,却意外催生了这六大iOS革新设计
iOS 26将迎来新设计 凤凰网科技讯 北京时间5月31日,据科技博客MacRumors报道,苹果新一代iOS 26、macOS 26、tvOS 26和watchOS 26系统(采用年份命名)即将亮相,该公司计划引入一套全新设计风格,据称灵感来自其头显Vision Pro搭载的最新操作系统visionOS。 根据目前的传闻和泄露信息,以下是iOS从visionOS借鉴的设计理念: 1.半透明 半透明设计 在苹果内部,iOS 26的重新设计项目代号为“阳光房”(Solarium),这个代号能够让外界一窥苹果的关注重点。“阳光房”其实就是一种全玻璃结构的房间,旨在引入大量光线。visionOS中的半透明设计元素能更好地融入背景,带来一种不突兀的视觉效果,让现实世界中的色彩和光线自然穿透界面。这种半透明设计如果应用在“照片”等应用中,效果会非常契合。 2.浮动导航栏与菜单 浮动设计 浮动菜单和导航栏与半透明效果完美结合。在VisionOS中,一切事物都仿佛漂浮在你周围的空间之中,无论你是通过透视摄像头观察周围环境,还是身处虚拟现实背景之中。在iOS 26中,苹果可能会通过阴影和投影效果来模拟这种效果,使界面元素看起来略微悬浮于背景内容之上,营造出柔和、模糊的层次感。 3.圆角按钮和界面元素 圆角按钮 iOS已采用圆角方形和圆角矩形来设计图标、应用内通知、菜单、搜索栏以及我们熟悉的所有卡片式界面,但visionOS的圆角设计更为圆润。iOS的悬浮导航栏可能采用药丸形状,边缘圆角更为锐利。 4.玻璃质感外观 玻璃质感 借助半透明设计,visionOS的界面看起来几乎像磨砂玻璃。苹果在2025年WWDC Logo展示的设计特色是一道带有渐变柔和色彩的磨砂玻璃彩虹,这或许暗示了他们计划采用一种类似海玻璃风格的磨砂质感设计,这与我们在visionOS中已经看到的风格相差不远。 5.细腻的光影变化 光影效果 在visionOS中,半透明的界面元素可以与用户所在房间的光照条件产生互动。虽然这种效果无法直接应用到iPhone上,但据称iOS将引入一些细腻的光影效果,用以强化界面的半透明感和玻璃质感设计。 6.简约化 设计简约 大多数情况下,visionOS中的苹果应用采用了简化的设计风格,由于需要为用户的视线交互预留足够空间,整体界面显得更为通透和轻盈。iOS 26可能会借鉴这一理念,采用更精简的导航和菜单元素,从而带来更清爽、不杂乱的视觉体验。(作者/箫雨) 更多一手新闻,欢迎下载凤凰新闻客户端订阅凤凰网科技。想看深度报道,请微信搜索“凤凰网科技”。
iPhone16 Pro两周狂卖150万台!苹果这一刀,国产机集体懵了
苹果这波操作,直接把国产手机厂商整不会了。两周时间,iPhone16 Pro在中国市场卖爆150万台,激活量暴涨150%,市场份额重回25%以上,把华为、小米统统挤下王座。谁能想到,年初还被唱衰“挤牙膏”的苹果,靠着一手降价加国补的组合拳,硬是打出了王炸效果。 事情要从两周前说起。苹果突然下调渠道价,尤其是128GB版iPhone16 Pro,价格直接杀到5999元。这还没完,赶上国家补贴政策,消费者还能再薅500元羊毛,最终到手价低至5499元。更狠的是,有些电商平台叠加优惠券后,价格直接干到4999元——这价格比某些国产旗舰机还便宜! 结果可想而知,第一周就卖断货。电商平台紧急调货后,第二周激活量直接冲上百万台。现在打开销量榜,iPhone16全系霸占前三名。更让厂商们头疼的是,苹果这波降价直接把高端市场的水搅浑了。 原本国产机们盯着6000元价位段,想着用“性价比”抢苹果用户,结果苹果反手就是一个“价格对冲”,128GB版iPhone16 Pro直接杀到5500元档,和国产旗舰机正面硬刚。 这一拳打得国产机毫无还手之力。论性能,A18芯片吊打所有安卓芯片;论生态,iOS系统碾压式优势;论拍照视频,iPhone的算法和色彩科学至今无人能敌;更别说品牌号召力,苹果logo往那一摆,就是最好的广告。现在价格还跟你差不多,消费者用脚投票的结果可想而知。 国产厂商现在进退两难。跟进降价吧,本身利润就薄,再打价格战怕是喝西北风;不降价吧,用户全被苹果抢走,库存压力直接拉满。更要命的是,苹果这波降价不是清库存,而是精准卡位国产机的核心价位段。以前国产机还能靠“大电池、快充、高像素”这些差异化卖点守住阵地,现在苹果把价格拉到同一水平线,这些优势瞬间就不香了。 说到底,苹果这波操作暴露了国产高端机的致命短板:缺乏不可替代的核心竞争力。当价格不再是护城河,当苹果愿意放下身段拼性价比,国产机引以为傲的“性价比”标签瞬间被撕得粉碎。这场突如其来的价格战,给所有国产厂商上了一课:高端市场不是靠堆料就能站稳的,没有真本事,降价就是自杀。 现在压力给到国产阵营这边——是咬牙跟进价格战,还是另辟蹊径找新赛道?苹果已经用实际行动证明,只要价格到位,高端市场的大门永远向它敞开。而国产机们,是时候拿出点真家伙了。
vivo S30 系列三丽鸥限定礼盒:你想要的可爱都在这里|新品画报
S30 系列发布的同时,vivo 还推出了和三丽鸥家族联名的产品 —— vivo S30 系列三丽鸥家族礼盒。 礼盒用了以粉色为主调的设计,做成了双层收纳的形式。顶盖有展开结构,可折叠出三丽鸥家族的圆形立牌结构。顶盖的内侧,就放置了一张附带限定联名相纸和联名手机主题的权益卡。 礼盒顶部放置了手机本体和联名保护壳,下层做成了抽屉结构,取出后能见到立牌支架、手机袋和延长手机挂绳。 手机壳用了粉色软壳设计,vivo 加入的洞洞壳元素,用户可以将三丽鸥家族的成员,像是凯蒂猫、美乐蒂、酷洛米、大耳狗和布丁狗以及 S30 系列联名铭牌按照自己喜好调整位置和角度。 延长挂绳用的串珠式的手饰设计,足够的长度可以做成手绳或挂颈。连接手机挂件的结构也是一个通用挂钩,用户可以将它挂在其他的地方。 支架做成了两块立牌组合的设计,表面印有三丽鸥家族成员的图案,立牌质感加上通用挂扣也方便用户将它们随意挂到别的地方。 手机包做得很厚实,同时也配备了都用挂扣的长挂绳,方便装拆的同时,也能让用户将之前的饰品全部挂上去。 除了礼盒,vivo 还推出了三欧丽家族联名的主题和相框,用户通过权益卡兑换后就能够在手机上使用。
一汽奥迪Q6L e-tron纯电SUV开启预售,搭载华为乾崑智驾技术
IT之家 5 月 31 日消息,一汽奥迪 Q6L e-tron 纯电 SUV 今日在 2025 粤港澳大湾区车展开启预售,共推出四款车型,搭载华为乾崑智驾技术,支付 1000 元预订金可抵扣 6000 元购车款。 预售期下订一汽奥迪 Q6L e-tron 超长续航版 / Q6L Sportback e-tron 超长续航版,至高可享价值 2.4 万先锋舒享装备包,包括价值 10000 元的全息视界抬头显示、价值 8000 元的高质感超纤顶棚、价值 6000 元的高定专属流光车身漆色。 预售期下订一汽奥迪 Q6L e-tron 首发领航版,标配奥迪高级驾驶辅助系统并至高可享价值 6 万装备权益,包含先锋舒享装备包以及升维智享装备包,后者包括价值 15000 元的贯穿式光域美学数字 OLED 尾灯、价值 10000 元的 21 英寸 Audi Sport 版动感轮毂、价值 10000 元的 Audi Sport 经典豪华黑光套件、价值 1000 元的首发版标识 Edition one 投地灯。 预售期下订一汽奥迪 Q6L Sportback e-tron 首发领航版,同样标配奥迪高级驾驶辅助系统并至高可享价值 3.22 万装备权益,包含先锋舒享装备包以及升维浸享装备包,后者包括价值 7200 元的 Bang & Olufsen 豪华音响系统、价值 1000 元的首发版标识 Edition one 投地灯。 根据此前官方公布的信息,奥迪 Q6L e-tron 是奥迪品牌基于 PPE 豪华纯电动平台打造的首款车型,长宽高分别为 4884/1965/1687 毫米,轴距达到 2995 毫米。 新车搭载华为乾崑技术组合驾驶辅助,并配备宁德时代 800 伏三元锂电池包。根据车型配置不同,提供 CLTC 纯电续航 709 公里、715 公里、752 公里、765 公里共 4 种版本。 该车座舱为“五屏联动”布局,包括防眩光双 OLED 曲面显示屏、10.9 英寸行业唯一双 e-cell 防窥技术智慧副屏,主副屏支持飞屏分享。同时,新车还有 88 英寸全息视界抬头显示,可将驾驶信息融入真实路况。新车内置 20 处 B&O 扬声器,最大输出功率 830W,还包含 B&O 头枕音响。 IT之家附官方一图知:
赛力斯张兴海谈入股引望:我跟余承东和华为领导说这是“亲上加亲”
快科技5月31日消息,2025(第三届)未来汽车先行者大会于5月31日至6月1日在深圳国际会展中心(宝安)盛大举办。赛力斯集团股份有限公司董事长张兴海受邀出席大会并发表演讲。 在演讲中,谈及赛力斯入股引望一事,张兴海透露道:“我们当时跟余总(余承东),跟华为领导说这是‘亲上加亲’,问界产品也可以更进一步得到赋能”。 引望,作为华为技术有限公司的子公司,于2024年1月正式成立。该公司专注于汽车智能系统及部件解决方案的研发、设计、生产、销售和服务,业务范畴广泛,涵盖汽车智能驾驶解决方案、汽车智能座舱、智能车控、智能车云以及智能车载光等多个领域。 2024年8月26日,赛力斯集团股份有限公司发布公告,宣布计划以115亿元现金出资入股深圳引望智能技术有限公司。通过此次投资,赛力斯将获得引望10%的股权以及1个董事席位。 值得一提的是,问界是赛力斯集团股份有限公司旗下的高端智慧汽车品牌,由赛力斯与华为携手深度合作打造。双方在技术研发、生产制造以及渠道销售等关键环节紧密协作,共同推动问界品牌的发展。截至2025年5月,问界品牌已成功推出4个系列车型,分别是M5、M7、M8和M9。
马斯克被曝正尝试游说美国立法者,为无人驾驶车辆“定规矩”
IT之家 5 月 31 日消息,彭博社援引知情人士消息称,埃隆・马斯克正推动立法者帮助为无人驾驶汽车扫清道路。 最近几周,马斯克与他的团队成员直接联系国会议员以寻求支持,并参与了 5 月 15 日提出的无人驾驶汽车法案修订工作。据IT之家了解,该法案旨在为无人驾驶汽车的基本框架奠定基础。 当地时间周五,在白宫的新闻发布会上,马斯克表示,即便他离开自己主导的政府效率部门,他仍将继续为政府建言献策。 特斯拉计划在 6 月 12 日于奥斯汀推出期待已久的共享出行服务,届时将使用少量现有的 Model Y SUV。特斯拉还计划将专门设计的 Cybercabs 加入其共享出行服务,预计明年开始量产。 目前,特斯拉的 Cybercab 将受限于联邦规定,只有一批不带方向盘和控制踏板的 2500 辆测试车能享受特殊豁免。特斯拉和其他无人驾驶汽车运营商多年来一直在推动联邦制定相关标准,允许此类无人驾驶汽车在美国公路上行驶。 美国政府表示,愿意接受无人驾驶汽车的联邦规定,而马斯克则通过特斯拉的财报电话会议呼吁为自动驾驶汽车制定统一的联邦框架。 本月早些时候,马斯克对拜访特斯拉的运输部长肖恩・达菲表示:“如果美国能够制定全国性的无人驾驶法规,而不是让每个州都制定各自的独立规则,那将是非常棒的。”
马斯克最新演讲:每年造 1000 艘飞船,让人类成为多星球物种
让人类成为 多星球物种 远离政坛,专注科技,这是马斯克最近的口号。 由于 X/xAI 和特斯拉正处于关键技术发布期,日前他在社交媒体上宣布将一切精力投向这些旗下科技企业,甚至不惜在工厂打地铺,让人梦回那个全力以赴、拼劲十足的「007 状态」。 然而,这一切并没有给他带来好消息。 即便现场督战,他也难以逆转星舰「三连跪」魔咒,不过,就在刚刚,SpaceX 还是发布了由马斯克主持的主题演讲:Making Life Multiplanetary(让人类成为多星球物种)。 没有比第一次星舰爆炸更糟糕的时刻了,而马斯克的火星梦想还在继续。正如他所说的那样: 你希望每天早上醒来时,能觉得未来会变得更美好——这正是成为一个太空文明的意义所在。这意味着对未来充满信心,相信明天会比昨天更好。而我想不出还有什么事情,比走向太空、置身群星之间,更让人激动人心了。 部分要点总结如下: SpaceX 正在扩建生产能力,目标是每年生产 1000 艘星舰。 即使地球供应中断,SpaceX 计划使火星具备自我发展的能力,实现「文明韧性」,并可能在地球出现问题时反过来救援地球。 SpaceX 下一步的关键技术是「接住」星舰本体,计划在今年晚些时候演示这一技术,预计两三个月内进行测试。星舰将被放置在助推器顶部,重新加注推进剂并再次起飞。 星舰、猛禽3号和助推器的第 3 代版本将具备快速重复使用、可靠运行和轨道推进剂补给等关键能力,预计在星舰 3.0 版本上实现。计划在年底首次发射。 即将发射的火箭版本足以支持人类实现多星球生存目标,未来将继续提升效率、增强能力,降低每吨成本,并减少前往火星的费用。 火星的发射窗口每 26 个月开启一次,下一次将在明年年底(约 18 个月后)。 在未来的火星窗口期,SpaceX 计划送人类前往火星。前提是之前的无人任务成功着陆。如果一切顺利,下一次发射将实现载人登火星,并开始基础设施建设。 为了确保任务成功,SpaceX 可能会进行一次 Optimus 机器人着陆任务,作为第三次发射的测试,确保载人任务的顺利进行。 附上原视频地址: https://x.com/SpaceX/status/1928185351933239641 让人类成为多星球物种 好,让我们开始今天的演讲。前往火星的大门已经开启,我们现在来到了新成立的「星舰基地」(Star Base)德克萨斯。 这应该是美国几十年来第一次新建一座城市,至少我是这么听说的。名字也很酷,之所以叫这个名字,是因为我们将在这里研发出让人类、文明和我们所知的生命首次走向另一个星球所需的技术——在地球 45 亿年的历史上前所未有。 让我们看看这个小视频。一开始,这里基本上什么都没有。最初,这里只是一块沙洲。什么都没有?就连那几个我们搭建的小设施,当然也是后来建起来的。 那是最初的「Mad Max」火箭。也是在那时我们意识到,给这「Mad Max」火箭打灯光真的很重要。 是的,几年前这里还基本上一片荒芜。而在短短五六年的时间里,靠着 SpaceX 团队的卓越努力,我们建起了一座小城市,建起了一个巨型发射平台,还有一个用于制造巨型火箭的巨大工厂。 更棒的是,任何看到这个视频的人,其实都可以亲自来参观。我们的整个生产设施和发射场都设在一条公共公路旁。也就是说,任何来到德州南部的人都可以非常近距离地看到火箭、参观工厂。 所以,只要你对地球上最大的飞行器感兴趣,随时都可以来,只要沿着那条公路开过去就行了,真的很酷。然后我们一路走到了现在——星舰基地,2025 年。 现在我们已经达到了大约每两到三周就能制造一艘飞船的水平。当然,我们并不是每两三周都固定生产一艘,因为我们还在不断进行设计升级。但我们的最终目标是每年能够生产 1000 艘飞船,也就是每天三艘。 这就是目前的进展。我现在正站在那个大楼里。那是我们的气垫船。我们正在把一个助推器运送到发射场,你可以看到那些超大组装厂房(mega bays)。 就像我之前说的,对于正在看这个视频的朋友来说,最酷的一点是你真的可以直接来到这里,开车沿着这条路就能亲眼看到这一切,这是历史上第一次有这种机会。左边那条路,那是条公路,是对公众开放的。你可以随时来看看,我非常推荐来一趟,我觉得这真的非常鼓舞人心。 我们正在扩建整合能力,以达到每年生产 1000 艘星舰的目标。虽然现在还没建好,但我们正在建。这是一座真正意义上的超级工程,从某些标准来看,可能会成为世界上最大的建筑之一。它的设计目标就是每年生产 1000 艘星舰。我们也在佛罗里达建设另一座厂房,这样我们在德州和佛州就会有两个生产基地。 这些建筑到底有多大,其实很难凭肉眼判断。你需要在旁边放一个人来对比,看到人站在建筑旁边有多渺小,你才能真正意识到它的巨大规模。 如果我们用「每年生产的运载工具」来对比,比如波音和空客制造的飞机数量,未来某个时间点,星舰的年产量可能会和波音、空客的商用飞机持平。这个项目的规模真的非常庞大。 而且每艘星舰的运载能力都远超波音 747 或空客 A380,真的可以说是「巨无霸」。 接下来是关于星链卫星(Starlink)方面的内容,第三代卫星的年产量大约在 5000 颗左右,将来可能会接近 10000 颗。每颗第三代卫星的体积大致相当于一架波音 737,非常大。拿来跟二战时期的 B-24 轰炸机做对比也不为过。 当然,这个规模跟特斯拉比起来还算小。未来特斯拉的年产量可能会是这个的两倍甚至三倍。 这些对比有助于我们建立一个概念:其实制造大量用于星际旅行的星舰是可行的。即使从总吨位的角度来看,像特斯拉和其他汽车公司依然在制造比 SpaceX 更复杂、产量更高的产品。 也就是说,这些看似夸张的数字,其实是人类完全有能力实现的,因为其他行业已经做到了类似的规模。 我们的进展,用一个标准来衡量,就是实现一个在火星上能够自我维持的文明所需要的时间。而星舰的每一次发射,尤其是在早期阶段,都是在不断学习和探索,为让人类成为多星球物种打基础,让星舰不断完善,最终能够将成千上万、甚至上百万的人送往火星。 理想状态下,任何想去火星的人都可以实现这个梦想,而且我们还能运送所有让火星实现自给自足所需的设备,让那里的社会可以独立发展。 即使在最坏的情况下,我们也要达到这样一个关键的转折点:即使地球的供应中断,火星仍然可以继续发展。那时我们就实现了「文明韧性」——甚至在地球出现严重问题时,火星还可能反过来救援地球。 当然,也可能是地球援助火星。但最重要的是,两个都能独立维持运转、都强大的星球共存,将对人类文明的长期生存至关重要。 我认为,任何一个文明如果是多星球的,它的寿命可能会延长十倍,甚至远超这个数字。而单一星球的文明,始终面临着一些不可预知的威胁,比如人类自毁性的冲突——比如第三次世界大战(虽然我们希望永远不会发生),又比如像小行星撞击、超级火山爆发这样的自然灾害。 如果我们只有一个星球,那一旦出现灾难,文明可能就此终结;但如果我们有两个星球,我们就能延续下去,甚至进一步扩展到火星以外的地方,比如小行星带、木星的卫星,甚至更遥远的地方,最终进入其他恒星系统。 我们可以真正走向群星之间,让「科幻」不再只是幻想。 为了实现这个目标,我们必须打造「快速可重复使用」的火箭,让每次飞行的成本、每吨送往火星的成本尽可能低。这就要求火箭必须具备快速复用的能力。 其实我们内部经常开玩笑,说这就像「快速、可复用、可靠的火箭」,三个「R」,简直像海盗的叫声「RRRR」,关键就是这三个「R」。 现在 SpaceX 团队在捕捉巨型火箭方面已经取得了惊人的进展。 想想看,我们的团队已经多次成功「空中接住」人类制造过的最大飞行器,用的是一种非常新颖的方式——用巨大的「筷子」从空中接住它。这真的是令人难以置信的技术突破。 我想问一句,你以前见过这样的场面吗? 再次祝贺大家,这真的是一个了不起的成就。我们之所以要用这种前所未有的方式来「接住」火箭,是因为这对实现火箭的快速复用至关重要。 超级重型助推器(Super Heavy Booster)体积庞大,直径大约 30 英尺(约 9 米)。如果它带着着陆腿降落在平台上, 我们就还需要再把它吊起来、收起着陆腿,再重新放回发射架,这样的操作相当复杂。而如果我们能用同一座塔,也就是最初安装它到发射架上的那座塔,来直接把它从空中接住并再次放回原位,那就是实现快速复用的最佳方案。 也就是说,火箭是被最初把它放进发射架的同一对机械臂接住,然后马上放回发射位置。 理论上,超级重型助推器可以在着陆后一个小时内重新发射。 飞行过程本身只需要 5 到 6 分钟,然后它被塔臂接住,放回发射架。大约再花 30 到 40 分钟补充推进剂,再把飞船放回顶部——原则上,这样我们就可以做到每小时发射一次,最多每两小时发射一次。 这就是火箭复用的极限状态。 接下来我们要做的一件大事,就是「接住」星舰本体(Ship)。我们现在还没有做到这一点,但我们一定会实现。 我们希望在今年晚些时候演示这个技术,可能最快两三个月内就能进行测试。之后,星舰将被放置在助推器顶部,重新加注推进剂,再次起飞。 不过,星舰的再飞行时间会比助推器略长一些,因为它需要绕地球飞行几圈,直到飞行轨迹回到发射场上空。尽管如此,星舰也计划实现每天多次重复飞行。 这是新一代的「猛禽 3 号」发动机,性能非常出色。我们要为猛禽团队点赞,这真的让人非常振奋。 猛禽 3 号的设计理念是不需要传统意义上的隔热罩(heat shield),这大大节省了发动机底部的重量,同时还提高了可靠性。例如,如果猛禽发动机出现少量燃料泄漏,燃料会直接泄漏到本就炽热的等离子体中,基本不会造成问题。而如果发动机被封闭在一个结构箱里,这种泄漏就会非常危险。 所以这是猛禽 3 号。我们可能还需要反复测试几次,但这款发动机在有效载荷能力、燃效和可靠性方面都有巨大的飞跃。可以说,它是一款具有革命性的火箭发动机。 我甚至会说,猛禽 3 号几乎像是「外星科技」的产物。 实际上,当我们第一次把猛禽 3 号的图片展示给业内专家时,他们说这台发动机还没组装完。然后我们就告诉他们:这就是「没组装完」的发动机,已经实现了前所未有的效率水平,并且正在运行。 而且,它的运行状态极其干净、稳定。 为了造出这样的发动机,我们对设计做了大量简化。比如,我们把次级流体回路、电路等都直接整合进了发动机结构里。所有关键系统都被很好地封装和保护了。坦率来说,这已经是工程设计的典范。 另一个对实现火星任务至关重要的技术就是——轨道推进剂补给。你可以把它理解为类似「空中加油」,只不过这次是「轨道加油」,对象是火箭。这种技术历史上从未实现过,但从技术角度是可行的。 虽然这个过程看起来总让人觉得有点「儿童不宜」,但总之,推进剂必须得传输嘛,没办法,必须完成这一步。 具体来说,是两艘星舰在轨道上对接,一艘星舰将推进剂(燃料和氧气)传输给另一艘星舰。实际上,大部分质量是氧气,氧气占了将近 80%,燃料只占 20% 左右。 所以,我们的策略是:先发射一艘装满货物的星舰进入轨道,然后再发射几艘「加油专用」的星舰,通过轨道补给把推进剂灌满。一旦推进剂补满,那艘星舰就可以启程飞往火星、月球,或者其他目的地。 这个技术非常关键,我们希望能在明年完成首次演示。 接下来要解决的最难问题之一就是「可重复使用的隔热罩」。 目前还没有人真正研发出能够多次使用的轨道隔热罩。这是一个极其困难的技术挑战。就连航天飞机的隔热罩,在每次飞行之后都需要几个月的维修——要修复破损的隔热瓦,还得逐块检测。 这是因为再入大气层时的高温和高压极其严酷,能承受这种极端环境的材料非常少,主要是一些先进陶瓷,比如玻璃、氧化铝,或者某些类型的碳材料。 但大多数材料在多次使用时要么会被腐蚀、要么会碎裂、剥落,很难经受住再入过程中的巨大压力。 这将是人类第一次真正开发出一个「可重复使用的轨道级隔热系统」。这个系统必须极其可靠。我们预计未来几年都将持续对它进行打磨和优化。 不过,这项技术是可以实现的。我们并不是在追求一个不可能完成的任务,它在物理学范围内是可行的——只是实现起来非常非常难而已。 至于火星的大气,虽然它主要由二氧化碳构成,乍一看好像比地球更「温和」,但实际上情况更糟。 当二氧化碳在再入过程中变成等离子体后,会分解成碳和氧气——这样一来,火星大气中游离氧的含量就会比地球还高。地球大气中氧气只有大约 20%,而火星在等离子分解后,氧含量可能是地球的两倍甚至三倍。 而这些自由氧会猛烈地氧化隔热罩,几乎是要把它「烧掉」。所以我们必须在二氧化碳环境中进行非常严格的测试,确保它不仅在地球上有效,在火星上同样可靠。 我们希望地球和火星使用同一套隔热罩系统和材料。因为隔热罩涉及很多技术细节,比如确保隔热瓦不会裂开、不会掉落等等。如果在地球上使用相同材料进行上百次测试,等真正要飞往火星时,我们就可以有充分的信心它能正常工作。 此外,我们正在研发下一代星舰,相较当前版本,它有很多改进。 比如,新一代星舰更高,船体和助推器之间的「中段结构」(interstage)也设计得更合理。你可以看到新的支撑结构(struts),这让「热级间分离」(hot staging)过程更加顺利。 所谓热级间分离,就是在助推器还在燃烧时,星舰的引擎就提前点火。这样,来自星舰发动机的火焰可以通过这些开放的支撑结构更顺畅地排出,不会干扰助推器。 而且这一次,我们不会像之前那样把这些结构扔掉,而是让它们随星舰一起飞行,做到可回收利用。 这一版本的星舰高度稍微增加了一点,从原来的 69 米提升到了 72 米。推进剂的容量,我们预计将略有提升,长期来看可能会达到 3700 吨。我的猜测是最终会接近 4000 吨的级别。 推力方面,也就是「推重比」部分,我们可能会达到 8000 吨推力,甚至最终上探至 8003 吨——这是在不断优化提升的过程中。我的估计是,最终我们会实现 4000 吨推进剂、接近 10000 吨推力的配置。 这就是下一代,也就是新版的「超级重型助推器」(Super Heavy)的形态。 助推器底部看起来可能会有些「光秃秃」的,因为「猛禽 3 号」发动机不需要隔热罩,所以看上去像是少了点什么,但其实那只是因为这些发动机不需要原来用于保护的结构。 猛禽 3 号直接暴露在炽热的等离子体中,但它本身设计得非常轻巧,不需要额外隔热。 这套系统也整合了热级间分离结构(Hot Stage Integration),我觉得它看起来非常酷。新版本的星舰船体也略长了一些,能力更强,推进剂容量提升至 1550 吨。长期来看,可能会比这个再多 20% 左右。 隔热罩的设计也更加流畅,从隔热层边缘过渡到「背风面」(leeward side)非常平滑,不再是那种参差不齐的隔热瓦。我觉得它外观上也非常简洁、优雅。 目前这个版本依然搭载 6 台发动机,但未来版本会升级到 9 台。 得益于猛禽 3 号的改进,我们实现了更低的发动机质量、更高的比冲(specific impulse),也就是效率更高。星舰第 3 版本(Starship Version 3)是一个重大飞跃。我认为它实现了我们所有核心目标: 通常,一个新技术要真正成熟、好用,需要经过三代的迭代。猛禽 3 号、星舰和助推器的第 3 代版本,将具备我们所需的所有关键能力:快速重复使用、可靠运行、轨道推进剂补给。 这些都是让人类成为多星球物种的必要条件,而这一切将在星舰 3.0 版本上实现。我们计划在今年底首次发射它。 你可以看到,在左边是目前的状态,中间是我们今年底的目标版本,而右边则是未来长期发展方向。最终高度会达到 142 米左右。 但即使是中间这个年底将发射的版本,已经完全具备执行火星任务的能力。之后的版本将会是性能上的进一步增强。就像我们过去对猎鹰 9 号所做的一样,我们会不断加长火箭,提升其运载能力。这就是我们的发展路线,简单明了。 但我要强调的是,即将于年底发射的这版火箭,已经足以支持人类实现多星球生存的目标。接下来要做的,就是继续提升效率、增强能力、降低每吨成本,以及让每位前往火星的人的花费更低。 正如我之前说的——我们的目标是,让任何想移居火星、想参与建设新文明的人都能做到这一点。 想想看,这得有多酷? 就算你自己不想去,也许你有儿子、女儿、或朋友愿意去。我认为,这将是人类能参与的最伟大的冒险之一——去另一个星球,亲手建设一个新的文明。 是的,最终我们的星舰将装备 42 台发动机 ——这几乎是命中注定的,就像伟大的先知 Douglas Adams 在他的书《银河系漫游指南》中预言的那样:生命的终极答案是 42。 所以,星舰最终也将拥有 42 台发动机,这就是宇宙的安排(笑)。 再来说说运载能力,最令人惊叹的是,在完全可重复使用的情况下,星舰将具备 200 吨的近地轨道运力。这是什么概念?这相当于是土星五号登月火箭运力的两倍。而土星五号是一次性使用的火箭,而星舰则是完全可重复使用的。 如果星舰也是一次性使用的话,它的近地轨道运力甚至可以达到 400 吨。 所以我要说的是:这是一枚非常庞大的火箭。但想要实现「人类多星球生存」,我们就必须拥有这样的大火箭。而在实现火星移民的过程中,我们还可以做很多很酷的事情,比如在月球建立一个基地——月球基地阿尔法。 很久以前有一部叫《月球基地阿尔法》的电视剧,虽然剧里关于物理的一些设定不太靠谱,比如月球基地好像还能漂离地球轨道(笑),但总之,在月球建立基地应该是继阿波罗登月计划之后的下一步。 想象一下,如果我们能在月球上建立一个巨型科学站,开展有关宇宙本质的研究,那将是一件非常酷的事。 那么,什么时候可以前往火星呢? 火星发射窗口每两年开启一次,具体来说是每 26个月。下一次的火星窗口是在明年年底,也就是大约 18 个月之后,时间点大概在 11 月或 12 月。 我们会努力抓住这个机会。如果运气好,我觉得我们现在大概有五五开的可能性实现目标。 实现火星任务的关键在于是否能及时完成轨道推进剂补给技术。如果能在窗口期之前完成这一技术,我们就会在明年年底发射首艘无人星舰前往火星。 接下来你会看到一个演示图,说明从地球(蓝色)到火星(红色)飞行的过程是如何实现的。 实际上,从地球飞往火星的飞行轨迹所经过的距离,差不多是到月球距离的上千倍。 你不能直接「直线飞」去火星,必须按照一种椭圆轨道进行转移——地球位于这个椭圆的一个焦点上,火星则在轨道的另一端。你还得精确计算飞船在轨道上的位置和时间点,确保能够与火星轨道相交。 这就是所谓的地火轨道转移(Hohmann Transfer),它是从地球前往火星的标准方式。 如果你有 Starlink 星链的 Wi-Fi 路由器,可以看看上面的标志图案,它就是这个轨道转移的图示。星链所提供的卫星互联网服务,正是帮助资助人类前往火星的项目之一。 所以我想特别感谢所有使用 Starlink 的人——你们正在帮助确保人类文明的未来,正在帮助人类成为多星球文明的一部分,正在帮助人类走向「宇宙航行时代」。谢谢你们。 这是一份初步的计划蓝图:我们希望随着每一次火星发射窗口的开启(也就是大约每两年一次),显著提高飞往火星的飞行频率和飞船数量。 最终,我们的目标是每次火星窗口发射 1000 到 2000 艘星舰前往火星。当然,这只是一个数量级上的估算,但根据我的判断,要想在火星上建立一个能够自给自足的文明,大约需要把 100 万吨的物资送上火星表面。 只有当火星具备了这样的基础能力,才算真正达到了「文明安全点」——也就是说,即使地球无法继续发运补给,火星文明也可以独立存续与发展。 为此,你不能缺少任何东西,哪怕是类似维生素 C 这种微小但关键的元素,都不能没有。火星必须拥有一切它所需要的东西,才能实现真正的增长。 我猜测大约需要 100 万吨,也可能是 1000 万吨,希望不会是一亿吨,那就太多了。但无论如何,我们会尽一切努力尽快达到这个目标,为人类文明的未来提供保障。 我们目前正在评估多个火星基地的候选地点,Arcadia 地区是目前的首选之一。火星上的「土地」资源很多,但综合考虑各种因素之后,选择范围会变得很小: 比如不能太靠近极地(环境过于极端),需要靠近冰层以获取水源,同时地形不能太崎岖,以便火箭安全降落。 综合这些因素后,Arcadia 是较为理想的地点之一。顺便说一句,我女儿的名字也叫 Arcadia。 在最初阶段,我们将把第一批星舰送上火星,以收集关键性数据。这些飞船将携带 Optimus 人形机器人,它们会先行到达,对周边环境进行探索,并为人类到来做好前期准备工作。 如果我们真的能在明年年底发射星舰,并成功抵达火星,那将是一幅非常震撼的画面。按照轨道周期计算,那艘飞船将在 2027 年抵达火星。 想象一下,Optimus 人形机器人在火星表面行走的画面,那将是划时代的一刻。 然后,在两年后的下一个火星窗口,我们将尝试送人类前往火星。前提是前几次无人任务成功着陆。如果一切顺利,我们就会在下一次发射中让人类踏上火星,真正开始在火星建设基础设施。 当然,为了更稳妥一些,我们也可能会再进行一次 Optimus 机器人着陆任务,把第三次发射作为载人任务。具体还要看前两次的实际效果。 你还记得那张著名的照片吗?——帝国大厦上的工人们坐在钢梁上吃午饭。我们希望也能在火星上拍出类似那样经典的画面。在火星通信方面,我们将使用一个版本的 Starlink 星链系统来提供互联网服务。 即便是光速传输,地球到火星的延迟也很明显——最理想的情况是约 3.5 分钟,最糟糕的情况,当火星处在太阳的另一侧时,延迟会高达 22 分钟或更久。 所以,在火星与地球之间进行高速通信确实是个挑战,但星链有能力解决这个问题。 接下来,第一批人类将在火星上打下基础,建立长期驻扎的前哨。就像我之前说的,我们的目标是尽快让火星具备自我维持的能力。 这一张图是我们对火星上第一座城市的粗略设想。 我猜测,我们会把发射台建得离着陆区远一些,以防出现事故。在火星上,我们将极度依赖太阳能。而在火星的早期阶段,由于它尚未「地球化」,人类无法在火星表面自由行走,必须穿着「火星服」,住在类似玻璃穹顶的封闭结构里。 不过这一切是可以实现的。最终,我们有希望将火星改造成一个类地星球。 我们的长期目标是:每一次火星转移窗口(约每两年一次),都能向火星运输超过一百万吨的物资。达到这个级别时,我们才算是真正开始建设一个「严肃的火星文明」——每次窗口运送「百万吨」级别的物资,是我们的最终标准。 那时候,我们将需要大量的太空港。由于飞行不能随时进行,只能集中在发射窗口期,我们将会有上千艘、甚至上两千艘星舰集结在地球轨道,等待同时起飞。 想象一下——就像《太空堡垒卡拉狄加》一样,上千艘飞船集结在轨道上,同时启程飞向火星,那将是人类历史上最壮观的场面之一。 当然,到时候我们也需要大量的火星着陆台和发射台。如果有几千艘星舰飞来,你至少需要几百个着陆位,或者非常高效地在着陆后迅速清空着陆区。 这个问题我们以后会解决(笑)。总之,在火星上建立人类首座外星城市,这将是件令人难以置信的壮举。这不仅是一个全新世界,同时也是一次机会——火星居民可以重新思考人类文明的模式: 你想要什么样的政府形式? 你希望制定哪些新的规则? 在火星上,人类拥有重新编写文明结构的自由。 这是属于「火星人」的决定。 所以,好了——让我们一起去完成这件事吧。 谢谢大家!

版权所有 (C) 广州智会云科技发展有限公司 粤ICP备20006386号

免责声明:本网站部分内容由用户自行上传,如权利人发现存在误传其作品情形,请及时与本站联系。