Канал Tech With Tim відомий практичними розборами інструментів для розробників. У свіжому великому гайді автор показує, як перетворити PyCharm на середовище для професійної AI‑розробки. Окремий акцент — на тому, як навчити AI‑агента працювати з вашим кодом і інфраструктурою через Model Context Protocol (MCP), правила (rules) та скіли (skills).

Це вже не про «попросити модель щось дописати», а про побудову повноцінного асистента всередині IDE, який вміє створювати репозиторії, дотримуватися ваших командних політик і виконувати повторювані воркфлоу за описом у Markdown‑файлах.

Від вибору агента до локальних моделей

У PyCharm AI‑функції працюють через «агентів» — спеціальні оболонки навколо мовних моделей. Вбудовано кілька варіантів, зокрема Junie, Claude та Codex, і між ними можна вільно перемикатися в панелі AI Assistant.

Окремо підкреслюється: якщо стандартних агентів недостатньо, їх можна розширювати.

Автор наголошує, що в PyCharm «можна встановити інші типи агентів з ACP directory… якщо хочете використовувати локальну модель, ви на 100% можете це зробити». ACP‑директорія тут виступає як каталог сторонніх агентів, які можна під’єднати до IDE, не обмежуючись JetBrains‑кредитами чи вбудованими підписками.

Також у налаштуваннях є розділ Providers and APIs, де можна:

• під’єднати власний обліковий запис для GPT замість підписки JetBrains;
• додати сумісних провайдерів, зокрема локальні: згадуються опції на кшталт LM Studio та Ollama, які під’єднуються через URL і дозволяють використовувати локальні моделі без хмарних викликів.

Ключовий момент: агент — це не сама модель, а «harness», набір інструментів, контекстної логіки та інтеграцій навколо моделі. Власне MCP‑сервери, правила і скіли живуть саме в цьому шарі.

Як підключити GitHub через MCP у PyCharm

Щоб AI‑агент дійсно працював із вашим кодом і репозиторіями, його потрібно «прив’язати» до зовнішніх сервісів. Для цього у PyCharm інтегрований Model Context Protocol.

Логіка роботи така: у вас є AI‑агент у PyCharm, а MCP‑сервери надають йому інструменти — наприклад, API для роботи з GitHub. Далі агент може викликати ці інструменти самостійно, виконуючи завдання з чату.

Автор демонструє повний шлях підключення GitHub MCP‑серверу.

По‑перше, потрібно знайти відповідні налаштування: «Щоб потрапити до MCP servers, я можу піти в settings і просто пошукати MCP… знайду Model Context Protocol і клікну у в’ю». Після цього вікно налаштувань дозволяє додавати нові MCP‑конфігурації.

Далі обирається варіант через HTTP, а конфігурація для GitHub MCP серверу береться з офіційної документації GitHub. У PyCharm створюється запис з типом, URL та заголовками. У полі Authorization використовується Bearer‑токен.

Критичний крок: «Я збираюся замінити це значення тут моїм GitHub personal access token… і тоді можу натиснути, і воно має під’єднатися». Для цього в GitHub у профілі через Developer settings створюється personal access token (класичний), з правами принаймні на repo і user. Згенерований токен вставляється в поле Authorization у форматі Bearer <token>.

Після збереження конфігурації MCP у PyCharm з’являється можливість протестувати, чи бачить агент підключений GitHub MCP‑сервер. У чаті достатньо запитати агента, чи він з’єднаний та які інструменти йому доступні. За потреби допомагає створення нового чату, щоб сесія «побачила» нову конфігурацію.

Коли Git стає інструментом агента

Після успішного підключення GitHub MCP‑серверу агент отримує доступ до дій із Git, які раніше вимагали ручної роботи в CLI або клієнті Git. Тепер це робиться через звичайний текстовий запит в AI‑чаті.

Формулювання з прикладу звучить однозначно: «Тепер будь‑що, що ми хочемо робити з Git, ми можемо просто сказати агенту… зроби новий публічний GitHub‑репозиторій і запуш усі код із цього проєкту». Агент використовує GitHub MCP як «руки», які створюють репозиторій, налаштовують remote origin і штовхають туди код.

У наведеній демонстрації агент:

• створює новий публічний репозиторій на GitHub;
• додає його як remote origin для локального Git‑репозиторію в проєкті PyCharm;
• пушить весь код у цей репозиторій.

В IDE усе це прозоро відслідковується у вікні Git: видно створений remote, зроблені коміти, операції з push. На GitHub у репозиторії в історії відображається, що код був завантажений спільно Tech With Tim і Junie Agent.

Такий спосіб роботи радикально змінює роль агента: він не просто «пише код», а виконує реальні дії з інфраструктурою, спираючись на інструкції MCP‑серверу та дозволи, закладені в GitHub‑токені.

Правила: постійні інструкції в кожному промпті

Щойно агент отримує інструменти, постає питання контролю. Як зробити так, щоб він поводився узгоджено з командними практиками: комітив важливі зміни, не ліз у певні частини системи або завжди робив додаткові перевірки?

Для цього в PyCharm є механізм правил (rules), які завжди додаються до контексту кожного запиту до агента. Вони зберігаються як Markdown‑файли в окремій директорії проєкту.

«Rule — це те, що завжди буде інжектитись у промпт щоразу, коли ви спілкуєтесь з агентами… я можу сказати: завжди коміть усі великі зміни в Git перед тим, як продовжити». У прикладі створюється правило always commit.md в папці AI Assistant rules. У ньому прописується проста, але показова інструкція: «Завжди коміть усі великі зміни в Git перед тим, як продовжити».

PyCharm дозволяє обрати, як застосовується правило (наприклад, глобально для проєкту або для певних сценаріїв). Після цього воно стає частиною контексту кожної взаємодії агента з цим кодовим базисом.

Важлива деталь: такі правила варто додавати до Git‑репозиторію, щоб інші члени команди успадковували той самий набір інструкцій. Тоді AI‑асистент працює за єдиними правилами для всіх розробників, що підвищує передбачуваність змін, зроблених агентом.

Скіли: задокументовані воркфлоу, які читає агент

Якщо правила задають загальні поведінкові норми, то скіли відповідають за повторювані сценарії роботи. Це окремий рівень над інструментами MCP: замість того щоб кожного разу довго пояснювати агенту, як саме деплоїти сервіс чи проводити аудит безпеки, це можна один раз описати в skill‑файлі.

У PyCharm це формулюється так: «Skill — це повторно використовуваний workflow, який агент може динамічно читати, коли йому треба зробити щось задокументоване чи часте». Скіли зберігаються у вигляді Markdown‑документів у спеціальній директорії для конкретного агента.

Skill hub: вбудований каталог готових сценаріїв

Для керування скілами в PyCharm є окремий інтерфейс. У налаштуваннях достатньо пошукати «skills»: «Є skill hub, вбудований у PyCharm… ви можете встановлювати готові skills або імпортувати свої, просто поклавши їх у правильну папку».

У Skill Hub можна:

• переглядати встановлені скіли;
• шукати нові за ключовими словами (наприклад, для бекенд‑розробки чи безпеки);
• встановлювати їх для конкретних агентів (скажімо, для Codex або Junie).

Як приклад показується встановлення скіла з рекомендаціями з безпеки. Після інсталяції цей workflow стає доступним агенту, і той може використовувати його при відповідних запитах.

Власні скіли: від структури проєкту до складних процесів

