程序员的北京折叠:生存、焦虑与抉择

引子:从《北京折叠》说起

《北京折叠》是郝景芳的一篇著名科幻小说,最早于 2012 年 12 月发表在清华大学的学生论坛水木社区的科幻版。2016 年获得第 74 届雨果奖最佳中短篇小说奖,2018 年获得第 49 届星云赏海外部门短篇小说奖项。雨果奖介绍这篇小说「构建了一个不同空间、不同阶层的北京,可像‘变形金刚般折叠起来的城市’,却又‘具有更为冷峻的现实感’」。

《北京折叠》讲述了北京这个城市被分割成了三个空间,每个空间的人们在各自的时空中生活,彼此之间几乎没有交集。第一空间的人高高在上,掌控着资源与权力;第二空间的中产阶级维持着相对体面的生活;第三空间的人则在贫困、压抑中挣扎求生。三层空间的生活轨迹几乎不会重叠,仿佛他们生活在完全不同的世界中。

作为一名程序员,这个故事让我不禁联想到我们这个行业中的「折叠北京」,在不同的公司、岗位和城市,程序员们同样被划分成了不同的「空间」。每个人的职业轨迹、生活方式和所面临的问题大相径庭,甚至无法体验到他人生活中的酸甜苦辣。

我曾在大厂呆过,在小公司也做过,自己也曾创业。在这些不同的「空间」里,我看到了程序员群体的多样性,感受到了他们各自的焦虑与困境。今天,我想借用《北京折叠》的框架,来聊聊程序员世界中的三种「空间」,它们之间的壁垒、差异,以及偶尔交错的瞬间。

1. 第一空间:大厂程序员的「黄金时代」

在程序员的世界里,第一空间无疑是那些在头部互联网大厂工作的精英们。字节跳动、阿里巴巴、腾讯、网易等巨头公司,几乎可以说是这个行业的象征。对于很多年轻程序员来说,进入大厂意味着职业生涯的「黄金时代」——高薪酬、丰厚的福利、甚至是行业内的一些光环,仿佛一切都昭示着成功与荣耀。

1.1 高压环境中的「内卷」

在大厂工作,最直观的感受就是无处不在的竞争。这种竞争不仅来源于外部市场的技术更新、产品迭代,更深刻地体现在公司内部,尤其是在同事之间。这种现象在互联网行业尤为明显,因此,很多人用「内卷」一词来概括大厂程序员们的工作环境。

1.1.1 绩效排名和末位淘汰制

大厂程序员普遍面临着严格的绩效考核制度。像字节跳动、阿里巴巴等公司,通常实行「361」类的强制考核,即在每次考核中,前20%的员工拿到最好的绩效,而后 20% 左右则面临淘汰的风险。每半年(或者一个季度)一次的绩效考核期,几乎是程序员们最为紧张的时刻,生怕自己成为「差劲」或「末位淘汰」的一员。

这种考核机制确实激励了员工不断提升自我,但也带来了巨大的心理压力和工作负担。为了在绩效评估中脱颖而出,程序员们不得不超负荷工作,甚至牺牲健康和个人生活。许多大厂的加班文化已成常态,尤其是在实行“996”工作制度的公司,程序员们的工作时长远远超出了法律规定的标准。

更为严重的是,由于绩效考核的竞争性,团队内部的合作有时变得愈发功利化。项目的成功不仅关乎团队整体的荣誉,还直接决定了每个人的绩效评定。于是,暗中较劲、互相攀比的现象时有发生,团队协作因此变得更加复杂且微妙。

1.1.2 怎样才算「成功」?

在大厂的程序员群体中,有一种不成文的共识:成功的标志不是你是否能够完成日常的任务,而是你能否写出新技术、推动新项目,甚至在团队中成为某个领域的权威。每个人都在追求「技术大咖」的头衔,渴望在某个技术社区或者公司内部的技术分享会上崭露头角。技术的不断迭代让人们时刻保持学习的心态,但这种持续的自我提升也带来了巨大的压力。

有时我会和一些在大厂的朋友聊起他们的生活,发现他们的焦虑和我在小厂时的焦虑并没有本质区别。尽管他们拿着比普通程序员高得多的工资,但他们的时间成本、精神压力和对未来的迷茫感也不比别人少。他们的生活轨迹看上去光鲜亮丽,但其实也是在一种高强度的环境中挣扎生存。

为了在考核中脱颖而出,程序员们会拼命寻找可以量化的业绩,比如开发新功能、优化系统性能、贡献开源项目等。然而,这种短期导向的行为,往往导致大量的重复劳动。不同的团队、甚至同一团队的成员,可能都在做相似的工作,因为每个人都希望自己的成果被视为「独创贡献」。

这种过度竞争导致了资源的浪费和技术的冗余。比如,不同团队可能会开发多个功能类似的工具或系统,但由于每个团队都希望展示自己的「独立成果」,这些项目往往没有被整合,造成了效率低下。这种「重复造轮子」的现象在大厂程序员中屡见不鲜,不同的部门,甚至不同的中心各有一套技术栈或管理系统的很常见。这不仅浪费了时间和资源,也让公司的整体创新能力受到抑制。

1.2 裁员潮下的生存危机

1.2.1 大厂裁员的频发性

近年来,随着互联网行业的逐渐成熟和增速放缓,国内外的大厂频繁爆出裁员的新闻。无论是由于公司战略调整,还是市场环境的变化,裁员已经成为了大厂的一种常见操作。即使是表现优异的部门,也可能因为公司调整方向而面临裁撤的命运。

大厂裁员并不仅仅针对绩效较差的员工。很多时候,裁员是为了优化成本结构,或者是公司业务重心发生了转移。某些曾经处于风口的业务部门,一旦被认为前景不妙,整个团队可能会在短时间内被解散。例如,一些大厂在短视频、智能硬件等领域的扩张速度过快,导致后期发展遇阻,一旦业务不达预期,相关团队就可能面临大规模裁员。

以字节为例,2023 年底字节跳动官宣大规模裁撤游戏项目和人员,未上线项目几乎全部关停,已上线且表现良好的游戏也要寻求剥离; 2024 年初飞书裁员超过 20%,

