Models | The .NET Blog

Claude Opus 4.8 в Foundry — еще один признак того, что выбор модели становится функцией платформы

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

Эта статья была переведена автоматически. Чтобы прочитать оригинал, нажмите здесь.

В какой-то момент объявления о доступности моделей перестают быть интересными только из-за конкретной модели.

Они становятся интересными, потому что укрепляют историю платформы.

Вот как я интерпретирую приход Claude Opus 4.8 в Microsoft Foundry.

Модель имеет значение, но более крупная история имеет еще большее значение

Да, Claude Opus 4.8 — это важное обновление модели само по себе.

Но я думаю, что более полезный сигнал состоит в том, что Foundry продолжает расширять свой серьезный выбор моделей под одной управляемой рабочей поверхностью.

Это важно, потому что это дает командам больше возможностей для:

сопоставления моделей с рабочими нагрузками
балансирования стоимости и возможностей
сохранения гибкости при изменении качества или цены модели
сохранения управления и дисциплины развертывания в одном месте

Это то, о чем я забочусь больше.

Почему это важно для размышления о платформе

Если ваша платформа AI хорошо работает только тогда, когда один поставщик моделей остается доминирующим всегда, то у вас нет действительно устойчивой платформы.

У вас есть зависимость с хорошим маркетингом.

Итак, каждый раз, когда Foundry добавляет еще один серьезный вариант модели, интересный вопрос не просто «хороша ли эта модель?»

Это также:

увеличивает ли это мою архитектурную гибкость?
снижает ли это давление блокировки поставщика?
делает ли это маршрутизацию для конкретной рабочей нагрузки более реалистичной?

Это уровень, на котором доступность модели становится стратегически полезной.

Мой вывод

Это менее всего о одном конкретном этапе модели, а более о том, что Foundry продолжает вести себя как серьезная многомодельная платформа.

Это более крупная история.

И чем больше Foundry укрепляет эту историю, тем более убедительной она становится как место, где команды могут осуществлять выбор модели, а не просто реагировать на него.

Оригинальный пост: Claude Opus 4.8 is now available in Microsoft Foundry

Microsoft Foundry, май 2026: обновления, за которыми я бы действительно следил

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

Эта статья была автоматически переведена. Для оригинальной версии, нажмите здесь.

Ежемесячные обзоры платформы очень быстро могут превратиться в перегрузку функциями.

Поэтому вот краткая версия What’s New in Microsoft Foundry | May 2026: платформа углубляется именно в тех областях, которые важнее всего для реальных AI-систем.

Линии, за которыми я бы следил:

оценка на основе trace
более широкий выбор моделей
более сильные инструменты для агентов
лучшая управляемая изоляция и более высокая прозрачность затрат
продолжающийся импульс вокруг локального AI через Foundry Local

Это плотный обзор, поэтому паттерн важнее количества

В оригинальной статье много отдельных пунктов.

Это нормально, но я не думаю, что лучший способ читать такой пост — по функциям, одну за другой.

Лучший вопрос такой: какое направление платформа явно усиливает?

И я думаю, ответ такой:

Foundry становится сильнее в операционных слоях вокруг агентов, а не только в каталоге моделей.

Это очень хороший знак.

Самая важная тема — оценка на основе trace

Если бы мне пришлось выбрать одну тему из всего обзора, вероятно, это была бы оценка на основе trace.

Почему? Потому что она меняет историю оценки от:

построения статического набора данных
запуска benchmark
надежды, что он отражает production

к чему-то более реалистичному:

наблюдать реальное поведение
оценивать реальные trace
учиться на том, что система действительно делает

Это гораздо более зрелая модель для AI в production.

Ширина моделей важна, но только если она остаётся operable

Дополнения, связанные с Grok, DeepSeek, Fireworks и reinforcement fine-tuning, полезны по-своему.

Но для меня важнее не просто то, что появился ещё один model.

Важно, что ширина моделей сочетается с:

операционной видимостью
инструментами оценки
поверхностями governance
согласованностью deployment

Именно это не даёт экосистеме моделей превратиться в хаос.

Foundry Local становится повторяющимся стратегическим сигналом

Ещё одна вещь, которую я бы не игнорировал, — как часто Foundry Local теперь появляется как серьёзная часть истории Foundry.

Это говорит мне о том, что Microsoft больше не рассматривает локальный AI как побочный эксперимент.

Он становится частью более широкой платформенной истории:

конфиденциальность
локальный inference на устройстве
переносимость hardware
edge deployment
гибридные операционные модели

