1. 从“千亿”到“万亿”：我们正在面对怎样的算力鸿沟？

最近圈子里聊得最多的，除了各家模型又出了什么新版本，就是“万亿Token”这个词了。听起来很宏大，但落到我们这些搞AI基础设施（AI Infra）的工程师肩上，感觉就是一座山。简单来说，过去我们训练一个百亿、千亿参数的模型，处理千亿级别的Token数据，已经让机房里的GPU集群哀嚎遍野了。现在，风向直接指向了“单日处理万亿Token”，这已经不是简单的量变，而是对整个基础设施栈的质变挑战。

想想看，DeepSeek模型单日吞下8万亿Token的新闻，背后意味着什么？假设每个Token平均占用2个字节（这已经很保守了），8万亿Token的原始文本数据量就接近160TB。这还只是“吞下”，即流经系统的数据。实际的训练过程涉及前向传播、反向传播、梯度计算和优化器状态，显存和内存的占用会呈指数级放大。推理侧也一样，当一个大模型服务要应对千万级甚至亿级的日活用户时，每秒需要处理的Token数（Tokens Per Second, TPS）和每用户会话长度都在激增，对推理引擎的吞吐量和延迟提出了近乎变态的要求。

这个挑战是全方位的。它首先卡在 算力 上：我们需要更多、更高效的AI加速芯片。英伟达的GPU固然强大，但价格、供应和生态锁定的问题日益凸显。于是，像华为昇腾这样的国产AI芯片被寄予厚望。大家搜索“昇腾AI Core利用率”、“昇腾系列有哪些GPU”，本质上是在问：国产算力到底能不能接住这波需求？它的实际算力、显存带宽、互联能力以及最重要的——软件栈成熟度，能否支撑起万亿Token规模的模型训练和推理？

其次，挑战在于 效率 。有了算力硬件，如何把它的潜力榨干？这就是AI Infra软件层的核心任务了。 推理引擎 （如vLLM、TGI等）和 训练框架 的优化，直接决定了单位算力成本下能处理多少Token。模型并行、流水线并行、张量并行这些分布式策略，在千亿参数时尚可应付，到了万亿参数级别，通信开销可能成为新的瓶颈。内存优化技术如激活重计算、混合精度训练、零冗余优化器（ZeRO），其精细程度决定了你能跑起来的模型规模上限。

最后，挑战还在于 稳定性与易用性 。热搜里一堆“token exchange failed”、“token失效”、“403 forbidden”的错误，虽然有些是应用层认证问题，但也折射出大规模服务下，令牌管理、请求调度、故障恢复的复杂性。当你的系统每秒要验证、路由、处理海量的Token请求时，认证服务、网关、负载均衡器任何一个环节成为短板，都会导致整个服务雪崩。

所以，“国产AI Infra准备好了吗？”这个问题，不是在问某一个芯片或某一个软件，而是在问从底层硬件、驱动、编译器、运行时库，到上层框架、调度器、部署平台的一整个 技术栈生态 ，是否已经具备了迎接“万亿Token时代”的战斗力。接下来，我们就掰开揉碎，从硬件到软件，看看现状与突围之路。

2. 算力基石：国产AI芯片的“可用”与“好用”之辩

谈到AI Infra，算力是绕不开的起点。当前，英伟达凭借其CUDA生态，构筑了极高的壁垒。但万亿Token的需求和供应链风险，使得国产AI芯片成为必须关注的选项。华为昇腾是其中的主要代表，从热搜词“华为昇腾950d 4换1 对标英伟达哪块gpu”就能看出，大家最关心的是对标与性价比。

2.1 昇腾芯片的能力象限与真实定位

首先需要厘清一个概念：昇腾芯片是一个系列，包括用于训练的 昇腾910 和用于推理的 昇腾310 （以及后续迭代型号）。昇腾910的理论算力（FP16）很强，但其设计理念和CUDA有显著差异。它采用“达芬奇架构”（DaVinci Core），更侧重于计算密度和能效比。

“4换1”这类说法通常出现在一些极端优化的Benchmark场景中，并不具备普适性。在实际的复杂模型训练任务中，由于软件栈成熟度、算子覆盖度、社区生态和开发者习惯的差异，要达到对等性能，可能需要更多的调优工作，甚至在某些环节仍存在差距。对标哪块GPU？粗略来说，昇腾910的目标是瞄准A100这个级别的训练卡，而昇腾310系列则对标T4等推理卡。

关键在于“ AI Core利用率 ”。这是衡量芯片是否“好用”的核心指标之一。利用率低，意味着芯片大部分时间在“空转”或等待数据，再高的理论算力也是白搭。影响利用率的因素极其复杂：

1. 算子支持度 ：模型中的每一个操作（如LayerNorm的特定实现、注意力机制的各种变体）都需要有对应的高效硬件算子。如果某个算子没有经过深度优化，或者需要回退到低效的通用计算单元执行，就会成为性能瓶颈。
2. 内存带宽与层次 ：AI计算是内存密集型任务。昇腾芯片的HBM带宽、片上缓存大小、数据搬运机制，决定了能否持续“喂饱”计算单元。万亿Token场景下，数据吞吐量巨大，内存系统的设计至关重要。
3. 软件栈与编译优化 ：昇腾的CANN（Compute Architecture for Neural Networks）软件栈，承担了将框架（如PyTorch）代码编译映射到硬件上的任务。编译器的优化能力，如算子融合、内存分配、流水线调度，直接决定了最终生成的机器码效率。一个优秀的编译器能将利用率提升数十个百分点。

注意 ：评估国产芯片，绝不能只看纸面算力（TFLOPS）。必须结合 实际模型 （如LLaMA、ChatGLM、DeepSeek），在 真实数据集 和 完整训练/推理流水线 中，去评估其端到端的吞吐量、收敛速度和稳定性。这需要大量的工程适配与调优。

2.2 生态突围：从“能用”到“敢用”的必经之路

硬件是躯体，软件生态是灵魂。CUDA的强大在于其历经十余年构建的、从驱动到库再到应用层的完整生态。国产芯片要突围，必须在软件生态上投入巨资。

1. 框架兼容性 ：理想情况是用户无需修改模型代码，就能无缝从CUDA切换到昇腾。这主要通过框架适配层实现。例如，PyTorch通过 torch_npu 插件来支持昇腾。但兼容性不仅仅是API对齐，更包括数值精度的一致性、随机数生成的确定性、以及分布式通信接口（如NCCL的替代品HCCL）的稳定性和性能。
2. 模型库与工具链 ：开发者需要开箱即用的模型示例、预训练权重转换工具、性能分析工具（类似Nsight Systems/Compute）。华为的MindSpore框架与昇腾深度绑定，提供了另一条路径，但如何吸引更庞大的PyTorch社区用户，是关键挑战。
3. 部署与运维 ：推理场景下，芯片需要集成到标准的服务器中，并提供稳定的驱动、容器镜像、监控指标。热搜中出现的“香橙派 lpddr5 310p 昇腾”，反映出社区和硬件厂商也在尝试推出基于昇腾的嵌入式或边缘计算设备，这是生态多样化的体现。

实操心得 ：在早期尝试国产芯片时，建议从一个 中等规模、结构成熟 的模型（如BERT、GPT-2规模）开始，而不是直接上最新的千亿参数大模型。这样能更快地定位问题是出在硬件、驱动、框架适配还是模型本身。同时，必须建立完善的性能基准测试（Benchmark）流程，持续追踪关键指标（如Tokens/sec per GPU， 训练损失曲线），并与CUDA基线进行对比，用数据驱动决策。

3. 推理引擎：吞吐量与延迟的生死竞速

当模型训练完成，部署上线服务用户时，挑战就从“如何训得快”变成了“如何推得稳、推得省”。万亿Token时代，推理成本将占据AI应用总成本的绝大部分。一个高效的推理引擎，是降本增效的核心。

3.1 自回归解码的瓶颈与优化核心

大语言模型的推理，尤其是生成任务，本质上是 自回归（Autoregressive） 的过程：根据已有的Token，预测下一个Token，循环往复。这个过程有两个特点：1) 计算依赖性强 ，必须串行进行；2) 内存访问频繁 ，需要反复读取模型权重和键值（KV）缓存。

因此，推理引擎的优化围绕以下几个核心展开：

1. 持续批处理（Continuous Batching） ：传统静态批处理要求所有请求长度一致、同时开始和结束，这在交互式场景中效率极低。持续批处理允许动态地将新请求加入批次，并让已结束的请求退出，极大提高了GPU利用率。vLLM和TGI等引擎的核心优势就在于此。
2. PagedAttention与KV缓存管理 ：生成文本时，需要缓存之前所有Token的Key和Value向量（KV Cache），这会消耗大量显存。PagedAttention技术借鉴操作系统内存分页的思想，将KV缓存分成块（Block），允许非连续存储，从而高效处理不同长度的序列，减少显存碎片，这也是vLLM性能飞跃的关键。
3. 算子融合与内核优化 ：将多个小算子（如LayerNorm、激活函数、残差连接）融合成一个大的CUDA（或NPU）内核，能减少内核启动开销和全局内存访问，显著提升性能。这需要针对特定硬件进行深度调优。