这种裁员的不可预测性,给大厂程序员的职业生涯带来了巨大的不确定性。即便你今天的绩效再优秀,也无法保证明天公司不会因为战略调整而决定裁掉你所在的部门。这种生存危机,成为了大厂程序员的长期困扰。

还在某大厂的兄弟说:以前,末位淘汰了还可以增补 HC,但是现在淘汰了就是淘汰了,不会有新的人补充进来,且强制 10% 的比例。这也是一种裁员的逻辑。

1.2.2 「大龄程序员」的困境

裁员的另一大受害者群体是所谓的「大龄程序员」,即那些年龄超过 35 岁、甚至 40 岁以上的技术人员。在很多大厂的文化中,年轻意味着活力和更强的工作负荷承受能力,因此,年龄较大的程序员往往被认为「性价比不高」。

当公司需要削减成本时,首先会考虑那些薪资较高的员工。而大龄程序员由于工龄长、薪资高,往往成为了裁员的首选对象。即便这些程序员有着丰富的技术经验和项目管理能力,但在日新月异的互联网行业,他们的优势往往被削弱。

同时,技术更新日新月异,大龄程序员若无法持续跟上行业的技术潮流,便可能在职业生涯中陷入困境。很多人会在 35 岁之后面临职业发展的瓶颈,不得不思考转型的可能性。

1.3 程序员的「供需失衡」

与十几年前程序员供不应求的情况不同,如今的互联网行业已经趋于饱和。随着越来越多的人涌入这个领域,市场对程序员的需求增速放缓,导致了供需之间的失衡。

在 2024 年 8 月招生季,太原理工 2024 软件工程招 60 个班,近 2000 人,冲上热搜。想象一下,在四年之后的这些学生的就业难度会像「通货膨胀」一样飞速上涨。

这种供需失衡带来了一系列问题。在初级程序员这一级,竞争会更加激烈,很多应届毕业生发现自己面临大量竞争对手,哪怕是基础岗位,也往往需要具备极高的技术能力。

企业在招聘时可以更加挑剔,倾向于选择那些工资要求低、技术基础扎实的年轻程序员,而那些经验丰富但薪资要求较高的资深程序员,反而变得不那么受欢迎。

程序员岗位已经从一个「卖方市场」彻底转变为「买方市场」

在「卖方市场」时期,企业为了吸引优秀的技术人才,往往会提供丰厚的薪资福利和极具吸引力的职业发展机会。然而,随着越来越多的程序员涌入市场,岗位供给的增速却远远赶不上需求的增长,企业开始占据更多的主动权。

在买方市场中,企业可以更加挑剔地选择应聘者,不仅要求候选人具备扎实的技术基础,还希望他们能够适应更高的工作强度和更低的薪资要求。这种局面尤其对初级程序员和应届毕业生不利。哪怕是一些基础岗位,也往往需要较高的技术门槛和项目经验,导致很多刚毕业的学生发现自己难以找到合适的工作机会。

与此同时,资深程序员的处境也不容乐观。那些拥有多年经验的程序员,虽然在技术上更为成熟,但由于薪资要求较高,企业在招聘时往往更愿意选择年轻、成本较低的程序员。这种现象让很多资深程序员陷入了「高不成低不就」的尴尬境地。他们的技术能力虽然依然强大,但在快速变化的互联网行业中,市场对他们的需求开始减少,尤其是在裁员潮和优化成本的背景下,资深程序员的议价能力逐渐被削弱。在就业市场上常常可以看到一个岗位多个人竞争的情况。

1.4 大厂程序员的「中年危机」

1.4.1 技术更新的焦虑

程序员这个职业最大的特点之一是技术更新的快速迭代。每隔几年,行业的技术栈就会发生翻天覆地的变化。从最早的C、C++到如今的云计算、人工智能和区块链,每一波技术浪潮都要求程序员持续学习新知识,适应新的工具和框架。

对于年轻程序员来说,学习新技术可能充满了乐趣和挑战性。但对于年纪较大的程序员来说,技术更新的压力往往带来了巨大的焦虑感。随着年龄增长,学习新技术的难度和精力投入都在增加,而大厂的工作环境又要求程序员始终保持对新兴技术的敏感度。这种持续的技术更新压力,让很多大龄程序员感到力不从心。

1.4.2 顶层的天花板

对于很多大厂程序员来说,最可怕的不是眼前的压力,而是那种隐隐约约的「天花板」感。你很难在大厂中看到五十岁、甚至四十岁以上的程序员,他们的去向仿佛成了一个谜题。

大家心照不宣地知道,到了某个年龄段,技术可能已经不再是你的核心竞争力,管理岗位有限,竞争者众多,如何突破这层「天花板」成了很多大厂程序员内心深处的焦虑。

面对年龄、技术更新和职业发展的瓶颈,很多大厂程序员在 30 岁之后开始考虑职业转型。然而,转型并不是一件容易的事情。大多数程序员的职业技能都围绕技术展开,一旦离开了技术岗位,很多人发现自己在其他领域缺乏竞争力。

常见的转型路径包括转向管理岗位、创业或进入教育培训行业。然而,管理岗位有限,创业风险极大,而教育培训行业本身也在经历着调整。这使得很多程序员在转型的过程中感到困惑和无助。职业发展的瓶颈使得大龄程序员的未来看起来充满了不确定性。

1.5 黄金时代的背后是无尽的焦虑

大厂程序员的生活看似光鲜,但背后却充满了无尽的压力与焦虑。高薪的代价是长期的加班和激烈的内卷;丰厚的待遇伴随着频繁的裁员和职业发展的瓶颈。尤其是大龄程序员,他们不仅面临着技术更新的焦虑,还要应对职业转型的困惑。

在这个日新月异的行业里,大厂程序员的「黄金时代」或许并不像外界看到的那样光鲜。当「中年危机」到来,如何平衡工作与生活、如何应对技术的快速变化,成为了每一个程序员都需要思考的问题。

如 will 老板所说:始终要思考的是如何在大厂活下去!,更进一步:其实更焦虑的是如何靠自己活下去

2. 第二空间:小厂程序员的迷茫与抉择

2.1 资源、团队与技术的困境

在小公司工作的程序员面临的第一个现实问题是资源的匮乏。与大厂程序员相比,小厂程序员的开发环境和资源往往十分有限。预算紧张使得小公司无法购买先进的开发工具,也没有大厂那样完善的基础设施和支持团队。很多时候,程序员需要用「土办法」去解决问题,甚至自己搭建和维护服务器、数据库等基础设施。