Окрім каталогу, PyCharm дозволяє створювати власні скіли. Це можна зробити двома шляхами: або вручну, створюючи Markdown‑файл у директорії skills потрібного агента, або прямо через агента, попросивши його «згенерувати» skill.

В одному з прикладів агенту дають завдання: створити скіл, який описує стек проєкту — які фреймворки та інструменти використовуються, щоб надалі можна було швидко пояснювати це будь‑якому учаснику процесу. У відповідь агент генерує новий skill‑файл у директорії Junie, із назвою й описом, після чого цей документ стає частиною проєкту.

Коли скіл створено, агент може його читати. Якщо у чаті дати запит на кшталт «Який стек у цього проєкту? Використовуй skill project stack», агент:

• оновлює інформацію про доступні скіли (у чаті видно повідомлення типу skills update);
• читає вміст відповідного Markdown‑файла;
• відповідає, спираючись на його текст.

Так описується принцип роботи: «Якщо ви попросите агента зробити щось, що передбачає використання skill, він має використати його автоматично… він читає skill‑документ». Це означає, що добре продумані скіли фактично перетворюють ваші внутрішні процедури, гайди й чеклісти на частину «пам’яті» агента, доступну йому в режимі реального часу.

Як це все працює разом

Зв’язка «агент + MCP + правила + скіли» у PyCharm формує більш зрілий рівень AI‑асистента в IDE:

• MCP‑сервери розширюють агента реальними інструментами — від GitHub до інших сервісів, з якими він може працювати через API.
• Правила задають рамки поведінки, які постійно вшиваються в кожну взаємодію: звичні для команди практики (наприклад, обов’язкові коміти) перетворюються на «закон» для агента.
• Скіли описують конкретні повторювані або складні воркфлоу — від деплою до безпекових перевірок — і дозволяють агенту виконувати їх без багаторазового пере-пояснення.

У результаті AI‑агент перестає бути просто «розумним автодоповненням» і стає інструментом, який розуміє ваш стек, дотримується командних практик і може самостійно працювати з інфраструктурою проєкту через стандартизований протокол.

Для команд, які будують серйозні AI‑асистенти в IDE, підхід, продемонстрований у цьому відео, показує, що ключ до контрольованого й корисного агента не в «найпотужнішій моделі», а в хорошій інтеграції MCP, чітко прописаних правилах і грамотно задокументованих скілах.

Джерело

How I Set Up Python for Professional AI Development — Tech With Tim

Правильно обрати звук будильника — ціле мистецтво. Він не має бути надто приємним, щоб ви із задоволенням слухали його ще кілька хвилин замість того, щоб робити заплановані справи. Але й надто дратівливим він бути не повинен — інакше настрій зранку буде зіпсований, поки ви вибираєтеся з ліжка, щоб його вимкнути (ви ж тримаєте свій iPhone поза зоною досяжності, коли спите, правда?). Деякі стандартні рінгтони та звуки будильника в iOS можуть якраз надто дратувати. На щастя, на iPhone досить легко налаштувати власний звук будильника.

Якщо ви хочете використовувати певну пісню, найпростіше це зробити, якщо ви підписані на Apple Music. Сервіс має понад 100 мільйонів треків, і будь-який із них можна поставити як звук будильника. Спочатку додайте потрібну композицію до своєї медіатеки. Для цього відкрийте додаток Apple Music, знайдіть пісню, яку хочете використовувати як будильник, і натисніть значок плюса (+) поряд з потрібним результатом, щоб додати її до медіатеки.

Потім відкрийте додаток «Годинник» на iPhone і перейдіть на вкладку «Будильник» внизу екрана. Ви можете натиснути значок плюса, щоб створити новий будильник, або вибрати вже наявний. Далі виберіть «Звук» > «Обрати пісню». Знайдіть трек, який хочете використати, натисніть кнопку плюса поруч із ним, потім стрілку «Назад» і, нарешті, «Зберегти» або позначку в правому верхньому куті. На цьому все.

Якщо ж ви хочете повністю свій, кастомний звук будильника на iPhone, доведеться діяти інакше.

Спершу потрібно отримати аудіо, яке ви хочете використовувати. Наприклад, можна завантажити звуковий файл з інтернету або створити його в додатку на кшталт GarageBand. Як саме ви дістанете аудіо — ваш вибір. Важливо те, що зберегти цей звук потрібно в додатку «Файли».

Починаючи з iOS 26, Apple максимально спростила використання збереженого аудіофайлу як власного звуку будильника на iPhone. Знайдіть потрібний файл у «Файлах» і зробіть довге натискання на ньому. Потім виберіть «Поділитися» > «Використати як рінгтон» (якщо тривалість звуку перевищує 30 секунд, iPhone запропонує обрізати його до цього ліміту). Після цього ваш кастомний звук буде встановлено як рінгтон. За потреби ви завжди можете змінити його назад.

Тепер відкрийте додаток «Годинник». Створіть новий будильник або торкніться наявного. Натисніть «Звук» і виберіть свій власний звуковий файл. Готово — будильник звучатиме саме так, як ви захотіли. Якщо тільки ви не вирішили ще й повернути попередній рінгтон.

Поява пункту «Використати як рінгтон» у меню «Поділитися» в iOS 26 означає, що ви також можете використати аудіо, яке хтось надіслав вам, наприклад, через iMessage чи електронну пошту. Тож, за бажання, можна обрізати голосове повідомлення друга і зробити його звуком будильника. А якщо хочете зовсім оригінально, запишіть власний голос у «Диктофоні» і пройдіть той самий шлях «Поділитися» > «Використати як рінгтон», щоб прокидатися під звук власних слів.

Джерело

Engadget

Стартап Clicks Technology, який готується запустити власну інтерпретацію смартфона BlackBerry, показав, що саме отримає користувач, у новому відео, опублікованому сьогодні.

Пристрій під назвою Clicks Communicator вперше представили на виставці Consumer Electronics Show (CES) у Лас-Вегасі в січні. Його створили для людей, які багато працюють зі смартфона, зокрема постійно пишуть повідомлення та листи. Насамперед новинка орієнтована на тих, хто сумує за фізичною клавіатурою BlackBerry, яку досі вважають зручнішою для таких задач.

За ціною $499 Communicator виглядає так, яким міг би бути сучасний BlackBerry: дисплей для перегляду та відповіді на повідомлення і тактильна, чутлива до дотику клавіатура під ним.

Втім, телефон не обмежується роллю копії BlackBerry й пропонує низку власних рішень. Наприклад, фірмова функція Signal Light — це кнопка з підсвічуванням на боковій грані, яку можна налаштовувати різними кольорами та світловими патернами. Вони відображатимуть, від кого саме надійшли повідомлення — певних людей, груп чи застосунків.

Смартфон також підтримує змінні задні кришки, які можна легко знімати й міняти, має 3,5‑мм аудіорозʼєм, лоток для фізичної SIM‑карти (додатково до eSIM), слот для карт microSD обсягом до 2 ТБ, а також окремий тумблер для швидкого вмикання та вимикання режиму польоту.

Clicks Communicator може зацікавити й тих, хто прагне дистанціюватися від сучасних смартфонів з їхніми затягувальними соцмережами та іграми. Компанія співпрацює з Niagara Launcher, який забезпечує доступ до Android‑застосунків, що працюють на пристрої. Завдяки Signal Light можна спокійно ігнорувати телефон, доки не зʼявиться справді критичне сповіщення.

У новому відео компанія демонструє передсерійний зразок пристрою та внутрішнє програмне забезпечення — як превʼю того, що чекає на покупців, коли смартфон почнуть відвантажувати у четвертому кварталі цього року.

На CES журналісти TechCrunch мали змогу потримати в руках прототип Communicator, який був за розмірами та вагою таким самим, як версія, що готується до запуску наприкінці року. Пристрій зручно лежав у руці, не був ані надто легким, ані надто важким, його легко тримати. Клавіші мали чіткий «клікаючий» хід, завдяки чому відчуття було дуже схожим на BlackBerry. Водночас команда планувала трохи змінити зусилля натискання, щоб пристрій краще підходив для швидкого набору тексту.

У наступних відео компанія обіцяє детальніше розповісти про окремі можливості Clicks Communicator — Signal Light, кнопку Prompt Key, Message Hub, сенсорну клавіатуру та інші функції.

Джерело

TechCrunch

Google у вівторок представила Nano Banana 2 Lite — оновлену версію власного генератора відео та зображень на базі ШІ. За заявою компанії, нова модель суттєво швидша та дешевша за попередній реліз.

Модель має значно нижчу затримку й здатна генерувати зображення за чотири секунди. Це робить її зручною для сценаріїв, коли потрібно швидко «проганяти» багато варіантів картинок і створювати їх у великій кількості, кажуть у Google. Вартість становить $0,034 за 1000 зображень, що робить сервіс досить доступним для тих, хто хоче масово створювати й вдосконалювати контент.

Цей реліз продовжує лінійку, започатковану торік після запуску оригінальної Nano Banana на базі Gemini 3.1 Flash, а також лютневої Nano Banana 2. Остання додала генератору можливість створювати більш реалістичні зображення. Окремо компанія пропонує Nano Banana Pro — більш потужну (і дорожчу) модель для складніших сценаріїв використання.

Якщо Nano Banana 2 у Google називають «універсальним робочим конем», то Banana 2 Lite, за словами компанії, оптимізована під високонавантажені процеси, де важлива швидкість опрацювання великого обсягу запитів.

Попри критику з боку користувачів так званого «AI‑мотлоху», який масово створюють генеративні моделі зображень, компанії продовжують активно інвестувати в інструменти для створення картинок і відео. Водночас Google часто просуває свої моделі як зручні інструменти для підготовки рекламних матеріалів.

Паралельно посилюються зв’язки між Голлівудом та AI‑компаніями — на невдоволення частини креативних спільнот і аудиторій. Зокрема, Google нещодавно уклала угоду на $75 млн з популярною незалежною студією A24 — партнерство, яке вже зазнало суттєвої критики з боку фанатів.

Nano Banana 2 Lite вже доступна через Google AI Studio та Gemini API, а також на платформі Google Gemini Enterprise Agent. У Google зазначають, що вона замінює оригінальну Nano Banana, яку тепер називають «застарілою моделлю».

Також у вівторок Google оголосила про ширший реліз Gemini Omni Flash, вперше показаної на Google I/O цього року. Вартість Flash становить $0,10 за секунду відеовиходу. Додатково компанія продемонструвала новий демо‑додаток Omni Product Studio, який, за її словами, може брати статичні зображення, згенеровані Omni, й перетворювати їх на «кінематографічні e‑commerce відео».

Джерело

TechCrunch

Netflix співпрацював із компанією ElevenLabs, щоб створити реконструкцію голосу Джина Вайлдера для нового нереального реаліті-шоу, натхненного романом Роальда Даля «Чарлі і шоколадна фабрика». Вайлдер зіграв власника шоколадної фабрики Віллі Вонку в екранізації 1971 року, і згенерована ШІ версія його голосу прозвучить у змагальному шоу з випробуваннями, заснованими як на книзі, так і на фільмі.

За даними Variety, голос відтворювали у співпраці зі спадкоємцями Вайлдера та за згодою його дружини, що виглядає мінімально необхідним жестом пристойності, коли йдеться про цифрове «повернення» померлого артиста. Але, як часто буває з історіями про ШІ-імітації знаменитостей, головне питання залишається тим самим: навіщо?

Схоже, що штучно відтворений голос Вайлдера вже використовується в трейлері шоу, і він справді нагадує його інтерпретацію Віллі Вонки. Водночас це моторошно — чути знайомий тембр у закадровому тексті до відео з павільйону, який радше нагадує уявлення продюсерів про «казковість». Так, образ хаотичного шоколатьє став однією з найзнаковіших ролей Вайлдера (хоча він також широко відомий завдяки численним ролям у фільмах Мела Брукса). Але Віллі Вонка народився як літературний персонаж і давно став полем для переосмислення іншими акторами. Вайлдер, можливо, був найкращим, але точно не єдиним, хто втілював цей образ.

Перша реакція на таку новину — підозра, що витрачати гроші на спробу відтворити конкретну гру актора за допомогою ШІ — це одночасно і піар-хід для привернення уваги, і спосіб не платити живому актору за подібну роботу. Автор допускає, що може помилятися й що все вийде достатньо тактовно, щоб це оцінили і фанати, і критики ШІ. Але особливих сподівань на це немає.

Джерело

Engadget

У 2026‑му інтеграція штучного інтелекту в IDE перестала бути «фічею для галочки» й перетворилася на повноцінний робочий шар над кодом. Один із тих, хто системно показує, як це виглядає в реальному розробницькому середовищі, — популярний техноблогер Tech With Tim. У великому гайді зі свого робочого сетапу він детально розібрав, як PyCharm працює з AI‑агентами, різними моделями та локальними LLM — від підключення Claude і GPT до Ollama та LM Studio.

Це не історія про ще один «чатик збоку», а про те, як IDE перетворюється на універсальний хаб для керування моделями та інфраструктурою навколо них.

Не лише JetBrains: IDE як універсальний AI‑хаб

Ключова ідея: розробник не має бути прив’язаний до одного вендора чи одного агента. У PyCharm AI‑шар побудований як відкрита система, де базовий JetBrains‑агент — лише опція за замовчуванням, а не обмеження.

У вікні AI Assistant користувач може обрати агентів на кшталт Claude Code, Codex або Junі і працювати з ними безпосередньо з редактора. Це знімає типову для багатьох IDE прив’язку до «рідного» AI‑сервісу. Наявний каталог агентів (через ACP‑директорію) дає змогу додавати сторонні рішення, а не чекати офіційних інтеграцій.

Таким чином, PyCharm виступає не як «оболонка для одного асистента», а як платформа, що дозволяє:

• обирати різні агентні обв’язки над моделями,
• комбінувати їх в одному проєкті,
• перемикатися між ними залежно від задачі.

Це важливо саме для професійних сценаріїв: команди й окремі інженери можуть експериментувати з різними агентами та не ламати при цьому основний воркфлоу в IDE.

Агент проти моделі: що тут насправді головне

Ще одне принципове розділення — між агентами та моделями. У класичному уявленні «модель = сервіс, з яким ви спілкуєтеся». У PyCharm усе інакше: модель — лише «двигун», а реальну поведінку визначає агентний шар над нею.

Агент описується як coding harness — спеціалізований набір інструментів, який запускає підлеглу модель і обгортає її додатковими можливостями. Власне LLM «просто перетворює текст у текст», тоді як агент:

• додає інструменти (від роботи з файлами до виклику MCP‑серверів),
• займається контекст‑інжинірингом,
• реалізує специфічну логіку взаємодії з кодом та IDE.

