本地 ai ？这也要战未来？

我就是丐版的 m1 max ，前年买的。我是前后端都要开发。现在感觉…emm…估计可以用到报废。现在 cpu 的算力根本不是事，严重溢出。日常 3 个 ide ，每个 ide 开 3-4 个项目。rust 、golang 、typescrypt 、再加一百来个网页从来懒得关…

另外文章底下有这么一句：

Karpenter 开源版本目前只能根据 Pod 的资源 request ，负责节点的选择、创建和删除，未对业务稳定性做深入设计

你犟什么呢？我一直在说 spot 会有稳定性影响。虽然不致命。但要起命来最少我是承担不起这个责任。

@cesign 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。sp 是每小时承诺不假啊，但他覆盖所有的机型和 fagrate 。你猜我是不是业务集群在白天，晚上业务集群是不忙了但大数据集群是不是可以干活了呢？

@cesign 继续和你掰扯，第一个，我自己碰到过突然机器没了没通知，或者一分钟内就会回收了。场景是大数据的 job 机。一天一分钟回收八百次得气死。。其实 k8s 的场景下 asg 已经解决了 spot 的优雅关机问题，他本来就是会自动平衡集群。收到事件后 asg 也会 callback 机器关闭调度。所有过程都非常优雅。唯独机器突然没了这种他自己都处理不了。其他场景 asg 足够了。所有间隔时间都可以调，你猜一个每天要赚钱的项目是相信云平台自己的还是一个不那么出名的开源项目？

第二个…按 pod request 啊。我猜你的意思是 hpa 的计算是按 pod request 计算的？不然自动伸缩自动伸缩，啥值会变呢？也只有 cpu 超过了我的阈值或者我需要按其他指标来扩容啊。没明白你说的按 pod request 咋扩容。不专业了。。我说的场景你没碰到过，没办法。野生运维。伸出来的时候所有 pod 刚启动都是 cpu100 。就一直加到最大值。等完事了发现太多了，又缩回去了。得，不够负载的，又加上起来。所谓集群再次重平衡是机器伸缩出来就涉及到 pod 会调度上来。也会有 node 的驱逐。这个过程又涉及到驱逐后的 pod 再次启动可能会挤到原先机器里面去。

k8 集群千奇百怪的…没有银弹

哦。你刚说的有问题…谁说白天 100u ，晚上 10u 我就要买 100u 了。我就不能买 10u ，然后补个 saves plan 么？我就这一个集群啊？运维是一个系统工程，那 90u 可以在其他的成本里面均摊。通常我是直接一个 savesplan 的。也没浪费多少。楼上有小伙伴说的对，优化成本是一个动态变化的，如果白天 90u 是必须的，晚上不需要 90u ，我为啥机器一定要开着呢？弹性伸缩嘛。还有其他的集群均摊成本，各种不同业务特征均摊成本。


跟你掰扯半天就是因为看过这个东西，如果用一个东西你节省了 60%成本。要么本来是 1000 节省到 400 每月。这也是节省 60%。要么就是之前浪费太多了，集群平均利用率水位压根不达标。我见过不少集群常年利用率水位在 10%上下的，还美其名曰留空间。这种就是你稍微关注一下就是一大笔钱省下来。工具只是提高管理效率，用一个工具就省钱就是本末倒置了。是因为省钱我需要用某个功能，正巧这个工具可以帮我做到这个功能而不用我自己开发。而不是因为这个工具可以省 60%成本，所以我要用这个工具……

哦，补充一句，你一直计算 spot 都是按最低计算的。这样的机器也是要看库存的。拿最低的 spot 申请的机器容易被回收。然后申请不到新的请问阁下如何应对…
一半拿 spot 做一定业务机，顶天了按 50%的折扣也就是 ri 的折扣水平去申请，而且要为没有机器做好准备的一些防御措施。因为…我就碰到过好几次 spot 不给我机器了，还是在高峰期。我当场脑子就炸了，后来一看哦，是开发测试环境，那没事了。