虽然现在云服务的使用已经很普遍了,但是能用好云服务的公司不多,甚至在常见的 CI/CD 流程都没有实施。

团队情况也是一个重要因素。小公司里,团队人员往往较少,职责分工不如大公司细致,很多程序员需要身兼数职,既要写代码,还要负责运维、测试,甚至参与产品设计和业务讨论。这种「多面手」的工作方式虽然能让个人能力得到快速锻炼,但也意味着专注度较低,无法在某一个领域深入钻研,导致技术积累不够扎实。

技术的硬门槛是另一大挑战。小公司通常专注于短期业务目标,项目进度往往比技术本身更加重要。这导致程序员在开发过程中可能会放弃对代码质量、性能优化等技术细节的追求,而更多地采用快速上线的策略。这种方式虽然能让产品迅速推向市场,但也限制了程序员的技术视野和思维,长期下去,很容易陷入技术瓶颈

2.2 平台、资源与局限

2.2.1 资源的限制

与大厂相比,小厂程序员的工作环境显得更加局促和紧张。他们没有大公司那样强大的技术团队或前沿的技术工具支持,很多时候只能依赖现有资源,甚至是开源工具来解决问题。

公司往往没有足够的预算去支持技术创新,项目的重点更多地放在如何快速满足客户需求上,而不是技术实现的完美度。因此,小厂程序员的工作更多的是一种「打补丁」的过程,解决眼前的问题,而不是从根本上提升系统的架构或性能。

由于缺少大厂的技术资源和系统流程,小厂程序员在面对复杂问题时只能依赖个人经验和有限的知识储备。这种资源的匮乏,让他们在遇到需要深入技术实现或复杂系统优化的问题时力不从心,也限制了他们的职业发展。

2.2.2 多面手的隐患

小公司经常要求程序员成为「全栈开发者」,不仅要负责前端、后端的开发,还要参与运维、测试,甚至是产品设计。这种「多面手」的角色虽然能在短时间内提升程序员的综合能力,但长期来看,专精度的不足是显而易见的。程序员往往在多个领域都有所涉及,却缺乏一个深耕的方向,导致在某些关键技术上与大厂程序员相比存在明显的差距。

这种现象尤其体现在一些高精尖的领域,比如分布式架构、性能优化、大规模数据处理等。小公司项目的局限性使得程序员鲜有机会接触这些高端技术,即便遇到相关问题,也往往是通过快速修补的方式解决,而不是深入理解和优化。多面手的广度虽然让小厂程序员具备了应对不同问题的能力,但缺乏深度的劣势在面对更高的技术挑战时显露无遗。

2.2.3 重复与瓶颈

小公司项目的重复性也是一个常见的问题。许多小公司专注于某些特定的业务场景,程序员在开发过程中,往往是在重复类似的增删改查操作。长时间在这种环境中工作,程序员容易陷入一种技术思维的局限,觉得自己的工作仅仅是完成客户需求,而忽视了技术本身的提升。这种局限让他们在面对更复杂的项目或系统时,缺乏应对的思路和方法。

在这种环境下,程序员可能会感到希望突破但找不到方向。他们渴望接触更复杂、更有挑战性的技术,但小公司的项目和资源限制了他们的视野,无法提供足够的成长空间。很多程序员在小公司工作多年后,逐渐意识到,自己的技术积累始终停留在某个水平,无法突破。

2.3 对未来的迷茫与期待

2.3.1 稳定性的假象

小厂程序员的处境,常常在稳定与成长之间徘徊。对于很多在小公司干了多年的人来说,工作内容虽然相对稳定,压力小,甚至在某些场合下还能当上小领导,但这种「舒适区」并不一定带来长久的安全感。

尽管有些程序员在小公司工作多年,积累了一定的业务经验,甚至在团队中占据了重要的角色,但这并不意味着未来的职业道路是一片坦途。小公司的抗风险能力差,经济波动或行业萎缩时,很多小公司会迅速陷入困境,甚至倒闭。对于很多 30 岁上下的程序员来说,一旦失去这份相对稳定的工作,他们可能会发现自己在技术上并没有明显优势,面临再就业的难题。

这种不稳定性让很多小厂程序员产生了焦虑感。他们担心公司倒闭后,自己所积累的业务经验和技术能力无法顺利转化到其他公司。尤其是在面对大厂的面试要求时,很多小厂程序员会发现自己的项目经验和技术广度远远不足以应付大厂的高标准。进退两难的局面让他们陷入迷茫,不知道未来的职业发展该何去何从。

2.3.2 突破的渴望与现实的差距

尽管如此,很多小厂程序员依然保持着突破现状的愿望。他们希望自己的公司能够做大做强,从而拥有更多的资源和技术成长的机会。然而,现实往往并不如人意。小公司能做到一定规模的并不多,很多公司最终还是会因为市场竞争激烈、资金不足等原因被淘汰。

因此,跳槽到中型公司或大厂历练,成为了不少小厂程序员的另一种理想选择。他们希望通过进入更大平台,接触到更多的技术挑战和行业资源,打破在小公司中「打转」的局面。但这种跳槽并不容易,尤其是对于长期习惯了小公司开发模式的程序员来说,想要进入大厂不仅需要提升技术硬实力,还需要适应大厂的工作节奏和文化。

2.4 跳槽到大厂:进阶还是冒险?

对于那些在小公司工作了多年,并且已经进入到领导层的程序员来说,最大的问题往往是:现在跳槽到大厂,值得吗?

2.4.1 跳槽的机遇

跳槽到大厂意味着能够接触到更复杂的技术栈和更具挑战性的项目。在大厂中,程序员不仅可以学习到前沿的技术(如微服务架构、Kubernetes、分布式系统等),还能够获得更为完善的职业晋升通道。大厂的技术氛围和资源整合能力,也意味着程序员能够更快地成长,跳出小公司单一业务的限制。

此外,大厂的品牌效应也不容忽视。即使是普通开发,拥有大厂背景的程序员在未来的求职市场上,无论是跳槽还是创业,都具有更高的含金量。

2.4.2 跳槽的风险

