Szybki start Vane (Perplexica 2.0) z Ollama i llama.cpp

Vane to jeden z bardziej pragmatycznych projektów w przestrzeni „AI-search z cytatami”: samodzielnie hostowany silnik odpowiedzi, który łączy wyszukiwanie na żywej sieci z modelami LLM (lokalnymi lub w chmurze), a jednocześnie pozwala zachować pełną kontrolę nad całym stackiem.

Projekt początkowo znany był jako Perplexica, a zmiana nazwy na Vane nie ma charakteru wyłącznie kosmetycznego: odzwierciedla zarówno uporządkowanie marki, jak i stopniowe odejście od traktowania projektu jako „klona” na rzecz pozycjonowania go jako uniwersalnego silnika odpowiedzi.

Ponieważ przydatna część stacku to nie tylko interfejs, ale też miejsce, w którym odbywa się wnioskowanie i przechowywane są dane, porównanie hostingu LLM w 2026 roku zestawia konfiguracje lokalne, samodzielnie hostowane i chmurowe, dzięki czemu możesz ustawić Vane obok innych środowisk wykonawczych i opcji wdrożenia.

Ten artykuł koncentruje się na częściach, o które naprawdę dbają czytelnicy techniczni: jak działa system, minimalny szybki start z Dockerem oraz jak uruchamiać go z lokalnym wnioskowaniem za pomocą Ollama i llama.cpp (bezpośrednio lub przez LM Studio). W międzyczasie każde pytanie z sekcji FAQ zostaje odpowiedziane w kontekście, a nie odkładane na koniec.

Vane to świadomie silnik odpowiedzi, a nie system rekurencyjnego badania, i warto precyzyjnie zaznaczyć tę różnicę. Systemy głębokiego badania z hostowaniem wewnętrznym: porównanie 12 narzędzi zestawia Vane z dwunastoma samodzielnie hostowanymi architekturami badawczymi i wyjaśnia, dlaczego „wykonywanie wielu wyszukiwań” nie jest tym samym co „przeprowadzanie głębokiego badania”.

Czym jest Vane i jak działają silniki wyszukiwania AI

Na wysokim poziomie Vane to aplikacja Next.js łącząca interfejs czatu z wyszukiwaniem i cytowaniem. Główny komponenty architektoniczne to dokładnie to, czego można by oczekiwać od nowoczesnego silnika wyszukiwania AI: trasy API dla czatu i wyszukiwania, orkiestracja decydująca, kiedy wykonać pobieranie danych, oraz generujący odpowiedzi moduł uwzględniający cytowanie.

Gdy wyślesz zapytanie w interfejsie, Vane wywołuje POST /api/chat. Wewnętrzny przebieg pracy jest celowo strukturalizowany:

• Najpierw klasyfikuje pytanie, aby zdecydować, czy potrzebne jest badanie i które elementy pomocnicze powinny zostać uruchomione.
• Uruchamia badanie i widgety równolegle.
• Generuje ostateczną odpowiedź i dołącza cytowania.

Etykieta „silnik wyszukiwania AI” ma znaczenie, ponieważ to nie jest tylko frontend czatu. Kluczową różnicą jest generowanie wzbogacone o pobieranie danych (RAG): zamiast polegać wyłącznie na parametrach modelu LLM, Vane pobiera zewnętrzny kontekst (wyniki sieciowe i opcjonalnie pliki przesłane przez użytkownika) i używa tego materiału jako fundamentu dla ostatecznej odpowiedzi. Dokumentacja projektu wyraźnie wskazuje wyszukiwanie w sieci i „przeszukiwanie plików przesłanych przez użytkownika” jako część procesu badawczego, przy czym do semantycznego przeszukiwania przesłań stosowane są wektory (embeddings).

Cytowania nie są traktowane jako dodatek. Vane nakazuje modelowi cytować użyte źródła, a następnie interfejs użytkownika wyświetla te cytowania obok odpowiedzi. W praktyce to właśnie odróżnia „przydatne” wyszukiwanie AI od pewnego siebie generującego halucynacje systemu, który akurat ma przycisk wyszukiwania.

W większości konfiguracji warstwę wyszukiwania w sieci obsługuje SearxNG. SearxNG to darmowy silnik metawyszukiwania, który agreguje wyniki z wielu usług wyszukiwania i z założenia nie śledzi ani nie profiluje użytkowników. To fundamentalnie inna filozofia niż płatne API wyszukiwarek, które zwykle dostarczają indeks jednej firmy i komercyjną umowę dotyczącą danych.

Historia i zmiana nazwy z Perplexica na Vane

Perplexica rozpoczął jako otwartoźródłowy, samodzielnie hostowany silnik odpowiedzi inspirowany Perplexity AI. Wiele publicznych poradników nadal opisuje projekt jako „dawniej znany jako Perplexica”, traktując Vane jako kontynuację, a nie wrogiego fork.

Zmiana nazwy została wdrożona bezpośrednio w repozytorium upstream. W historii commitów gałęzi master commit zatytułowany feat(app): rename to 'vane' pojawił się 9 marca 2026 r. (SHA 39c0f19).

Sposób realizacji jest ciekawszy niż sam nagłówek. Ten commit zmiany nazwy to nie tylko poprawka README: aktualizuje nazwy obrazów Docker z itzcrazykns1337/perplexica na itzcrazykns1337/vane, zmienia ścieżki w systemie plików kontenera z /home/perplexica na /home/vane oraz odpowiednio aktualizuje tekst i zasoby projektu.

Jeśli zastanawiasz się, dlaczego projekty AI z otwartym kodem zmieniają nazwy, Vane jest podręcznikowym przykładem typowych czynników napędzających tę decyzję:

• Bliskość nazwy do marki komercyjnej powoduje zamieszanie (a czasem ryzyko prawne).
• Zakres projektu wykracza poza oryginalne ramy (od „klona” do „silnika odpowiedzi”).
• Artefakty dystrybucji wymagają spójnej tożsamości (obrazy Docker, dokumentacja, etykiety w interfejsie).

Co więcej, ekosystem nie zmienia nazw z dnia na dzień. W Docker Hub nadal widoczne są oba repozytoria pod kontem podtrzymującego, w tym itzcrazykns1337/vane i itzcrazykns1337/perplexica. Dlatego nawet po zmianie nazwy repozytorium nadal można spotkać starsze wpisy blogowe, pliki compose oraz odniesienia do rejestru używające nazewnictwa Perplexica.

Szybki start z Dockerem i podstawowa konfiguracja

Oficjalne README Vane jest przeświecająco bezpośrednie: uruchamiasz pojedynczy kontener i otrzymujesz Vane oraz wbudowany backend wyszukiwania SearxNG. Minimalny szybki start z Dockerem wygląda następująco.

docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest

Ten obraz pozycjonowany jest jako ścieżka „działa od razu”, ponieważ zawiera już SearxNG, więc nie musisz posiadać zewnętrznego backendu wyszukiwania, aby przetestować interfejs. Konfiguracja odbywa się na ekranie ustawień po otwarciu interfejsu webowego pod adresem http://localhost:3000.

Jeśli już używasz SearxNG (co jest powszechne w domowych serwerowniach), „smukły” obraz Vane oczekuje, że skierujesz go na zewnętrzny instancja SearxNG za pomocą SEARXNG_API_URL. README wskazuje też dwa praktyczne oczekiwania dotyczące ustawień SearxNG: włączenie wyjścia JSON oraz włączenie silnika Wolfram Alpha.

docker run -d -p 3000:3000 \
  -e SEARXNG_API_URL=http://your-searxng-url:8080 \
  -v vane-data:/home/vane/data \
  --name vane \
  itzcrazykns1337/vane:slim-latest

Aktualizowanie Vane jest również udokumentowane w repozytorium. Oficjalny proces aktualizacji to w zasadzie pobranie najnowszej wersji obrazu i ponowne uruchomienie z tym samym woluminem, co zachowuje ustawienia.

docker pull itzcrazykns1337/vane:latest
docker stop vane
docker rm vane
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest

Gdy już działasz, Vane można wykorzystać jako skrót do wyszukiwania w przeglądarce, kierując niestandardowy silnik na adres http://localhost:3000/?q=%s. To niewielka funkcja, ale o dużym wpływie, jeśli chcesz, aby „AI-search” przypominało wyszukiwanie, a nie aplikację, do której się zagląda.

