Pichai 在 Q2 财报会上说了一句话,整个云计算行业都听懂了:TPU 先紧着 AGI 用
Pichai 在 Q2 财报会上说了一句话整个云计算行业都听懂了TPU 先紧着 AGI 用事情发生在北京时间 7 月 27 日凌晨的 Alphabet 第二季度财报电话会议上。GoldmanSachs分析师EricSheridan提了一个听起来很常规的问题Google在AI算力上的资本支出在大幅增长但云计算客户对TPU的需求也在同步飙升。Google怎么在自家研发和外部客户之间分配这些宝贵的算力资源这个问题放在几年前几乎不成立。那时的云厂商就是卖算力的——你出钱我出货供需关系决定价格。但2026年的Google已经不是纯粹的基础设施提供商了。它同时是AI模型的研发者、AI芯片的设计者、云服务提供商、以及AGI的追逐者。这四重身份在算力分配上天然冲突。Pichai 的回答只有一句话——如果你做 AI 基础设施决策这句话值得反复读几遍。In terms of allocating our TPUs, our first priority is making sure we are allocating what we need to compete at the frontier in terms of AGI development.Pichai用了一个词——frontier。他说的是在AGI前沿竞争必须的算力不是日常运营不是合规需求是前沿。这个措辞进一步确认了Google的AGI优先级是动态的如果前沿竞争加剧分配给内部的份额可以进一步上调。没有一个分析师追问这个细节但这可能是整场电话会里最重要的隐含信息。翻译过来就是TPU分配的第一优先级不是云客户的商业合同不是短期收入最大化而是保证Google自己在AGI前沿竞争所需的算力。剩下的才轮到外部客户。这句话不是临时发挥的。这是一场面向华尔街分析师的正式财报电话会议每个字都有法律含义。Pichai在这个场合公开说出AGI优先于商业收入说明Google内部已经把这个原则写进了资源分配决策框架。一个 82% 增长的云业务为什么在 Google 内部不是第一优先级先看几个让人坐直的数字。GoogleCloud本季度收入247.5亿美元同比增长82%。利润88亿美元同比增长214%。季度backlog——客户已签约但尚未消耗的算力需求——累积到5140亿美元。这三个数字任何一个放在上市公司财报里都是值得单独开一场电话会的利好。三个同时出现在正常情况下应该让云业务成为全公司的绝对优先事项。但Pichai的回答恰恰相反。即使在云业务增长如此强劲的背景下算力分配的第一顺位仍然是AGI研发。这是反常的也是值得深挖的。有两种可能的解释。第一种是Google内部对AGI的判断已经非常明确——管理层认为AGI的实现时间窗口就在未来几年现在省的算力等于未来丢的市场。第二种是GoogleCloud的TPU需求增长确实遇到了物理瓶颈管理层在提前管理市场预期告诉大家别指望无限量的TPU供应。我个人倾向于第一种。原因是Pichai用了AGI这个词而不是AIresearch或者foundationmodel。这个措辞选择是有意为之的。AGI这个词在财报会上是有风险的。它不像机器学或大模型那样已经有了清晰的市场认知和可衡量的里程碑。AGI还是一个没有统一定义、不知道什么时候能实现、甚至不确定能不能实现的概念。一个上市公司CEO在财报会上用这个词来指导算力分配要么是极度自信要么是被内部研发进度推着走。Bernstein的分析师MarkShmulik显然不满足于第一个回答。他紧跟着追问了一个更具体的问题搜索、云、模型训练这三块算力到底怎么分有没有一个明确的优先级排序Pichai在这个追问下画出了更清晰的框架。第一层AGI前沿研发不设上限。这是全公司算力分配的优先基线所有其他需求都在这条基线之上叠加。第二层核心产品的算力保障包括搜索、YouTube、Cloud的推理部署。注意这里他特意提到了VertexAI和GeminiEnterprise——Google云上跑推理的客户是有保障的。第三层对外出租的训练算力。这部分的需求满足程度取决于第一层和第二层之后还剩多少。这个排序本身就是一份战略宣言。为了理解这个排序的真正含义可以做一组对比。如果Google把这三层的优先级反过来——云客户第一、产品第二、AGI第三——那么GoogleCloud的短期收入可能会更高因为训练算力比推理算力更贵、消耗量更大、客户付费意愿更强。但Google没有这么做。因为管理层判断AGI的长期价值远超云训练的短期收入。这不是一个关于效率的决策而是一个关于方向的决策。同一场财报会上Google还宣布了另外几个值得关注的数据。搜索广告收入同比增长14%YouTube广告收入增长20%OtherBets包括Waymo收入增长43%。整体收入超过1,000亿美元自由现金流超过200亿美元。在这种财务健康度下牺牲短期云收入来押注AGI是一个完全可以承受的决策。Google有这个底气。有一个数据点特别值得放大。Q2的整体资本支出达到175亿美元其中绝大部分流向AI基础设施。这说明Google的算力策略不是总量紧张下的分配焦虑而是一个主动的战略选择——他们在同时做两件事大幅增加算力总供给同时明确内部优先于外部的分配原则。这不是因为不够分而是想好怎么分了。为什么偏偏是现在Google 的 AGI 叙事正在加速要理解 Pichai 这句话的真正分量需要回顾一下 Google 在 AGI 问题上过去几年的表态节奏。2023年到2024年Google高管在公开场合几乎不提AGI这个词。DeepMind的论文里偶尔会出现但Pichai本人的口径一直是AIresponsibly和helpfulAI。AGI被视为一个过于遥远、也过于敏感的概念不适合在投资者沟通中讨论。2025年开始出现变化。Gemini系列模型的快速迭代让Google的技术自信回升。DeepMind和GoogleBrain的合并效应开始显现。Pichai开始在财报会上提及frontierAIcapabilities这样的表述但仍然避免使用AGI这个词。2026年——就是现在——发生了变化。GoogleI/O上Pichai公开宣布AgentEra的到来。Gemini3.6Flash、Gemini3.1Pro、TPUv5系列产品密集发布。然后在Q2财报会上他直接用了AGI这个词并且把它作为算力分配的顶层原则。这个节奏不是巧合。它反映的是Google内部对AGI技术成熟度的评估正在加速。如果DeepMind的团队跟CEO说再给我们两倍算力我们有信心在X年内实现Y里程碑那CEO在财报会上说TPU优先给AGI就是一个合理的决策。我们不知道Google内部看到了什么。但从公开信号来看他们看到的比我们想象的更具体。几个值得关注的线索。第一DeepMind的Gemma系列研究模型迭代速度在加快从几个月一个版本缩短到几周。第二Google在Agent能力上的投入明显加大——从Antigravity2.0到GeminiSparkGoogle今年在Agent产品上的发布密度超过了前面三年的总和。第三Pichai在I/O上提到的AgentEra不是一个营销话术Google内部已经围绕Agent范式重组了多个产品团队。这三条线索指向同一个方向Google相信AI的下一个能力跃迁来自于Agent范式的成熟而AGI是这个范式演化的自然终点。超大规模云厂商的算力悖论你既是卖算力的又是用算力的Pichai的这个表态之所以引发关注是因为它捅破了一层所有超大规模云厂商都在面临但不愿意公开讨论的窗户纸。这层窗户纸是这样子的。第一层矛盾云厂商的AI芯片产能是有限的。不管是Google的TPU、AWS的Trainium、还是Microsoft的Maia都需要在自研、晶圆代工、封装、测试几个环节之间取得平衡。在产能爬坡期每个季度能拿到的芯片数量是确定的。这个蛋糕不管怎么切总量就那么多。第二层矛盾云厂商同时也是AI模型的研发者。Google有GeminiAWS有AmazonQ和TitanMicrosoft有MAI系列。这些模型团队对算力的需求是给我尽可能多——他们没有天花板因为更大规模的集群意味着更快的实验迭代。第三层矛盾外部客户对AI算力的需求也在爆炸式增长。OpenAI在租Microsoft的算力Anthropic在租Google的算力数以万计的创业公司在租三家云厂商的GPU。这些客户合同中往往有算力保障条款。这三层矛盾在同一家公司的算力分配决策中碰撞结果就是谁最优先谁第二、第三不是一个技术问题而是一个战略选择。Pichai的选择清晰而且诚实AGI研发第一产品推理第二客户训练第三。没有说出来的部分是客户推理算力的SLA会得到尊重但训练算力——尤其是大规模预训练集群——会越来越倾向于内部使用。这不是 Google 独有的问题。AWS 和 Microsoft 面临着完全相同的矛盾只是他们的答案可能不同。AWS的策略是偏向外部的。因为AWS的核心商业模式就是卖基础设施如果客户不能在AWS上训模型他们会直接转向其他云。所以AWS在Trainium的分配上大概率会倾向客户而不是内部模型团队。Microsoft的策略是混合式的。Azure既有OpenAI的独占训练集群也有面向一般客户的GPU租赁。Microsoft的自研MAI模型也在快速迭代据TheInformation报道MAI-Code-1-Flash只有5B参数但在代码场景已经逼近ClaudeHaiku4.5。这意味着Microsoft内部对训练算力的需求也在快速膨胀。三家的策略差异意味着同一个趋势在云上训最大模型这件事正在从通用商品变成战略资源。你从不同的云厂商能租到的训练算力额度、型号和价格是不一样的而且这种差异只会越来越大。同一个战略推演也适用于开发者选择Agent框架时的决策。如果你依赖Google的GeminiAPI做Agent编排你需要知道Google的算力分配优先级意味着Gemini的底层模型更新节奏可能比其他平台的预期慢。不是Gemini不好而是Google把最先进的芯片优先给AGI研发而不是推理服务。5140 亿 backlog 和 TPU 优先的内在对冲增量够大就不需要存量博弈回到Google的数据。82%的云收入增长和5140亿的backlog听起来和TPU优先给内部用是矛盾的。如果算力真的那么紧张云收入怎么可能还有82%的增长答案是增量。整个AI算力市场在2026年的年化增长率超过60%。这意味着每一年蛋糕变大60%以上而不是在存量蛋糕里重新分。Google的策略是在增量中做优先级的排序而不是在存量中抢份额。举个例子假设Google2025年Q2有100万TPU小时其中60万小时给了内部40万小时给了外部客户。到了2026年Q2TPU总可用小时增长到了170万70%增长。即使内部需求也增长了——从60万涨到100万——外部客户可用的小时仍然从40万涨到了70万。两边都在增长只是内部增长得更快。这就是Google能同时做到TPU优先给内部和云收入增长82%的原因。不是因为他们牺牲了客户而是因为增量本身大到足以同时满足两边的增长需求。Pichai说GoogleCloud的重点是servingmodelsinVertexandGeminiEnterprise。这画了一条清晰的分界线云计算TPU优先给推理和模型部署场景训练和前沿研发由内部保留。这个分工从技术角度看也是合理的。推理负载是稳定的、可预测的、适合做SLA承诺的。客户愿意为推理的稳定性付溢价。而训练负载是高波动、高消耗、适合内部统一调度的。Google把推理算力卖给云客户把训练算力留在自己手里——两边都发挥了自己的比较优势。对开发者的六个实际影响如果你在用GoogleCloud部署AI应用短期内不会有明显变化。VertexAI和GeminiAPI的推理服务正常运营Google明确说了推理算力是Cloud的分配重点。但以下几个趋势值得关注。第一TPU型号更新节奏可能放缓。最新的TPUv5或v5e如果大部分被内部AGI研发消耗云客户能租到的可能以旧型号为主。对于推理场景来说这不是致命问题——TPUv4甚至v3在多数推理任务上仍然有竞争力——但如果你需要最新芯片做低延迟优化需要留意可用性。第二训练算力的租赁竞争会加剧。如果你的创业公司需要大量TPU来做模型预训练或大规模微调GoogleCloud可能不是最优选择。AWS的训练算力态度更开放Azure通过OpenAI合作关系也有丰富的训练集群。Google在训练算力供应上会越来越保守。第三NVIDIAGPU不受影响。Google的TPU优先政策只影响TPU——自研芯片。GoogleCloud上的NVIDIAGPUH100、H200、B200不受这个优先级排序的约束。如果你的训练负载跑在NVIDIA生态上Google的这个战略调整对你不构成影响。第四推理成本可能在中期上升。如果外部客户能获取的TPU以旧型号为主相同推理负载需要的计算时间会更长或者需要更多芯片并行为代价。这会推高推理的计费成本。建议密切跟踪GoogleCloudTPU的定价变化和型号更新公告。第五多云策略的重要性在上升。当不同云厂商在训练算力供应上出现实质性差异时绑定单一云厂商的风险在增加。如果你的训练规模在百亿参数以上建议至少在两家云厂商上有预留算力并定期测试迁移成本。第六AGI期权价值。长期来看如果Google在AGI上取得了实质性突破——哪怕是阶段性突破——现在的算力预留可能是一个极具前瞻性的决策。如果AGI真的在几年内以某种形式到来拥有最先进AGI模型的公司的估值远远超过一个季度几十亿美元的云收入。这件事的本质就是Google在用云业务的当期利润去博一个AGI的远期期权。这个期权是否值得取决于你对AGI时间表的判断。成本模型算力分配的财务逻辑最后用一个量化的视角来看这个问题。我写了一个简单到粗暴的 Python 脚本模拟算力分配的核心经济逻辑。def simulate_tpu_allocation( total_hours: int 1_000_000, internal_share: float 0.60, external_price: float 2.0, internal_roi: float 5.0, ) - dict: 模拟 TPU 算力分配的经济价值。 Parameters: - total_hours: 总可用 TPU 小时数 - internal_share: 分配给内部的比例0.0 ~ 1.0 - external_price: 对外销售每小时价格美元 - internal_roi: 内部研发每小时产生的价值估值美元 Returns: - 分配方案的经济效益对比 internal_hours total_hours * internal_share external_hours total_hours * (1 - internal_share) external_revenue external_hours * external_price internal_value internal_hours * internal_roi total_value external_revenue internal_value return { internal_hours: internal_hours, external_hours: external_hours, external_revenue: external_revenue, internal_value: internal_value, total_value: total_value, external_rev_share: external_revenue / total_value, } # 默认参数模拟 base simulate_tpu_allocation() for k, v in base.items(): print(f{k}: {v:,.0f} if isinstance(v, (int, float)) else f{k}: {v}) # 灵敏度测试内部 ROI 变化对分配的影响 print(\n--- 灵敏度分析 ---) for roi in [2.0, 5.0, 10.0, 20.0]: result simulate_tpu_allocation(internal_roiroi) print( f内部 ROI ${roi:.0f}/h → f外部收入 ${result[external_revenue]:,.0f}, f总价值 ${result[total_value]:,.0f}, f外部占比 {result[external_rev_share]:.0%} )脚本的核心参数是internal_roi——Google内部认为AGI研发每小时能带来多少价值。这个价值不是直接的收入而是技术领先优势、人才吸引力、未来产品竞争力的综合估值。如果Google认为AGI研发每小时能创造5美元的综合价值而对外销售价格是2美元每小时那么把60%算力分配给内部就是理性的。即使外部收入看起来更高内部价值估算拉平了差距。灵敏度分析显示当内部ROI达到10美元每小时时最优分配会倾斜到80%内部、20%外部。当内部ROI只有2美元每小时时外部销售更划算。Pichai的公开表态暗示Google内部对AGIROI的估值至少在5美元以上。这个模型极度简化——没有考虑合同约束、客户留存、品牌影响等因素——但它能说明核心机制只要 Google 对内部 AGI 研发的预期价值足够高优先给自己用 就是一个理性的财务决策。算力竞争正在进入第三阶段回看过去几年AI算力的演变可以分为三个阶段。第一阶段2022-2024算力荒。ChatGPT横空出世后整个行业突然发现GPU不够用了。训练一个GPT-4级别的模型需要数千张GPU跑几个月。这个阶段的特征是大家抢着买芯片谁买到谁就有优势。第二阶段2024-2025算力基建化。NVIDIA的产能扩张、各大云厂商自研芯片的量产、以及推理优化的成熟让算力的绝对供应大幅增加。这个阶段的特征是芯片供给不再是最紧的瓶颈但高质量算力新一代GPU/TPU仍然稀缺。第三阶段2026-算力战略化。我们正在进入的阶段。算力的绝对供给继续增长但分配方式开始被战略优先级重塑。云厂商从算力销售商变成算力使用者和销售商的双重身份这个转变改变了一切。和前面两个阶段不同算力战略化阶段的问题不能靠建厂或供应链管理来解决。芯片短缺可以通过增加投资、和晶圆代工厂签订长期协议来缓解。高性能GPU排产周期长的问题可以通过预付款锁定产能来应对。但战略分配优先权是商业竞争的内生结果——云厂商首先是一个追求自身利益最大化的商业实体其次才是一个算力提供商。市场机制不会纠正这个偏差因为它本身就是市场在发挥作用。这对AI创业生态有一个更深远的影响。最前沿的训练算力可能会越来越难从云厂商公开获得。前沿模型的训练可能更多地转向自建算力、专业算力租赁公司、甚至通过主权算力项目来获取。算力分配透明度会成为企业选择云厂商的新考量维度——不只是一个技术指标而是一个战略评估维度。可以做一个具体的推演。假设2027年出现了一个新的开源模型项目需要1万张TPUv5e训练30天。如果这个项目去找GoogleCloud租算力Google会不会接这个订单按照Pichai现在的优先级框架答案很可能是不接——因为AGI研发优先这些TPU首先要满足内部需求。但如果这个项目去找AWS呢AWS没有自己的前沿模型生态Titan系列的竞争力远不如Gemini所以AWS大概率会接。这个差异意味着未来的开源前沿模型会更倾向于诞生在AWS或第三方算力平台上而不是GoogleCloud上。这不是猜测而是Pichai公开表态的直接推论。当一家云厂商公开说内部研发优先于客户训练那大型训练负载就会流向不说这句话的云厂商。市场会自我调节但调节的结果不是每家云厂商的算力供应变得均等而是不同类型的训练负载会聚集到不同的云厂商上。这是一个更加碎片化、也更容易形成锁定效应的算力市场。今天Google公开说了AGI优先明天AWS或Microsoft可能会在某个分析师会议上做类似的表态。当三家都这样想的时候在云上训最大模型这个叙事就需要重新审视了。回到Pichai那句原话。他说的是competeatthefrontierintermsofAGIdevelopment。这里的compete是一个很有意思的用词——他对标的不只是OpenAI或Anthropic而是整个前沿AGI的发展进程。这个视角本身就说清楚了为什么TPU优先分配是必要的。从2023年AI是这一生最重要的技术到2026年TPU优先给AGI——Google的战略措辞在变窄但承诺在变深。以前是泛泛的AI优先现在是具体的AGI优先算力跟上。这种从口号到资源分配硬约束的变化比任何PR通稿都更有说服力。值不值得赌三到五年后见分晓。但至少 Pichai 把牌摊在了桌面上——这是你作为开发者选择云厂商时需要考虑的因素。

