8000P之后，酒仙桥算力园区先把利用率说清楚
北京酒仙桥的“算力星河基地”有两组值得放在一起看的数字。
世纪互联公开资料显示，该项目由世纪互联与北京电子数智科技有限责任公司联合打造，一期智能算力达到1000P。世纪互联介绍项目时，还提到2023年5月发布的《北京市促进通用人工智能创新发展的若干措施》。
到2025年6月19日，新华网相关报道则以“8000P算力与空间赋能”介绍这座AGI园区。
1000P与8000P未必矛盾。一个可能对应一期建设规模，另一个可能指向后续整体能力。不过，现有公开摘要没有解释8000P中有多少已经上线、多少可以直接分配给客户，也没有披露连续运营期内的平均利用率。
因此，“运营半年、平均算力利用率不足40%”目前不能作为公开事实使用。要判断园区有没有“高配低用”，还得先把统计口径摆到桌面上。
先把1000P和8000P放在同一张表里
P值能说明算力规模，却不能直接代表交付能力。园区的运营数据至少要拆成几层：机房里已经安装多少设备，实际在线多少，可供租户分配多少，最终完成了多少训练或推理任务。
设备在线率、资源分配率、加速卡占用率和模型算力利用率也不是一回事。训练任务可以观察模型算力利用率（MFU），RAG和在线推理则更依赖端到端吞吐、响应延迟与任务成功率。只公布一条平均利用率曲线，很难判断问题出在客户需求、设备故障，还是数据与软件链路。
同样是加速卡处于忙碌状态，它可能正在完成有效计算，也可能在等待数据、重跑失败任务或处理兼容性问题。反过来，占用率不高也不等于没有订单。模型微调、批量推理和在线问答的负载节奏差异很大，峰值与均值本来就会拉开。
算力星河基地目前公开的是建设规模。要讨论真实利用率，还需要运营方补充在线算力、可分配算力、任务排队时间和完成情况。
昇腾910C不能靠推测写进园区
现有可引用材料没有标明算力星河基地采用哪一种加速卡，也不足以证明园区大量部署了昇腾910C。芯片型号、集群规模、软件栈和支持的计算精度，都应以运营方披露或实测记录为准。
如果企业确实需要把业务从NVIDIA CUDA迁往昇腾/CANN，软件适配成本必须提前计算。算子支持、框架版本、模型导出、精度校验、推理服务和监控工具，都可能影响最终交付效果。
RAG迁移还会把问题分散到更多环节。离线阶段包括文档处理、分块、向量化和索引构建；在线阶段要完成检索、重排和生成。任何一个环节兼容性不足，都可能拉开硬件峰值与实际响应速度之间的距离。
这类差异需要基准测试来回答：使用同一模型、同一批数据和同一并发条件，记录吞吐、延迟、显存占用及任务失败情况。没有测试记录，就无法得出“延迟翻倍”或具体人力成本占比等结论。
RAG跑得慢，问题可能在卡外
RAG服务并不是把模型放上加速卡就结束了。文档要从存储系统读取，检索请求要访问向量数据库，重排和生成之间还涉及网络传输与CPU预处理。数据链路跟不上时，加速卡只能等待。
多租户调度同样容易损耗有效算力。不同模型的显存占用、上下文长度、批次大小和请求节奏并不相同。只按卡数平均切分资源，可能出现大任务排队、小任务占满碎片资源的情况。设备看似有空余，租户却找不到一组可以连续使用的资源。
这也是评估算力园区时容易被忽略的一点：计算、存储、网络和调度器必须一起看。单独提高加速卡规模，不会自动解决数据读取、显存分配和任务重启等问题。
比一条利用率曲线更有用的数据
如果园区要让8000P的交付能力变得可核验，一份运营报告至少应回答以下问题：
- 一期1000P与8000P口径是什么关系，已安装、已上线和可分配算力分别是多少；
- 集群采用哪些硬件和软件栈，异构资源如何分配；
- 利用率按设备占用、已售资源还是有效任务计算，统计时间窗口多长；
- 训练和推理任务的排队时间、完成情况与重试情况如何；
- 存储、网络与调度是否成为瓶颈，园区能提供哪些迁移和调优支持。
新华网相关材料提到，截至2024年底，全国已经形成超100个以人工智能为核心的园区。同一材料援引赛迪顾问预测，到2025年底，中国算力核心产业规模有望突破1.5万亿元。园区数量增加后，单看名义规模越来越难拉开差距，客户最终购买的是稳定可用的计算服务。
眼下能确认的信息很明确：算力星河基地位于北京酒仙桥，由世纪互联与北电数智联合打造；一期公开数字为1000P；2025年的报道使用了8000P口径。真实平均利用率仍待披露。
下一次运营更新如果能把在线规模、可分配资源、任务完成情况和迁移支持写清楚，会比再抛出一个更大的P值更有说服力。
资料来源