Claude, Codex, Juni у цьому підході — це не «ще одні моделі», а саме agent harnesses або model harnesses, які надають свої набори функцій і спосіб роботи з тією ж самою підлеглою моделлю.

Показовий момент: всередині одного агента (наприклад, Juni) можна вибрати модель GPT 5.5, а потім переключитися в агент Codex — і там теж використати GPT 5.5. Різниця не в моделі, а в harness або інфраструктурі навколо моделі. Одна і та ж LLM поводитиметься інакше, тому що:

• агенти по‑різному формують промпт,
• по‑різному керують інструментами,
• по‑різному організовують контекст.

Цим пояснюється знайомий багатьом ефект: дві різні IDE чи два різні AI‑асистенти «на одному й тому ж GPT» дають зовсім різну користь у реальному проєкті. У PyCharm це розділення винесено на рівень інтерфейсу: розробник явно обирає не просто модель, а поєднання «агент + модель».

Як IDE дозволяє обійтися без JetBrains‑кредитів

Для багатьох інженерів критичною є можливість контролювати, через чий тариф ідуть AI‑запити. PyCharm не зачиняє користувача в моделі монетизації JetBrains.

У налаштуваннях Providers and APIs можна переглянути, які агенти на що «підписані». Наприклад:

• Claude агент може працювати через JetBrains AI subscription,
• Juni повністю керується JetBrains‑обліковкою.

Та ключовий момент у тому, що розробник може підключити власний GPT‑акаунт. Достатньо залогінитися зі своїм ChatGPT (або відповідним обліковим записом), і далі будь‑яке використання піде через особисту підписку, а не JetBrains AI.

Це дає одразу кілька наслідків для професійного середовища:

• компанія може використовувати корпоративний GPT‑акаунт із власними політиками,
• не потрібно купувати додаткові кредити в JetBrains, якщо інфраструктура вже побудована навколо окремих AI‑постачальників,
• розробник не втрачає доступ до улюбленої IDE, навіть якщо JetBrains‑підписка обмежена, зате є оплачені токени в іншому сервісі.

Фактично PyCharm перетворюється на тонкий клієнт, який уміє маршрутизувати запити до різних бекендів, не втручаючись у фінансові чи облікові схеми компанії.

Від хмари до локалки: Gemini, Ollama, LM Studio та інші провайдери

Ще одна важлива грань — підтримка не лише хмарних, а й локальних та сумісних із OpenAI постачальників. У тих же налаштуваннях Providers and APIs доступна можливість додати:

• провайдери на кшталт Gemini,
• будь‑що сумісне з OpenAI API,
• локальні хости на базі LM Studio,
• локальні інстанси через Ollama.

Сценарій підключення локальної моделі виглядає доволі прямолінійно: у списку провайдерів обирається Ollama, вказується його URL, відмічаються потрібні функції — і після цього можна починати використовувати локальні моделі в AI‑чаті IDE. Аналогічно з LM Studio: PyCharm підключається до нього, і всі моделі, підняті там, стають доступними безпосередньо з редактора.

Це суттєво змінює картину для команд, які:

• працюють з чутливими даними й не можуть виводити код у хмару,
• тестують експериментальні локальні LLM,
• будують гібридну інфраструктуру, де частина запитів іде в хмару, а частина — на локальний GPU.

IDE в цьому випадку стає єдиною точкою входу, з якої розробник може непомітно для себе «перестрибувати» з хмарного GPT 5.5 на локальну модель в LM Studio, змінюючи лише налаштування провайдера.

Коли «агент важливіший за модель»

На практиці все це веде до доволі нетривіального висновку: у повсякденній роботі розробника різниця між моделями часто менш помітна, ніж різниця між agent harnesses.

Саме harness:

• вирішує, які інструменти підключати (MCP‑сервери, робота з Git, БД, файловою системою),
• структуровано підсовує моделі релевантний код,
• реалізує правила й скіли (рутини типу «як у цьому проєкті деплоїться сервіс»),
• адаптує поведінку моделі до конкретної IDE й стеку.

У результаті той самий GPT 5.5 під Juni всередині PyCharm буде поводитися не так, як під іншим агентом у сторонній системі. IDE‑інфраструктура додає «важку артилерію» у вигляді:

• правил, які завжди інжектяться в промпти,
• скілів, що документують та автоматизують повторювані воркфлоу,
• підключених MCP‑серверів, наприклад GitHub MCP для роботи з репозиторіями.

Саме ця надбудова робить AI інструментом професійної розробки, а не просто «розумним автодоповненням».

Висновки: IDE як фронтенд до вашої AI‑інфраструктури

Підхід, який демонструє PyCharm, показує, як може виглядати зріла інтеграція AI в робоче середовище програміста. Кілька принципів тут особливо помітні:

• агентний шар відділено від моделей, і саме він визначає характер взаємодії з кодом;
• IDE не нав’язує одного постачальника — можна використовувати Claude, Codex, Juni, власний GPT‑акаунт чи локальні LLM;
• PyCharm працює як універсальний фронтенд до AI‑інфраструктури: від хмарних API до локальних хостів, не руйнуючи звичний дебаг, навігацію та роботу з БД.

Для розробників це означає, що вибір IDE більше не зводиться до питання «чи є там AI‑підказки». Насправді ключове — наскільки IDE дозволяє керувати агентами, провайдерами й локальними моделями, не змінюючи інженерних практик. У цьому сенсі PyCharm показує приклад того, як можна поєднати класичний інструментарій професійної розробки з гнучким, але контрольованим використанням LLM у повсякденній роботі.

Джерело

How I Set Up Python for Professional AI Development — Tech With Tim

Онлайн-освітня платформа Futurepedia у своєму великому гайді з OpenAI Codex показує не теоретичні можливості агента, а цілком приземлений кейс: як перетворити хаотичну бізнес‑папку з логами продажів, рахунками та інвентаризаціями на структурувану систему даних і повноцінний HTML‑дашборд для власника малого бізнесу.

Вихідні дані: «сміттєва» папка з реального комп’ютера

Для демонстрації використовується не демонстраційний сет, а справжня папка на комп’ютері творця відео. У ній «звалені» різні робочі файли одного бізнесу: логи продажів, інвойси, інвентаризації та інші документи, пов’язані з умовною кав’ярнею «The Context Window».

Файли — різного типу: електронні таблиці, PDF та зображення. Структури немає: усе лежить в одному місці, як це часто буває в невеликих бізнесах, де документи накопичуються поступово й без єдиних правил.

Саме цю папку Codex отримує як «проєктну» директорію, всередині якої йому дозволено працювати: аналізувати документи, переміщувати їх, редагувати й створювати нові.

Перший крок: автоматичне прибирання та майстер-таблиця

Початкове завдання звучить максимально по-людськи: є «безладна папка з мого кафе», треба її розчистити та звести інформацію в одну таблицю, щоб зрозуміти, «що відбувається з бізнесом».

Codex отримує інструкцію:

– впорядкувати файли, розклавши їх по логічних підпапках;
– створити одну електронну таблицю, що «підтягує все разом» — продажі, витрати, інвентаризацію тощо.

Через кілька хвилин папка змінюється до невпізнання. Перший результат — сама структура: з’являються чітко підписані підпапки, у кожній з яких лежать відповідні файли. Хаотичний набір документів перетворюється на базову файлову систему, побудовану без участі власника.

Другий результат важливіший для аналітики: у проєктній папці виникає новий файл — «майстер‑таблиця» з різними вкладками. У цих вкладках зібрано ключові зрізи інформації з усіх джерел. Творець відео наголошує, що Codex не просто зібрав дані з таблиць, а й витягнув інформацію з PDF‑інвойсів і привів позначення інвентарю до зручного для читання формату.

Окремо зазначено, що агент самостійно виявив частину помилок і розбіжностей у даних. У файлі‑результаті не тільки зведені показники, а й перелік помилок та проблемних місць із позначеннями пріоритетності — що вимагає уваги в першу чергу, а що може почекати. Для власника малого бізнесу це фактично автоматизований аудит даних без участі бухгалтера чи аналітика.

Усе це можна переглядати прямо в інтерфейсі Codex через вбудоване прев’ю, але файли фізично живуть у вихідній папці, без додаткових завантажень чи експорту — агент працює безпосередньо у файловій системі.

Від таблиці до HTML‑дашборду: як Codex мислить планом

Наступний крок — побудувати з майстер‑таблиці дашборд для власника. Для цього Codex отримує чітко визначений вхід: конкретний файл‑таблиця, позначений через @‑посилання, і завдання:

на основі цієї таблиці створити «візуальний дашборд власника для Context Window», який дає змогу легко побачити стан кафе, зрозуміти продажі, витрати, робочу силу, проблеми з інвентарем і сфокусуватися на тому, що потребує уваги.

Перед запуском побудови вмикається режим планування (plan mode). Це ключовий режим для складних завдань: Codex спочатку «продумує все й розкладає план», а вже потім щось будує. Замість того, щоб одразу генерувати код або візуалізації, агент готує поетапний план робіт, ставить уточнювальні запитання, збирає додаткові вподобання щодо формату й тільки після затвердження переходить до реалізації.

У цьому випадку Codex запитує, яким має бути формат дашборду. Серед опцій обирається HTML‑дашборд і рекомендований варіант структури на кшталт «owner command center». Після відповіді агент починає виконання плану. Користувач водночас може вести паралельні чати в межах того самого проєкту, наприклад, попросити Codex перелічити знайдені раніше помилки в даних, не зупиняючи роботу над дашбордом.

Режим планування дає ще одну важливу можливість: під час довгого обчислювального процесу можна надіслати додаткові інструкції без переривання поточного завдання. Для цього використовується спеціальний спосіб відправлення, при якому повідомлення йде як «керування» (steer), а не як скасування або перезапуск запиту.

У результаті план формується як деталізований опис структури майбутнього дашборду, списку блоків, логіки обчислення показників і візуальних компонентів. Користувач може затвердити цей план або попросити корекції ще до того, як Codex напише жоден рядок коду.

Готовий дашборд: показники, пріоритети та графіки

Після виконання плану, що триває близько десятка хвилин, формується готовий HTML‑дашборд. У підсумковому огляді видно, що Codex:

обчислює всі ключові підсумки на основі даних з майстер‑таблиці;
виводить зверху блок із «опціями» — агрегованими показниками, які зручно переглядати власнику;
використовує кольорове кодування для виділення елементів, що потребують перегляду, та «високопріоритетних дій»;
генерує низку графіків і візуальних блоків — від проблем з інвентарем та топ‑продавців до списку конкретних action items.

Усе це — у форматі HTML‑сторінки, яка, за словами автора, виглядає адаптивною (reactive) і має добре відображатися на мобільних пристроях. Важливо, що побудова відбувається з першої спроби без ручного доопрацювання коду з боку користувача.

Якщо ж потрібно щось змінити, взаємодія залишається розмовною. Щоб, наприклад, додати інтерактивність, достатньо сформулювати прохання:

зробити дашборд інтерактивним із hover‑станами на кшталт графіка продажів, щоб при наведенні відображалися точні значення.

Codex оновлює дашборд протягом кількох хвилин, після чого при наведенні курсора на точки графіка з’являються точні числові показники. Тобто навіть тонкі деталі взаємодії з інтерфейсом задаються простою мовою, без необхідності лізти в JS‑код чи бібліотеки візуалізації.

Помилки, очищення й контроль: як агент працює з «брудними» даними

Окремий аспект кейсу — робота Codex із неідеальними, «брудними» даними. У вихідній папці навмисно допущені пропуски полів, помилки та неузгодженості. Після початкового прибирання й зведення таблиці агент:

виявляє частину цих некоректностей автоматично;
витягує інформацію з PDF‑інвойсів у структурований вигляд;
формує перелік помилок та «питань, що потребують уваги», до того ж розставляє рівні пріоритетності.

Такий підхід означає, що власнику не потрібно спочатку вручну чистити всі файли, а потім уже будувати аналітику. Навпаки, агент сам виступає «фільтром першого рівня», який приводить дані до прийнятного стану, позначає проблемні місця й підказує, що треба виправити в першу чергу.

Це важливо й у контексті подальших кроків. Наступні запити — на кшталт побудови дашборду чи запуску регулярних оновлень — спираються вже на структурований масив даних, а не на той «смітник», що був на початку.

Висновок: агент як «операційний шар» малого бізнесу

Показаний кейс з контекстною кав’ярнею демонструє Codex не як черговий «чат‑бот», а як інструмент, що закриває цілий пласт рутинної роботи малого бізнесу:

від хаотичного скидання файлів у папку до продуманої структури з підпапками;
від розрізнених логів, чеків і PDF до єдиної майстер‑таблиці;
від ручного пошуку помилок до автоматизованого списку помилок і пріоритетних задач;
від сухих таблиць до інтерактивного HTML‑дашборду з пріоритизацією дій для власника.

Усі ці переходи відбуваються без написання коду зі сторони користувача — лише через послідовні природномовні інструкції, від простого «прибери папку й створи одну таблицю» до «зроби дашборд інтерактивним із hover‑станами».

Такий підхід показує, як агенти на кшталт Codex можуть перетворюватися на операційний шар для малого бізнесу: працювати з файловою системою, чистити й структурувати дані, виявляти помилки й виносити їх у пріоритет, а потім будувати поверх цього візуальні інструменти прийняття рішень, які оновлюються за запитом або за розкладом.

Джерело

Full OpenAI Codex Tutorial: Beginner to Advanced — Futurepedia

Anthropic представила нову версію Claude, розраховану на опрацювання запитів не лише від людей, а й від агентних (agentic) ІІ-систем. Компанія стверджує, що її нова модель Sonnet 5 здатна виконувати агентні задачі й забезпечує продуктивність, подібну до нещодавніх моделей Opus, але за нижчою вартістю.

Починаючи з 1 вересня, Sonnet 5 коштуватиме 3 долари за мільйон вхідних токенів (базовий тариф) і 15 доларів за мільйон вихідних токенів. До цієї дати ціни будуть ще нижчими. Для порівняння, Opus 4.8 зараз коштує 4 долари за мільйон вхідних токенів і 25 доларів за мільйон вихідних токенів. Sonnet 5 буде доступною за цими тарифами в Claude Code та на платформі Claude.

Sonnet 5 також буде доступною для всіх підписок, зокрема як модель за замовчуванням для безплатного та pro-тарифів Claude від Anthropic.

Джерело

Engadget

«Автоматизований рак-робот» дістається й до мобільних пристроїв.