相关新闻

AI 自动化任务工具 OpenClaw 实操分享 本地环境快速搭建方案(含安装包)

AI 自动化任务工具 OpenClaw 实操分享 本地环境快速搭建方案(含安装包)

Windows 一键部署 OpenClaw 实操指南|快速搭建本地 AI 智能体,简化环境配置 核心亮点:零代码入门|可视化交互界面|自动配置运行环境|内置全套依赖组件|配备 28 万 Tokens 额度 Windows 部署包…

2026/10/15 18:41:40 阅读更多 →
如何彻底清理显卡驱动?Display Driver Uninstaller终极指南

如何彻底清理显卡驱动?Display Driver Uninstaller终极指南

如何彻底清理显卡驱动?Display Driver Uninstaller终极指南 【免费下载链接】display-drivers-uninstaller Display Driver Uninstaller (DDU) a driver removal utility / cleaner utility 项目地址: https://gitcode.com/gh_mirrors/di/display-drivers-uninsta…

2026/10/9 2:28:19 阅读更多 →
测试用例去重率90%:这个用AI“瘦身”的脚本,测试经理求着我要源码

测试用例去重率90%:这个用AI“瘦身”的脚本,测试经理求着我要源码

关注 霍格沃兹软件测试开发 公众号,回复「资料」, 领取人工智能测试开发技术合集 从5000条用例到500条,回归时间从6小时降到40分钟,我们到底怎么做到的? 大家好,我是某互联网公司质量效能团队的测试架构师,…