3.2 国产推理引擎的机遇与挑战

面对xLLM（各类开源大语言模型）的推理需求，国产Infra的机遇在于：

• 深度硬件协同 ：像昇腾这样的国产芯片，其推理引擎（如MindSpore Lite、昇腾推理框架）可以针对自家硬件指令集和内存架构进行极致优化，理论上能挖掘出比通用框架（如ONNX Runtime + 昇腾）更高的性能。
• 定制化场景优化 ：针对国内高并发、长文本（如法律、文档分析）等特定场景，可以开发更具针对性的优化策略，例如对“百万token能用多久”这种长上下文场景的显存优化。

但挑战同样明显：

• 模型兼容性 ：如何快速、无损地支持PyTorch、Hugging Face格式的各类主流模型（LLaMA, Qwen, DeepSeek, GLM等），是一个巨大的工程问题。需要强大的模型转换、图优化和量化工具链。
• 功能完整性 ：除了基础生成，还需要支持流式输出（Streaming）、工具调用（Function Calling）、对数概率输出、停止词等高级特性。这些功能在vLLM等引擎中已经比较完善。
• 生态与社区 ：开发者是否愿意使用？是否有丰富的文档、案例和活跃的社区来解决问题？这是决定一个引擎能否流行的关键。

避坑指南 ：在选择或自研推理引擎时，不要只看峰值吞吐量（Throughput）数据。必须测试 尾部延迟（P99 Latency） ，即在高压下，响应最慢的那1%请求的耗时。这对用户体验至关重要。同时，要测试在 混合负载 （有短有长的请求）下的表现。可以自己搭建一个测试平台，模拟真实请求分布，收集吞吐、延迟、显存占用、成本（Token/元）等全方位指标。

4. 软件栈纵深：从框架到调度的系统级博弈

芯片和引擎是锋利的武器，但要让它们在一个大规模数据中心里协同工作，需要一整套复杂的软件栈来指挥调度。这包括了深度学习框架、分布式训练库、资源调度器、容器编排平台等。

4.1 训练框架的分布式之痛

训练万亿参数模型，必须进行分布式训练。主流方案有：

• 数据并行 ：每张卡都有完整的模型副本，处理不同批次的数据。简单，但要求单卡能放下整个模型，对于超大模型不适用。
• 模型并行 ：将模型的不同层拆分到不同的卡上。通信开销大，编程复杂。
• 流水线并行 ：将模型按层分成多个阶段（Stage），像工厂流水线一样处理数据。需要精细的微批次（Micro-batch）调度来避免气泡（Bubble）。
• 张量并行 ：将单个层内的矩阵运算（如注意力头、FFN层）拆分到多卡上。通信密集，但对带宽要求极高。

在实际中，通常是 3D并行 （数据+流水线+张量）的组合。PyTorch的 Fully Sharded Data Parallel (FSDP) 和微软的 DeepSpeed （及其ZeRO系列优化）是当前主流的分布式训练解决方案。它们通过优化器状态、梯度、参数的划分，来减少单卡显存占用。

国产Infra在这里的挑战是 ：这些先进的分布式策略，能否在非CUDA生态上高效运行？例如，DeepSpeed与昇腾的集成度如何？华为的MindSpore也提供了自动并行等能力，但其API和编程范式与PyTorch社区不完全一致，存在一定的学习和迁移成本。核心在于，这套复杂的分布式系统，其 通信库 （替代NCCL的HCCL等）的 延迟 和 带宽 ，以及 故障恢复 机制，能否支撑起长达数周甚至数月的万亿Token训练任务而不中断。

4.2 调度与运维：稳定性的最后一道防线

假设硬件和框架都跑通了，在一个拥有成千上万张AI加速卡的数据中心里，如何高效、公平、稳定地调度成千上万个训练和推理任务？

1. 资源调度器 ：如Kubernetes结合Volcano、Kueue等批调度插件，或者像Slurm这样的HPC调度器。它们需要理解AI作业的特性：需要多少卡、需要什么样的拓扑（NVLink/NVSwitch组网）、是弹性任务还是刚性任务。国产Infra需要确保自己的硬件（如昇腾集群）能被主流调度器良好识别和管理。
2. 多租户与配额管理 ：如何防止单个用户的巨型任务饿死其他小任务？如何设置公平共享、优先级抢占、预算限制？
3. 可观测性与故障诊断 ：当作业失败或性能不达标时，如何快速定位问题？是硬件故障、网络拥塞、存储IO瓶颈，还是软件bug？需要建立从芯片温度、功耗、利用率，到框架指标、作业日志的全链路监控和告警体系。
4. 持续训练与推理平台 ：提供一站式的模型开发、训练、评估、部署、监控流水线（MLOps）。这对于降低AI应用门槛、提升团队协作效率至关重要。