然而,跳槽到大厂并非没有风险。大厂的竞争激烈,程序员需要面对年轻一代的强大竞争压力。大厂的工作节奏快、加班文化重,许多 30 岁左右的程序员可能会发现,自己在体力和精力上难以与年轻人抗衡。

进入大厂后,之前在小公司积累的业务经验和管理经验未必能够直接转化为优势。大厂的岗位分工更加明确,很多程序员在跳槽后可能需要从普通开发做起,甚至重新适应新的工作流程和技术要求。

跳槽到大厂对于 30 岁上下的程序员来说,是一个双刃剑。如果能够抓住机会快速提升技术能力,则职业生涯将迎来新的突破;但如果无法适应大厂的节奏,则可能面临事业的再次迷茫。

2.5 技术能力和学习能力是立足之本

小厂程序员的迷茫和焦虑,归根结底源于技术成长的瓶颈和职业发展的不确定性。面对快速变化的行业环境,程序员们需要不断提升自我,不仅要在技术上有所突破,还应当具备长远的职业规划。

无论是在小公司继续发展,还是跳槽到大厂,程序员都应当意识到,技术能力和学习能力是立足于这个行业的根本。唯有不断学习和进步,才能在程序员的职业道路上走得更远、更稳。

3. 第三空间:外包与自由职业者的「生存游戏」

3.1 外包的世界

在大厂和小厂之外,还有一群程序员,他们生活在外包公司中。外包程序员的生活与大厂和小厂截然不同,他们的工作内容往往由客户决定,技术栈也不是自己可以随意选择的。一些外包程序员可能会长期为某个大厂或者知名企业提供服务,但他们并不属于这些公司,他们的身份始终是「外包」。

外包程序员的收入通常与大厂程序员有较大差距,工作内容也更加琐碎。与大厂和小厂的开发者相比,外包程序员的职业发展路径更为模糊。很多人觉得外包是一个「临时的选择」,但一旦进入外包行业,往往很难轻易跳出来

3.2 自由职业者的自由与孤独

与外包程序员类似,自由职业者也是程序员群体中的一个独特存在。他们没有固定的公司和老板,依靠接项目为生。自由职业者的生活看似自由,但实际上他们承担了巨大的生活压力:项目的来源、项目的质量、客户的付款周期,这些都直接决定了他们的收入。

我有一位朋友曾辞职做过一段时间的自由职业者,他的经历让我对这一群体有了更深的了解。他曾告诉我,自由职业的最大挑战不是技术,而是如何维持客户关系、如何接到稳定的项目。自由职业者的生活往往充满了不确定性,每天都是一次新的「生存游戏」。

4. 结语:折叠的程序员世界

程序员的世界如同《北京折叠》中的三个空间:大厂、小厂,外包与自由职业者,各自有着截然不同的生活方式与职业挑战。大厂程序员在高薪与内卷中挣扎,小厂程序员在资源匮乏和职业迷茫中徘徊,外包和自由职业者则在充满不确定性的项目中谋生。每个空间都有其独特的焦虑与困境,而这些困境往往是外界无法轻易察觉的。

然而,这些看似完全隔绝的空间并非毫无交集。在某些时刻,程序员们的职业轨迹会短暂交错:大厂的程序员可能因职业倦怠转而投身小厂,或选择成为自由职业者;小公司的程序员也可能抓住机会进入大厂,体验另一种生活。外包和自由职业者也常常通过项目合作,与大厂程序员产生联系。

折叠的背后,是程序员们面对的共同挑战:快速变化的技术浪潮、工作与生活的平衡、未来职业发展的不确定性。

无论身处哪个空间,程序员不仅要面对代码和产品,还要面对生活的选择与妥协。技术的迭代让人时刻保持危机感,职场的竞争让人不断追逐更高的目标,但归根结底,程序员们都在寻找如何掌控自己的命运,在压力与选择中找到一条适合自己的道路。

或许,正是这种多元的职业轨迹和复杂的生存环境,构成了程序员世界中的「折叠北京」。每个空间的故事,都在提醒我们:技术人的真正挑战,不仅在于掌握技术,更在于如何在折叠的世界中找到属于自己的平衡与方向

5 块钱,就可以给娃训练一个专属的 AI 模型

上周末花了 5 个小时,从零开始给娃训练了一个基于 flux1_dev 的 lora,用于生成娃的照片。

以下为详细(保姆级)的过程记录,有想法又没有自己训练过 lora 的程序员爸爸或妈妈们可以尝试一下。

可能的时间成本:2 ~ 5 小时,资金成本:5 ~ 10 块。

环境准备

因为我们会用到 GPU 机器,去类似于阿里云这种云平台租,太贵。

这里我们选择的是 audodl ,一个比阿里云便宜 60% 的可按小时租 GPU 服务器的算力平台。autodl 基于容器实现,在使用上有一些局限性,但是对于我们当下的需求来说,还是非常匹配的。

我们选择如图 1 所示的配置:

图1

4090D + 50 G 额外的空间

尽量选择空闲 GPU 多的主机或所在区,因为可能会存在主机 GPU 不够的情况。

下单付款,等待容器启动。

容器启动后,直接使用官方提供的 web 的终端,这个终端有一个好处是当你关掉浏览器以后,终端还在,有点类似于 nohup 的执行状态。

需要说明一下,autodl 的存储分为系统盘和数据盘,在 /root/autodl-tmp 下为数据盘空间。我们要下载的模型、项目等都放到数据盘下。

把 commfy UI flux 跑起来

1. 创建 comfyUI 的环境并跑起来

cd ~/autodl-tmp

git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
conda create -n comfyui python=3.12 -y

conda init
source ~/.bashrc

conda activate comfyui
pip install -r requirements.txt 

在 git clone 时可能会遇到克隆失败的情况,此时需要使用 autodl 的学术资源加速:https://www.autodl.com/docs/network_turbo/

另外,在 conda create 后无法直接 conda activate,需要先 conda init,然后 source ~/.bashrc 或重新启动一下终端

接下来是启动 ComfyUI

python main.py

启动是启动了,但是如何访问了,这台机器又不在我本地,难道要启一个外网端口监听,此时就需要启动自定义服务,当然我们也可以使用 ssh 的通道能力,让本地电脑能访问远程的服务,在本地命令行中执行如下的命令:

ssh -CNg -L 8188:127.0.0.1:8188 -p 49027 root@connect.westb.seetacloud.com

以上的 -p 后的参数对于不同的机器不同,请参考控制台上的登录指令,如图2:

图2

输入后会提示:root@connect.westb.seetacloud.com’s password:

当时将控制台的密码复制出来,粘贴即可,回车。此时,可能没有啥反应,嗯。这是正常的。不用管他,除非报错告诉你连接失败或者密码错误,再重新输入。

在浏览器中输入:http://localhost:8188/

就可以看到 ComfyUI 的界面了。

2. 下载并运行 flux

在 ComfyUI 的 flux1 的 Demo 界面中:https://comfyui-wiki.com/tutorial/advanced/flux1-comfyui-guide-workflow-and-examples

可以把 Flux Dev ComfyUI workflow example 那张美少女的照片下载下来,直接拖到 ComfyUI 的界面上,或者下载 json 文件加载进来。如下图所示:

图3

要把示例跑起来,我们有 4 个文件要下载,分别是:

  • 放到 models/unet 目录下的 flux1.dev fp8 模型:https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/flux1-dev-fp8.safetensors
  • 放到 models/vae 目录下的 VAE 模型:https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/ae.safetensors
  • 放到 models/clip 目录下的 clip 编码器:https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/clip_l.safetensors
  • 放到 models/clip 目录下的 T5XXL 文本编码器:https://hf-mirror.com/camenduru/FLUX.1-dev/resolve/main/t5xxl_fp8_e4m3fn.safetensors

在 hf 下可能会存在下载失败的情况,这里我们选择 hf-mirror: https://hf-mirror.com/camenduru/FLUX.1-dev/tree/main

下载可能会持续个 20 分钟左右,视网络情况,早上下载可能会快一些。

接下来就比较简单了,在本地浏览器中打开,点击运行 Queue Prompt 按钮

第一次运行会慢一点,因为需要加载模型这些,后面再次执行就大概 10 秒多一点。

图4

把 lora 加到管线并跑起来

1. 下载 lora 模型在类似于 liblib.art 之类的网站下载一个你觉得不错的 lora 模型,将其放到 ComfyUI 的 models/loras 目录中。

在 ComfyUI 的界面中增加一个 lora 的节点,这里我选择的是纯粹的 lora 节点,如图 5 所示

图5

点击 Queue Prompt 按钮,等一会儿就能看到生成的图片了,如果图片不符合预期,可以调整一下 prompt 试试,如你选择的 LoRA 是一个美女明星的 LoRA,简单点的:a girl,portrait, professional portrait

2. 调整 LoRA 强度与权重在 LoRA 节点中,你也可以调整 LoRA 的权重,以影响生成图片时对 LoRA 的依赖程度。通常,权重值可以设置在 0.5 到 1.0 之间,这取决于你希望模型生成的图片与 LoRA 模型的契合度。权重越高,生成的图片越接近 LoRA 模型的风格;而权重越低,则越依赖于你输入的 prompt

调整 LoRA 节点的参数后,再次点击 Queue Prompt 按钮,等待生成的新图片。如果生成的图片依然不符合预期,可以继续调整 LoRA 权重,或者尝试修改 prompt 来更好地引导模型。

打标

在 LoRA 跑起来并生成合适的图片后,下一步就是准备训练数据集。数据集的质量对模型的效果至关重要,因此我们需要对数据集进行打标。打标的目的是为每张图片生成准确的描述标签,使模型能够理解图片的内容,以便在未来生成类似的图像时能够参考这些标签。

打标工具

选择合适的打标工具或方案可以帮助我们生成高质量的标签。以下是一些常用的打标工具或方案:

  1. Florence 2:Florence 2 是一个强大的自动打标工具,能够为图片生成高精度的标签。它的优点是标签的细节和准确性较高,适合用于需要精确描述的图片场景。
  2. JoyCaption:JoyCaption 是 WD14 的替代工具,提供了更细致的标签生成能力。它能够为每张图片生成更详细的描述,适合用于生成具备复杂场景或人物的标签。不过,它也有一定的出错概率,因此需要额外的人工检查。
  3. MiniCPM:MiniCPM 是一个轻量级的打标工具,适合小规模数据集的快速打标。它的优点是操作简便,生成速度快,缺点是生成的标签可能不够详细,适合用于简单场景的图片。
  4. WD14:WD14 是一个非常流行的打标工具,特别适合用于文生图任务。它的标签生成能力较强,能够根据图片生成与文本 prompt 相关性较高的标签。特别适用于需要高质量和一致性的图片生成任务。

打标策略

为了确保数据集的质量,打标时可以采用以下策略:

  1. 多工具结合使用:如果你的图片集包含不同类型的图片,可以使用多个打标工具来生成初步标签,然后对标签进行合并和校对。比如:使用 Florence 2 生成的标签作为基础,再用 WD14 生成补充标签。
  2. 人工校对:虽然自动打标工具能够节省大量时间,但是人工校对是必不可少的环节。检查和修正错误标签,确保每张图片的标签描述都准确无误。
  3. 标签标准化:在打标过程中,确保使用一致的标签格式和风格。比如:尽量使用标准化标签(如 “portrait”, “landscape”, “girl”, “cityscape” 等)来确保不同图片的标签一致性。
  4. 使用特定的标签:对于我们当前这个场景,对每个图片在 AI 打标的基础上增加额外的一个标签来代表娃,比如我在这里使用的是 bbdr,具体参考打标的脚本。

WD 打标

在这里我选择的是 https://huggingface.co/SmilingWolf/wd-swinv2-tagger-v3 来实现的打标,在其 web demo 的基础上做了一点小改造,具体代码见:https://github.com/phppan/wd-swinv2-tagger-v3-script/blob/main/wd_tag.py

git clone https://github.com/phppan/wd-swinv2-tagger-v3-script

cd wd-swinv2-tagger-v3-script/

conda create -n wds python=3.12 -y
conda activate wds
pip install -r requirements.txt 
mkdir data

export HF_ENDPOINT=https://hf-mirror.com

可能会存在克隆失败的情况,如:

fatal: unable to access 'https://github.com/phppan/wd-swinv2-tagger-v3-script/': GnuTLS recv error (-110): The TLS connection was non-properly terminated.

