Models | The .NET Blog

Foundry 中的 Claude Opus 4.8 表明模型选择正在成为平台功能

Emiliano Montesdeoca — Mon, 15 Jun 2026 00:00:00 +0000

这篇文章是自动翻译的。要查看原文，请点击这里。

在某个时刻，模型可用性公告不再因为特定的模型而有趣。

它们之所以有趣，是因为它们强化了平台故事。

这就是我对 Claude Opus 4.8 登陆 Microsoft Foundry 的理解。

模型很重要，但更大的故事更重要

是的，Claude Opus 4.8 本身是一个重要的模型更新。

但我认为更有用的信号是，Foundry 继续在一个受管理的操作界面下扩展其严肃的模型选择。

这很重要，因为它为团队提供了更多空间来：

将模型与工作负载相匹配
平衡成本和能力
在模型质量或定价变化时保持灵活性
在一个地方保持治理和部署纪律

这是我更关心的部分。

为什么这对平台思维很重要

如果你的人工智能平台只有在一个模型供应商永远保持主导地位时才能良好运作，那么你就没有真正的可靠平台。

你有一个营销做得不错的依赖关系。

所以每当 Foundry 添加另一个严肃的模型选项时，有趣的问题不仅仅是"这个模型好吗？"

还有：

这是否增加了我的架构灵活性？
它是否减少了供应商锁定压力？
它是否使特定工作负载的路由更加现实？

这是模型可用性变得具有战略价值的水平。

我的观点

这更少地关于一个特定的模型里程碑，而更多地关于 Foundry 继续表现得像一个严肃的多模型平台。

这是更大的故事。

Foundry 越加强这个故事，它就越成为一个可信的地方，在那里团队可以操作模型选择，而不是仅仅对其做出反应。

原始文章：Claude Opus 4.8 现已在 Microsoft Foundry 中推出

Microsoft Foundry 2026 年 5 月：我真正会密切关注的更新

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

本文已自动翻译。原文请点击这里。

每月的平台汇总很容易很快变成功能堆叠。

所以 What’s New in Microsoft Foundry | May 2026 的简短版可以概括为：这个平台正在正好深入那些对真实 AI 系统最重要的领域。

我会关注的主线是：

基于 trace 的评估
更广泛的模型选择
更强的代理工具
更好的受管隔离和更高的成本可见性
通过 Foundry Local 持续推进本地 AI

这是一个信息密度很高的汇总，所以模式比数量更重要

原文里有很多单独的要点。

这没问题，但我不认为阅读这类文章的最佳方式是逐条看功能。

更好的问题是：平台究竟在明确强化什么方向？

而我的答案是：

Foundry 正在把自己在代理周边的运维层面做得更强，而不只是把模型目录做得更大。

这是一个非常好的信号。

最重要的主题是基于 trace 的评估

如果让我从整个汇总里选一个主题，那大概就是基于 trace 的评估。

为什么？因为它把评估故事从：

构建静态数据集
运行 benchmark
希望它能反映 production

变成了更现实的东西：

观察真实行为
评估真实 trace
从系统实际在做什么中学习

这对于 production AI 来说，是一个成熟得多的模型。

模型广度很重要，但前提是它仍然可运营

与 Grok、DeepSeek、Fireworks 和 reinforcement fine-tuning 相关的新增内容都有各自的价值。

但对我来说，更重要的不是又来了一个 model。

更重要的是，模型广度正在与以下内容结合：

运维可见性
评估工具
governance 表面
部署一致性

这正是防止模型生态变成混乱的关键。

Foundry Local 正在成为反复出现的战略信号

还有一点我不会忽略，那就是 Foundry Local 现在作为 Foundry 故事中一个认真部分出现得有多频繁。

这告诉我，Microsoft 不再把本地 AI 看作一个边缘实验。

它正在成为更大平台叙事的一部分：