Йдеться про OpenClaw — безкоштовного, відкритого AI-агента, який на початку цього року підкорив інтернет. Тепер OpenClaw нарешті доступний як застосунок для iOS та Android. Про це команда OpenClaw повідомила у X у вівторок.

На обох платформах ви можете поєднати свій смартфон з OpenClaw Gateway — своєрідним маршрутизатором, який з’єднує ваші запити з AI-агентами та інструментами й навичками, на які вони спираються, щоб виконувати завдання.

Це означає, що ви зможете запускати своїх агентів OpenClaw фактично з кишені — і, якщо ви їх коректно запрограмували, вони можуть виявитись доволі корисними для вирішення повсякденних задач. Користувачі OpenClaw вже застосовували його для всього — від програмування до планування харчування, хоча дехто повідомляв і про не надто вдалі результати.

OpenClaw став вірусним раніше цього року на хвилі запуску MoltBook — соцмережі, де, як стверджується, усі користувачі є агентами. У лютому творець OpenClaw, Петер Штайнберґер, оголосив, що приєднався до OpenAI.

Джерело

TechCrunch

Amazon погодилася сплатити $2,25 млн цивільних штрафів для врегулювання справи з Федеральною торговою комісією США (FTC), що стосується жертв крадіжки особистих даних. Регулятор заявив, що техногігант порушив Закон про чесну кредитну звітність (Fair Credit Reporting Act, FCRA), коли відмовлявся надавати цим жертвам, а в окремих випадках і правоохоронним органам, дані про транзакції з його онлайн-магазину. Компанія поки не прокоментувала мирову угоду.

Згідно з FCRA, компанії зобов’язані надавати людям, чиї особисті дані були викрадені, відомості про шахрайські транзакції, здійснені від їхнього імені, протягом 30 днів з моменту звернення споживача.

У скарзі FTC стверджується, що співробітники служби підтримки Amazon відмовляли частині таких клієнтів, посилаючись на міркування безпеки або конфіденційності. В інших випадках представники компанії нібито повідомляли жертвам, що не можуть отримати необхідні записи. У тих випадках, коли Amazon все ж надавала інформацію, це іноді відбувалося з порушенням 30-денного строку.

Джерело

Engadget

Найімовірніше, незабаром відбудеться черговий захід Samsung Unpacked, але компанія вже почала дражнити публіку натяками на те, що ми побачимо під час наступної презентації. Серія нових відеороликів у соцмережах вказує на інше співвідношення сторін у наступного складаного смартфона Samsung.

Хоча зображень самого телефона поки немає, у відео акцент робиться на об’єктах (поламана плитка шоколаду, ледь «обезголовлений» пазл тощо), які відрізняються від стандартних габаритів смартфона. Нові пропорції виглядають нижчими та «кремезнішими», ніж у більшості подібних пристроїв на ринку, які прагнуть відтворити приблизний розмір звичайного смартфона в закритому стані, лише з більшою товщиною.

Перехід до «коробкуватішої» форми в складеному вигляді означає, що у відкритій конфігурації користувач, імовірно, отримає більш «широкоформатний» досвід, замість того щоб мати пристрій, який відчувається як товстіший планшет із майже квадратним екраном.

Джерело

Engadget

Ринок AI‑асистентів для програмування вибухнув: Claude Code, Codex, Cursor, Copilot, Windsurf, локальні моделі — вибір величезний, а ціни й умови змінюються щомісяця. Відео Марини Wyss, сеньйор applied scientist в Twitch, стало нагодою розібратися, як підходити до вибору інструментів так, щоб не отримати «сюрприз» у рахунку й не втратити в якості коду.

Чотири типи AI‑інструментів для коду

Замість порівнювати десятки продуктів по черзі, зручніше дивитися на класи інструментів — у кожного своя логіка використання, сильні сторони й ризики з точки зору вартості.

1. «Тяжка артилерія»: термінальні агенти

Це автономні агенти, з якими працюють переважно через командний рядок.

Основні гравці:

• Claude Code (Anthropic)
• Codex (OpenAI, інтегрований у ChatGPT‑плани)

Спільні риси:

• агент‑first: ви ставите задачі, а не просто отримуєте автодоповнення під час набору;
• один постачальник моделей (Anthropic або OpenAI);
• входять до платних планів (Claude чи ChatGPT) з лімітами використання, після яких доведеться чекати ресета, оновлювати план або докуповувати кредити;
• окрім CLI, уже мають IDE‑та десктоп‑клієнти.

Коли Claude Code:

• складні задачі з важким «reasoning»;
• великі й комплексні зміни по всій кодовій базі;
• потрібна глибока кастомізація:
• проєктні інструкції;
• hooks;
• під‑агенти (skills);
• плагіни й MCP‑інтеграції.

Фактично це максимально налаштовуваний «парний програміст», яким можна тонко керувати.

Коли Codex:

• потрібно делегувати кілька задач одразу;
• запускати роботу локально або в хмарі;
• стежити за довгими джобами з різних девайсів;
• зручно переключатися між CLI, IDE, десктопом.

Головна перевага Codex — саме в оркестрації агентів і робочих процесів, а не в голій якості коду.

2. AI‑нативні редактори: «форки» замість плагінів

Це редактори, побудовані поверх уже відомих open source IDE (зазвичай VS Code), але з глибоко вшитим AI.

Cursor

• Позиціонується як «щоденний драйвер», один інструмент «на всі випадки».
• Модел‑агностик:
• підтримує Claude, GPT, Gemini;
• не прив’язує до одного постачальника.
• Дуже низький поріг входу, зручний UX.

Слабке місце — ціна:

• тарифікація по використанню;
• при складних задачах легко «зіскочити»:
• з $20/місяць на $60;
• а потім і на $200/місяць.

Windsurf / Dev in Desktop

• Форк з інтеграцією в Dev in Desktop.
• Сильний безкоштовний тариф:
• необмежені таб‑комплішни;
• висока швидкість.
• Платні плани за структурою схожі на Cursor: після виходу за безкоштовний рівень вартість стає близькою.

За якістю обидва продукти достатньо близькі, щоб не обирати виключно «по якості коду». Cursor має більш відполірований UX і більшу спільноту, Windsurf — меншу, але стабільний і швидкий агент.

Мінімальні зміни в робочому середовищі: Copilot

Для тих, хто не хоче ставити новий редактор, є окремий клас інструментів: асистенти, що вбудовуються у ваш існуючий IDE.

GitHub Copilot:

• встановлюється як плагін у:
• VS Code;
• JetBrains;
• інші популярні IDE;
• інтегрується з GitHub (у т.ч. на рівні pull request summary);
• не змушує вчитися новому інтерфейсу;
• давно вийшов за межі «просто автодоповнення»:
• чат;
• агент‑режим для роботи з кількома файлами;
• огляди pull‑реквестів;
• також модел‑агностик: працює з Claude, GPT, Gemini.

Ціноутворення:

• безкоштовний рівень:
• 2 000 кодових автодоповнень;
• 50 чат‑запитів на місяць;
• Pro‑план від $10/місяць — дешевше, ніж більшість конкурентів.

Водночас саме Copilot став мішенню критики після переходу 1 червня 2026 року на помодельні кредити:

• з’явилася метрика AI‑кредитів;
• дешевий «fallback‑модель» забрали;
• передбачуваний фіксований платіж перетворився на потенційно нескінченну суму, якщо вийти за базові ліміти.

Ризик несподіваних рахунків тут особливо відчутний.

Локальні моделі: коли важливі контроль і стабільна вартість

Щоб повністю прибрати фактор «сюрпризів» у рахунках і зменшити залежність від політик провайдерів, частина розробників обирає локальні open‑weight моделі.

Що це дає:

• відсутність API‑платежів за моделі;
• більше контролю над тим, куди «витікає» код;
• захист від раптових змін цін, лімітів або доступності моделей у хмарі;
• можливість офлайн‑роботи.

Але важливі застереження:

• локальна інфраструктура не автоматично безпечна:
• треба перевіряти телеметрію;
• уважно ставитися до розширень, MCP‑серверів та інших інтеграцій, які можуть звертатися до зовнішніх сервісів;
• потрібне залізо й терпіння:
• встановлення й підтримка — на користувачеві;
• для «важкої» reasoning‑роботи локальні моделі все ще відстають від топових хмарних;
• агентам потрібне більше, ніж просто completion:
• здатність виконувати інструкції;
• надійно викликати інструменти;
• тримати достатній контекст.

Один із практичних варіантів: використовувати Klein як агентний шар у VS Code з моделлю, запущеною локально через Ollama.

Для машини з 16 ГБ пам’яті рекомендовано експериментувати з:

• Qwen 2.5 Code R 7B (квантизована версія, 7B параметрів);
• або:
• DeepSeek-Coder‑6.7B‑Instruct;
• полегшена версія DeepSeek‑Coder‑V2.

Результати сильно залежать від конкретного агента й параметрів квантизації, але цього достатньо, щоб оцінити, чи підходить локальний сценарій під ваші задачі.

Локальні моделі мають особливий сенс, якщо:

• є жорсткі вимоги до приватності;
• критично важлива повністю прогнозована вартість;
• потрібна робота в середовищах з обмеженим або відсутнім інтернетом.

Безпека й якість коду: роль сторонніх інструментів

Окрема лінія — перевірка безпеки та якості AI‑згенерованого коду. Один із прикладів інтеграцій — плагін Sonar для Claude Code:

• підтягує аналіз SonarQube прямо в термінал Claude Code;
• дозволяє:
• перевіряти статус quality gate;
• оцінювати ризики залежностей;
• дивитися code coverage;
• сканувати понад 450 патернів витоку секретів до того, як контент потрапить у контекст LLM;
• не вимагає переходу у браузер.

Згідно з дослідженнями Sonar, розробники, які використовують SonarQube, на 44% рідше стикаються з outage‑ами, пов’язаними з AI. У контексті масового використання генеративних інструментів це стає важливою точкою диференціації між «кодингом на відчуттях» і продакшн‑підходом.

Чому вибір інструменту важливий менше, ніж здається

Попри емоційні баталії в спільноті, верхні гравці ринку за сирою якістю уже знаходяться досить близько один до одного. На практиці набагато більше значення мають два фактори, які не залежать від бренду:

1. Дисципліна рев’ю

2. AI‑код усе одно потребує перевірки;

3. у середньому він менш безпечний;

4. відповідальність за помилки й вразливості лежить на розробнику, а не на сервісі.

5. Глибина налаштування

6. MCP‑сервери, керівні файли, правила для проєкту;

7. тонкі кастомізації, що з’являються лише після тривалого використання;
8. правильне «сприйняття» вашим інструментом конкретної кодової бази.

Саме тут і виникає справжній «множник ефективності». Його практично неможливо досягти, якщо постійно стрибати з інструмента на інструмент через FOMO.

Оптимальна стратегія:

• обрати один інструмент, який добре вписується у ваш спосіб роботи (CLI чи IDE, хмара чи локально, жорсткі бюджетні обмеження чи ні);
• вкластися в глибоке освоєння:
• налаштування контексту;
• інтеграцій;
• проєктних інструкцій;
• за потреби — мати другий інструмент іншого класу.

Згідно з опитуванням розробників 2026 року, середній досвідчений девелопер використовує близько двох AI‑інструментів:

• швидкий редактор для щоденної роботи (Copilot, Cursor тощо);
• «важкий агент» для багатофайлових змін і складного reasoning (Claude Code, Codex).

Як обрати свій стек AI‑інструментів

На вибір впливають:

• апаратні ресурси (чи потягне локальні моделі);
• бюджет і ставлення до метеринг‑моделей;
• ОС (Windows, Linux, macOS);
• вимоги до приватності;
• готовність/небажання працювати в терміналі;
• важливість можливості легко змінити провайдера моделей.

Для системного порівняння існує таблиця, де зведено:

• сильні сторони кожного інструмента;
• тип використання (термінал, редактор, хмара, локально);
• модель білінгу;
• типові сценарії застосування.

Після цього вибір перестає бути гонитвою за «єдиним правильним» продуктом і перетворюється на прагматичне рішення під конкретну ситуацію.

Джерело

Відео «Don’t waste money on the wrong AI coding tool»:
https://www.youtube.com/watch?v=drefNax1iUM

Коли десятки чи сотні користувачів одночасно звертаються до однієї мовної моделі, затримки ростуть, GPU-пам’ять забивається, а пропускна здатність падає. Канал IBM Technology пояснює, як механізми KV cache і paged attention з екосистеми VLLM дозволяють радикально зменшити латентність і витрати на інференс без оновлення «заліза».

Дві фази інференсу: де насправді виникають гальма

Щоб зрозуміти, навіщо потрібні оптимізації пам’яті, варто розділити роботу великої мовної моделі на дві ключові фази.

Prefill: обчислювальне «горло пляшки»

Після відправки довгого промпту користувач спочатку бачить паузу — «час до першого токена». Це фаза prefill:

• модель проганяє ввід крізь усі шари трансформера;
• будує математичне уявлення всього контексту;
• ще нічого не генерує, лише готується до першого вихідного токена.

Ця частина інференсу жорстко обчислювально обмежена: навантаження впирається в можливості самого GPU за FLOPS.

Decode: все впирається в пам’ять

Після появи першого токена починається decode:

• модель генерує по одному токену;
• кожного кроку їй потрібно «згадати» всі попередні токени;
• для цього вона постійно звертається до GPU-пам’яті.

На цьому етапі вже домінує не обчислювальна потужність, а доступ до пам’яті. Саме тут вступає в гру KV cache — і саме тут неефективне управління пам’яттю найболючіше б’є по латентності.

Що таке KV cache і чому без нього LLM повільні

У трансформері кожен шар для кожного токена рахує три вектори:

• query — «запит» поточного токена: що для мене важливо?
• key — «ключ», який дозволяє іншим токенам знайти цей токен;
• value — «зміст» цього токена, який враховується в увазі.

В авторегресивній генерації модель створює відповідь токен за токеном, але на кожному кроці змушена знову застосовувати механізм attention до всієї попередньої послідовності.

Без кешу це означає:

• при генерації 1000-го токена модель повторно рахує key і value для всіх 999 попередніх токенів;
• обчислення дублюються тисячі разів, що різко збільшує час відповіді.

KV cache розв’язує це просто:

• матриці key та value для вже оброблених токенів зберігаються в GPU-пам’яті;
• кожен новий токен рахує лише свої власні key, value, query;
• увага рахується поверх уже збереженої історії KV, а не перераховується з нуля.

Це типовий компроміс «пам’ять замість обчислень». Для довгих послідовностей він виправданий: головним вузьким місцем стає не обсяг операцій, а те, як саме організована пам’ять для цього кешу.

Де зникає пам’ять: фрагментація і марнування VRAM

