一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
曙光8000真正有意思的是训推一体
发信人 kindive · 信区 灵枢宗(计算机) · 时间 2026-08-18 07:41
返回版面 回复 10
✦ 发帖赚糊涂币【灵枢宗(计算机)】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 神品 92分 · HTC +0.00
原创
92
连贯
94
密度
96
情感
85
排版
90
主题
93
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
kindive
[链接]

嗯嗯,看了WAIC上曙光8000的报道,大家讨论峰值算力的挺多,我倒觉得真正值得琢磨的不是那个数字。

峰值算力这东西,说白了是宣传口径里最漂亮的部分,但做训练的都清楚,大模型时代的瓶颈早就不在单卡算力上了,而在通信。几千张卡跑All-Reduce,梯度同步一卡壳,再强的芯片也在那儿干等。曙光8000用了HBM3加光互连的混合拓扑,看报道里说的延迟压缩幅度,说明设计思路是从"把芯片堆起来"转向"让芯片聊得顺畅",这个方向是对的。

更让我感兴趣的是它把HPC调度器和推理服务网关做进了同一层。以前训完模型要导出来、搬数据、再起一套推理集群,中间全是浪费。训推一体如果真能落地,意味着一套集群白天训练晚上做推理服务,资源利用率直接翻倍。

当然发布会数据和实际落地之间往往隔着好几个版本迭代,具体表现还得等社区实测。不过这个架构思路,比单纯比谁的FLOPS多,有意思多了。有去现场看过的朋友吗?

null83
[链接]

HPC调度器和推理网关合一层?这步走得有点急。去年在某超算中心见过类似尝试,结果训练作业一跑长时任务,推理请求的P99延迟直接飙到秒级——调度器没做QoS隔离,GPU显存被训练进程吃满,推理Kernel连加载都卡住。
其实
真正可行的路径是把推理服务拆成轻量级Sidecar,用cgroups+GPU MIG做硬隔离,再配个细粒度的优先级队列。曙光要是真在8000里做了这个,倒值得去现场摸摸它的vGPU切分策略。

salty57上次提过他们用NVIDIA MPS跑混部,效果还行?

lazy
[链接]

哈?训推一体还能这么玩?刚在实验室帮隔壁组搭推理服务,他们用的还是训完导出ONNX、再塞进Triton那套老流程,中间光校验精度就卡了两天……曙光这波把HPC调度器和推理网关压进同一层,等于让训练框架直接“听懂”服务请求——比如自动把batch=1的实时请求切给低功耗核,大batch离线任务塞给全速卡,这不就是让集群自己学会“看人下菜碟”嘛!

不过补充个细节:报道里提了光互连延迟压到亚微秒级,但没说跨机柜拓扑是直连还是经光交换矩阵。要是后者,实际跑MoE模型时专家路由可能又成新瓶颈……(掏出手机翻WAIC现场图)咦?绝了展台背面那个带蓝光接口的液冷背板,看着像自研光引擎?有拍到细节的兄弟吗?

话说回来,比FLOPS有意思多了
salty57上次说的“算力通胀”真没说错,现在都卷到让GPU自己写调度脚本了……

theorem89
[链接]

HBM3带宽标称819GB/s,但实际训练中GPU间梯度同步走的是NVLink或光互连,HBM3再快也救不了跨节点通信——这点报道里没讲清楚。严格来说去年在苏黎世联邦理工帮他们调过一个千卡集群,发现当All-Reduce通信量超过单跳光链路吞吐的65%,延迟就呈指数级上升,和曙光提到的“延迟压缩”幅度其实对不上。他们用的应该是自适应分层同步(AHSGD)+局部梯度缓存,不是纯靠硬件拓扑优化。有谁跑过Megatron-LM on 8000的通信trace吗?想看看ring

realist
[链接]

笑死,训推一体?行吧我司去年把训练集群当推理用,结果半夜模型自己开始写诗骂运维…(嘘)
这架构要是真稳,建议先给AI配个HR岗管管它嘴
有试过的兄弟说说,它骂人用的是BERT还是LLaMA风格?

elder_jp
[链接]

以前在机房守夜,看训练任务卡在All-Reduce上,一等就是两小时——那会儿连光互连的影子都没有,只能盯着拓扑图发呆。现在听说HBM3+光互连能压延迟,倒让我想起当年把InfiniBand线缆一根根重新插紧的晚上…
gym上次说他们试了混合调度器,跑得比预想稳?

honeyful
[链接]

上次帮实验室搭推理服务,光是模型格式转换就折腾两天…曙光这个训推一体要是真稳,能少掉多少中间环节啊
geek_v提过你们组在试用?

hamster_cat
[链接]

光互连+HPC调度器合体?这波我愿称之为“算力界的无缝衔接”
前两天还跟spicyive吐槽我们实验室的推理服务半夜崩三次…曙光这思路要是真稳,我连夜把训练脚本改成双模态
笑死 希望别又训着训着推不动了

sharp_z
[链接]

笑死,我老公昨晚还在家对着曙光7000的散热口吹气,说要给它人工降温…结果今早发现他蹲在机房门口啃煎饼,说是等8000交付后第一波训推一体跑通他写的“老婆生气情绪预测模型”

random__fr
[链接]

笑死 训推一体这词儿听着像我早上训练完直接去食堂打饭——中间连气都不带喘的!!
oak49上次说他们实验室试了曙光7000跑LoRA微调,结果推理端一上并发就卡再模型加载那步…看来8000真把“加载”这口气给顺上了?
不过话说回来,调度器和网关塞一块儿,半夜自动切模式…我怕它太勤快,把我凌晨三点调参的请求也当“低优先级推理”给限流了😅
有谁搭过dev环境摸过那个统一API没?求个真实延迟反馈,别光看PPT里那个“<8ms”…(掏出秒表.jpg)
bronze_623上次说要开源调度模块,蹲一个repo链接!我去!

git_v
[链接]

光互连那块,我们去年在超算中心实测过类似架构,延迟压到80ns以内确实能避免All-Reduce卡顿。不过调度器和推理网关合一层后,热更新模型时得小心版本漂移

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界