多试几次。

最后的 export HF_ENDPOINT=https://hf-mirror.com 要执行,我们从镜像网站下载模型,hf 有时候无法直接访问。

如果嫌麻烦,可以 vim ~/.bashrc,在此文件中添加后 source ~/.bashrc

上传数据集并生成打标内容

将前面准备好的 10 张照片上传到上面创建的 data 目录。执行

python wd_tag.py

在上面的打标脚本中,我将特定的标签 bbdr 加到标签中,后续在生成的时候都会带上这个标签。你也可以改成你自己的标签,赖博说这里:最好几个辅音叠加,不容易冲突

等待模型下载完成,并执行完打标工作,在 output 目录中可以看到生成和图片名称同名的 txt 文件,这就是我们打好了的标签。

开始训练模型

模型训练,这里我选择的是 ai-toolkit:https://github.com/ostris/ai-toolkit

git clone https://github.com/ostris/ai-toolkit
cd ai-toolkit/
git submodule update --init --recursive

conda create -n aitool python=3.12 -y
conda activate aitool

pip3 install torch
pip3 install -r requirements.txt

修改配置文件并执行训练

cp config/examples/train_lora_flux_24gb.yaml ./config/bbdr.yaml
vim ./config/bbdr.yaml

一些参数的修改可以参考视频:https://www.youtube.com/watch?v=HzGW_Kyermg 主要是修改:name(名字)、training_folder(训练生成的目录)、folder_path(训练集路径)

python run.py ./config/bbdr.yaml

接下来就是等待训练完成。

训练完成后,在上面参数中设置的生成目录中可以看到你想要的 lora 模型文件,如我们设置的名字是 bbdr,则生成的模型名为:bbdr.safetensors

将其复制到前面我们已经部署好了的 ComfyUI 项目的 models/loras 目录下,在界面中选择你要的 lora 模型,在 prompt 中把你自定义的标签加上,如我们这里是 bbdr,一个简单的示例:bbdr,a girl,cute,perfect body,standing,street

等一下,就能看到专属于娃的 AI 模型生成的图片了。

其它

  1. 如果在编写/调试代码、上传下载数据到实例、给他人做代码展示等不需要GPU卡场景时,可以关机后使用无卡模式开机,无卡模式开机的区别在于对于这次开机会使用0.5核;2GB内存;无GPU卡的配置,价格统一为¥0.1/小时
  2. 如果不想等训练完成,可以设置定时关机。
  3. 照片请准备同一时期的照片,不同时期的照片,特别是小朋友,可能相貌差别较大,会导致最终生成的效果不好

以上是程序员逻辑,主打一个学习和挑战。

不想整这么复杂的,可以选择在类似于 liblib 的 lora 训练平台上生成:https://www.liblib.art/pretrain 或者类似于 https://www.mimicpc.com/ 这样的平台。

强哥说:看了这么久的理论,这次终于破天荒来了篇工程的。

以上。

最后感谢赖博的指导

研发效能之规模管理:工程化与系统化的思考

随着业务的发展,研发团队和系统架构往往面临一个共同的难题:如何在规模不断扩大的情况下,保持高效、稳定的输出

你是否曾经历过这样的困境:系统运行环境中的负载不断攀升,不得不频繁进行性能优化;团队规模扩充后,开发协作开始变得混乱,沟通成本直线上升;技术债务不断积累,系统的开发和维护变得艰难?

这些问题的本质在于规模管理的缺失或不足。规模不仅仅体现在系统需要处理越来越多的用户和数据层面,还包括团队管理、开发流程和技术栈的复杂性增长。如果缺乏系统化和工程化的管理方法,规模的扩大往往会拖慢研发效率,甚至导致项目失控。

那么,如何通过系统化、工程化的手段,来解决规模扩展带来的复杂性和挑战呢?

1 研发中的规模

在软件研发中,规模主要可以分为生产规模开发规模两大类。具体来说,研发中的规模主要包括以下几个方面:

1.1 生产规模

生产规模指的是系统在实际运行环境中所需处理的负载、并发能力和扩展性。它关注的是一个系统在面对业务增长时,是否能够高效处理不断增加的数据量、用户请求、并发任务等。包括:

  • 并发处理能力:系统可以同时处理多少用户请求或任务。
  • 数据处理能力:系统能够处理的数据量级别如何,是否支持大数据量的存储、查询和分析。
  • 网络流量承受能力:系统在面对大规模用户访问时,是否能够保持稳定的响应时间,并在流量高峰期依然能够正常工作。
  • 弹性扩展能力:系统是否可以根据流量的变化自动扩展资源,避免高负载时的性能瓶颈和低负载时的资源浪费。
  • 容错与高可用性:系统在面对硬件或软件故障时是否具备自我恢复能力,确保业务的连续性。

1.2 开发规模

开发规模指的是随着项目和团队的扩展,如何有效管理代码库、开发流程和团队协作。随着开发人数、代码库复杂度的增长,团队需要更加系统化的管理手段,以保持高效的开发效率和高质量的代码输出。

  • 代码库规模:项目的代码量逐渐增加,模块和功能变得更加复杂。如何确保代码库的可维护性、可测试性和可扩展性是关键。
  • 团队规模:参与开发的工程师人数增多,如何确保团队成员高效协作、避免冲突和重复工作是管理的重点。
  • 协作复杂度:随着团队规模扩大,沟通和协作的难度也会增加。如何通过协作工具、流程规范和文档化手段确保团队高效运转。
  • 开发流程的复杂度:团队规模和项目复杂度增加,开发流程自然也会变得更复杂。如何通过流程优化和工具化手段(如CI/CD、自动化测试等)简化开发、测试、发布流程。
  • 知识管理:随着项目复杂度增加,技术债务和知识流失的风险也随之增加。如何通过文档化、知识共享平台等手段,确保团队成员(尤其是新人)快速上手和理解项目。

除了上面的 5 点,还有一些技术规模相关的点:

  • 技术栈的扩展性:技术选型是否具备支撑未来业务增长的能力,是否容易扩展、维护和升级。
  • 基础设施的扩展性:从服务器、数据库到网络架构,是否能够支持高并发、大数据量、快速响应等需求。
  • 技术债务管理:随着项目的发展,技术债务的积累不可避免。如何在技术规模扩展的同时进行技术债务的管理和偿还。

