企业官网建设流程全解析

最近跟做AI基础设施的朋友聊了很久，发现大家的关注点不知不觉都落到了同一个地方：AI芯片的推理规模商用。过去一年多，行业里所有人都在盯着训练——谁的集群大，谁把模型训得快，谁在各种榜单上刷了分。可模型发布潮过去之后，真正长期烧钱的地方变成了推理。每一次用户发消息、生成图片、跑Agent任务，背后都是实打实的算力开销。现在，几家在海外资本市场挂牌的科技巨头几乎不约而同地亮出了自研AI芯片的进展，目标也高度一致：把推理这张牌打好，占领规模商用的先机。

这里我不逐一点名，用“某GPU巨头”“某云计算厂商”之类的代号来说。因为这次聊的重点不是股票行情，而是底层技术路线和产品逻辑——到底为什么这些公司要自研芯片，推理场景和训练场景在架构上有什么本质区别，规模商用真正卡人的技术点在哪里，以及落到实操层面，我们自己选型、压测、部署推理服务时应该盯什么指标。下面按我的理解，把这轮AI芯片“下半场”拆开讲清楚。

1. AI芯片为什么突然进入“下半场”

1.1 训练和推理是两种完全不同的“体力活”

很多人以为训练芯片和推理芯片是同一件事，无非训练负载更大、推理负载更小。实际完全不是同一个逻辑。训练阶段是海量数据反复冲刷模型参数，计算密集、梯度通信密集，追求的是整体吞吐，哪怕一个批次跑几分钟都可以接受。推理阶段是面向在线用户的即时响应，用户发出一个请求，几百毫秒内要有结果，这对延迟极度敏感。

拿生活里的例子类比：训练像是建一座大型工厂，一次性大规模生产原材料，过程可以慢慢磨，追求的是单位时间里产出的总量。推理像零售门店，顾客随到随买，每个订单都要当场打包好，既不能让人等太久，也不能因为订单量大就把服务质量拖垮。所以训练拼的是峰值算力，推理拼的是单位成本、稳定性、延迟控制和规模化后依然能扛住波动的能力。

这也是为什么很多头部科技公司会把推理称为“AI芯片下半场”。训练市场的需求相对集中，主要在中高端GPU集群和超算中心；但推理市场分散在各行各业，云服务、端侧App、边缘设备、推荐系统、企业内部知识库，到处都是需求。谁能在推理阶段把单位成本打下来，谁就掌握了真正能长期变现的算力入口。

1.2 推理规模商用要迈过三道门槛

我在做技术选型和方案评估时，习惯把推理规模商用拆成三个核心问题，任何一家自研芯片如果在这三方面有短板，最终都难落地。

第一道门槛是成本。推理是持续性的开销，每个在线请求都会产生计算费用。模型服务商付给云厂商的每一分钱都来自推理算力消耗，成本不够低，商业模式就转不动。自研芯片最大的卖点往往就是：通过专用架构设计，把相同吞吐下的单位成本降到通用GPU的几分之一。但注意，“标称成本”不等于“真实成本”，还要算上研发摊销、软件适配、运维复杂度。

第二道门槛是稳定性。在线推理对长尾延迟极其敏感，P99（99分位延迟）哪怕偶尔抖动到秒级，用户体验就会明显劣化。训练任务跑挂了可以重新排队，推理服务挂了就是直接事故。芯片的散热、内存错误、互联拥塞、调度抖动都会放大成线上故障。

第三道门槛是软件生态。一块芯片纸面算力再高，如果主流深度学习框架和推理引擎适配不到位，开发者根本用不起来；勉强能跑，性能也要打折扣。过去几年很多自研AI芯片折戟，不是芯片本身不行，而是软件生态跟不上，硬件连编译器和运行时都没打磨好，最终只能在实验室里展示，无法规模化交付。

这三道门槛，就是这轮五家科技巨头“齐推自研”背后的真实动机。各家基因不同，切入路线也不同，但都希望在下半场占据一个结构化优势。

2. 五家科技巨头的自研路线：同一赛场，五种打法

2.1 为什么同一个时期，这么多巨头集体选择自研

有一个问题很多人会问：既然外部供应链也能买到AI加速卡，巨头为什么还要花大价钱自研？答案不是“省采购费”这么简单。

第一个原因是算力成本已经变成经营命脉。对于云计算厂商和互联网平台型公司来说，推理算力占据整体成本的比例逐年上升。外部采购一张AI加速卡动辄数万元，且路线图掌握在别人手里，性能迭代节奏、供应量、价格都不由自己控制。自研芯片虽然前期投入巨大，但一旦规模上去，每颗芯片的边际成本可以摊得很低，且可以根据自己的业务场景随意裁剪。

