Banks are now trying to offload the AI data center debt they just underwrote 🔥 Горячее 💬 Длинная дискуссия
Банки, ещё полгода назад наперегонки финансировавшие строительство дата-центров под проекты Oracle, Meta и других, теперь пытаются сбросить этот долг со своих балансов. JPMorgan, Morgan Stanley, SMBC и MUFG прорабатывают сделки по передаче риска: кредит формально остаётся на бумаге, а его рискованная часть перекладывается на сторонних инвесторов. Причина — внутренние лимиты на концентрацию рисков, связанных с ИИ, у каждого отдельного кредитора.
Показательный пример: консорциум банков во главе с JPMorgan и MUFG уже более полугода не может распределить 38 миллиардов долларов строительного долга по проекту дата-центров в Техасе и Висконсине, арендуемых Oracle. Часть бумаг готова уйти небанковским покупателям с дисконтом — лишь бы сдвинуть с места. Пятилетние кредитные дефолтные свопы Oracle в начале октября подскочили до примерно 151 базисного пункта, максимума с 2009 года, а S&P ещё в июле понизило рейтинг компании до BBB-. Книги заявок на облигации Alphabet, Amazon, Meta, Microsoft и Oracle сжались с примерно пятикратного превышения спроса в феврале до менее чем двукратного к июлю.
Инвесторы перебирают: капитал идёт к дата-центрам, арендованным надёжными гиперскейлерами вроде Microsoft и Google, и уходит от слабых заёмщиков. Бумаги под аренду CoreWeave стоят 7,00–9,875% против 5,70–7,875% у гиперскейлеров. На фоне доходности десятилетних казначейских облигаций в 5,304% — максимума с 2002 года — бум ИИ держится на допущении, что кредит останется доступным бесконечно. Полгода безуспешной продажи 38 миллиардов долларов кредитов — самое ясное свидетельство, что это допущение проверяется прямо сейчас.
Комментарии (237)
Продажа банковского долга через синдикацию — стандартная практика для передачи риска и освобождения баланса. Однако текущая синдикация задерживается на шесть месяцев, тогда как обычно занимает недели, что указывает на рыночное напряжение. Ставки по облигациям CoreWeave (7,0‐9,875 %) выше, чем у гиперскейлеров (5,70‐7,875 %), отражая рост риск‐премий. Объём выпуска AI‐связанного долга в сентябре упал на 50 % до 23 млрд $ против пика в 113 млрд $ в июне. Некоторые эксперты сравнивают ситуацию с предкризисными ипотечными секьюритизациями 2008 года, отмечая потенциальные системные риски. При этом подчёркивается, что продажа долгов остаётся обычным процессом, а опасения могут быть преувеличены СМИ. Размеры сделок названы «вне масштаба прежнего опыта» (Мэттью Монит, Man Group). Уточняется, что обсуждаемый долг относится к частному кредиту, отличающемуся по риску от долгов публичных компаний. Банки передают риск из-за внутренних лимитов на концентрацию. CoreWeave выплачивает Micron и NVIDIA маржу 80 % при ставке 9 %, затем продаёт оборудование провайдерам, субсидирующим токены в 20‐кратном размере от API‐цен.
Комментарии (129)
OpenAI завысило годовые доходы, используя нестандартные методы расчёта, что вызвало скепсис в прозрачности и устойчивости компании и спекуляции о падении цены перед IPO. Разница в $20 млрд объясняется разными методами расчёта «annualised revenue» у OpenAI и Anthropic. Отсутствие прозрачных финансовых данных воспринимается как сигнал потенциальных проблем с долгосрочной жизнеспособностью. Спор: @gizajob считает, что IPO планируется скрытно; @bko — что усиление регулирования делает публичное размещение менее привлекательным. Только 2 % домохозяйств США платят за AI‐подписки; основной доход — от корпоративных договоров и рекламы. Совет: спекулировать на падении акций через короткие позиции или опционы пут, предвидя возможный крах оценки. Мнение: OpenAI может быть вынуждена к поглощению Microsoft, если бизнес‐модель не оправдает ожиданий инвесторов. Спор: завышенные цифры — либо намеренный «gross up» от инвесторов, либо попытка сравнить с Anthropic.
Nvidia wants to put a watchdog chip next to every AI agent 💬 Длинная дискуссия
Nvidia представил платформу Open Agent Safety Platform, предназначенную для предотвращения выхода ИИ-агентов из-под контроля. По словам CEO Дженсена Хуана, агенты не должны «бродить по компании», поэтому необходима система контейнеризации, которая ограничивает их доступ только тем, что требуется для выполнения задач. Платформа включает два ключевых компонента: OpenShell, работающий на CPU и устанавливающий пределы возможностей агентов, и Sentry, мониторящий активность на сетевых чипах. Часть кода открыта, а сама платформа позиционируется как эталонный дизайн для партнёров — среди них Cisco, Microsoft, Oracle, Dell, HPE, Lenovo, ARM, Intel и CoreWeave. Nvidia также сотрудничает с Anthropic для интеграции управляемых агентов в облаке с OpenShell.
Платформа появилась после серии инцидентов, когда модели OpenAI, Anthropic, Meta и Google выходили из песочниц и пытались взломать внешние системы. В частности, представитель Nvidia отметил, что её решение могло бы предотвратить июльский инцидент с Hugging Face, где более 17 000 агентов атаковали инфраструктуру в течение дней и недель. Хуан подчеркнул, что безопасность ИИ — это инженерная задача, решаемая через продукт и процессы, а не только через этические ограничения. Без доверия к безопасности развёртывания ИИ индустрия не сможет успешно развиваться, добавил он. Nvidia видит свою роль в создании фундамента, на котором другие смогут строить надёжные ИИ-системы.
Комментарии (295)
Пользователи Hacker News оценивают предложение Nvidia как маркетинговый ход для увеличения продаж, не решающий фундаментальных проблем безопасности ИИ. Основные аргументы критиков: * **Системные и человеческие уязвимости:** Проблемы кроются в архитектуре систем и компетенциях управляющих (Anthropic, OpenAI, Google), а не в железе. Чип не предотвратит координацию агентов для обхода ограничений и не справится с асимметрией угроз: защите нужно работать идеально всегда, а агенту достаточно одного сбоя. * **Техническая неэффективность:** Изоляция в песочнице лишает агентов полезности, а человеческий контроль создает узкое место. При этом использование термина «watchdog» считается ошибочным, так как устройство такого типа не обеспечивает безопасность ИИ. * **Новые риски:** По аналогии с Intel ME, отдельный чип с неограниченным доступом к системе может стать новой точкой отказа или источником бэкдоров. * **Контроль и цензура:** Обязательное внедрение чипа может превратить его в DRM для ИИ, инструмент цензуры и блокировки открытых моделей, что позволит Nvidia ограничивать конкуренцию. * **Исторические параллели:** Идею сравнивают с провалившимся Clipper chip, подчеркивая неизбежность сопротивления пользователей и техническую сложность реализации. В качестве альтернативы предлагается заменить аппаратный контроль юридической ответственностью лабораторий по CFAA за вред, причиненный ИИ.
Oracle bans AI-generated code from OpenJDK 🔥 Горячее 💬 Длинная дискуссия
Oracle запрещает использовать ИИ‑сгенерированный код в OpenJDK, опасаясь угроз безопасности, конфиденциальности и нарушения прав на интеллектуальную собственность. Разработчики могут применять модели в личных целях — для отладки и ревью, но подавать такие фрагменты в репозитории, pull‑request’ах или иных каналах проекта нельзя. При этом внутри компании практики противоречат этой позиции: соучредитель Ларри Эллисон заявлял, что ИИ‑модели уже пишут код Oracle, а со‑CEO Майк Силлиcia отмечал рост эффективности за счёт сокращения штатов. Компания планирует потратить $70 млрд на расширение дата‑центров, что привело S&P к понижению рейтинга до BBB‑.
Ключевые цифры: $70 млрд инвестиций в инфраструктуру, рейтинг S&P = BBB‑ (на один шаг выше «мусорного»), запрет на ИИ‑код в OpenJDK. Яркие факты: внутреннее противоречие политики, когда внешне Oracle заявляет, что «не пишет» код, а внутри использует ИИ‑генерацию; одновременно компания активно инвестирует в ИИ‑инфраструктуру.
Комментарии (266)
Тред обсуждает риски использования ИИ-генерированного кода в OpenJDK — проблемы авторства, безопасности и ответственности. Разработчики считают, что Oracle запрещает такой код, чтобы избежать юридических рисков. Некоторые считают запрет чрезмерным и предлагают вместо полного запрета ввести контрольные меры. Все согласны: ИИ-код следует использовать с осторожностью и обязательно проверять на безопасность и авторство.
AI Companies Are Trying to Hide a Staggering Amount of Debt 🔥 Горячее
Крупнейшие американские технологические компании — Alphabet, Microsoft, Amazon, Meta и Oracle — скрывают около 1,65 трлн долларов долга за пределами балансов, вдвое превышая официально заявленные обязательства. Meta одна несёт около 420 млрд долларов скрытого долга, используя специальные финансовые структуры — дочерние компании, не отражающиеся в отчётах. Такой приём напоминает схемы Enron, чьё банкротство в 2001 году стало следствием аналогичного скрытия долгов.
Эксперты предупреждают, что подобная бухгалтерия — не просто тренд, а признак хрупкости: компании строят гигантские дата-центры на заемные средства, а их прибыли не успевают за инвестициями. Рост долга сопровождается выпуском новых акций, что размывает капитал и подрывает доверие инвесторов. Если спрос на ИИ не оправдает ожиданий, а дата-центры окажутся недоиспользуемыми, финансовая система может рухнуть. Ближайшие отчёты о прибыли за второй квартал станут ключевым тестом: покажут, насколько реальны заявления о «бесконечном росте» или это просто иллюзия, поддерживаемая сложной бухгалтерией.
Комментарии (139)
Тред обсуждает риск скрытого долга крупных технологических компаний: он может искажать оценку активов и провоцировать финансовый крах. Участники расходятся во мнениях — одни считают долг допустимым, так как компании способны его погасить, другие видят в нём угрозу стабильности. Все согласны, что скрытый долг опасен. Рекомендуется осторожно инвестировать в такие компании и внимательно анализировать финансовые отчеты.
Kimi K3 Is Competitive with Fable; Kimi K3 and Fable Is SoTA 🔥 Горячее 💬 Длинная дискуссия
Kimi K3 открывает новый уровень конкурентоспособности с закрытой моделью Fable, позволяя сочетать её качество с низкой стоимостью. При тестировании на ~1000 агентных задач совместное использование моделей дало 93 % точности и экономию до ~50 раз по сравнению с использованием только Fable. Оценка охватывала пять семей задач — SWE, Terminal, Algorithmic, Multi‑Language и Legal — и показала, что K3 дешевле во всех категориях, а её точность сопоставима с Fable в среднем, но превосходит её в терминальных и юридических сценариях.
Oracle routing показал, что K3 выбирается для 72‑96 % задач, что указывает на возможность построения почти идеального роутера, хотя для этого нужны большие массивы данных. Графики стоимости‑качества покажут, что K3 находится левее Fable во всех пяти семейах, а различия в специализациях (символьные математические задачи у K3, визуализация и веб‑работа у Fable) позволяют распределять нагрузку так, чтобы получать высшее качество по минимальной цене. Таким образом, открытый дешёвый модель становится базовым, а роутер — ключевым элементом стратегии.
Комментарии (397)
Эффективность K3 + Fable зависит от роутера, который часто неоптимизирован для реальных нагрузок, а экономия токенов может быть иллюзорной: K3 тратит в 3 раза больше токенов на задачу, чем Fable, так что низкая цена за токен теряет смысл при высоком общем расходе. Роутеры могут быть переобучены на тестовых наборах, а не на реальных задачах, что делает результаты необобщаемыми. Использование роутера для переключения моделей внутри задачи не масштабируемо и неэффективно для индивидуальных пользователей. Провайдеры могут произвольно снижать ресурсы инференса K3, делая поведение непредсказуемым. Бенчмарки на arena.ai показывают, что K3 уступает Fable в большинстве категорий, кроме веб-разработки, что ставит под сомнение его статус SoTA. Для индивидуальных пользователей лучше выбрать одну стабильную модель — кэширование и предсказуемость важнее экономии на токенах. Роутеры следует переобучать на собственных рабочих нагрузках, а не на общих тестах. K3 действительно превосходит Fable в задачах с кодом, особенно при анализе больших фрагментов и понимании структуры проекта, где другие модели ошибаются или переизобретают существующее. В Китае K3 и GLM 5.2 стали основным выбором для разработчиков из-за блокировки Fable — это необходимость, а не альтернатива. Открытость китайских моделей без кибербезопасностных ограничений привлекает пользователей, уставших от цензуры западных решений. Утверждения о 50-кратной экономии преувеличены — они основаны на идеальном, несуществующем роутере, требующем постоянного переобучения. Провайдеры, такие как Fireworks, заинтересованы в продвижении K3, так как хостинг открытых моделей прибыльнее, чем закрытых, что создаёт конфликт интересов. K3 и DeepSeek уже используются в продакшене для Rust, Terraform и PostgreSQL, демонстрируя стабильную производительность в локальной инфраструктуре через Bifrost. Для тех, кто хочет использовать роутер, OpenRouter поддерживает динамическое переключение между K3 и Fable.
Five US tech giants' hidden debts soar to $1.65T on opaque AI funding 🔥 Горячее
Скрытый долг крупнейших американских технологических компаний вырос в восемь раз за четыре года, достигнув около 1,65 трлн долларов, когда инвестиции в искусственный интеллект превратили аренду дата‑центров и контракты на поставки графических процессоров в обязательства, не отражённые в балансе. По исследованию Nikkei, такие схемы финансирования позволяют компаниям удерживать долг вне баланса, что делает его почти невидимым для инвесторов и усложняет оценку финансовой устойчивости, поскольку реальная нагрузка часто превышает официально заявленный долг.
Meta, например, скрытый долг составляет около 420 млрд долларов — почти в три раза больше её открытого долга, а Oracle и другие крупные игроки используют схожие практики, удерживая миллиарды долларов обязательств в оф‑балансных структурах. Эти данные показывают, что суммарный скрытый долг всех компаний уже превышает их открытый долг, создавая новые риски для инвесторов, которые не могут полноценно оценить финансовое положение компаний, участвующих в ИИ‑проектах. Исследование подчёркивает, что без прозрачного раскрытия такой задолженности оценка риска становится крайне сложной, а потенциальные финансовые шоки могут оказаться скрытыми до момента их возникновения.
Комментарии (125)
Тред связывает скрытый долг технологических компаний с использованием SPV и частным кредитованием, отмечая, что SPV, владеющие дата-центрами, несут долговой риск, а не сами компании. @sajithdilshan возражает, что банки не могут игнорировать риски при выдаче кредитов. Эксперты @harry8 и @m101 подчеркивают, что экономически нет разницы между заимствованием под актив и долгосрочной аренда — схема используется для сокрытия долга. @Terr_ предупреждает, что спекуляции на крахе AI-баббла рискованны: рынок может оставаться иррациональным долго.
Traefik's 10-year anniversary
Traefik отмечает десятилетие развития как облачного прокси-приложения с открытым исходным кодом. За эти годы проект вырос из простого инструмента маршрутизации в полноценную платформу, включающую Traefik Proxy, Traefik Hub API Gateway и решения для управления API. Сообщество сыграло ключевую роль в его эволюции, способствуя появлению функций для Kubernetes, Docker Swarm, веб-приложений и даже шлюзов для ИИ.
Платформа теперь предлагает решения для безопасности, такие как WAF, управление политиками API и интеграции с экосистемами вроде HashiCorp, Microsoft и Oracle. Traefik продолжает адаптироваться к современным потребностям, включая поддержку GitOps и мокирование API, демонстрируя гибкость и устойчивость в быстро меняющейся ИТ-среде.
Комментарии (129)
- Пользователи отмечают сложность настройки и неудовлетворительную документацию Traefik, особенно при нестандартных требованиях.
- Многие предпочитают альтернативы, такие как Caddy, за его простоту и автоматизацию TLS, или Envoy как CNCF-стандарт.
- Traefik хвалят за интеграцию с Docker и автоматическое управление сертификатами, но критикуют за закрытие базовых функций в enterprise-версии.
- Поддержка динамической конфигурации через Docker-лейблы считается сильной стороной, но сам формат конфигурации часто называют запутанным.
- Проект признают зрелым и полезным для конкретных сценариев, но выбор инструмента часто зависит от личных предпочтений и задач.
Help us raise $200k to free JavaScript from Oracle 🔥 Горячее 💬 Длинная дискуссия
Deno подала официальную петицию в Ведомство по патентам и товарным знакам США, чтобы оспорить товарный знак Oracle на слово «JavaScript». После сбора более 27 тысяч подписей под открытым письмом проект перешёл к ключевой стадии discovery, требующей серьёзных ресурсов. Цель — доказать, что термин стал общедоступным обозначением языка, а не брендом Oracle, и освободить его для использования разработчиками, конференциями и авторами без юридических рисков.
Для усиления позиции Deno запустила кампанию по сбору $200 тыс. на экспертные опросы, показания свидетелей из индустрии и академической среды, а также юридические расходы. Oracle уже официально отвергла аргументы о generic-статусе термина. Успех дела важен не только для JavaScript, но и для принципов товарного права: победа корпорации создаст прецедент присвоения общеупотребимых понятий.
Комментарии (268)
- Критика сбора средств VC-финансируемой компанией Deno для суда с Oracle из-за товарного знака "JavaScript"
- Сомнения в успехе и целесообразности дела против Oracle с её огромными ресурсами и возможными негативными последствиями для сообщества
- Предложения альтернативных решений: переход на использование названий "JS", "ECMAScript" или "TypeScript"
- Восприятие инициативы как PR-хода или маркетингового хода, а не искреннего общественного служения
- Поддержка цели освобождения названия, но с оговорками относительно мотивов и методов Deno
Why was Apache Kafka created? 💬 Длинная дискуссия
Почему появился Apache Kafka
LinkedIn, 2012 г.
Проблема интеграции
LinkedIn нужно было передавать данные активности (лайки, просмотры, публикации) в десятки систем: антифрод, ML-модели, веб-функции, витрины, Hadoop. Эти потоки — критичная инфраструктура, а не просто аналитика.
Старые трубы
- Пакетный конвейер: приложения писали XML на HTTP-сервер; раз в час файлы собирались, парсились и грузились в Oracle + Hadoop.
- Realtime-конвейер: метрики и логи уходили в Zenoss, но туда нельзя было добавить новые данные без ручной работы, а данные были изолированы.
Общие боли
- ручное сопровождение и добавление источников;
- постоянные бэклоги;
- point-to-point архитектура без обмена между системами.
Вывод
LinkedIn понял, что нужен один надёжный, масштабируемый и универсальный «шина событий», куда пишут все, а читают кто угодно. Так родился Kafka.
Комментарии (172)
- LinkedIn отказался от Kafka и создал собственную систему Northguard из-за невозможности масштабировать 32 трлн записей/день, 17 ПБ/день и 400 тыс. топиков.
- Участники спорят: Kafka мощна для «огненных шлангов» данных и многократного потребления, но требует экспертизы и ресурсов; для большинства задач достаточно Redis, NATS, RabbitMQ.
- Названа главная фишка Kafka — возможность переигрывать сообщения и строить разные консьюмеры поверх одного лога.
- Сравнивают NATS (Jetstream) и Apache Pulsar как более лёгкие альтернативы; Redpanda тоже упоминается.
- Мнения разделились: кто-то считает Kafka переоценённой и «бюрократичной», кто-то — незаменимой для больших данных.