Розробники, які використовують локальні великі мовні моделі (LLM), виявляють, що один сервер Multi-Channel-Protocol (MCP) може поглинути все контекстне вікно ще до того, як користувач введе перший запит. Їм доводиться обирати між обмеженими описами інструментів або порушенням логіки діалогу.

Чому роздуття токенів має значення для локальних LLM

MCP дозволяє LLM викликати зовнішні інструменти — API, скрипти або утиліти файлової системи — шляхом надання моделі опису кожного інструменту. Хмарні моделі з вікном у 128 тисяч токенів можуть вмістити багато визначень інструментів і все одно залишити місце для діалогу з користувачем. Модель із 7 мільярдами параметрів, що працює локально з вікном у 8 тисяч токенів, вичерпує простір після завантаження лише кількох інструментів. Вибір стоїть різко: короткі та дешеві описи призводять до неправильного маршрутування викликів; довгі та детальні описи споживають бюджет, необхідний для чату.

Ланцюжок подій, що призвів до цього

MCP був створений, щоб замінити кастомний код інтеграції єдиним інтерфейсом для багатьох джерел даних, керованим моделлю. Більшість MCP-серверів є лише тонкими обгортками навколо REST-ендпоінтів, призначених для людей, а не для машин. Коли ці обгортки потрапляють у сесію локальної LLM, модель повинна прочитати назву, параметри та примітки щодо використання кожного інструменту, перш ніж вирішити, який із них викликати. Маленькі контекстні вікна перетворюють ці «накладні витрати на описи» на структурне вузьке місце.

Хто виграє, а хто програє

  • Розробники, які створюють асистентів для пристроїв, втрачають гнучкість. Вони або скорочують каталоги інструментів, ризикуючи частими помилками, або погоджуються на роздутий промпт, який обрізає ввід користувача.
  • Кінцеві користувачі стикаються з нестабільною поведінкою, коли асистент обирає не той інструмент або відмовляється діяти, бо контекст переповнений.
  • Постачальники інструментів отримують єдину точку входу.

Вартість полягає не лише в погіршенні користувацького досвіду; це також створює проблеми з безпекою. Коли MCP-агент може читати будь-який локальний файл, модель дозволів зводиться до принципу «все або нічого». Без «пісочниці» неправильно налаштований інструмент може відкрити доступ до всієї файлової системи.

Що розробники роблять із цим

У спільноті домінують три способи вирішення:

  • Скорочення описів — видалення метаданих інструментів до мінімуму. Це звільняє токени, але підвищує ймовірність того, що модель обере не той ендпоінт, що призводить до помилок, які розробники мають відловлювати та повторювати.
  • Динамічне завантаження — завантаження лише тієї частини інструментів, яка стосується поточної розмови. Легкий диспетчер вирішує, на основі намірів користувача, який набір інструментів впровадити. Це зменшує марне використання токенів, але додає затримку та складність коду.
  • Обмеження активних серверів — встановлення ліміту на кількість MCP-серверів за сесію, що змушує розробників надавати пріоритет найнеобхіднішим інтеграціям. Це дозволяє тримати розмір промпту під контролем, але жертвує широтою можливостей.

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

Ризики безпеки, пов'язані з проблемою токенів

Локальні агенти часто працюють з необмеженим доступом до файлової системи. Протокол MCP не забезпечує гранулярності між «прочитай цю папку» та «прочитай усе». Деякі команди створили рівні шлюзів (gateways), щоб вирішити проблему повного доступу, що додає складності. Ці шлюзи пом'якшують проблему «повного контролю», але також збільшують кодову базу.

Проєктування інструментів для малих моделей

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

  • Вузька функціональність — кожен інструмент має виконувати лише одну дію. Інструмент «пошук», який також записує файли, заплутає модель, яка не може відстежувати перекриття обов'язків.
  • Однозначні назви — уникайте загальних назв на кшталт «process» або «handle». Назви мають чітко передавати конкретну операцію, зменшуючи когнітивне навантаження на модель.
  • Чіткі та стислі описи — включайте лише ті параметри, які моделі справді потрібні для прийняття рішення. Використовуйте послідовний формат, щоб модель могла швидко розпізнавати патерни.

Контраргумент: протокол все одно має цінність

Попри труднощі, MCP залишається привабливим, оскільки він абстрагує шаблонний код. Єдиний інтерфейс, керований моделлю, може підключатися до десятків сервісів без написання кастомних адаптерів для кожного з них. Команди, які можуть дозволити собі хмарні моделі, не вважають роздуття токенів проблемою, і зручність переважає накладні витрати. Виклик полягає в тому, щоб перенести цю зручність у обмежений світ локальних LLM на пристроях.

Висновок

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