第二个原因是专用场景用通用芯片太浪费。推荐系统、视频理解、端侧语音、图像生成，这些场景的算子组合和访存模式各不相同。通用GPU为了兼顾所有场景，芯片面积里塞了大量不太用到的电路模块；专用芯片可以砍掉冗余单元，把晶体管集中到数学运算、缓存、互联上和自己的业务高度匹配。

第三个原因是软件生态的话语权。谁拥有芯片的指令集和编译栈，谁就能定义开发者的使用路径。巨头们自研芯片不完全是为了替代外部方案，更多是想建立从硬件到框架再到业务系统的垂直技术栈。这种垂直优化能力，在毛利率和业务响应速度上会形成长期差异。

2.2 五条差异化路线的横向对比

我把这五家巨头的策略整理成一张表，方便对照：

这张表只是粗看，背后的门道比表格复杂得多。比如云计算厂商做ASIC的难点在于业务规模大到某个临界点才划算，否则研发成本很难摊销；消费电子厂商做端侧NPU则要面对碎片化的App场景，芯片算力再强，最终还得看框架层能不能让开发者方便调用。

2.3 自研芯片的护城河，其实是软件栈

这是我最想强调的一点。很多硬件团队做芯片时只盯RTL代码、工艺节点和峰值算力，但对推理规模商用来说，芯片流片只是第一步。软件栈才是决定实际可用性的关键。

推理芯片的软件栈包括编译器、运行时、算子库、图优化器、集群调度器和与主流框架的适配层。开发者在框架里写一个模型，编译器要把它转换到芯片指令，自动完成算子融合、内存复用、并行切分。这个过程中的任何一步没优化好，最终性能都会差一大截。

我在帮一个团队评估自研推理加速卡时，就见过典型例子：芯片标称算力在官方benchmark上很漂亮，但换一个稍冷门的注意力变体算子，编译器无法高效生成代码，运行时只能fallback到通用CPU路径，端到端性能直接掉到原来的五分之一。所以评估自研芯片，不能只看“跑分”，还要拿自己真实的模型拓扑去测，看编译器到底能优化到什么程度。

3. 推理规模商用落地的关键技术细节

3.1 推理性能指标：别被峰值TOPS忽悠

很多芯片发布稿喜欢放“XX TOPS”的峰值算力，那是在理想条件下测出来的：矩阵全部对齐、数据全部在片上缓存、计算单元满负荷运转。但真实推理服务里，模型参数要从内存搬进缓存，权重和激活要反复读写，中间结果要暂存，访问瓶颈往往比计算瓶颈更严重。

我在实际压测中会盯四类指标：

• 吞吐：单位时间处理的请求数或生成的Token数，一般看每秒请求数（QPS）或每秒生成的Token数。
• 延迟：首Token延迟（用户看到第一个输出字的时间）和单Token生成速度，这两个指标对在线体验影响很大。
• 有效算力利用率：跑真实模型时算出的实际算力占芯片峰值算力的比例，很多时候只有30%~60%。
• 能效比：单位功耗换来的推理吞吐，直接决定数据中心电费账单。

一张表格列清楚：

3.2 量化与模型压缩：推理效率的第一杠杆

把大模型从FP16压缩到INT8甚至INT4，是推理成本优化的最直接手段。权重量化会直接影响模型体积和带宽占用，激活量化能减少中间结果的显存压力。但要小心，量化不是简单的“把数值变小”，而是要做校准集验证。

我在生产环境里遇到过量化后某一层误差放大，导致整体回答质量明显下降的情况。后来排查发现，当时只用了一组通用校准集，没有覆盖用户真实输入中偏长文本和特殊格式的分布。正确做法是准备三组数据：常规业务数据、长尾输入数据、边界输入数据，用它们跑一遍量化前后的模型输出对比，确定可接受的精度损失阈值。

更低比特的量化还会带来硬件支持差异。有的芯片原生支持INT4矩阵运算，有的需要通过反量化绕一圈，性能差距很大。选型时一定要确认：模型量化到目标精度后，芯片是否有对应的算子加速单位。

3.3 服务化层面的优化：连续批处理、PD分离与投机解码

单块芯片再强，服务化做不好，规模化就是空话。现在主流推理引擎都在做几个关键优化。