经验之谈 ：在大规模集群中，“稳定性压倒一切”。一次全局性的网络故障或存储抖动，可能导致数百张卡上运行了数天的训练任务全部失败，损失巨大。因此，Infra团队必须投入大量精力在 冗余设计 （如多路径网络）、 故障隔离 和 快速恢复 上。例如，实现训练作业的 断点续训（Checkpointing） 自动化，并确保Checkpoint能跨不同硬件（如从A100集群恢复到昇腾集群，虽然困难）或至少跨不同节点快速加载。

5. 安全、成本与可持续性：无法回避的工程现实

除了纯粹的技术性能，在“万亿Token”的尺度上，一些工程现实问题会被急剧放大。

5.1 认证、令牌与安全链

热搜中大量出现的“token”相关错误，虽然多数指OAuth 2.0、JWT等应用层身份验证令牌，但在AI Infra层面，也有其映射。例如，在云上使用AI服务时，每个API调用都需要一个访问令牌（API Token）。当每秒有数百万次请求时，令牌的验证、刷新、吊销服务必须是一个高可用、低延迟的分布式系统。否则，就会出现“token exchange failed”、“token失效”等问题，导致服务不可用。

在模型服务内部，也可能存在一种“推理令牌”的概念，用于限流、计费和审计。如何安全、高效地管理这些令牌，防止泄露和滥用，是保障服务商业可持续性的基础。这涉及到密钥管理、令牌签名验证、请求限流、防重放攻击等一系列安全工程实践。

5.2 成本模型与优化

万亿Token的直接代价是惊人的电费和硬件折旧。因此，构建一个精确的 成本模型 至关重要。这个模型需要能计算：

• 训练成本 ：训练一个模型到收敛，总消耗的算力（GPU Hours）是多少？结合电费和硬件成本，每个Token的训练成本是多少？
• 推理成本 ：服务一个用户请求，平均消耗的算力（Token/sec per GPU）是多少？结合QPS和硬件利用率，每个Token的推理成本是多少？

有了成本模型，才能进行有效的优化：

• 模型压缩与量化 ：将FP16/BF16的模型量化为INT8甚至INT4，能大幅减少显存占用和计算量，提升推理速度，是降低成本最有效的手段之一。但需要评估精度损失。
• 自适应计算 ：根据查询的难易程度，动态调整模型的计算量（如早退机制Early Exiting、条件计算Conditional Computation）。
• 混合精度训练 ：在训练中合理使用BF16/FP16混合精度，在保证收敛性的前提下提升速度，节省显存。
• 硬件选型与混部 ：根据任务特性，选择性价比最高的硬件。例如，对延迟不敏感的批量推理任务，可以使用算力密度高但单卡性能稍弱的卡；对交互式任务，则必须使用高性能卡。

5.3 可持续发展与自主可控

“国产AI Infra准备好了吗？”这个问题背后，还有一层战略含义：自主可控。过度依赖单一供应商的硬件和软件生态，在极端情况下可能带来断供风险。发展国产AI Infra，不仅是商业竞争，也是技术安全的必然要求。

这条道路注定漫长且艰难。它需要芯片设计、半导体工艺、基础软件（编译器、驱动）、深度学习框架、算法研究、应用生态等多个领域的长期、高强度协同投入。目前，我们看到了像昇腾、海光、寒武纪等硬件厂商，以及MindSpore、PaddlePaddle等框架的努力，但整个生态的成熟度、开发者社区的活跃度、以及在国际主流学术和工业界的接受度，仍有很长的路要走。

最后的个人体会 ：作为一名一线工程师，我认为“准备好”不是一个“是”或“否”的二进制状态，而是一个持续演进的过程。当前，国产AI Infra在部分场景和特定模型上已经“可用”，甚至“好用”。但要全面、从容地迎接“万亿Token时代”，必须在 极致性能优化 、 全栈软件生态 和 大规模工程稳定性 这三个维度上同时发力。对于我们开发者而言，最务实的态度是：保持开放，积极尝试。在非核心或成本敏感的场景中，主动试用国产栈，积累实战经验，反馈问题，共同参与生态建设。同时，在核心生产系统中，采取“双轨制”或“混合云”策略，在保证业务连续性的前提下，逐步增加国产化比例。这条路不好走，但它是通向真正技术自主的必经之路。