Проект "How Did I Get Here" от Hack Club демонстрирует путь, который пакеты данных проходят от вашего устройства до сервера. С помощью самописного трейсера ktr, работающего по протоколу ICMP с использованием поля TTL, проект в реальном времени отслеживает каждый узел маршрута. Интересно, что сайт работает даже без JavaScript — сервер последовательно отправляет обновленную HTML-разметку, создавая иллюзию плавной загрузки трейсера.

Важно отметить, что показанный маршрут является "обратным" — от сервера к вашему устройству, а не наоборот, что может незначительно отличаться от реального пути из-за асимметрии маршрутизации. Каждый "сеть" в маршруте на самом деле представляет собой автономную систему (AS) — коллекцию маршрутизаторов, принадлежащую одной компании. Статья вскрывает, что интернет — это не свободная сеть, а скорее совокупность корпоративных сетей, связанных финансовыми соглашениями и бюрократическими процедурами.

• Обсуждение охватывает различные аспекты traceroute и его ограничений, включая то, что AS-путь может быть нестабилен, а фактические точки пиринга могут сильно различаться.
• Участники обсуждают, что traceroute может не отображать обратный путь, особенно если сеть использует асимметричное маршрутизирование.
• Обсуждается, что веб-сайт может не работать из-за блокировки ICMP или из-за того, что маршрутизаторы не отвечают на ICMP запросы.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.

Анализ трёх недавних проблем

С 17 сентября 2025 года

В период с августа по начало сентября три ошибки в инфраструктуре периодически снижали качество ответов Claude. Мы устранили эти проблемы и хотим объяснить, что произошло.

В начале августа пользователи начали сообщать о снижении качества ответов. Изначально эти сообщения было сложно отличить от обычных колебаний обратной связи. К концу августа участившиеся жалобы побудили нас начать расследование, которое выявило три отдельные инфраструктурные ошибки.

Мы никогда не снижаем качество модели из-за спроса, времени суток или нагрузки на серверы. Проблемы были вызваны исключительно ошибками инфраструктуры.

Хронология событий

Наложение этих ошибок значительно усложнило диагностику. Первая ошибка появилась 5 августа, затронув около 0,8% запросов к Sonnet 4. Две другие возникли 25-26 августа.

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

Три перекрывающиеся проблемы

1. Ошибка маршрутизации контекстного окна

5 августа некоторые запросы Sonnet 4 перенаправлялись на серверы, настроенные для контекстного окна в 1 млн токенов. Изначально ошибка затрагивала 0,8% запросов, но к 31 августа эта доля выросла до 16%.

Около 30% пользователей Claude Code столкнулись с ухудшением ответов. На Amazon Bedrock пик затронутых запросов составил 0,18%, на Google Cloud Vertex AI — менее 0,0004%.

Решение: Исправлена логика маршрутизации. Фикс развернут 4 сентября, к 16 сентября распространен на основные платформы.

2. Повреждение вывода

25 августа ошибка конфигурации на серверах TPU вызвала сбой при генерации токенов. Это приводило к появлению неожиданных символов (например, тайских или китайских в ответ на английские запросы) или синтаксических ошибок в коде.

Проблема затрагивала Opus 4.1/4 (25-28 августа) и Sonnet 4 (25 августа - 2 сентября). Сторонние платформы не пострадали.

Решение: Выявлена и откатана ошибочная конфигурация.

• Критика отсутствия юнит-тестов и акцент на использовании эвалов для тестирования моделей.
• Удивление способностью Anthropic влиять на инфраструктуру AWS Bedrock, что противоречит обязательствам AWS.
• Обсуждение технических сбоев: ошибки маршрутизации запросов, коррупция вывода и баг компилятора XLA, повлиявшие на качество Claude.
• Высокое количество инцидентов, отмеченных на статусной странице Claude, и призывы к улучшению качества и надежности сервиса.
• Критика недостаточной прозрачности отчета Anthropic, включая отсутствие данных о степени деградации и компенсаций для пользователей.
• Обсуждение проблем недетерминированности в LLM и сложностей обеспечения воспроизводимости результатов.
• Спекуляции о причинах использования разных аппаратных платформ (TPU, AWS) и их влиянии на пользовательский опыт.

Идея: вместо одного огромного LLM использовать роутер, который для каждого запроса выбирает наиболее подходящую по размеру и качеству модель из набора.
Проблема: GPT-4/5 дороги и не всегда нужны; мелкие модели дешевле, но хуже.
Решение: обучить роутер-LLM прогнозировать, какая модель справится с задачей с минимальными затратами и заданным порогом качества.

Методика:

• Собрали 30 задач NLP (перевод, суммаризация, код и т.д.).
• Для каждой задачи подготовили набор моделей разных размеров (от 1.3 B до 70 B параметров).
• Обучили роутер на 100k примеров, где вход — запрос, выход — выбор модели + оценка качества.
• Использовали Pareto-оптимизацию: минимизировать стоимость при фиксированном качестве.

Результаты:

• При том же качестве, что у GPT-4, роутер сокращает стоимость в 4–6 раз.
• На 50 % запросов достаточно модели 7 B вместо 70 B.
• Роутер добавляет <1 мс задержки (незаметно).

Вывод: дешевле и быстрее держать «зоопарк» моделей + роутер, чем один сверхбольшой LLM.

• Обсуждают «роутинг» запросов между разными LLM вместо одной большой модели: берут 70 % примеров, смотрят, какая модель лучше справляется с каждым кластером, и на оставшиеся 30 % уже маршрутизируют.
• Идея пока простая (эмбеддинг + выбор лучшей по истории), но сообщество считает её неизбежным следующим шагом после CoT и способом дешевле масштабироваться.
• Критика: не учитывают латентность роутера, могут промахнуться со «сложными» запросами, выглядящими простыми; GPT-5 редко включает reasoning-модель.
• Некоторые сравнивают с NotDiamond и другими стартапами, а также с «облачной» эволюцией: сначала дорого, потом дешевеет.
• Видение будущего — AGI как ансамбль специализированных модулей, которые можно миксовать под задачу пользователя.

Не выбирайте странные подсети для встраиваемых сетей, используйте VRF

Встраиваемая сеть — это, например, переносная стойка с видео- и сетевым оборудованием, которую подключают к сети площадки. Устройства внутри стойки должны общаться между собой, но перенастраивать их IP при каждой смене локации неудобно. Обычно добавляют маршрутизатор с NAT и используют простую подсеть вроде 10.0.0.0/24. Проблема возникает, если внешняя сеть площадки использует ту же подсеть — возникают конфликты. Люди начинают выбирать «редкие» диапазоны (172.16.42.0/24, 10.11.12.0/24), но конфликты всё равно случаются.

IPv6-решение
Использовать link-local адреса fe80::/64 и протоколы обнаружения (avahi). Маршрутизатор раздаёт маршруты, и внутренние устройства получают доступ в интернет. Недостаток: большинство встраиваемых устройств (аудио- и видеомикшеры) не поддерживают IPv6. Аналогичный IPv4-механизм APIPA (169.254.0.0/16) не даёт шлюза и интернета.

Универсальное решение
Вместо экзотических подсетей ограничьте «странность» настройками маршрутизатора. Используйте VRF (Virtual Routing and Forwarding), чтобы изолировать внутреннюю сеть и избежать конфликтов, не меняя адресацию устройств.

• Docker случайно выбирает подсеть RFC1918, которая может конфликтовать с корпоративной сетью; это частая проблема в AWS и вызывает головную боль при отладке.
• IPv6-поддержка всё ещё редка, поэтому обсуждают альтернативы: IPv4 link-local, CGNAT 100.64.0.0/10, «benchmark» 198.18.0.0/15 и даже выделение «мертвой» подсети.
• Некоторые просто используют VRF или VLAN, чтобы изолировать трафик и избежать конфликтов, хотя это требует понимания маршрутизации.
• Участники сомневаются, что IPv4 исчезнет скоро: у провайдеров его много, а стимул перехода на IPv6 минимален без внешнего давления.

Nexus — открытый AI-роутер, который объединяет MCP-серверы и маршрутизирует запросы между LLM, добавляя безопасность и управление.

Что делает

• Агрегация MCP: один вызов вместо множества подключений к разным MCP-серверам.
• Умный роутинг LLM: выбирает модель по типу задачи, цене, задержке и доступности.
• Безопасность и наблюдаемость: единые политики, логирование, отказоустойчивость.

Плюсы

• Простота: одна точка интеграции вместо сети подключений.
• Масштабируемость: новые MCP или LLM добавляются без изменения кода.
• Надёжность: автоматический fallback при сбоях.
• Прозрачность: мониторинг и аналитика в реальном времени.

Дальше

• Продвинутые алгоритмы роутинга, дашборды, кастомные правила, rate-limiting и расширенная безопасность.

Попробуйте Nexus уже сейчас и упростите архитектуру своих AI-приложений.

• Grafbase выпустил Nexus — open-source «AI Router», объединяющий MCP-серверы и LLM через один endpoint.
• Основной фокус: enterprise-уровень governance, контроль и observability.
• Участники сравнивают с коммерческим nexos.ai и open-source OpenRouter/LiteLLM.
• Ключевое отличие — агрегация MCP-серверов и возможность self-host.
• Название вызвало шутки про «Torment Nexus» и старый телефон Nexus.