2026/9/25 22:10:39 阅读更多 →

最新新闻

SD Maid SE 去重器截图示例缩略图:素材来源、许可合规与渲染管线全解析

SD Maid SE 去重器截图示例缩略图:素材来源、许可合规与渲染管线全解析

移动开发文件管理 【免费下载链接】sdmaid-se SD Maid 2/SE is Androids most thorough cleaning tool. 项目地址: https://gitcode.com/gh_mirrors/sd/sdmaid-se 点击查看 免费下载 本指南以仓库内 SCREENSHOT_SAMPLE_IMAGES.md 为骨架,系统梳理 SD Ma…

2026/10/15 18:40:54 阅读更多 →
Murmure为什么总是翻译成英文?语音转文字10大常见问题与修复清单

Murmure为什么总是翻译成英文?语音转文字10大常见问题与修复清单

【免费下载链接】murmure Fully local, private and cross platform Speech-to-Text with LLM Post-processing 项目地址: https://gitcode.com/gh_mirrors/mu/murmure 点击查看 免费下载 Murmure 是一款完全本地运行、隐私优先的语音转文字(Speech-to-…

2026/10/15 18:40:54 阅读更多 →
5 分钟上手 Bonsai:Cargo 一行配置 + 你的第一个游戏 NPC 行为树实战

5 分钟上手 Bonsai:Cargo 一行配置 + 你的第一个游戏 NPC 行为树实战

【免费下载链接】bonsai Rust implementation of behavior trees for deterministic AI (now with Python bindings) 项目地址: https://gitcode.com/gh_mirrors/bonsai1/bonsai 点击查看 免费下载 Bonsai 是用 Rust 语言编写的行为树(Behavior Tree&am…

2026/10/15 18:40:54 阅读更多 →
XLPagerTabStrip Swift 2 到 Swift 3 迁移指南:6.0+ 全部 API 命名变化与源码级验证

XLPagerTabStrip Swift 2 到 Swift 3 迁移指南:6.0+ 全部 API 命名变化与源码级验证

UI组件移动开发 【免费下载链接】XLPagerTabStrip Android PagerTabStrip for iOS. 项目地址: https://gitcode.com/gh_mirrors/xl/XLPagerTabStrip 点击查看 免费下载 本文面向正在把基于 XLPagerTabStrip 的 iOS 项目从 Swift 2 升级到 Swift 3 的开发者&#xf…

2026/10/15 18:40:54 阅读更多 →
DS18B20单总线多点温度检测:原理、电路与调试

DS18B20单总线多点温度检测:原理、电路与调试

简介:一份基于AT89C51单片机与DS18B20数字温度传感器的多点温度检测系统设计资料,适合正在做课程设计、毕业设计或入门嵌入式测温应用的单片机学习者。方案采用两个DS18B20采集温度,通过1602LCD循环显示,系统测温范围约-30℃至99℃…

2026/10/15 18:40:54 阅读更多 →
Seata AT模式实战:Spring Cloud微服务分布式事务落地指南

Seata AT模式实战:Spring Cloud微服务分布式事务落地指南

1. 项目概述:为什么微服务里“转账失败”比你想象中更难防在某次线上压测中,一个看似简单的“用户A向用户B转账100元”操作,在分布式环境下连续触发了3起资金不一致事故:A账户扣款成功,B账户余额没加,但事务…

2026/10/15 18:39:53 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/15 16:18:54 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/15 13:48:15 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 0:14:36 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 9:49:14 阅读更多 →