连续批处理：传统批处理要等一个批次所有请求都完成才释放资源，可能出现“先到的请求干等后到的请求”的情况。连续批处理让请求一经完成立即腾出位置，新请求随即补入，极大提升吞吐。这个机制对芯片的连续内存分配和调度能力有较高要求。

PD分离：大模型生成过程分为预填充（Prefill）和逐Token解码（Decode）两阶段。Prefill是计算密集型任务，Decode是访存密集型任务。把它们放在同一批硬件上混跑会互相干扰。分离部署后，Prefill节点专门处理长输入序列，Decode节点专门快速产出Token，两者通过内部高速通道衔接，能更精细地利用资源。

投机解码：用一个小模型先产出一串候选Token，再用大模型一次性验证，避免每个Token都走一次完整自回归流程。这需要小模型与大模型配合，增加一定的工程复杂度，但在长输出场景下收益明显。

这些优化，落到芯片上意味着硬件要支持灵活的内存管理、细粒度的任务抢占和高效的数据通道。自研芯片如果只做大矩阵乘法，不管内存调度，规模商用后会有很多隐形坑。

4. 实操过程：从选型到上线的参考路径

4.1 第一步：先画清楚推理负载画像

很多团队选推理芯片时，第一步就错了——先看芯片参数，而不是先看自己业务的实际负载。正确的顺序是反过来。

我通常会让业务方先回答这几个问题：

• 模型参数量是多少，预期上下文长度是多长？
• 单请求的输入Token量和输出Token量大概是什么分布？
• 高峰QPS是多少，P99延迟目标是多少？
• 请求是否集中在特定时间段，峰谷比例如何？
• 是否需要并发扩缩容，还是稳定长跑？

这些问题直接决定显存和带宽需求。举个例子，假设一个70亿参数的模型，FP16权重大约14GB，加上激活和KV缓存，单路推理需要预留25GB以上显存。如果业务要求同时支持2048 Token上下文、并发8路，显存就得200GB往上。这个数字如果没算清楚，后面买什么卡都别扭。

补充一个估算KV缓存的方法：一般情况下，KV缓存大小近似等于“层数×每层KV维度×2×字节数×序列长度”。具体配置不同数值会有差异，但一定不能只看模型参数体积，KV缓存在大长上下文场景下膨胀得非常快。

4.2 第二步：拿真实模型跑POC，而不是看官方跑分

确定几个候选方案后，我会要求厂商支持我们把自己的压测负载跑在上面。压测数据必须是生产环境采样的真实请求，不是固定长度的模拟数据。

压测时重点观察三个阶段：

• 单路稳定测试：看一个请求的长文本生成延迟，是否在预期范围内。
• 并发递增测试：从1路并发逐步增加到16路、32路，观察吞吐曲线和P99延迟拐点。很多芯片在并发一高时延迟迅速劣化，这说明内部调度或内存带宽撑不住。
• 长稳测试：至少跑48小时，看是否有内存泄漏、错误率上升、性能逐渐衰减的现象。

压测时一定要记录中间状态，比如显存峰值、算力利用率、是否存在重试。只拿最终跑分说事，大概率错过真正的问题。

4.3 第三步：容量规划与上线灰度

容量规划的关键是确定“单节点可用QPS”。用压测得到的单实例QPS数据，乘上节点数，再留出30%~40%余量应对突发流量。推理集群和训练集群不同，训练可以排队等资源，推理不能，必须预留余量。

上线建议采用灰度和双跑策略：新芯片的推理服务先是只接入5%流量，用Shadow流量模式同时把请求复制到旧系统做结果对比。观察准确率指标、延迟分布和成本变化之后，再逐步扩大比例。这一步我见过很多人跳过，结果新硬件模型输出质量有细微退化，线上用户反馈很久才暴露。

5. 常见问题与排查技巧实录

5.1 显存不够和KV缓存碎片化

现象：并发上去后频繁OOM，或者GPU显存占用率很高但吞吐上不去。

这是推理场景最经典的问题。大模型推理的显存消耗不只是模型权重，KV缓存会随并发和上下文长度动态增长。如果引擎不做合理的内存分块管理，碎片化会非常严重。

排查思路：先看显存分配的峰值和均值，区分是权重占了大头还是KV缓存占了大头。如果是KV缓存膨胀，就要限制单请求最大上下文长度，或者对KV缓存做低比特量化；如果是内存碎片化，优先改用支持分页式KV缓存管理的推理引擎，它能把不连续的内存块拼起来用，显存浪费显著减少。

5.2 P99延迟抖动和慢请求

现象：平均延迟很理想，但总有少量请求特别慢，长尾明显。

可能原因包括：冷启动模型首次加载、并发过高导致排队、CPU预处理线程成为瓶颈、芯片内部某个算子调度冲突。排查时要按阶段切分耗时：请求排队时间、模型预处理时间、GPU计算时间、Token生成时间。切分之后才能定位是哪一段在拖尾。

我见过一次诡异抖动，最后定位到是日志打印线程在高并发时抢了CPU核心，导致Token生成阶段频繁停等。把日志改成异步非阻塞之后，P99延迟直接降了40%。这种坑，在官方文档里根本查不到，只能靠现场分析和监控数据说话。

5.3 温度过热与功耗限制

现象：芯片没有跑满负载，但已经达到温度墙，频率被强制下调，吞吐下降。

推理芯片和训练芯片不同，很多时候处于长时间持续负载状态，发热更集中。机柜散热能力和供电冗余没有跟上，很容易触发热降频。排查时看芯片实时主频，如果发现主频在运行一段时间后明显降低，大概率就是散热或功耗墙问题。

解决方案：优化数据中心的散热布局，增加液冷或加强风道；在软件层面设置功耗上限，让芯片在较低频率下稳定运行，虽然单点性能略降，但整体吞吐反而更稳。对推理服务来说，稳定远比峰值更重要。

5.4 自研芯片的算子缺失和编译兼容性

现象：模型可以跑通，但推理速度远低于预期，甚至某些调用比CPU还慢。

这是自研芯片最现实的问题。通用模型里有很多开源的算子、融合模式，芯片编译器不一定都支持。遇到不支持的算子，运行时要么走通用降级路径，要么报错。排查时先打开编译器的日志，看有哪些算子未能高效映射，然后做替换或融合改造。

这里我的经验是：尽量把模型标准化，减少自定义算子和冷门结构。自研芯片在标准化模型上通常优化得比较好，越特殊的拓扑越容易踩到生态盲区。如果业务确实需要特殊算子，要提前跟芯片厂商的软件团队沟通，确认支持计划。

6. 影响范围分析与后续观察

6.1 对AI应用开发者的直接影响

推理成本下降的最终受益人，是上层应用开发者。当芯片厂商把单位Token成本降到足够低，API价格才有下降空间，应用层才敢尝试更大模型、更长上下文、更复杂的多步推理。反过来，更丰富的应用场景又会增加对推理算力的需求，形成正向循环。

对开发者的实际启示是：不要把自己绑定到单一硬件平台的私有编程接口上，尽量使用标准化格式和通用框架。这样未来在新芯片落地时，迁移成本相对可控。自研芯片再多，最终都要通过框架和标准对接到开发者手里，越通用的代码，越能吃到多个芯片竞争的溢出红利。

6.2 对云服务模式与算力价格的影响

五家巨头同时在推理端发力，会倒逼整个算力市场的定价体系重构。云厂商会越来越多地按“实际推理用量”计费，而不是按“机型加时间”计费；自研芯片的每一代迭代，都会直接反映在API价格下调上。这对于中小团队是个好消息，因为他们不需要自建硬件基础设施，就能用到大厂自研芯片优化后的算力红利。

但也要认识到，自研芯片的成本优势需要规模来兑现。小规模采购自研算力时，不一定比成熟通用GPU便宜；只有云服务层面规模化运营，优势才会显现。所以未来几年会看到明显的“算力批发”趋势：少数几家大型云厂商成为推理算力的主要输出方，中小规模玩家更多以应用层角色参与。

6.3 我后续会持续盯的几个信号

接下来的行业观察里，我会重点关注三件事。

第一，各家自研芯片的软件栈能否真正对开发者开放，而不是只能在自家云服务内部使用。开放程度决定生态规模。

第二，推理成本能否持续下降，同时保持模型输出质量。成本和质量是跷跷板，谁能在更低的比特数下稳住模型表现，谁的技术就更扎实。

第三，端侧推理和云端推理的边界如何演变。消费电子厂商的端侧NPU如果足够强，很多隐私敏感场景会从云端迁回本地；但大模型的复杂能力仍然依赖云端。最终的形态大概率是端云协同，而不是谁完全替代谁。

我个人在实际评估这类方案时，最深的体会是：芯片参数表上的数字再好看，都要回归到“真实负载下的P99延迟、单位Token成本、软件生态体验”这三个维度去检验。训练芯片拼的是纸面和规模，推理芯片拼的是细节和工程。谁能把成百上千个细小环节都磨平，谁才真正握有AI芯片下半场的主动权。