Do automatyzacji i integracji Vane udostępnia API. Dokumentacja opisuje GET /api/providers do wykrywania skonfigurowanych dostawców i modeli oraz POST /api/search do wykonania wyszukiwania z wybranym modelem czatu, modelem embeddingowym, źródłami oraz parametrem optimizationMode (prędkość, balans, jakość).

Lokalna konfiguracja LLM z Ollama

Vane obsługuje lokalne modele LLM przez Ollama oraz dostawców chmurowych w tym samym interfejsie, co jest odpowiednim abstrakcyjnym podejściem, jeśli myślisz w kategoriach „połączeń” i „modeli”, a nie „dostawców”.

Ściągawka z poleceń Ollama wymienia powszechnie używane polecenia CLI i szybkie sprawdzenia API, które dobrze współgrają z wybieraniem modeli i weryfikacją Ollama przed rozwiązywaniem problemów z siecią w Dockerze.

Najczęstszym problemem nie jest wybór modelu, ale sieć. Gdy Vane działa w Dockerze, a Ollama na hoście, „localhost” nie oznacza wewnątrz kontenera tego, co myślisz. Vane dokumentuje specyficzne dla systemu operacyjnego bazy URL do łączenia się z Ollama z kontenera.

Problemy z połączeniem w Dockerze

Sekcja rozwiązywania problemów w Vane wyraźnie zaleca:

• Windows i macOS: http://host.docker.internal:11434
• Linux: http://<prywatny_adres_ip_hosta>:11434

Dla Linuksa Vane zaznacza też, że Ollama domyślnie może być powiązany z 127.0.0.1 i wymaga ekspozycji. README sugeruje ustawienie OLLAMA_HOST=0.0.0.0:11434 w usłudze systemd i ponowne uruchomienie tej usługi.

To zgodne z własnymi zmiennymi środowiskowymi serwera serve w Ollama, gdzie OLLAMA_HOST kontroluje adres wiązania serwera i domyślnie ma wartość 127.0.0.1:11434.

Utrzymywanie modeli w stanie gotowości i dobór modeli

Jeśli wykonujesz lokalne wnioskowanie, poczujesz opóźnienia przy zimnym starcie. Ollama ma dwa powiązane mechanizmy utrzymywania modeli w pamięci:

• OLLAMA_KEEP_ALIVE jako ustawienie serwera.
• keep_alive jako parametr per-request dla /api/generate i /api/chat, który nadpisuje domyślne ustawienie serwera.

Vane dodał własne wsparcie dla keep_alive w przypadku modeli Ollama (tak, aby aplikacja mogła wpływać na to, jak długo model pozostaje w pamięci). Ta funkcja pojawiła się w notatkach wydania v1.10.0 Vane.

Wybór modelu to część, która nadmiernie komplikuje się w internecie. Dla typowych zastosowań Vane najbardziej praktyczny podział to:

• Model czatu dostrojony do instrukcji (do podsumowań i syntezy).
• Model embeddingowy do wyszukiwania podobieństw w przesłanych plikach i pobranym tekście. Dokumentacja API Vane pokazuje, że żądanie wyszukiwania wyraźnie wybiera zarówno model czatu, jak i model embeddingowy.

Sam Ollama obsługuje przepływy pracy z embeddingami, a nawet dokumentacja CLI zawiera przykład używania nomic-embed-text do embeddingów.

Jest to również odpowiedź na pytanie z FAQ dotyczące uruchamiania AI-search lokalnie bez API chmurowych: z Vane w Dockerze, lokalnym SearxNG i Ollama na swoim sprzęcie możesz utrzymać zarówno zapytania wyszukiwania, jak i prywatne pliki w obrębie własnej sieci. (Jeśli zdecydujesz się jednak na połączenie z dostawcą chmurowym, ścieżka danych oczywiście się zmieni.)

Lokalna konfiguracja LLM z llama.cpp

Istnieją dwa realistyczne sposoby połączenia Vane z llama.cpp:

• Użycie LM Studio jako warstwy serwera (i pozwolenie Vane na komunikację z nim).
• Uruchomienie własnego serwera HTTP llama.cpp (llama-server) i połączenie przez punkt końcowy zgodny z OpenAI.

Vane wyraźnie obsługuje „Lokalne serwery zgodne z API OpenAI” i wskazuje typowe wymagania: powiązanie z 0.0.0.0 zamiast 127.0.0.1, użycie właściwego portu, ustawienie nazwy modelu istniejącej na serwerze oraz pozostawienie pola klucza API niepustego, nawet jeśli serwer nie wymusza uwierzytelniania.

LM Studio ma tu znaczenie, ponieważ siedzi na lokalnych backendach (często llama.cpp), jednocześnie udostępniając API zgodne z OpenAI. W Vane v1.12.1 konkretnie wspomniano o dodaniu dostawcy LM Studio.

Dokumentacja LM Studio wymienia obsługiwane punkty końcowe zgodne z OpenAI i pokazuje przykład bazy URL z użyciem http://localhost:1234/v1 (zakładając port 1234). To ważne, ponieważ z perspektywy Vane jest to „po prostu kolejny serwer w stylu OpenAI”.

Jeśli wolisz uruchamiać llama.cpp bezpośrednio, Szybki start z llama.cpp z CLI i Serwerem obejmuje instalację, llama-cli i llama-server. Oficjalny serwer HTTP llama.cpp obsługuje zgodne z API OpenAI ścieżki do ukończeń czatu, odpowiedzi i embeddingów, a także długą listę funkcji serwera (batching, monitorowanie, używanie narzędzi).

Nawet jeśli nie zapamiętasz flag, najważniejsze są:

• Serwer istnieje i jest aktywnie dokumentowany.
• Powierzchnia API jest wystarczająco kompatybilna, aby klienci w stylu OpenAI mogli z nim rozmawiać, a to jest dokładnie to, czego Vane potrzebuje dla swojego wzorca połączenia „zgodnego z OpenAI”.

Co ostatnio wydano i co się teraz zmienia

Jeśli chcesz zrozumieć, czym Vane stało się w ciągu ostatniego roku, śledź notatki wydawnicze i historię gałęzi master, a nie fanaberie.

Stanem na 10 kwietnia 2026 r. (strefa czasowa Australia/Melbourne), najnowszy oznaczony wydanie widoczne na stronie wydań GitHub to v1.12.1 (31 grudnia 2025 r.). Notatki tego wydania wspomina o dodaniu dostawcy LM Studio oraz poprawkach związanych z wywołaniem funkcji w dostawcach zgodnych z OpenAI i analizą JSON.

Poprzednie wydania nakreślają większe zmiany:

• v1.11.0 (21 października 2025 r.) wprowadziło nowy kreatora ustawień i przeprojektowany system konfiguracji, wraz z szerszym wsparciem dla dostawców i ścieżką instalacji Dockerem za pomocą pojedynczego polecenia. Wspomina też o dynamicznym pobieraniu modeli oraz różnych ulepszeniach interfejsu i doświadczenia deweloperskiego.
• v1.12.0 (27 grudnia 2025 r.) to reset architektoniczny: usuwa LangChain na rzecz własnej implementacji dla strumieniowania, generowania i zachowań specyficznych dla dostawców. Przenosi również nazwę „dostawcy” na „połączenia”, dodaje ulepszenia renderowania UI i kodu oraz przenosi więcej funkcji do własnych abstrakcji projektu (w tym poprawione wywoływanie funkcji w porównaniu z poprzednimi podejściami do analizy).
• Wcześniejszy v1.10.0 (20 marca 2025 r.) dodał przesłanie plików (PDF, TXT, DOCX), parametr keep_alive dla Ollama, klasę agenta wyszukiwania metowego w celu poprawy utrzymywalności i tworzenia trybu skupienia, a także automatyczną funkcję wyszukiwania obrazów i wideo.

Jeśli chodzi o markę, zmiana na Vane wdrożona została 9 marca 2026 r. w masterze (feat(app): rename to 'vane'), aktualizując zarówno nazewnictwo w kodzie, jak i artefakty Docker.

Projekt nie przestał się rozwijać po wydaniu z grudnia 2025 r. Commity gałęzi master z 8–9 kwietnia 2026 r. obejmują prace opisane jako „zaktualizowany tryb głębokiego badania, zarządzanie kontekstem” oraz nowe zmiany związane z wykonywaniem wyszukiwań i scrapowaniem. Innymi słowy, część „silnika wyszukiwania AI” jest nadal aktywnie iterowana, a nie zamrożona za oznaczeniami wydań.

Niektóre źródła

• Farfalle vs Perplexica - samodzielnie hostowane silniki wyszukiwania