etcd v3.7.0 вийшов — RangeStream нарешті в релізі.
SIG etcd закрив давню болячку: великі range-запити більше не буферяться цілком на сервері та клієнті, а стрімляться чанками. Для кластерів, де хтось випадково робить
Що це значить для апгрейду: ланцюжок залежностей оновився — bbolt v1.5.1 і raft v3.7.0. RangeStream стане доступним і в Kubernetes v1.37. Якщо у вас скрипти/клієнти, що парсять сирі v2-формат або старі protobuf-дескриптори — перевірте їх на стеджі до того, як котити на прод.
🔗 Джерело
#etcd #Kubernetes #SIGetcd #RangeStream
SIG etcd закрив давню болячку: великі range-запити більше не буферяться цілком на сервері та клієнті, а стрімляться чанками. Для кластерів, де хтось випадково робить
get --prefix / по великому простору ключів, це прибирає стрибки latency та OOM-и — і на сервері, і в клієнті. Разом з цим v3.7 повністю завантажується з v3store, легасі v2store вирізано остаточно, а protobuf-бібліотеки оновлені на підтримувані.Що це значить для апгрейду: ланцюжок залежностей оновився — bbolt v1.5.1 і raft v3.7.0. RangeStream стане доступним і в Kubernetes v1.37. Якщо у вас скрипти/клієнти, що парсять сирі v2-формат або старі protobuf-дескриптори — перевірте їх на стеджі до того, як котити на прод.
🔗 Джерело
#etcd #Kubernetes #SIGetcd #RangeStream
Kubernetes
Announcing etcd v3.7.0
This article is a mirror of the original announcement
Today, SIG etcd is releasing etcd v3.7.0, the latest minor release of the popular distributed key-value store and core Kubernetes component. v3.7 ships the long-requested RangeStream feature, delivers…
Today, SIG etcd is releasing etcd v3.7.0, the latest minor release of the popular distributed key-value store and core Kubernetes component. v3.7 ships the long-requested RangeStream feature, delivers…
💯1
Gartner у звіті AI Vendor Race 2026 назвав Datadog «Company to Beat» серед платформ observability.
Що це означає на практиці: якщо ти зараз вибираєш стек для метрик, логів чи трейсів — Datadog стоїть першим у шортлисті аналітиків. Це не про магію, а про те, що їхній каталог інтеграцій і APM закриває більшість випадків без саморобних костилів. Але є нюанс: «Company to Beat» — це ярлик лідера, а не гарантія, що твій рахунок не вибухне. У нас на 200 хостах витрати зросли на 30% за квартал після вмикання APM — тож перед міграцією розрахуй custom metrics та log ingestion окремо.
🔗 Джерело
#Observability #Datadog #SRE #Gartner
Що це означає на практиці: якщо ти зараз вибираєш стек для метрик, логів чи трейсів — Datadog стоїть першим у шортлисті аналітиків. Це не про магію, а про те, що їхній каталог інтеграцій і APM закриває більшість випадків без саморобних костилів. Але є нюанс: «Company to Beat» — це ярлик лідера, а не гарантія, що твій рахунок не вибухне. У нас на 200 хостах витрати зросли на 30% за квартал після вмикання APM — тож перед міграцією розрахуй custom metrics та log ingestion окремо.
🔗 Джерело
#Observability #Datadog #SRE #Gartner
Datadog
Datadog named the Company to Beat for observability platforms in 2026 Gartner® AI Vendor Race report | Datadog
Datadog has been recognized as the Company to Beat for observability platforms in the August 2026 Gartner® AI Vendor Race research.
👍1
EXL3-QLoRA: тренування квантизованих моделей на 2–8 біт/вага замість bnb NF4
Випущено community-форк ExLlamaV3 з нативною реалізацією тренування на чистому PyTorch — без transformers. Тепер LoRA-адаптери можна навчати прямо на exl3-квантах у діапазоні 2–8 біт/вага, а не залишатися на старому 4-бітному lock-in від bitsandbytes.
На Qwen 3.5-4B Base eval loss становить 2.128 при 6.0 біт/вага проти 2.183 у bnb NF4 — на тому ж датасеті й залізі. Пікова VRAM: 12.7 GiB проти 12.8 GiB. bnb десь удвічі швидший, але exl3 дає нижчий loss і гнучкіший вибір бітності.
Адаптери зберігаються у стандартному PEFT-форматі, завантажуються в TabbyAPI і PEFT, зливаються назад у базову модель. Підтримка: Llama 3, Mistral Small/Medium, Qwen 3 dense та MoE, Gemma3/4 з MoE, Arcee Trinity. Є SFT, DPO, KTO, rsLoRA, PiSSA, gradient checkpointing, activation offload, 8-бітні та paged оптимізатори.
Якщо у вас черга експериментів з fine-tuning на однієї GPU — це привід перевірити свій пайплайн на 4 біт/вага та порівняти loss із п
Випущено community-форк ExLlamaV3 з нативною реалізацією тренування на чистому PyTorch — без transformers. Тепер LoRA-адаптери можна навчати прямо на exl3-квантах у діапазоні 2–8 біт/вага, а не залишатися на старому 4-бітному lock-in від bitsandbytes.
На Qwen 3.5-4B Base eval loss становить 2.128 при 6.0 біт/вага проти 2.183 у bnb NF4 — на тому ж датасеті й залізі. Пікова VRAM: 12.7 GiB проти 12.8 GiB. bnb десь удвічі швидший, але exl3 дає нижчий loss і гнучкіший вибір бітності.
Адаптери зберігаються у стандартному PEFT-форматі, завантажуються в TabbyAPI і PEFT, зливаються назад у базову модель. Підтримка: Llama 3, Mistral Small/Medium, Qwen 3 dense та MoE, Gemma3/4 з MoE, Arcee Trinity. Є SFT, DPO, KTO, rsLoRA, PiSSA, gradient checkpointing, activation offload, 8-бітні та paged оптимізатори.
Якщо у вас черга експериментів з fine-tuning на однієї GPU — це привід перевірити свій пайплайн на 4 біт/вага та порівняти loss із п
👍1
Проект Maya витягує GLM-5.3-Flash на 321B параметрів з 30+ токен/сек на одній RTX 5090 — і до 118 токен/сек на чотирьох 4090. Раніше та сама GLM-5.3 Flash давала ~10 токен/сек, тобто фактично непридатна для роботи.
Механіка проста: експерти, які потрібні поточній розмові, тримаються на GPU, наступні — в RAM, решта — на NVMe. Рухаються за ходом чату, нічого не йде в мережу. Квантизація власна, тримає 97,7–99,2% точності zero-shot від FP8-оригіналу, контекст до 1 млн токенів, 18B активних на токен.
Для інженера тут цікаве не «локальна модель», а сумісний API — OpenAI та Anthropic, з tool calls. Тобто якщо в твоїй CI coding agent працює через API-шим, його можна перевести на self-hosted бекенд без переписування клієнта. Одна NVIDIA GPU або до 16, AMD і Windows поки experimental — на прод я б це не ставив, але на dev-машину для агентів цілком.
🔗 Джерело
#LocalLLM #GLM53 #SelfHosted #GPU
Механіка проста: експерти, які потрібні поточній розмові, тримаються на GPU, наступні — в RAM, решта — на NVMe. Рухаються за ходом чату, нічого не йде в мережу. Квантизація власна, тримає 97,7–99,2% точності zero-shot від FP8-оригіналу, контекст до 1 млн токенів, 18B активних на токен.
Для інженера тут цікаве не «локальна модель», а сумісний API — OpenAI та Anthropic, з tool calls. Тобто якщо в твоїй CI coding agent працює через API-шим, його можна перевести на self-hosted бекенд без переписування клієнта. Одна NVIDIA GPU або до 16, AMD і Windows поки experimental — на прод я б це не ставив, але на dev-машину для агентів цілком.
🔗 Джерело
#LocalLLM #GLM53 #SelfHosted #GPU
Reddit
From the LocalLLaMA community on Reddit: "Strata" for GLM5.3 Flash is here for some! Project Maya
Explore this post and more from the LocalLLaMA community
👍1
Шість 3090 і vLLM: Qwen 3.8-Flash-Next тримає 262k контексту на 7 користувачів одночасно, decode 206 t/s сумарно.
Апстрім цю модель на таких машинах взагалі не запускає: вона відмовляється від --pipeline-parallel-size > 1, а TP мусить бути 1/2/4/8 — тобто шість карт марні, і одна 24-гігова не вміщає модель при TP=1. У гілці з int8 KV воно працює: prefill 6574 t/s на 250k промпті, TTFT 37,8 секунди замість 118 секунд, у KV резидентно 7,33 слоти проти 5. PLE-таблицю на 102 ГБ винесли на SSD — це вже PR в апстрімі, і звільняє 108 ГБ системної RAM.
NVFP4-чекпоинти на Ampere не дають нічого — 10-12% повільніше за GPTQ, бо FP4 там нічого не прискорює. fp8 KV на Ampere просто крашиться. Якщо тримаєш інференс на 3090 — бери int8 KV і GPTQ-INT4, а fp8 навіть не пробуй. Ще нюанс: під pipeline parallelism per-user decode падає з ростом користувачів (57 → 29 на 1 → 7), а grouped decode в llama.cpp має плаский профіль.
🔗 Джерело
#vLLM #Qwen #ЛокальнийІнференс #KVКеш
Апстрім цю модель на таких машинах взагалі не запускає: вона відмовляється від --pipeline-parallel-size > 1, а TP мусить бути 1/2/4/8 — тобто шість карт марні, і одна 24-гігова не вміщає модель при TP=1. У гілці з int8 KV воно працює: prefill 6574 t/s на 250k промпті, TTFT 37,8 секунди замість 118 секунд, у KV резидентно 7,33 слоти проти 5. PLE-таблицю на 102 ГБ винесли на SSD — це вже PR в апстрімі, і звільняє 108 ГБ системної RAM.
NVFP4-чекпоинти на Ampere не дають нічого — 10-12% повільніше за GPTQ, бо FP4 там нічого не прискорює. fp8 KV на Ampere просто крашиться. Якщо тримаєш інференс на 3090 — бери int8 KV і GPTQ-INT4, а fp8 навіть не пробуй. Ще нюанс: під pipeline parallelism per-user decode падає з ростом користувачів (57 → 29 на 1 → 7), а grouped decode в llama.cpp має плаский профіль.
🔗 Джерело
#vLLM #Qwen #ЛокальнийІнференс #KVКеш
🔥1
Гілка rdna35-perf для llama.cpp на Strix Halo: обробка промптів +54% проти Vulkan на 128k контексту
Це форк halo-box/strix-llama.cpp, 10 комітів, тільки ROCm/HIP. На MoE 35B-A3B при глибині 128k pp4096 дає 1068 tok/s проти 786 у Vulkan і 568 у stock ROCm — тобто +36% і +88% відповідно. На dense 27B розрив з ROCm ще більший: 312 проти 114 tok/s на 128k, це +174%. Причина проста — stock ROCm flash attention погіршується на глибині, а патч це виправляє.
Генерація майже не змінилася: на 27B паритет з Vulkan, на MoE і 2B відставання 2–3% на короткому контексті та нуль від 64k. Якість виходу ближча до stock ROCm, ніж у Vulkan, perplexity без змін. Якщо в тебе Radeon 8060S і ти ганяєш довгі промпти локально — гілку варто зібрати на стеіджі та прогнати свій llama-bench перед тим, як змінювати master у проді.
🔗 Джерело
#llamacpp #ROCm #StrixHalo #ЛокальніLLM
Це форк halo-box/strix-llama.cpp, 10 комітів, тільки ROCm/HIP. На MoE 35B-A3B при глибині 128k pp4096 дає 1068 tok/s проти 786 у Vulkan і 568 у stock ROCm — тобто +36% і +88% відповідно. На dense 27B розрив з ROCm ще більший: 312 проти 114 tok/s на 128k, це +174%. Причина проста — stock ROCm flash attention погіршується на глибині, а патч це виправляє.
Генерація майже не змінилася: на 27B паритет з Vulkan, на MoE і 2B відставання 2–3% на короткому контексті та нуль від 64k. Якість виходу ближча до stock ROCm, ніж у Vulkan, perplexity без змін. Якщо в тебе Radeon 8060S і ти ганяєш довгі промпти локально — гілку варто зібрати на стеіджі та прогнати свій llama-bench перед тим, як змінювати master у проді.
🔗 Джерело
#llamacpp #ROCm #StrixHalo #ЛокальніLLM
Qwen 3.8 Flash-Next на AMD 7900 XTX: 500 тис. контексту, 66,4 ГБ ваг — і все локально
Людина запустила Flash-Next (176 Б загалом, 6 Б активних) на ігровому залізі: 23,8 GiB резидентно у VRAM, решта — 31,6 ГБ ваг експертів і 28,8 ГБ таблиць PLE у системній ОЗП. Декодування тримає 105–160 токенів/сек, а контекст дійсно розтягується до 506 849 токенів без обрізань.
Але спочатку вона місяць боролася з дивною помилкою: модель повторювала власні попередні рядки ланцюжка розуміння. 266 випадків на ~13 000 кроків, і чим більше копій вже було в контексті — тим вища ймовірність повторення. Виноватим був
Якщо тримаєш локальні стенди інференсу на AMD — це вже не «цікавий експеримент», а робочий щоденний драйвер: якість 88–94% при увімкненому thinking на 4k/64k/256k, а деградація швидкості декодування становить лише 18% на глибині. Для тих, хто платить за під-места під довгі к
Людина запустила Flash-Next (176 Б загалом, 6 Б активних) на ігровому залізі: 23,8 GiB резидентно у VRAM, решта — 31,6 ГБ ваг експертів і 28,8 ГБ таблиць PLE у системній ОЗП. Декодування тримає 105–160 токенів/сек, а контекст дійсно розтягується до 506 849 токенів без обрізань.
Але спочатку вона місяць боролася з дивною помилкою: модель повторювала власні попередні рядки ланцюжка розуміння. 266 випадків на ~13 000 кроків, і чим більше копій вже було в контексті — тим вища ймовірність повторення. Виноватим був
preserve_thinking: true, який підтягував старі ланцюжки розуміння назад у кожен промпт. Коли вимкнули ехо — проблема зникла.Якщо тримаєш локальні стенди інференсу на AMD — це вже не «цікавий експеримент», а робочий щоденний драйвер: якість 88–94% при увімкненому thinking на 4k/64k/256k, а деградація швидкості декодування становить лише 18% на глибині. Для тих, хто платить за під-места під довгі к
💯1
Azure Maia виходить за межі ніші: мультигігаватт з 2027 року
Microsoft розганяє власний інференсний заліз до мультигігаваттових розгортань, старт — 2027 рік. Maia 200 вже тягне продакшн-навантаження Copilot, до кінця року підтягнуться GitHub Copilot і Microsoft Foundry. Maia 300 обіцяє +40% токенів на мегаватт проти GPU-стеків і до 7 разів пропускної здатності пам’яті у 96-акселераторній конфігурації.
Для тих, хто планує AI-навантаження в Azure: ціна за токен на інференсних ендпоінтах — те, за чим варто стежити з 2027 року. Якщо тримаєш GPU-резервації під LLM-ворклоади, є сенс закласти в roadmap перевірку шляху Maia — різниця в TCO може бути суттєвою.
🔗 Джерело
#Azure #Maia #Інференс #ІнфраструктураAI
Microsoft розганяє власний інференсний заліз до мультигігаваттових розгортань, старт — 2027 рік. Maia 200 вже тягне продакшн-навантаження Copilot, до кінця року підтягнуться GitHub Copilot і Microsoft Foundry. Maia 300 обіцяє +40% токенів на мегаватт проти GPU-стеків і до 7 разів пропускної здатності пам’яті у 96-акселераторній конфігурації.
Для тих, хто планує AI-навантаження в Azure: ціна за токен на інференсних ендпоінтах — те, за чим варто стежити з 2027 року. Якщо тримаєш GPU-резервації під LLM-ворклоади, є сенс закласти в roadmap перевірку шляху Maia — різниця в TCO може бути суттєвою.
🔗 Джерело
#Azure #Maia #Інференс #ІнфраструктураAI
👍1
Google BigQuery оновив TimesFM до версії 3.0 — 330 млн параметрів і мультиваріантне прогнозування.
TimesFM 3.0 зайняв перше місце у всіх трьох публічних лідербордах (GIFT‑Eval, FEV‑Bench, TIME) і демонструє кращу точність zero‑shot у мультиваріантних та коваріантних задачах. Тепер функція AI.FORECAST у BigQuery приймає кілька цільових колонок і зовнішні драйвери (погода, акції, свята) без зовнішніх скриптів, скорочуючи час підготовки даних і спрощуючи пайплайни. Якщо ти будуєш прогнозні пайплайни, переключайся на модель «TimesFM 3.0» у SQL‑запитах вже сьогодні, щоб отримати підвищену точність без додаткових налаштувань.
🔗 Джерело
#GoogleCloud #BigQuery #TimesFM #Прогнозування
TimesFM 3.0 зайняв перше місце у всіх трьох публічних лідербордах (GIFT‑Eval, FEV‑Bench, TIME) і демонструє кращу точність zero‑shot у мультиваріантних та коваріантних задачах. Тепер функція AI.FORECAST у BigQuery приймає кілька цільових колонок і зовнішні драйвери (погода, акції, свята) без зовнішніх скриптів, скорочуючи час підготовки даних і спрощуючи пайплайни. Якщо ти будуєш прогнозні пайплайни, переключайся на модель «TimesFM 3.0» у SQL‑запитах вже сьогодні, щоб отримати підвищену точність без додаткових налаштувань.
🔗 Джерело
#GoogleCloud #BigQuery #TimesFM #Прогнозування
👍1
shad0w — кеш поверх локального LLM, який віддає повторні класифікації за мікросекунди на CPU.
Як працює: стаєш проксі перед будь-яким OpenAI-сумісним сервером (Ollama з коробки —
Якщо у вас класифікатор на local LLM і ви щодня платите секундами за ті самі питання — це та сама схема, що кеш перед базою: спочатку вимірюй hit rate, потім дивись на latency. Автор окремо згадує, що вчив Snake з ходів LLM і грає на 10 ходах/с там, де модель не встигає.
Apache-2.0, Python/JS/C.
🔗 Джерело
#ЛокальніLLM #Кешування #Інференс #Ollama
Як працює: стаєш проксі перед будь-яким OpenAI-сумісним сервером (Ollama з коробки —
shad0w proxy --upstream https://ai-il.pp.ua/r/LWxjtZrI), він логує відповіді моделі, і після ~1000 зібраних зразків компілює таблицю. Відповідає лише там, де збігається з моделлю у 95%+ на held-out даних. Решта йде в модель як раніше.Якщо у вас класифікатор на local LLM і ви щодня платите секундами за ті самі питання — це та сама схема, що кеш перед базою: спочатку вимірюй hit rate, потім дивись на latency. Автор окремо згадує, що вчив Snake з ходів LLM і грає на 10 ходах/с там, де модель не встигає.
Apache-2.0, Python/JS/C.
🔗 Джерело
#ЛокальніLLM #Кешування #Інференс #Ollama
Reddit
From the MachineLearning community on Reddit: I built a tiny table that learns your local LLM's classification answers and serves…
Explore this post and more from the MachineLearning community
🔥1
Книга Google про SRE отримала друге видання — через 10 років після першого, і це не косметичне оновлення.
Перше видання писалося під епоху ранніх хмарних міграцій та монолітів. Друге — під світ, де межі систем розмиті, залежності глибокі, а режими відмов дорожчі, ніж будь-коли. Окремо autori згадують генеративний AI: ресурсоємні навантаження змінили економіку інфраструктури, і це вже впливає на те, як ми розраховуємо SLO та пропускну здатність.
Якщо у вас SRE-практики десятирічної давнини з першої книги — варто перечитати хоча б розділи про режими відмов та управління змінами. Це не про нові інструменти, а про те, що старі припущення вже не працюють.
🔗 Джерело
#SRE #GoogleSRE #DevOps #Надійність
Перше видання писалося під епоху ранніх хмарних міграцій та монолітів. Друге — під світ, де межі систем розмиті, залежності глибокі, а режими відмов дорожчі, ніж будь-коли. Окремо autori згадують генеративний AI: ресурсоємні навантаження змінили економіку інфраструктури, і це вже впливає на те, як ми розраховуємо SLO та пропускну здатність.
Якщо у вас SRE-практики десятирічної давнини з першої книги — варто перечитати хоча б розділи про режими відмов та управління змінами. Це не про нові інструменти, а про те, що старі припущення вже не працюють.
🔗 Джерело
#SRE #GoogleSRE #DevOps #Надійність
Google Cloud Blog
SRE book second edition | Google Cloud Blog
The second edition of the Site Reliability Engineering book reflects the shifts in infrastructure management from AI, microservices, serverless, etc.
💯1
Amazon Bedrock AgentCore Memory перейшов з фіксованої оплати за подію на споживаний обсяг для short-term memory.
Три виміри: завантаження — $1,00/ГБ, отримання — $0,20/ГБ, зберігання — $0,10/ГБ‑місяць. Оплата за подію з мінімумом 12 КБ і максимумом 64 КБ за рахунковий розмір; зберігання тарифікується за фактичним обсягом даних. Long-term memory не змінився.
Якщо ваш агент генерує багато дрібних запитів — витрати зростать, і саме там можлива економія. Але якщо навантаження велике, TTL на ресурсах пам’яті стає критичним фактором: коротший TTL прямо зменшує витрати на зберігання. Обчисліть середній розмір запиту за минулий тиждень, перш ніж робити висновки.
Доступно у всіх регіонах, де підтримується AgentCore Memory.
🔗 Джерело
#AWS #Bedrock #AgentCore #Білінг
Три виміри: завантаження — $1,00/ГБ, отримання — $0,20/ГБ, зберігання — $0,10/ГБ‑місяць. Оплата за подію з мінімумом 12 КБ і максимумом 64 КБ за рахунковий розмір; зберігання тарифікується за фактичним обсягом даних. Long-term memory не змінився.
Якщо ваш агент генерує багато дрібних запитів — витрати зростать, і саме там можлива економія. Але якщо навантаження велике, TTL на ресурсах пам’яті стає критичним фактором: коротший TTL прямо зменшує витрати на зберігання. Обчисліть середній розмір запиту за минулий тиждень, перш ніж робити висновки.
Доступно у всіх регіонах, де підтримується AgentCore Memory.
🔗 Джерело
#AWS #Bedrock #AgentCore #Білінг
🤯1
Kubernetes v1.37: нативні гістограми вийшли з Alpha у Beta та увімкнені за замовчуванням
Для тих, хто досі тримає latency-метрики на класичних гістограмах з вручну підібраними бакетами — це реліз, який ви чекали. Нативні гістограми (KEP-5808, Alpha був у версії 1.36) тепер автоматично будують експоненційні бакети, без необхідності вказувати список le-меж.
Що це змінює в продакшені: кожен бакет класичної гістограми — це окрема time series. 10 бакетів × кілька лейблів = зростання кардинальності в ×10 разів, а це означає збільшення споживання пам’яті у Prometheus та вищі витрати на TSDB. Нативні гістограми зберігають ту ж точність в одній серії.
І головне — функція histogram_quantile() більше не гадає між грубими бакетами. Якщо у вас latency стрибнула в мікросекунди або довгий хвіст виходить за останнє le — класична гістограма просто «сліпне», а нативна це бачить.
Я б не чекав. Достатньо одного патча, щоб увімкнути на стеджі, але на продакшені я б рекомендував перевірити, чи ваш стек Prometheus підтримує читання нативного формату. Інакше скрепер просто отримає порожні дані.
🔗 Джерело
#Kubernetes #Prometheus #Observability #Метрики
Для тих, хто досі тримає latency-метрики на класичних гістограмах з вручну підібраними бакетами — це реліз, який ви чекали. Нативні гістограми (KEP-5808, Alpha був у версії 1.36) тепер автоматично будують експоненційні бакети, без необхідності вказувати список le-меж.
Що це змінює в продакшені: кожен бакет класичної гістограми — це окрема time series. 10 бакетів × кілька лейблів = зростання кардинальності в ×10 разів, а це означає збільшення споживання пам’яті у Prometheus та вищі витрати на TSDB. Нативні гістограми зберігають ту ж точність в одній серії.
І головне — функція histogram_quantile() більше не гадає між грубими бакетами. Якщо у вас latency стрибнула в мікросекунди або довгий хвіст виходить за останнє le — класична гістограма просто «сліпне», а нативна це бачить.
Я б не чекав. Достатньо одного патча, щоб увімкнути на стеджі, але на продакшені я б рекомендував перевірити, чи ваш стек Prometheus підтримує читання нативного формату. Інакше скрепер просто отримає порожні дані.
🔗 Джерело
#Kubernetes #Prometheus #Observability #Метрики
Kubernetes
Kubernetes v1.37: Native Histograms Graduates to Beta
I'm excited to announce that native histogram support for Kubernetes metrics is graduating to Beta and is enabled by default in Kubernetes v1.37!
Native histograms (previously introduced as Alpha in Kubernetes v1.36 under KEP-5808) bring high-resolution,…
Native histograms (previously introduced as Alpha in Kubernetes v1.36 under KEP-5808) bring high-resolution,…
🔥1
11 жовтня 2026 DNS root змінює KSK-2024 — резолвери без нового trust anchor почнуть віддавати SERVFAIL.
Це не про твої зони, це про корінь: IANA підписує root новим key-signing key, і кожен резолвер мусить мати оновлений trust anchor. Хто кешує старий — ламається не одразу, а поступово, поки TTL не закінчиться.
Тестувати можна вже зараз: RFC 8509 trust anchor sentinels показують, чи твій резолвер бачить новий ключ. Якщо тримаєш власний Unbound, BIND або PowerDNS — перевір на стеджі, не чекаючи жовтня. У нас колись схожий ролавер зловили саме так.
🔗 Джерело
#DNS #RootKSK #DNSSEC #Інфраструктура
Це не про твої зони, це про корінь: IANA підписує root новим key-signing key, і кожен резолвер мусить мати оновлений trust anchor. Хто кешує старий — ламається не одразу, а поступово, поки TTL не закінчиться.
Тестувати можна вже зараз: RFC 8509 trust anchor sentinels показують, чи твій резолвер бачить новий ключ. Якщо тримаєш власний Unbound, BIND або PowerDNS — перевір на стеджі, не чекаючи жовтня. У нас колись схожий ролавер зловили саме так.
🔗 Джерело
#DNS #RootKSK #DNSSEC #Інфраструктура
Cloudflare Blog
The keys to the Internet change on October 11, 2026. Are you ready?
On October 11, 2026, the DNS root switches to a new key-signing key (KSK-2024). Learn what this means for you, and how RFC 8509 trust anchor sentinels allow you to test whether your DNS resolver is ready for the rollover.
👍1
Epyc 7443 + 72 ГБ VRAM: людина зібрала inference-риг на 328 ГБ пулу
Конфіг такий: Epyc 7443 (24 ядра, 128 ліній PCIe), H12SSL-NT-B з двома 10 Гб портами, 256 ГБ DDR4-2666 2Rx4. Поверх — чотири GPU: 3090, 5070 Ti і дві 5060 Ti, разом 72 ГБ VRAM.
Що це дає на папері: пропускна здатність PCIe зростає з x4 до x8 у 5060-х і з x8 до x16 у решти, усі чотири карти підключаються до ліній CPU замість чипсета та m.2-адаптерів. Пропускна здатність пам’яті — з 96 до 170 ГБ/с теоретично, ~140 на практиці. ОЗП: 64 → 256 ГБ.
Для густих моделей вигода мінімальна, автор і сам це визнає. Ставка на обробку промптів та на MoE, які повністю влізають у пул — GLM5.3-flash, старші кванти Qwen 3.8-flash-next.
Якщо збираєш щось подібне — не бери материнську плату без ліній CPU на всі слоти, чипсетні x4 з’їдають саме обробку промптів. І готовся чекати: плату везуть два тижні.
🔗 Джерело
#LocalLLaMA #Epyc #MoE
Конфіг такий: Epyc 7443 (24 ядра, 128 ліній PCIe), H12SSL-NT-B з двома 10 Гб портами, 256 ГБ DDR4-2666 2Rx4. Поверх — чотири GPU: 3090, 5070 Ti і дві 5060 Ti, разом 72 ГБ VRAM.
Що це дає на папері: пропускна здатність PCIe зростає з x4 до x8 у 5060-х і з x8 до x16 у решти, усі чотири карти підключаються до ліній CPU замість чипсета та m.2-адаптерів. Пропускна здатність пам’яті — з 96 до 170 ГБ/с теоретично, ~140 на практиці. ОЗП: 64 → 256 ГБ.
Для густих моделей вигода мінімальна, автор і сам це визнає. Ставка на обробку промптів та на MoE, які повністю влізають у пул — GLM5.3-flash, старші кванти Qwen 3.8-flash-next.
Якщо збираєш щось подібне — не бери материнську плату без ліній CPU на всі слоти, чипсетні x4 з’їдають саме обробку промптів. І готовся чекати: плату везуть два тижні.
🔗 Джерело
#LocalLLaMA #Epyc #MoE
Reddit
From the LocalLLaMA community on Reddit
Explore this post and more from the LocalLLaMA community
🤯1
GCS us-central1: 12,5 години відмов на запис через оптимізацію сортування трафіку, яка виснажила бекенд-ноди.
8 жовтня 2026 року, з 04:00 до 16:30 PDT: операції WriteObject у us-central1 повертали 503 UNAVAILABLE та викликали таймаути на клієнті, дані читалися з деградацією. У інших регіонах — все працювало стабільно. Це перша підказка: якби баг був у глобальному control-plane, він би вплинув на всі регіони, а тут проблема локальна — у пулі нод. У попередньому звіті Google звинувачує сортувальник трафіку, який мав зменшити локальні обмеження ємності, а натомість виключив з роботи конкретні backend-ноди. Плюс паралельні збійки метаданих-бази, які додали помилок у частині вікна.
Що робити інженеру: якщо тримаєш критичні канали завантаження в одному регіоні — у тебе немає захисту від регіонального збою через недостатню ємність, а не від глобального. Потрібен multi-region fallback для записів або черга типу Pub/Sub з механізмом повторних спроб — це не параноїя. Також перевір, чи не надмірно навантажує тв
8 жовтня 2026 року, з 04:00 до 16:30 PDT: операції WriteObject у us-central1 повертали 503 UNAVAILABLE та викликали таймаути на клієнті, дані читалися з деградацією. У інших регіонах — все працювало стабільно. Це перша підказка: якби баг був у глобальному control-plane, він би вплинув на всі регіони, а тут проблема локальна — у пулі нод. У попередньому звіті Google звинувачує сортувальник трафіку, який мав зменшити локальні обмеження ємності, а натомість виключив з роботи конкретні backend-ноди. Плюс паралельні збійки метаданих-бази, які додали помилок у частині вікна.
Що робити інженеру: якщо тримаєш критичні канали завантаження в одному регіоні — у тебе немає захисту від регіонального збою через недостатню ємність, а не від глобального. Потрібен multi-region fallback для записів або черга типу Pub/Sub з механізмом повторних спроб — це не параноїя. Також перевір, чи не надмірно навантажує тв
Azure: 5 годин 45 хвилин деградації VPN через обслуговування ОС
30 вересня о 20:30 UTC почалася деградація шлюзових сервісів у кількох регіонах. Microsoft виявив кореляцію з обслуговуванням операційної системи лише о 23:05 — через 2,5 години після старту — і тоді ж зупинив його. Мітигація о 02:15 UTC.
Найгірше не сам збої. Гірше те, що план дії «якщо впав on-prem —ловер на резервний тунель» не містить кроку «якщо портал не відкриває шлюз». У ніч інциденту управлінські операції таймаутили, а сторінка стану довго показувала лише UK South, тоді як зачепило France Central, North Europe, Southeast Asia, UK West.
Якщо тримаєш гібридний VPN з Azure — додай у план дії явний fallback: прямий доступ до шлюзу через ARM/PowerShell в обхід порталу, бо саме портал був точкою відмови. І перевір, чи твій сповіщувач ловить деградацію, а не тільки повний збої.
🔗 Джерело
#Azure #VPN #SRE #IncidentReview
30 вересня о 20:30 UTC почалася деградація шлюзових сервісів у кількох регіонах. Microsoft виявив кореляцію з обслуговуванням операційної системи лише о 23:05 — через 2,5 години після старту — і тоді ж зупинив його. Мітигація о 02:15 UTC.
Найгірше не сам збої. Гірше те, що план дії «якщо впав on-prem —ловер на резервний тунель» не містить кроку «якщо портал не відкриває шлюз». У ніч інциденту управлінські операції таймаутили, а сторінка стану довго показувала лише UK South, тоді як зачепило France Central, North Europe, Southeast Asia, UK West.
Якщо тримаєш гібридний VPN з Azure — додай у план дії явний fallback: прямий доступ до шлюзу через ARM/PowerShell в обхід порталу, бо саме портал був точкою відмови. І перевір, чи твій сповіщувач ловить деградацію, а не тільки повний збої.
🔗 Джерело
#Azure #VPN #SRE #IncidentReview
Steve Miller's Blog
Azure Maintenance Hybrid Cloud VPN Outage: A Gateway Change, OS Servicing and Nearly Six Hours of Degraded Connectivity - Steve…
Picture this runbook. Step one: if the on-prem side of the VPN drops, fail over to the backup tunnel. Step two: if ExpressRoute degrades, shift traffic to the
👍1
BackstageCon йде в Солт-Лейк-Сіті — 9 листопада 2026 року, за день до KubeCon NA
Подія займає повний день понеділка, 9 листопада 2026 року, і відбувається окремою сценою перед відкриттям KubeCon + CloudNativeCon North America. Збирають адаптерів, контриб'юторів та maintainerів Backstage — тобто тих, хто вже має внутрішній developer portal на ньому, і тих, хто тільки планує його впроваджувати.
Практичний сенс один: це найдешевший спосіб подивитися, як інші команди вирішують plugin hell та catalog sync у продакшені, поки це ще не стало твоєю проблемою. Якщо твій портал працює на Backstage і ви застрягли на саморобних плагінах — CFP та програма варте одного погляду, перш ніж бронювати переліт.
🔗 Джерело
#Backstage #KubeCon #CloudNative #DeveloperPortal
Подія займає повний день понеділка, 9 листопада 2026 року, і відбувається окремою сценою перед відкриттям KubeCon + CloudNativeCon North America. Збирають адаптерів, контриб'юторів та maintainerів Backstage — тобто тих, хто вже має внутрішній developer portal на ньому, і тих, хто тільки планує його впроваджувати.
Практичний сенс один: це найдешевший спосіб подивитися, як інші команди вирішують plugin hell та catalog sync у продакшені, поки це ще не стало твоєю проблемою. Якщо твій портал працює на Backstage і ви застрягли на саморобних плагінах — CFP та програма варте одного погляду, перш ніж бронювати переліт.
🔗 Джерело
#Backstage #KubeCon #CloudNative #DeveloperPortal
CNCF
BackstageCon comes to KubeCon + CloudNativeCon North America 2026 in Salt Lake City
BackstageCon takes place all day on Monday, November 9, 2026, the day before KubeCon + CloudNativeCon North America opens in Salt Lake City. We’re excited to bring together Backstage adopters…
💯1
Цикл Kubernetes v1.37 затверджено: код-фріз 22 липня, реліз 26 серпня 2026
Розклад такий. Enhancements Freeze — 16 червня, Code Freeze і Test Freeze — 22 липня, Docs Freeze — 5 серпня. Сам v1.37.0 виходить у середу 26 серпня. Alpha вже розповсюджується по master.
Що це означає для тебе: якщо плануєш додати нову функцію у v1.37 — PR треба подати до 16 червня, інакше чекаєш v1.38. Винятки з код-фрізу подаються до 13 липня, але це вже на твій страх і ризик. KubeCon India (18-19 червня) і KubeCon Japan (28-30 липня) вписуються прямо в цикл — рецензентів буде менше, ніж зазвичай.
Мій досвід: залишай тиждень буфера до фрізу, бо останній тиждень перед Enhancements Freeze — це завжди черга з 40+ PR.
🔗 Джерело
#Kubernetes #K8s137 #CodeFreeze #ReleaseCycle
Розклад такий. Enhancements Freeze — 16 червня, Code Freeze і Test Freeze — 22 липня, Docs Freeze — 5 серпня. Сам v1.37.0 виходить у середу 26 серпня. Alpha вже розповсюджується по master.
Що це означає для тебе: якщо плануєш додати нову функцію у v1.37 — PR треба подати до 16 червня, інакше чекаєш v1.38. Винятки з код-фрізу подаються до 13 липня, але це вже на твій страх і ризик. KubeCon India (18-19 червня) і KubeCon Japan (28-30 липня) вписуються прямо в цикл — рецензентів буде менше, ніж зазвичай.
Мій досвід: залишай тиждень буфера до фрізу, бо останній тиждень перед Enhancements Freeze — це завжди черга з 40+ PR.
🔗 Джерело
#Kubernetes #K8s137 #CodeFreeze #ReleaseCycle
Kubernetes Contributors
Kubernetes v1.37 Release Information
Information regarding the current release cycle including important dates,
Release Team contact information, tracking spreadsheets and more!
Release Team contact information, tracking spreadsheets and more!
❤1
Low-code агенти: коли команда впирається в стінку техобслуговування
Знаєма історія з r/AI_Agents: Zapier, Relevance AI і Lindy дають швидко зібрати мультикракові робочі процеси без коду. Але іноді кілька людей у команді починають будувати своїх агентів — кожен з нуля переписує ті самі кроки: форматування, enrichment, інтеграції з інструментами.
Питання з треду пряме: централізований реєстр спільних інструментів і дозволів (Port.io, Backstage) під стеком — чи кожен агент живе в своєму силосі? Якщо в тебе вже >2 агенти від різних людей — це вже не питання смаку, а технічний борг. Порахуй, скільки разів у вас продубльовано один і той самий інтеграційний інструмент, і побачиш масштаб.
🔗 Джерело
#LowCode #AIAgents #Техборг #ПлатформнаІнженерія
Знаєма історія з r/AI_Agents: Zapier, Relevance AI і Lindy дають швидко зібрати мультикракові робочі процеси без коду. Але іноді кілька людей у команді починають будувати своїх агентів — кожен з нуля переписує ті самі кроки: форматування, enrichment, інтеграції з інструментами.
Питання з треду пряме: централізований реєстр спільних інструментів і дозволів (Port.io, Backstage) під стеком — чи кожен агент живе в своєму силосі? Якщо в тебе вже >2 агенти від різних людей — це вже не питання смаку, а технічний борг. Порахуй, скільки разів у вас продубльовано один і той самий інтеграційний інструмент, і побачиш масштаб.
🔗 Джерело
#LowCode #AIAgents #Техборг #ПлатформнаІнженерія
Reddit
From the AI_Agents community on Reddit
Explore this post and more from the AI_Agents community
👍1