@cesign 第一个点：spot 最大问题是有可能不通知回收机器，最常见的是 60 秒前才通知。普通伸缩是可以优雅关机优雅降级。spot 就是看 aws 通知了，还是那个点，业务要能忍受和鲁棒。如果全靠通知自动伸缩，锅从天上来。

fargate 相信你没用过，所以你才说和 ec2 一个体验。第一，ec2 的 as 有延迟，默认时间是 300s 。可以改，但有问题，他缩回去也有延迟，也可以改。我一开始也用过这个方案，但是 k8s 的 as 的逻辑极其诡异，很容易一会弹出 10 个机器，一会全缩完了。来回蹦跶。如果是 java 业务就更蛋疼了，在默认情况下，如果集群很大，在刚起来的时候所有 pod 的 cpu 巨高，就会弹出一堆机器。然后缩回去的时候又集群平衡。pod 一直处于不稳定状态，需要几分钟的稳定时间。所有值都需要经验去增加 buf 时间，我们高峰期就十分钟，你扛不住今天就损失几十万…

个人觉得。。。挺好的。。不用处理。50 度基本没啥问题。核心是形成对流。为了美观你前面又不可能开口。个人觉得无所谓，坏了还能全坏了不成？你这还是 4 盘位。更不用担心了。装风扇还要考虑供电噪音吧啦吧啦吧啦的。

更多的。。可能要考虑温度引起的板材变形。这两坨感觉都会变形（ 5 年为一个单位）。。就很难看了。如果是我。我会把这坨东西放到旁边那个开放格的最上层。弄个百叶门，看不见，也没有板材变形的风险。。

有。瑞幸的三次有一次我会拉肚子。而且瑞幸的咖啡含量个人感觉很少，压根没到 2 shot 。所以我自己买了半自动咖啡机。早上喝一杯下午就不需要了。
一杯成本看选择什么奶，燕麦的话大概是 7 块一杯。牛奶的话在 3-5 块一杯。性价比和口味秒杀外面买到的 30 以下所有拿铁。添加剂？没有什么添加剂，糖都没有。就咖啡+奶

如果只能有一个优秀，就是自己把握。哪有轮流的。。。想打造什么团队，绩效就以什么样的方向偏呗。
如果你觉得都很好，不分伯仲，也总有一个可以选择为优秀的。然后。。。。我的操作是：我自己掏钱请所有人吃饭。明确表示，绩效是公司的认可，这顿饭是我的认可。

我刚抄起键盘想着：“哪个神仙公司给程序员配 8G 内存”

专利代理人？那正常。电脑只是工具。。。领导不在乎的，甚至很多领导电脑有哪些东西都不懂。不能拿程序员的角度来看。甚至我看到很多 4G 内存的老古董也不少。又不是不能用。打开浏览器 5 分钟。那就去上个厕所，抽根烟。这种摸鱼还不香啊。。

@cesign

运维很多事情不光是技术层面，还有很多其他要考虑的。
spot 回收哪怕你 3 年没出问题，出一次问题。就是一个锅。
甚至说锅这个东西因人而异。大部分公司，线上是一点问题都别出的。出了就要扯皮。哪怕没业务损失。
那么问题来了，为啥要去踩这个雷呢。很多领导，你要是跟他说 0.00001%的概率可能会业务出故障或者订单丢失，逻辑丢失，数据丢失之类的。。很多领导直接就会否了方案。

前面你说的第一和第二没有维护成本区别：一个是要做一个程序去控制，如果 spot 回收还要想办法加回来。这个程序要不要维护？有 bug 怎么办？ api 升级了怎么办？集群升级了怎么办？是不是都是运维管理成本？第二种，哪有什么成本，年初买个 RI ，云平台设置一下定时关机。几年都不用去管他。甚至忘了的存在。

fargate 就不是这么节省成本的，你这个算法就跟我入现在这个公司发现所有服务都跑在 eci 上一样。fargate 哪能这么用，fargate 不能当长期服务用的，贵死人。他的定位是毫秒级可以分配 pod 。秒级拉起新 pod 。应对流量的高低变化。比如白天我就要 2 台常驻的就够了。晚上随着 cpu 的水位自动增加到 10 台。然后某些核心业务服务群用 fargate 自动横向伸缩，比如最高峰要从 2 个 pod 调度出 20-30 个 pod 。fargate 瞬间就能拉起来。这个高峰最多半个小时。缩回去就没成本了。这才是 fargate 的核心使用场景。而且 aws 的 fargate 不清楚有没有 spot 类型。阿里云的 eci 都有 spot 类型。你拿普通的机器 spot 当宿主机打死都不可能比我就运行 1 个小时就出 1 个小时的钱便宜（正常价格的 1/24 ，spot 顶天了 1/10 ，为了稳定可能是 50%上下的定价范围）。

也不能说那个同时观看人数完全是个假的，产品经理为了数字能吸引人，会采用一些“策略”，但绝对不会只有几十个人，里面塞几十万假的。简单一点就是二次函数或者曲线，人数越逼近一个理想值越真实，之后就都是真实的值了

除非费用特别高。。我个人不太倾向业务在 spot 上跑。不管你感知多牛逼。AWS 免责说的明明白白，尽可能通知你，但有可能不通知你，自己负责。不过 spot 的回收率我根 BD 聊，大概 93%以上是没触发过回收。我实际在阿里云用也差不多，半年回收一次。所以策略自己搞个脚本其实很容易。不过吧，因为整体费用并不高，投入人力物力实在是不划算。维护成本也是成本。本来 2 个人就搞完的，因为又要高大上又要省钱，很容易一顿操作猛如虎，一看就省 2 毛五。


@hwcloudnative

第一个问题，这是一个综合成本考虑。买 RI 也没人逼着你全买 RI 啊。RI+Savings plans 是一个比较好的组合。RI 负责 24 小时都要开机的常驻机器。Savings plans 负责每小时的最小用量不限定机器类型。我一般组合着错开买，RI 的折扣力度大，SavingsPlans 折扣力度小但是非常灵活，而且支持 fargate 。

而且还要分业务和环境。我做过两种方案，第一种方案呢，开发测试环境白天开 spot ，晚上关机。第二种方案就是直接 RI 覆盖 50%。晚上自动把多余的机器关了，再自动根据流量伸缩一些 spot 机器出来临时用用。看着是前者省钱了，但是一顿操作猛如虎，一看就省 2 毛五。总得招个人来干吧，总得有第二个人维护和懂吧。第二个方案反而是本来就省钱了，多少而已，但是整体维护成本极低。

现在 fargate 其实是个不错的节省成本方案，如果无状态的，临时调度的扔 fargate 里面，跑完就关了。比开机器舒服多了。比如 CI/CD 。以前总是要一个一直在的集群，还有大小限制，死鬼死鬼。现在有 fargate/ask 的加持，就开一个宿主机跑调度就好了。其他都是 eci 。以前 github 跑 runner 要小 3000 美金一个月。现在。。3000 人民币就够了。

国内目前阶段嘛。。。。。《刑法》。可以试试

@bald3r 哦。决定回家那这个帖就结帖了。。。没看其他的，就看的业务方向和规模。可能会死，但不会爆死。ERP ，WMS 这种的通常都还有大量老客户，活得很滋润。除非整个经济市场玩法大变，基本可以搞个 3-5 年没啥问题，运气好 10 年都没问题，做个狗着的地方挺好的，赚钱是不指望了。

但老家吧。。有一说一，运气不好就是干 1 个月就无了。。。工厂对这东西都是看不上做技术的，不是核心诉求。

@cesign 这个我好像是试用过。。我自己 1 天就能搞定的事硬是被套进来一系列的概念。要精细化运维，最好的方式是自己做。缺什么工具做什么。。这种所谓的大一统的工具，用不了。。用不了。。。关键还要大量的团队学习成本。本来只要会 k8s 。我什么大家都知道，结果用了一个非主流的工具。活都成我的了