2 如何管理规模

作为研发管理者,面对系统和团队规模的不断扩大,如何确保研发效能的持续提升,是一个复杂且多维度的挑战。规模管理的核心在于通过技术手段与管理方法的结合,保证系统和团队能够适应业务增长,同时避免因规模扩大而带来的效率损失和质量问题。

2.1 管理生产规模

生产规模通常指的是系统在实际运行环境中所能处理的负载、并发能力和扩展性。然而,生产规模的扩展实际上离不开架构、基础设施、自动化手段等,即通过技术手段来保证系统能处理不断增长的业务需求。

2.1.1 架构设计与扩展性

生产规模的扩展依赖于架构设计的弹性和扩展性。架构设计是生产系统能否承载更大负载、更高并发的根本。

  • 微服务架构:在面对大规模扩展时,单体架构往往难以承受较大负载和频繁的变更。微服务架构通过将系统拆分为多个独立的服务,每个服务可以独立扩展、部署和维护。这种架构设计允许生产系统根据业务需求水平扩展,避免单点瓶颈。

  • 事件驱动架构:在高并发环境下,事件驱动架构可以通过异步消息处理来解耦系统中的模块,从而提高弹性和扩展性。这种架构设计允许系统通过消息队列(如Kafka、RabbitMQ)来处理大量并发请求,并减少同步通信带来的延迟和性能瓶颈。

  • 分布式架构:对于需要处理海量数据和高并发请求的生产系统,分布式架构是必不可少的。通过水平扩展(如分布式数据库、分布式缓存、分布式存储等),系统可以在生产环境中扩展以应对更高的负载。

架构设计决定了生产规模的技术上限。架构设计是生产系统能否在负载增加时保持高效运行的关键。

在管理生产规模时,需要着重考虑当前架构的合理性和前瞻性。

2.1.2 基础设施扩展和性能优化

  • 自动化扩展:利用云计算平台的弹性伸缩功能,根据流量动态增加或减少资源。为了实现更灵活的资源管理和扩展,容器化技术(如 Docker )和容器编排系统(如 Kubernetes )成为生产规模扩展的基础。通过容器化,生产环境中的服务可以快速部署、扩展和迁移,从而应对瞬时的流量峰值。同时,Kubernetes 的自动扩展功能可以根据资源的使用情况自动调整服务的实例数量,确保系统在负载变化时能够灵活响应。

  • 缓存与 CDN:在高并发访问场景下,合理使用缓存(如Redis、Memcached)和 CDN 可以显著减轻后端的压力,提升系统的响应速度。缓存机制不仅加快了数据的读写,还减少了数据库的压力。

  • 技术栈的性能和扩展性:技术选型中的语言、框架和数据库等技术栈的扩展性直接决定了生产系统的性能瓶颈。例如,选择支持大规模并发请求的技术栈(如 Node.js、Go、Java 中的 Netty 框架等)可以显著提升系统在高负载下的表现。同时,选择可扩展的数据库技术(如 NoSQL 数据库、分布式数据库)可以确保系统在面对海量数据时依然能够快速响应。当确实存在性能问题时,换一种技术栈可能是一种比较彻底的解决问题的思路。

  • 性能监控与优化:生产规模的管理离不开实时性能监控。通过监控工具(如Prometheus、Grafana)监控系统的关键性能指标(如CPU、内存、带宽、响应时间等),并通过自动化告警机制及时发现并解决瓶颈问题,确保系统的稳定性和高效性。

  • 云计算与弹性扩展:云平台提供的弹性扩展能力是生产规模扩展的重要技术基础。通过云服务(如阿里云、腾讯云、AWS、Azure、Google Cloud)提供的按需扩展资源,生产系统可以根据流量动态调整计算资源、存储资源和网络带宽,确保系统在高并发和高负载下保持稳定。

基础设施扩展能力和性能优化及监控直接影响生产系统的弹性和可扩展性。合理的选型能够为生产系统提供未来业务增长所需的技术保障。

2.1.3 自动化与运维能力

生产规模的扩展离不开自动化运维能力的支持。自动化工具链(如 CI/CD、自动化测试、基础设施即代码)是保障生产系统在扩展过程中保持高效运作的重要手段。

  • 持续集成与持续交付 (CI/CD) :在生产环境中,频繁的更新和部署可能会带来较高的风险。通过CI/CD工具链,生产系统的更新、测试和部署可以自动化完成,从而减少人工操作带来的错误和延迟。CI/CD工具确保在生产规模扩展的过程中,系统的更新频率不会影响其稳定运行。

  • 自动化测试与监控:在生产规模扩展时,系统的复杂性和负载增加会带来更多的不确定性。通过自动化测试,生产系统可以在每次更新前进行回归测试和性能测试,确保系统在发布新功能时不会出现性能瓶颈或不可预见的错误。同时,通过监控工具(如Prometheus、Grafana),可以实时监控生产系统的性能指标,提前发现并解决潜在的性能问题。

  • 自动化扩展与容灾能力:通过基础设施自动化(如 Terraform、Ansible),生产系统在面对突发流量时可以自动扩展资源,并在发生故障时进行自动化恢复。这种技术规模中的自动化能力,是生产系统在高负载或故障环境下能够保持高可用性的关键。

  • 蓝绿部署和金丝雀发布:在大规模生产环境下,通过蓝绿部署和金丝雀发布,可以减小新功能或修复补丁上线时的风险,确保在问题发生时能够快速回滚。其实就是灰度发布,或者说要严格地执行灰度发布。

自动化能力不仅提高了生产系统的运维效率,还在生产规模扩展时提供了韧性和容错能力。

2.1.4 技术债务管理与可维护性

随着生产规模的扩展,技术债务的管理变得尤为重要。技术债务的管理不当会直接影响生产系统的性能和稳定性。技术规模中的技术债务管理策略需要融入生产规模的规划中,以确保系统在扩展过程中不会因为技术债务的积累而出现故障或性能下降。

  • 定期重构与优化:随着系统的不断扩展,代码复杂度和技术债务不可避免地会增加。通过定期的代码重构和性能优化,可以减少技术债务的积累,确保系统在生产环境中的稳定性。例如,定期优化数据库查询或重构基础代码模块,可以避免随着业务增长而出现的性能瓶颈。

  • 技术债务的监控与清理:通过技术债务监控工具,团队可以定期评估系统中的技术债务,并规划技术债务的偿还时间。特别是在生产系统扩展时,及时清理技术债务能够大幅减少系统的不可预测性,确保生产系统的可维护性。

更多技术债务的内容可以参考之前写的这篇文章:架构师必备:技术债务的识别、管理与解决之道

2.2 管理开发规模

开发规模指的是随着项目复杂度、代码库、开发团队人数的增加,如何有效管理开发流程、代码库和团队协作。包括以下几个部分:

2.2.1 代码库与模块化管理

随着项目的规模扩大,代码库的复杂度也随之增加。为了保持代码库的可维护性和可扩展性,合理的技术架构设计和技术栈选型至关重要。

  • 模块化与组件化:模块化设计(例如微服务架构)能帮助团队将系统拆分为多个独立的模块或服务,减少耦合性,并允许团队并行开发。合理的模块化设计不仅可以简化代码管理,还能减少不同团队之间的依赖,提升开发效率。

  • 技术栈的扩展性:技术栈的选择对开发规模的扩展至关重要。选用成熟、可扩展的技术栈(如Kubernetes、容器化、云原生技术)可以帮助团队更好地应对复杂的开发需求。技术栈选型不仅影响系统的运行能力,还影响团队的学习曲线、代码质量和开发速度。

  • 接口设计与抽象:合理的接口抽象能够减少模块之间的依赖。通过面向接口编程,团队可以在不破坏项目整体架构的情况下,灵活地扩展或替换某些模块。这种设计使得开发团队在面对复杂业务时,能够保持系统的灵活性和可维护性。

2.2.2 开发流程与自动化

随着团队人数的增加和代码库的扩展,开发流程的复杂性也随之增加。为了提升开发效率,技术规模中的基础设施扩展性和自动化能力是开发流程中的重要组成部分。

  • 持续集成与持续交付 (CI/CD) :自动化工具链是开发规模扩展中的关键要素。通过自动化测试、构建、部署流程,开发团队能够更频繁地发布代码,减少人为操作的风险。技术规模中的自动化工具(如Jenkins、GitLab CI、CircleCI,各公有云的云效产品)对开发效率的提升至关重要。

  • 代码评审与规范:制定统一的代码规范,确保团队成员的代码风格一致,避免“代码腐化”为难以维护的“意大利面条式代码”。通过代码评审(Code Review),团队可以发现潜在问题,提升代码的整体质量和可维护性。

  • 自动化测试:技术规模扩展中的自动化程度直接影响开发团队的效率。通过引入单元测试、集成测试、端到端测试,团队可以在不断扩展的代码库中保持代码质量,并快速识别回归错误。

  • 技术债务管理与重构计划:随着开发规模的扩大,技术债务的管理变得尤为重要。技术债务的积累会降低开发效率,增加维护成本。因此,定期的技术债务清理和代码重构计划是开发流程管理中的必要步骤。通过技术规模中的架构优化和代码重构,团队可以确保系统在业务增长时依然保持可维护性。

2.2.3 团队协作与知识管理

开发规模不仅仅依赖于技术架构和工具链的管理,还需要通过良好的协作机制和知识管理确保团队的高效运作。技术规模中的技术栈选型和架构设计也会影响团队的协作方式。

  • 知识共享与文档化:在开发规模扩展的过程中,技术栈的复杂性增加,团队成员需要通过高效的知识管理平台(如Confluence、Notion)来共享与管理技术文档。特别是当团队采用复杂的技术架构时(如微服务或分布式架构),通过文档化来规范开发流程和技术决策,可以减少沟通成本,提升协作效率。

  • 技术栈选择对协作的影响:选择合适的技术栈不仅影响系统的技术规模,也会影响团队的协作方式。例如,采用微服务架构可以让不同团队独立开发、部署自己的服务,减少团队之间的依赖。而采用更紧耦合的单体架构则需要更多的沟通与协调。因此,技术栈的选择在开发规模扩展中起到至关重要的作用。

2.2.4 选择合适的开发模型

开发模型是帮助团队组织开发流程、管理代码质量和发布节奏的框架。在不同的开发规模下,开发模型需要根据技术规模中涉及的技术栈、架构设计和自动化能力进行调整。

在开发规模扩展的过程中,技术栈和架构设计往往决定了开发模型的选择。例如:

  • 微服务架构与敏捷开发模型:微服务架构鼓励独立发布和独立开发,因此更适合敏捷开发模式。在这种模式下,技术团队可以迭代地发布小的功能模块,并通过自动化测试和持续集成工具确保代码质量。微服务架构的技术规模管理要求开发模型灵活且高效,以适应快速变化的业务需求。

  • 单体架构与瀑布模型:对于采用单体架构的系统,开发模型往往倾向于传统的瀑布模型或迭代开发模型。由于单体架构的耦合性较强,系统的发布和开发需要更为慎重,开发模型在这种情况下会更注重前期设计、集成测试和代码审核。

3 小结

管理规模的扩展不仅仅是对技术的挑战,更是对一个企业工程化与系统化能力的考验。通过清晰的架构设计、自动化工具的引入、规范化的流程和有效的团队协作机制,企业可以在规模扩张的同时保持研发效能和系统的稳定性。

这不仅要求架构师从技术角度进行弹性设计,还需要研发管理者从整体角度系统化地规划团队协作和流程优化。规模扩展的成功,依赖于工具、流程、架构和团队的有机结合与协同运作。只有通过持续的工程化改进和系统化的管理方法,企业才能在面对规模扩展时从容应对,并建立起长久的竞争优势。

规模的扩展并不可怕,真正的挑战在于能否通过合理的手段,保证系统和团队在快速变化的环境中依然具备强大而灵活的应对能力。

正如一座高楼,只有在扎实的地基之上,才能随风而屹立不倒。在研发管理的世界里,规模的管理就是那座高楼的地基。通过科学的规模管理,企业不仅能够应对当前的增长,更能够为未来的持续创新打下坚实的基础。

最后再次推荐一下 cursor 编辑器,写起来代码来真的很 6。

以上。