MiroFish — експериментальний open source‑проєкт, який за лічені тижні перетворився на один із найгучніших феноменів GitHub. Автор Tech With Tim у своєму відео розбирає, як ця система «цифрового світу» з тисячами агентів будує знання та робить прогнози, а головне — як її реально запустити без власного дата‑центру.
Ця стаття зосереджується не на самих прогнозах, а на практичному боці: з чого складається стек MiroFish, які мовні моделі можна підключити, скільки це коштує в реальних грошах і як розгорнути систему локально або за один клік на VPS.
Вибухова популярність MiroFish: 10 днів розробки, мільйони фінансування і топ GitHub
MiroFish з’явився на GitHub буквально «з нізвідки» і дуже швидко став вірусним. На момент запису відео репозиторій мав близько 51 000 зірок і приблизно 7 600 форків. Проєкт був номером один серед глобально трендових репозиторіїв GitHub, що для інструмента з настільки специфічною функцією — симуляцією майбутнього — виглядає нетипово навіть на фоні хайпу навколо AI.
Ще один показовий факт: за словами Тіма, MiroFish був побудований приблизно за 10 днів і при цьому вже мав понад 4 мільйони доларів фінансування. Така комбінація швидкості розробки, відкритого коду та значних інвестицій частково пояснює, чому спільнота так активно звернула увагу на проєкт.
Популярність MiroFish підживлюється не лише ідеєю «передбачення майбутнього», а й тим, що це не закритий SaaS‑продукт, а open source‑система, яку можна клонувати, змінювати й запускати на власних ресурсах. Однак за цією свободою стоїть доволі складний стек, кілька зовнішніх сервісів і реальні витрати на API‑запити до LLM.
Усередині MiroFish: Oasis, Zep Cloud, FastAPI, Vue.js і будь‑який LLM зі стилем OpenAI
Технічна основа MiroFish складається з кількох ключових компонентів, кожен із яких відповідає за свою частину «цифрового світу» агентів.
Серцем симуляції є Oasis — рушій, який відповідає за побудову та виконання самої моделі світу. Саме Oasis керує тим, як агенти взаємодіють, як формується граф знань і як відпрацьовуються сценарії в умовному «аналогові Twitter і Reddit». Це не просто бібліотека для виклику LLM, а повноцінний simulation engine, який задає правила гри для всієї системи.
Другий критичний елемент — Zep Cloud. Він використовується як пам’ять для агентів: зберігає контекст, історію взаємодій, знання, які накопичуються протягом симуляцій. На відміну від інших частин стека, Zep Cloud не є open source і працює як зовнішній сервіс. У типовій конфігурації MiroFish саме Zep відповідає за те, щоб агенти не були «амнезійними» й могли послідовно розвивати свої думки та стратегії.
Поверх цього працює бекенд на FastAPI — популярному Python‑фреймворку для побудови високопродуктивних API. Він забезпечує інтерфейс між рушієм симуляції, LLM‑моделями, пам’яттю та фронтендом.
Фронтенд реалізовано на Vue.js. Через нього користувач бачить граф знань, може досліджувати агентів, читати згенеровані звіти та взаємодіяти з симульованим середовищем. Це важлива частина досвіду роботи з MiroFish: система не просто повертає текстовий прогноз, а дає змогу «зазирнути» в логіку агентів.
Нарешті, мовна «начинка» — будь‑яка LLM, сумісна з OpenAI‑SDK. MiroFish не прив’язаний жорстко до одного провайдера: він очікує API у стилі OpenAI, а конкретну модель і базовий URL можна задати в налаштуваннях. Це відкриває шлях до використання різних постачальників — від OpenAI до Anthropic чи Minimax — без переписування коду.
У підсумку стек виглядає так: Oasis як симуляційний рушій, Zep Cloud як пам’ять, FastAPI як бекенд, Vue.js як інтерфейс і будь‑який OpenAI‑сумісний LLM як мовний мозок. Усе, окрім Zep Cloud, — open source і може бути розгорнуто локально.
Вибір мовної моделі: OpenAI, Claude, Minimax і чому не варто брати «ультра‑преміум»
Один із ключових практичних моментів для тих, хто хоче запустити MiroFish, — це вибір LLM. Система розрахована на використання моделей, які підтримують OpenAI‑style API. Це означає, що вона очікує знайомий формат запитів і відповідей, а також стандартні параметри на кшталт model, messages тощо.
У налаштуваннях MiroFish можна вказати:
- базовий URL API,
- назву моделі,
- API‑ключ.
Якщо використовується OpenAI, усе виглядає стандартно: ключ створюється на платформі OpenAI, модель обирається зі списку доступних (у прикладі Тіма — GPT‑4.0). Якщо ж користувач хоче перейти на інший провайдер, доведеться змінити базовий URL на той, що надає відповідний сервіс, і вказати сумісну назву моделі.
Так, для Minimax буде свій URL, для Anthropic Claude — інший. Головна вимога — підтримка OpenAI‑подібного API. Якщо це виконано, MiroFish може працювати з цими моделями без глибоких змін у коді: достатньо підставити правильний endpoint і модель.
Однак вибір моделі — це не лише питання якості, а й грошей. MiroFish запускає велику кількість агентів, які багато разів звертаються до LLM. У демонстраційному запуску з GPT‑4.0 повна симуляція обійшлася приблизно в 3 долари за API‑виклики. Це вже не копійки, але й не захмарна сума для складного експерименту.
Тім прямо застерігає від використання «ультра‑преміум» моделей на кшталт Opus із найвищими тарифами. За його оцінкою, у такому разі вартість одного повного прогону може легко зрости до десятків доларів — 20, 30, 40, 50 і більше, залежно від кількості агентів і тривалості симуляції.
Тому для більшості користувачів, які хочуть «погратися» з MiroFish, компроміс на кшталт GPT‑4.0 виглядає раціональним: модель достатньо потужна, щоб підтримувати складні дискусії агентів, але не настільки дорога, щоб кожен запуск ставав фінансовим ризиком.
Для тих, хто має доступ до дешевших або спеціалізованих моделей через OpenAI‑сумісні API, можливість змінювати базовий URL і модель відкриває шлях до оптимізації витрат. Але в будь‑якому разі варто пам’ятати: MiroFish — це не «один запит до чату», а сотні й тисячі звернень до LLM у межах однієї симуляції.
Zep Cloud: єдиний закритий компонент і фактична вимога за замовчуванням
Попри те, що MiroFish і Oasis є open source і можуть бути вільно клоновані, у стандартній конфігурації є один критичний виняток — Zep Cloud. Це хмарний сервіс, який використовується як система пам’яті для агентів. Він зберігає їхній контекст, історію, знання, що дозволяє симуляції бути послідовною, а не складатися з набору незалежних викликів LLM.
У типовому стеку MiroFish Zep Cloud — єдиний не‑open‑source компонент. Формально його можна замінити, але це потребуватиме суттєвої перенастройки проєкту. Тім прямо зазначає, що без «важкої» реконфігурації відмовитися від Zep практично неможливо: система на нього розрахована.
Водночас вхідний бар’єр для використання Zep Cloud відносно низький. Сервіс надає 1 000 безкоштовних кредитів і не вимагає введення даних банківської картки для старту. Для перших експериментів цього достатньо, особливо якщо не запускати симуляції безперервно.
Щоб підключити Zep до MiroFish, потрібно:
- створити обліковий запис на Zep,
- створити проєкт,
- згенерувати API‑ключ у налаштуваннях,
- додати цей ключ у змінні середовища MiroFish.
Після цього система може використовувати Zep як бекенд пам’яті. Якщо користувачеві знадобиться більше ресурсів, ніж дають безкоштовні кредити, доведеться перейти на платний тариф. У прикладі Тіма він уже оплатив додаткові ресурси, оскільки запускає багато симуляцій.
Для розробників, які принципово хочуть уникнути закритих сервісів, теоретично можливо замінити Zep на власне рішення або інший open source‑аналог. Але це вже окрема інженерна задача, яка виходить за межі «запустити MiroFish за інструкцією з GitHub». У стандартному сценарії Zep Cloud — фактично обов’язковий елемент.
Open source, локальний запуск і роль змінних середовища
Попри залежність від Zep Cloud, MiroFish залишається проєктом, який можна повністю розгорнути на власній машині. Репозиторій на GitHub відкритий, так само як і Oasis — рушій симуляції, що стоїть за ним. Це означає, що користувач може:
- клонувати репозиторій,
- встановити залежності,
- налаштувати змінні середовища,
- запустити бекенд і фронтенд локально.
Ключовим кроком є саме конфігурація змінних середовища. Сюди входять:
- API‑ключ LLM‑провайдера (OpenAI чи іншого OpenAI‑сумісного сервісу),
- базовий URL для API моделі, якщо використовується не OpenAI,
- назва моделі,
- API‑ключ Zep Cloud,
- інші параметри, які потрібні для коректної роботи Oasis і FastAPI.
Без цих змінних MiroFish просто не зможе звертатися до моделей і пам’яті. У випадку локального запуску користувач сам відповідає за безпеку ключів, конфігурацію середовища та стабільність роботи сервісів.
Тім визнає, що локальне розгортання не є надто складним з технічної точки зору, але може бути часозатратним. Потрібно клонувати репозиторій, пройтися по інструкції, встановити залежності, налаштувати змінні середовища, перевірити, що все працює коректно. Для досвідчених розробників це звична рутина, але для тих, хто просто хоче «подивитися, як воно працює», це може стати бар’єром.
Саме тому в гру вступає ще один елемент екосистеми — готове VPS‑розгортання.
Один клік до симуляції: VPS‑деплой MiroFish через Hostinger
Щоб знизити поріг входу для користувачів, які не хочуть витрачати години на налаштування, Тім уклав партнерство з Hostinger. Результат — можливість розгорнути MiroFish на віртуальному приватному сервері в один клік, використовуючи Docker.
За його словами, Hostinger став першою компанією, яка запропонувала таке рішення для MiroFish. Суть підходу проста: користувач обирає VPS‑план, натискає кнопку деплою, і система автоматично розгортає контейнер із MiroFish у захищеному середовищі. Після цього залишається лише ввести власні API‑ключі для LLM і Zep Cloud.
Ціни на такі VPS‑плани стартують приблизно від 6,50 долара на місяць. Тім рекомендує план KVM2, який коштує близько 9 доларів на місяць і, на його думку, краще підходить для стабільної роботи MiroFish. Усі розгортання відбуваються в Docker‑контейнері, що ізолює симуляцію від інших процесів і спрощує управління середовищем.
Після завершення деплою користувач отримує HTTPS‑URL, за яким доступний інтерфейс MiroFish. Далі потрібно:
- ввести API‑ключ LLM‑провайдера (наприклад, OpenAI),
- обрати модель (наприклад, GPT‑4.0),
- за потреби змінити базовий URL і модель для альтернативних провайдерів,
- додати API‑ключ Zep Cloud.
Усе це зберігається як змінні середовища всередині контейнера. Після цього можна запускати симуляції з будь‑якого пристрою, не турбуючись про локальні ресурси чи конфігурацію Python‑середовища.
Перевага такого підходу — не лише в зручності, а й у безпеці: симуляції виконуються на окремому сервері, не навантажуючи основну машину користувача. Для тих, хто хоче довго й багато експериментувати з MiroFish, це може виявитися практичнішим, ніж тримати все на власному ноутбуці чи десктопі.
Вартість експериментів: де закінчується «безкоштовно» і починаються реальні гроші
Запуск MiroFish — це завжди поєднання трьох типів витрат: інфраструктура, пам’ять і LLM‑запити.
Інфраструктура може бути безкоштовною, якщо користувач запускає систему локально на власному обладнанні. У такому разі доведеться платити лише за API‑виклики до LLM і, за потреби, за додаткові кредити в Zep Cloud. Якщо ж обрати VPS‑варіант, до цього додається щомісячна абонплата за сервер — від приблизно 6,50 до 9 доларів і вище, залежно від плану.
Пам’ять у вигляді Zep Cloud стартує з 1 000 безкоштовних кредитів без вимоги вказувати картку. Це дозволяє провести низку повноцінних симуляцій, перш ніж виникне потреба в оплаті. Для інтенсивного використання, як у випадку Тіма, знадобиться перехід на платний тариф.
Найбільш змінною статтею витрат залишаються LLM‑запити. У демонстраційному запуску з GPT‑4.0 повна симуляція коштувала близько 3 доларів. Це дає орієнтир для тих, хто планує серію експериментів: десяток прогонів — це вже десятки доларів лише на API‑виклики.
Якщо ж використовувати дорожчі моделі, витрати зростають непропорційно. Оскільки MiroFish запускає багато агентів, кожен із яких робить численні звернення до LLM, тариф «за тисячу токенів» швидко множиться. Саме тому рекомендація уникати найвищих за ціною моделей виглядає не просто порадою, а практичною вимогою для тих, хто не має великого бюджету.
У цьому контексті можливість підключати альтернативні OpenAI‑сумісні моделі може стати важливим інструментом оптимізації. Якщо провайдер пропонує дешевші тарифи при прийнятній якості, MiroFish дозволяє скористатися цим без глибоких змін у коді.
Висновок: MiroFish як тест на зрілість AI‑інфраструктури
MiroFish — це не лише ефектна демонстрація того, як тисячі агентів можуть будувати граф знань і робити прогнози. Це ще й показник того, наскільки дозріли інструменти для побудови складних AI‑систем поверх відкритого коду й хмарних сервісів.
З одного боку, користувач отримує повністю open source‑рушій симуляції (Oasis), відкритий репозиторій MiroFish, можливість запускати все локально й гнучко обирати LLM‑провайдера. З іншого — залежність від зовнішнього сервісу пам’яті (Zep Cloud), реальні витрати на API‑запити й потребу в мінімальній інженерній грамотності для налаштування змінних середовища.
Партнерський VPS‑деплой через Hostinger показує ще один тренд: поява «один‑клік» інфраструктури для складних AI‑проєктів. Те, що ще кілька років тому вимагало окремої DevOps‑команди, сьогодні зводиться до вибору тарифу й введення кількох ключів.
Для розробників і дослідників MiroFish стає своєрідним полігоном: тут можна експериментувати з різними моделями, конфігураціями агентів і сценаріями, одночасно відчуваючи на собі реальну економіку LLM‑інфраструктури. А для індустрії загалом це ще один сигнал, що ера «іграшкових» AI‑демо закінчується: навіть експериментальні проєкти на кшталт MiroFish одразу виходять на рівень десятків тисяч зірок, мільйонних інвестицій і готових хмарних розгортань.
Джерело
YouTube: I Spawned 10,000 AI Agents to Predict the Future (MiroFish is Insane)