Із KV cache з’являється новий виклик: як зберігати його ефективно, коли одночасно обслуговуються сотні запитів різної довжини?

Модель забрала 65% VRAM — і це тільки початок

Показовий приклад:

• 13-мільярдна модель рівня LLaMA 13B займає приблизно 26 ГБ VRAM лише під ваги на GPU з 40 ГБ;
• це близько 65% всієї пам’яті — ще до того, як надійшов перший запит;
• решта 35% мають вмістити KV cache для всіх активних сесій.

Саме в цих 35% традиційні сервіси LLM починають масово марнувати ресурси.

Фіксовані буфери і «гостя селять на цілий поверх»

Класичний підхід до KV cache у багатьох фреймворках:

• для кожного запиту заздалегідь виділяється великий безперервний блок пам’яті під максимальну довжину контексту;
• наприклад, при max context 2048 токенів, навіть якщо типовий користувач надсилає 200 токенів і отримує 300 — під нього все одно резервують місце під 2048.

Це призводить до:

• до внутрішньої фрагментації — значна частина виділеної області залишається порожньою;
• дослідження показують, що в таких конфігураціях 60–80% пам’яті KV cache фактично простоюють.

До цього додається зовнішня фрагментація: запити різної довжини залишають «дірки» між блоками, і в підсумку:

• загалом вільної пам’яті може бути достатньо;
• але немає одного великого безперервного сегмента, щоб розмістити новий запит.

Окрема проблема — дублювання системного промпту: якщо однаковий system prompt використовується в сотнях сесій, він часто зберігається окремо для кожної.

У сумі це різко обмежує кількість одночасних запитів, які може обробити одна GPU-карта, і вбиває масштабованість.

Paged attention: GPU-пам’ять як віртуальна пам’ять ОС

Paged attention пропонує інший підхід до зберігання KV cache, який багато в чому повторює ідею віртуальної пам’яті в операційних системах.

Розбиття кешу на «сторінки»

Замість одного монолітного буфера під кожен запит paged attention:

• розбиває KV cache на невеликі сторінки фіксованого розміру (за замовчуванням — по 16 токенів);
• кожна сторінка може бути розміщена в будь-якому місці VRAM, немає вимоги суцільного блоку;
• сторінки виділяються динамічно, за потреби, у міру росту послідовності.

Внаслідок цього:

• пам’ять використовується значно щільніше;
• внутрішня фрагментація різко зменшується;
• зовнішня фрагментація перестає бути критичною, тому що потрібні лише невеликі вільні шматки під сторінки.

Таблиця відображень замість жорстких блоків

Аби вся ця гнучкість не ламала логіку моделі, використовується проміжний рівень:

• легка таблиця сторінок відображає логічні адреси (які бачить модель) у фізичні (де сторінки реально лежать у VRAM);
• модель працює з безперервним логічним простором, навіть якщо фізично дані розкидані.

Таке «препакування» VRAM дозволяє:

• витискати максимум із тих самих 35% пам’яті під KV cache;
• піднімати кількість одночасних запитів без заміни GPU;
• уникати ситуацій, коли окрема велика відповідь блокує обслуговування інших.

Налаштування інференсу: що варто крутити в першу чергу

Механізми KV cache та paged attention уже реалізовані в open-source рушії VLLM. Щоб реально отримати виграш у продуктивності, важливо правильно виставити кілька параметрів.

1. Використання GPU-пам’яті під KV cache

Параметр GPU memory utilization визначає, яку частку доступної після завантаження ваг VRAM можна віддати під KV cache:

• типовий дефолт — 0,9 (90% залишку пам’яті);
• для стабільних навантажень має сенс підняти до 0,95, щоб вмістити більше одночасних запитів;
• якщо при сплесках трафіку з’являються Out-of-Memory (OOM) помилки, краще знизити до 0,8.

Рекомендація — обов’язково проганяти бенчмарки на цільовій моделі перед бойовим запуском. Для цього в екосистемі VLLM є інструмент guidellm.

2. Prefix caching: не рахувати однаковий початок по сто разів

Paged attention підтримує так званий prefix caching:

• кожен KV-блок хешується за своєю послідовністю токенів;
• якщо кілька запитів мають спільний префікс (наприклад, однаковий system prompt);
• вони просто посилаються на одну й ту саму область пам’яті, а не зберігають її дубльовано.

Практичні ефекти:

• у RAG-пайплайнах, багатотуровому чаті, кодових асистентах співпадіння префіксів у діапазоні 75–95% зустрічаються часто;
• час до першого токена різко скорочується, оскільки спільна частина prefill уже виконана й закешована;
• навантаження на GPU знижується, вивільняючи ресурси для decode.

3. Chunked prefill: щоб стрім не «заїкався»

За замовчуванням VLLM обробляє prefill до кінця, перш ніж знову перейти до decode. Це створює проблему:

• при надходженні довгих промптів стрімінг уже генерованих відповідей може «підвисати»;
• користувач сприймає це як стрибки латентності.

Chunked prefill вирівнює ситуацію:

• замість повного prefill нових запитів спочатку виконується decode для вже активних запитів;
• решта обчислювального бюджету заповнюється невеликими частинами prefill;
• завдяки цьому стрімінг стає стабільнішим, а нові промпти не блокують уже відкриті сесії.

Реальні розгортання показали, що з таким підходом можна отримати до 50% приросту пропускної здатності. Додатково рекомендується збільшити параметр max-num-batch-tokens понад 2048, щоб краще наситити GPU.

4. Спекулятивне декодування для низької латентності

Для сценаріїв, де важливіша моментальна відповідь, ніж максимальний загальний throughput, варто розглянути speculative decoding:

• паралельно з основною великою моделлю запускається менша «чернеткова» модель;
• вона пропонує послідовність наступних токенів наперед;
• велика модель одним проходом перевіряє цей фрагмент:
• якщо прогноз вдалий — весь шматок одразу приймається;
• якщо ні — помилкові токени виправляються.

З точки зору якості:

• вихід ідентичний тому, що дала б одна лише велика модель без спекулятивного шару;
• виграш досягається за рахунок того, що проста модель використовує «вільний» обчислювальний ресурс між зверненнями до пам’яті.

Однак за дуже високої одночасності користувачів цей підхід дає менше користі: GPU і так повністю завантажується батчами, і «вікна простою» майже немає. Тому:

• варто вмикати спекулятивне декодування там, де критична інтерактивна швидкодія;
• менший ефект — у чисто офлайн- або batch-сценаріях із максимальним завантаженням.

У складі VLLM доступний «нульововартісний» Ingram-спекулятор через прапорець --speculative-model Ingram, орієнтований на структуровані чи повторювані відповіді.

Підсумок

Гальма великих мовних моделей при пікових навантаженнях часто пов’язані не з архітектурою самої моделі, а з тим, як саме організовано сховище й доступ до контексту в GPU-пам’яті. Поєднання KV cache та paged attention:

• зменшує дублювання обчислень;
• усуває внутрішню й зовнішню фрагментацію VRAM;
• збільшує кількість одночасних запитів без оновлення GPU;
• покращує і час до першого токена, і загальний throughput.

Точні налаштування — частка VRAM під кеш, prefix caching, chunked prefill і, за потреби, спекулятивне декодування — перетворюють те саме «залізо» на значно ефективнішу платформу для LLM-сервінгу.

Джерело

YouTube: How KV Cache Speeds Up LLMs for Faster AI Models on GPUs