隐私
设备本地推理
硬件可移植性
边缘部署
混合运维模型

这一点值得关注。

我的看法

细节很重要，但更大的模式更重要。

Foundry 仍在朝着这样一个平台前进：代理、评估、模型、本地 runtime 和 governance 可以更自然地连接起来。

这正是我最关心的方向。

而这篇汇总，比许多更小的单独公告，更容易让人一次性看清这个方向。

原文： What’s new in Microsoft Foundry | May 2026

AI 开发最难的部分已经不再是访问，而是把正确的模型运营好

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

本文已自动翻译。查看原文，请点击这里。

我们早就过了“只要能访问一个强大的模型就足够”的阶段。

这正是这份新的 Foundry 模型、成本与质量管理指南 抓住的重点。

真正的挑战现在是运营层面的：

为每个 workload 选择正确的模型
用自己的数据对它进行验证
管理延迟和支出
管理升级和回归风险

这正是严肃团队必须擅长的事情。

原文把问题定义得很准确

原文中的一句话非常好地概括了这种变化：

“如今构建 AI 系统最难的部分已经不再是获得一个有能力的模型。而是知道如何在真实应用的整个生命周期中选择、验证、优化并运营正确的模型。”

这就是完全正确的诊断。

太多团队仍然认为模型选择才是最主要的决定。

并不是。

模型运营才是更大的问题：

哪个 workload 用哪个模型？
质量如何验证？
什么样的成本结构是可接受的？
当新模型出现，或者旧模型开始漂移时，会发生什么？
如何在不破坏真实工作流的情况下测试变更？

这才是现在真正的工程工作。

为什么这篇 Foundry 内容有用

我喜欢这篇文章，因为它谈论 AI 系统的方式，正是有经验的平台工程师真正需要思考的方式。

不是“挑最聪明的模型然后继续”。

而是作为生活在各种权衡下的系统：

能力
延迟
成本
安全
治理
升级压力

这比只看 benchmark 的乐观主义有用得多。

最重要的转变是先看标准

原文建议在打开模型目录之前先定义成功标准。

我认为这是团队最应该养成的习惯之一。

如果先打开目录，你会锚定在声誉上。

如果先定义标准，你会锚定在 workload 的现实上。

这是一种更健康的流程。

因为在 benchmark 中获胜的模型，不一定就是在以下方面获胜的模型：

你的 prompts
你的延迟预算
你的成本 guardrails
你的治理要求

这种区别，正是成熟 AI engineering 的起点。

多模型故事正在变成真正的优势

另一个我喜欢的点，是它明确采用了 model-agnostic 的 framing。

文章把 Foundry રજૂ出来，不是作为单一模型的终点，而是作为一个跨越以下内容的 operational surface：

Microsoft 模型
合作伙伴模型
开源模型
后训练变体
routing 和 optimization 策略

这很重要，因为模型灵活性已经不再是奢侈品。它是风险管理的一部分。

如果质量变化、价格波动，或者 quota 紧张，团队就需要可选方案。

成本控制不是次要问题

文章把成本看作架构问题，这一点也很对。

这不是“以后再优化”的问题。

如果默认把每个任务都发给最重的模型，它在 demo 里可能表现很好，但在生产经济性面前会崩掉。

所以我认为关于以下内容的部分，比很多人想象的更重要：

routing
batching
caching
provisioned throughput
quota 管理

把成本纪律当作系统设计的一部分的团队，会比把它当作事后清理工作的团队更能长期发展。

我的看法

这篇 Foundry 内容有用，因为它谈论 AI 系统的方式，正是有经验的工程师真正需要去运营的方式。

不是 demo。不是一次性原型。也不是排行榜旅游。

而是面向 workloads、限制、权衡和持续变化的 operating systems。

我们需要继续把讨论提升到这个层次。

如果你正在构建生产级 AI 系统，这正是我希望团队尽早内化的 mindset。

原文链接： A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry