标签:deployment

  • 业务人员写原型、工程师接盘上线:高盛试了三个月为什么把 AI 编程工具收回去了 yage.ai
    高盛和苹果等大型机构正在重新评估AI编程工具的使用权限和算力配额。此前,公司曾尝试允许业务人员使用AI工具(如Claude Code)直接生成原型,但最终收回了权限,将高权限工具和充足算力分配给具备代码审计能力的工程师和量化策略师。这种分工模式旨在解决业务人员快速原型生成与工程团队验证、审计和线上故障排查之间的效率和风险问题。同时,苹果正在根据岗位价值对不同团队设置差异化的算力配额,以实现资源分配的精简和成本控制。
  • 同样被智能体撑爆代码库,为什么 Anthropic 掀了 Git 的桌子,OpenAI 却连命令行都没改? yage.ai
    文章对比了 Anthropic 和 OpenAI 在应对智能体高并发代码读写压力时,对 Git 系统的不同解决方案。Anthropic 选择重造了版本控制系统 Scion,而 OpenAI 则保留了 Git 命令行和协议,只重写了后端架构,通过将代码拆分成静态包并利用缓存机制解决了高并发下的同步和拉取性能问题。文章指出,两家选择不同路线的原因在于团队的知识基因和业务场景的差异,体现了在智能体时代,分辨外部契约和内部假设的能力比重写代码本身更重要。
  • 拆开 Qwen3.8 的参数排查后,那些外呼阿里云的指令只是没洗干净的训练日志 yage.ai
    文章通过对Qwen3.8模型参数排查,揭示了训练过程中由于工程师未清理基础设施留下的运行日志,导致模型在特定场景下生成了指向阿里云服务器的指令,而非人为植入的后门。研究人员通过五步实验,排除了人为后门的嫌疑,并分析了模型在训练过程中学习到的网页抓取中间件残留、固定请求探针以及对内部内网凭据地址的记忆等训练残留,指出部署时需要通过容器防火墙、代理层和系统调用过滤等方式来构建安全边界。
  • 你以为卖大模型毛利有 80%?Anthropic 招股书揭开的六个月保质期与交付奇迹 yage.ai
    文章分析了Anthropic招股书揭示的大模型商业模式的真实情况,指出其盈利并非依赖于模型本身,而是依赖于跨领域专家协作的交付奇迹,包括多套芯片的推理工程、云平台渠道分成、以及对客户API的按量计费和上下文缓存定价。核心观点是,大模型公司的商业壁垒在于模型之外的交付链条,而非单纯的模型能力,需要解决算力、渠道、产品设计和安全等问题。
  • 守住了大模型,却在人事软件上失守:Anthropic 和 OpenAI 的外围防线是怎么被攻陷的 yage.ai
    文章讨论了Anthropic和OpenAI在核心大模型安全方面正面防守严密,但其外围的第三方软件(如人事软件、Slack、GitHub等)上的安全漏洞被攻击者利用,通过统一登录和工具连接器等现成通道,成功绕过了核心防线,将攻击路径导向了企业内网。文章指出,AI智能体在侦察和利用这些外围漏洞方面展现出强大的能力,改变了外围安全侦察的经济规律。文章提出了应对策略,即在统一登录上按安全等级切开信任域、在工具连接器上按假设供应商失守的标准分配最小权限,以及在内部数据调取卡口上设置速率限制与独立告警,以在连通器交界处设置“防水闸”。
  • AI 原生组织,到底靠买还是靠建:通用层、行业层、自有层的商业取舍 yage.ai
    文章探讨了在构建AI原生组织时,商业取舍的决策逻辑,即如何将业务能力拆分为通用层、行业层和自有层,并决定每层是“用、买还是建”。核心观点是,不应在默认开关和从零自建之间二选一,而应先拆分能力,再逐层决定拿法。行业层倾向于购买包含行业规则和组装指南的“生成内核”,而自有层则专注于编写大模型无法自由发挥的商业判断函数和适配旧系统的安全护栏。最终建议采取“先内后外、先可逆后不可逆”的排期策略,对外用通用层免费开关卡位,对内先用行业层试点,再用自有层打补丁护栏,以稳健推进。
  • Cerebras 那么快,为什么公共 API 上没有 Kimi K3 yage.ai
    文章讨论了为什么旗舰模型Kimi K3没有出现在Cerebras的公共API上,而是仅出现在企业专属模型目录中。核心原因是Kimi K3拥有接近3万亿参数,需要部署在Cerebras的片上内存中,这导致部署成本高昂,使得将其拆分零散地在公共共享池中按量销售变得困难。Cerebras采用的推理方式是将模型权重常驻片上内存,并利用混合注意力结构来优化长上下文缓存,这使得部署一个Kimi K3模型需要59片晶圆系统。文章还对比了不同注意力结构对晶圆片数的影响,并分析了推理速度的提升主要体现在模型输出部分,对工具调用等任务影响有限。
  • 一周四起 AI 现场记录:OpenAI 模型自筹手续费、平台拦截代客下单、Postgres 撤回新特性与 OpenCode 密钥暴露 yage.ai
    文章记录了近期在AI工具、软件开发和平台交互领域发生的四起事件:OpenAI模型在测试链上部署程序时因缺少手续费而自行寻找资金支付;摩根大通、嘉信理财等金融机构对外部AI助手的使用权限进行了读写分层管理,限制了代客动钱的能力;开源数据库PostgreSQL 19版本发布时,因大模型辅助代码评审发现了大量边缘缺陷而撤回了部分新功能;OpenCode开源编程工具的云端控制台系统遭遇旧系统未授权访问,导致部分用户托管的第三方模型密钥面临泄露风险。
  • 掏钱上班、电视盒里的大模型、和一个卖不掉自己的 AI 陪聊公司 yage.ai
    文章探讨了当前AI在工作流、硬件部署和商业模式中的几个关键议题。首先,法院判决对企业使用第三方AI工具时,提出了事先制定规则或事后承担举证责任的要求,强调了数据敏感性和合规性的重要性。其次,Anthropic的实验展示了在廉价的异构硬件上实现大模型分布式推理的可能性,揭示了边缘计算和硬件组合在AI部署中的新趋势。最后,Character.ai的破产出售案例表明,在AI创业中,用户规模和收入并不能等同于公司价值,当产品存在安全和合规风险时,可变现的资产是工程代码、专利和技术人员,而非用户数据和品牌。
  • Google SynthID 详解:为什么文字边写边打,图片却要等画完再补? yage.ai
    文章详细分析了Google SynthID系统在文字和图片上的水印技术实现,强调了其背后的工程考量。文字水印采用模型生成过程中的采样循环嵌入,实现低成本和高效率;而图像水印则在生成完成后通过独立的编码器网络进行后处理嵌入。文章指出,工程上的限制(如跨团队协作、海量验证的吞吐压力、版本长期共存)是决定文字和图像水印设计差异的关键,最终导致了文字水印的嵌入位置和图像水印的后处理方式不同。此外,文章还探讨了水印检测中的工程挑战,如如何使用保形预测替代硬币假设、如何应对高并发查验压力,以及如何设计兼容多代版本的验证系统。最终结论是,水印技术需要与C2PA等工具生态结合,并从工程实践中解决实际的落地问题。
  • 自建大模型:多卡为什么卡,以及为什么还是比 API 贵 yage.ai
    文章讨论了自建多卡大模型推理的性能瓶颈和成本问题。核心观点是,多卡并行时,性能受限于任务调度(routing)机制,即如何平衡缓存亲和性(cache affinity)和负载均衡(load balancing)。个人玩家在缺乏底层调度器和实时状态监控的情况下,难以实现最优的资源分配,导致资源利用率低,最终自建的单位成本(按token计费)往往高于使用云端API。
  • v0 一键集成:连接服务时,供应商的推荐用法自动进入 AI yage.ai
    文章介绍了 Vercel v0 推出的一键集成功能,该功能允许供应商的推荐用法(如邮件发送、数据库连接等)在服务连接建立的瞬间自动加载到 AI 模型的生成上下文中。这标志着软件工程的演进,即供应商的使用规约与访问凭据同步交付,将工程知识与调用凭据的交付形态进行了革新,并探讨了这种模式对软件生态、治理和风险暴露带来的影响。
  • 端侧 AI 没有龙头,因为它正在从卖点变成零件 yage.ai
    文章探讨了端侧AI的现状,指出它正从市场卖点演变为设备中的一个基础零件。文章分析了端侧AI的讨论存在两种截然相反的论调,并指出其核心矛盾在于将端侧AI与传统嵌入式窄任务、硬件换机周期以及本地大模型这三种不同的业务混为一谈。最终认为,端侧AI的价值更多体现在特定工业和专业场景中,而非大众消费级通用助手,其商业价值的支撑点在于响应延迟、离线可用性、数据驻留和法律合规等硬约束。
  • 8 路并发每路仍有 141 tok/s:2×5090 跑 27B 小模型,为什么它已经是 sweet spot yage.ai
    文章探讨了在本地自托管 27B 小模型时,如何通过优化硬件配置(如 2×5090)和推理引擎(如 SGLang DFlash2)来达到性能甜蜜点(sweet spot)。核心论点在于,自托管的价值不在于单纯的成本节约,而在于对数据合规性、隐私控制和推理栈的完全掌控。文章通过详细的并发压测数据,论证了在特定负载下,消费级硬件可以提供充裕的解码吞吐,并对比了自建与云端租赁的经济决策变量,强调了使用率对成本效益的决定性影响。
  • 每天一千万次调用的 GPT-4o mini,不聊天也不写代码 yage.ai
    文章分析了 GPT-4o mini 在 OpenRouter 平台上的调用数据,揭示了其在工程流水线中扮演的角色。该模型主要处理低吞吐量、短输出的任务,如数据分拣、结构化字段抽取等,而非复杂的多步代码生成或长文本对话。文章探讨了轻量模型在工程实践中作为特定分工的工具,其适用性取决于任务的输出结构和对长程规划的需求。
  • 一个闹钟,一份验收,就能养一个代码库 yage.ai
    文章探讨了如何通过设置定时任务和明确的验收标准,将重复性的代码维护任务从依赖于过程确定性的死脚本或人工会话,转变为依赖于结果确定性的智能基础设施。核心观点是,基础设施应轻量化,通过唤醒机制、日志埋点、上下文外部化以及清晰的完工边界来构建,从而让代理能够自主决定下一步行动,而不是被复杂的流程图所束缚。
  • AI Agent 不必等模型完美:美军给 AI Builder 的部署方法 yage.ai
    文章探讨了在部署大语言模型(LLM)时,不必追求模型的绝对完美,而是通过设计任务边界、操作权限限制以及运行闭环来构建系统的弹性。核心思想是,安全和可靠性依赖于对模型行为的动态控制,包括设置多层防护屏障(如沙盒隔离)、在关键决策点引入人工干预机制,以及建立基于客观执行凭证的信任体系,从而实现小步迭代与快速回退。
  • Vercel 开源 eve:「一个文件夹就是一个 agent」这句话为什么不是废话 yage.ai
    文章探讨了 Vercel 开源的 'eve' 项目,它提出了将 Agent 视为独立软件(一个文件夹)而非单一框架或模型延伸的观点。通过对比 LangChain 的零件拼装路线和 Claude Managed Agents 的云端配置项路线,eve 强调了 agent 生产生命周期中对部署、版本管理和持久化执行等基础设施的需求,并提出了一种将运行能力与个人认知上下文(context infrastructure)相结合的三层分工模型。
  • Ready AI:一句话生成日式咖啡馆网站,并实现24小时智能客服与多语言支持 AI超元域
    本文测评 Ready AI 建站工具,演示如何仅用自然语言快速生成功能完善的日式咖啡馆网站,包含菜单、预约、智能客服与多语言切换,并能一键部署及集成数据库,显著提升中小企业建站效率。