Ollama Cloud вирішує реальну проблему: найбільші моделі потребують обладнання, яке мала чи середня компанія не хоче купувати. Але «зручний доступ до потужності» перетворюється на хаос, якщо кожен сервіс викликає хмару по-своєму. Зріле використання має один шлюз.
Чому один роутер, а не прямі виклики#
Прямі виклики з багатьох місць означають розпорошені ключі, відсутність спільного контролю витрат і ризик, що персональні дані вийдуть назовні без маскування. Роутер (OpenClaw) — це єдиний вхід до моделей: тут ухвалюється рішення, яка модель обробить завдання, тут маскуємо PII, тут рахуємо витрати й активується fallback, коли модель повертає порожню відповідь. Такий роутер LLM є для всієї організації єдиним шаром контролю — незалежно від того, скільки сервісів його використовують.
Підбір моделі під завдання#
Не кожне завдання потребує найбільшої моделі. Роутер спрямовує класифікацію та прості потоки на малу, дешеву модель, а потужність резервує для завдань, які її справді потребують (складні міркування, довгі контексти). Це водночас найважливіший важіль витратний і якісний.
На практиці більшість трафіку можна обслужити меншим класом моделі, а найдорожчу потужність залишити для вузького зрізу завдань. Нижче орієнтовне зіставлення — витрати подаємо відносно (порядки величини, а не конкретні ставки), бо прайси змінюються й залежать від довжини промпту:
| Тип завдання | Клас моделі | Відносна вартість | Коли обирати |
|---|---|---|---|
| Класифікація, маршрутизація, тегування, простий вибір | малий | найнижча | Коротке введення, однозначна відповідь, великий обсяг |
| Витяг даних, підсумовування, переписування | середній | помірна | Потрібні структура й точність, але без багатокрокових міркувань |
| Складні міркування, довгий контекст, аналіз документів | великий | найвища | Завдання потребує якості, яку видно лише на більшій моделі |
Правило просте: починай із найменшого класу, який проходить тест якості на твоїх даних, і підіймай його лише там, де точності реально бракує. Як підбирати модель під конкретне завдання, докладно розкладаємо у статті як підібрати модель AI.
Хмара та GDPR в одному потоці#
Ollama Cloud — це обробка поза вашою інфраструктурою, тому ставимося до неї як до будь-якого виходу даних: маскування PII перед відправкою є обов’язковим, а чутливі шляхи спрямовуємо на локальну модель. Для даних, які не можуть вийти назовні, поєднуємо хмару з self-hostingом в одному узгодженому роутері. Безпека та GDPR важливіші за окрему функцію — як це вибудувати крок за кроком, розгортаємо у статті про self-hosting та GDPR.
На практиці маскування перед викликом хмари має кілька етапів, які роутер виконує щоразу:
- Виявити сутності — у промпті знайди персональні та чутливі дані: імена, e-mail, номери телефонів, ідентифікаційні номери, адреси, ідентифікатори клієнтів.
- Замаскувати або псевдонімізувати — заміни їх на стабільні токени-замінники (напр.
КЛІЄНТ_1,EMAIL_1), зберігаючи відображення лише локально. - Надіслати замаскований промпт до хмари — модель бачить структуру завдання, але не реальні дані.
- Відновити значення у відповіді на боці твоєї інфраструктури, на основі локальної мапи.
Деякі дані ми не маскуємо, а взагалі не випускаємо: шляхи, що торкаються документів під таємницею, даних особливої категорії (напр. медичних) або контенту із завеликим ризиком розкриття, роутер спрямовує повністю на локальну модель. Це свідоме рішення в одному місці, а не надія, що кожен розробник про це пам’ятає.
Телеметрія: бачите, за що платите#
Один шлюз дає одне джерело правди про використання: які завдання генерують витрати, як розподіляється трафік між моделями, де варто перенести навантаження на локальну модель. Без цієї спостережуваності оптимізація витрат — це вгадування.
Щоб «бачите, за що платите» було конкретикою, роутер записує при кожному виклику набір полів:
- модель і клас (tier) — яка модель обробила завдання та з якої полиці (мала/середня/велика).
- токени входу й виходу — бо саме вони переходять у вартість.
- латентність — час відповіді, корисний при виборі між моделями схожої якості.
- орієнтовна вартість — обчислена з кількості токенів і ставки відповідного класу.
- чи замасковано PII — слід, що шлях пройшов через потрібне маскування.
- чи спрацював fallback або блокування — сигнал, що модель повернула порожню відповідь або завдання було зупинено.
З таких полів складається картина, яка дозволяє ухвалювати рішення на основі чисел, а не вражень: де знизити клас моделі, які завдання перенести локально, а де витрати ростуть швидше за цінність. Повний розклад витрат усього агента — не лише самих викликів моделі — розкладаємо у статті скільки коштує агент AI.
FAQ#
Чим Ollama Cloud відрізняється від утримання моделі у себе?#
Ollama Cloud — це потужність на вимогу без власного обладнання: низький поріг входу, змінні витрати. Self-hosting — вищий поріг входу, але повний контроль і передбачувані витрати за великого обсягу. Часто оптимальною є гібридна модель.
Чи можу я використовувати Ollama Cloud згідно з GDPR?#
Так, за умови маскування персональних даних перед відправкою, обмеження обсягу до мінімуму та спрямування чутливих шляхів на локальну модель. Роутер забезпечує ці правила в одному місці, замість того, щоб покладатися на дисципліну кожного розробника.
Навіщо роутер, якщо можна викликати API напряму?#
Прямі виклики розпорошують контроль: витрати, безпека та підбір моделі розходяться між сервісами. Роутер централізує рішення, маскування PII, fallback і телеметрію — це різниця між експериментом і продакшн-системою.