На это стоит обратить внимание.

Моё мнение

Детали важны, но общая картина важнее.

Foundry продолжает двигаться к платформе, где агенты, оценки, модели, локальные runtime и governance соединяются более естественно.

Именно это направление мне интереснее всего.

И этот обзор, больше чем многие более мелкие отдельные анонсы, делает это направление проще для восприятия в одном месте.

Оригинальная статья: What’s new in Microsoft Foundry | May 2026

Сложная часть разработки ИИ уже не в доступе. Она в том, чтобы хорошо работать с правильной моделью

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

Эта статья была автоматически переведена. Чтобы открыть оригинал, нажмите здесь.

Мы уже давно прошли этап, когда одного лишь доступа к мощной модели было достаточно.

Именно это новый гид Foundry по управлению моделями, стоимостью и качеством понимает правильно.

Настоящая задача теперь операционная:

выбирать правильную модель для каждой нагрузки
проверять её на собственных данных
управлять задержкой и расходами
контролировать обновления и риск регрессий

Именно в этом серьезные команды должны научиться быть хорошими.

Исходная статья правильно формулирует проблему

Одна фраза из оригинального поста очень точно передаёт этот сдвиг:

“Самая сложная часть построения AI-систем сегодня уже не в том, чтобы получить доступ к способной модели. Она в том, чтобы знать, как выбирать, проверять, оптимизировать и эксплуатировать правильную модель на всём жизненном цикле реального приложения.”

Это совершенно правильный диагноз.

Слишком многие команды до сих пор думают, что выбор модели — это главное решение.

Это не так.

Более крупная проблема — эксплуатация модели:

какая нагрузка получает какую модель?
как проверяется качество?
какая форма стоимости допустима?
что происходит, когда появляется новая модель или старая начинает дрейфовать?
как протестировать изменение, не ломая реальные workflow?

Вот где сейчас настоящая инженерная работа.

Почему этот материал Foundry полезен

Мне нравится эта статья, потому что она говорит об AI-системах так, как действительно приходится думать опытным платформенным инженерам.

Не как “выбери самую умную модель и двигайся дальше”.

А как о системах, живущих под компромиссами:

capability
latency
cost
safety
governance
давление обновлений

Это гораздо полезнее, чем оптимизм, основанный только на бенчмарках.

Самый важный сдвиг — сначала думать о критериях

В оригинальном посте рекомендуется определить критерии успеха до открытия каталога моделей.

Я думаю, что это одна из самых важных привычек, которые команды могут выработать.

Если сначала открыть каталог, вы якоритесь на репутации.

Если сначала определить критерии, вы якоритесь на реальности нагрузки.

Это более здоровый процесс.

Потому что модель, которая выигрывает бенчмарк, не обязательно выигрывает в:

ваших prompt’ах
вашем бюджете на latency
ваших cost guardrails
ваших требованиях к governance

Это различие и есть точка начала зрелой AI-инженерии.

История multi-model становится реальным преимуществом

Ещё одна вещь, которая мне нравится, — явно модель-агностичный подход.

Статья показывает Foundry не как цель для одной модели, а как операционную поверхность поверх:

моделей Microsoft
моделей партнёров
open-source моделей
post-trained вариантов
стратегий routing и optimization

Это важно, потому что гибкость моделей больше не роскошь. Это часть управления риском.

Если качество меняется, цены двигаются или квоты сжимаются, командам нужны варианты.

Контроль затрат — не второстепенная тема

Статья также права, когда рассматривает стоимость как архитектурную проблему.

Это не задача формата “потом оптимизируем”.

Если по умолчанию отправлять каждую задачу в самый тяжёлый model, в демо это может работать отлично, а в экономике production — развалиться.

Поэтому я считаю, что разделы о:

routing
batching
caching
provisioned throughput
управлении quota

важнее, чем может показаться многим.

Команды, которые воспринимают дисциплину затрат как часть системного дизайна, будут жить намного лучше, чем те, кто видит в ней позднюю уборку.

Моё мнение

Это полезный материал Foundry, потому что он говорит об AI-системах так, как их действительно приходится эксплуатировать опытным инженерам.

Не как о демо. Не как об одноразовых прототипах. И не как о туризме по лидербордам.

А как об операционных системах для нагрузок, ограничений, компромиссов и постоянных изменений.

Нам нужно продолжать поднимать разговор до этого уровня.

И если вы строите production AI systems, то именно такой mindset командам стоит усвоить как можно раньше.

Оригинальная публикация: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry