楼主: 匿名
跳转到指定楼层
上一主题 下一主题
收起左侧

[改行] 做存储infra的想转AI Infra容易么

   
全局:
本帖最后由 转角遇见猫 于 2023-2-28 15:17 编辑
coffee521521 发表于 2023-2-28 08:32
不要想当然,建议去g, meta的model serving 组了解了解. 举个例子,core infra 也需要用Linux kernel, 出 ...

Google的model serving大多用TFX,是brain某个组做的,这个十来个人的组是不会为产品组oncall的。不过重要的产品model serving确实会有专门的组维护,方式和普通的backend service一样,离AI和ML已经很远了,组里的人估计连linear norm和batch norm都分不清了。-baidu 1point3acres

单机的model serving有自己的价值,现在在手机和智能汽车领域已经很重要了。比如,现在各种图生成模型的业界新闻都是x人把x模型优化到x秒出图。可以设想以后大模型的training会被大公司垄断,小公司拿着开源模型在各种硬件上做适配和优化,所以小规模的model serving会是主流,也会是AI行业就业岗位最多的领域。
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-ZZKL5  | 添加认证 | 2023-3-1 08:21:32
转角遇见猫 发表于 2023-2-28 02:00
其实有两种方式,一种是写算子kernel,对gpu而言需要对cuda非常熟悉;还有就是compiler codegen,生成比c ...

直接生成PTX确实有一定的门槛,但做这个的人是极少数,绝大多数都是生成CUDA然后交给nvcc,这个门槛并不高
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-5SUW4  | 添加认证 | 2023-3-1 12:24:49 来自APP
匿名用户 发表于 2023-02-25 20:09:15
chatgpt的infra的主要问题都是hpc范畴内的,和存储关系不大。
Chatgpt infra主要是hpc的什么问题呢?能否举个例子。谢谢
回复

使用道具 举报

全局:
嗯 同意比较有趣的是compiler,高层和中间层一般G,META 这种大厂做比较多,底层后端一些比如NV,AWS Annapurna 和G的TPU.
回复

使用道具 举报

全局:
分布式大模型最近比较火感觉很多东西可以搞,网络优化,serving调度等等
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-CSA0E  | 添加认证 | 2023-3-1 13:21:16 来自APP
匿名用户 发表于 2023-02-28 20:24:49
Chatgpt infra主要是hpc的什么问题呢?能否举个例子。谢谢
同问。估计是通信优化,一致性之类的?
回复

使用道具 举报

全局:
匿名用户 发表于 2023-02-28 16:21:32
直接生成PTX确实有一定的门槛,但做这个的人是极少数,绝大多数都是生成CUDA然后交给nvcc,这个门槛并不高
门槛不高但是baseline高。cutlass  aitemplate早就把该做的做好了,你如果不在nv或者meta的相关组,那么这块没你什么事儿。
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-CSA0E  | 添加认证 | 2023-3-1 13:26:54 来自APP
匿名用户 发表于 2023-02-28 00:54:14
能否举个例子为啥AI infra对high concurrency要求高?因为大量I/O么?
我觉得无论concurrency还是scalable,core infra不也有要求吗
我猜他想说的是ai infra对算力要求高,同样用户规模自然涉及更多的节点
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-CSA0E  | 添加认证 | 2023-3-1 13:29:22 来自APP
匿名用户 发表于 2023-02-26 19:50:48
您好 想问一下业界能做到类似anyscale这样的竞品多么 也就是想问 随着未来ai需求进一步增加 您觉得看好anyscale么
不了解anyscale,但是为什么不用k8s或者nomad搭配triton serving自己管?
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-V74OV  | 添加认证 | 2023-3-1 13:46:52
转角遇见猫 发表于 2023-2-27 09:55
ai infra和core infra一样分类挺细的,其中一部分和data engineering重合(所以很多big data可以号称ai fir ...

ai infra training不强调fault tolerance,基本不需要on call,即使training有问题,解决之后从上一个checkpoint开始就可以了。inference更强调latency和numerics,同样不需要on call。
> inference 的oncall很重很重,而且非常急,出问题的跟一般ML领域基本没啥关系。

core infra/storage/big data则与之不同,丢data是天大的事,所以才会有那么紧急的on call。还有很多security方面的问题,个人很不喜欢。.--
> 不是所有数据库都是oltp,olap的data loss不一定是大问题。甚至有些use case都不要求算的准确,能够更快的deliver一个approximate结果比很慢的算出一个准确的结果有时更有用。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号
职场达人
  • ↑ 本版用于讨论职场各种干货话题,闲聊请去🔗聊聊或者🔗匿名版
  • ❌ 本版严禁水贴,引战,发布广告,拉群,贴个人联系方式,扣分无警告
  • ☑ 求职、面经等去 🔗北美求职和 🔗回国求职大区,刷题和学习请去 🔗终身学习大区
  • ☑ 请去专版发布 🔗内推, 🔗招聘信息,和讨论 🔗创业内容
  • ☑ PIP / DevList/ Need Support 等话题也已开设 🔗专版

本版积分规则

>
快速回复 返回顶部 返回列表