Niecenzurowany model LLM w edytorze: Cursor, Ollama i Venice

Prosisz model w edytorze o skrypt testowy, a on uznaje, że to atak. Wklejasz kawałek kodu do analizy i dostajesz formułkę o polityce treści. Ma to swoją nazwę: nadmierna odmowa (over-refusal). Czasami jak próbowałem przerobić swoje zdjęcie w Nano Banana, to informował mnie że nie może edytować zdjęć publicznych osób (cokolwiek to znaczy). Dlatego coraz więcej programistów podpina pod edytor coś innego: własny klucz API, lokalną Ollamę albo prywatną chmurę w rodzaju Venice.ai. Poniżej opisuję, jak to działa, jak skonfigurować Cursora, Copilota i OpenCode i w którym miejscu taka swoboda zaczyna być ryzykowna.

Źródło: unsplash.com

Skąd ta nadmierna odmowa

Dostawcy trzymają bezpieczeństwo u siebie: RLHF, filtry, polityki treści. Przy oczywistym nadużyciu to działa i nie mam z tym problemu. Kłopot w tym, że w programowaniu i audytach bezpieczeństwa ten sam mechanizm blokuje normalną pracę: testy penetracyjne, analizę malware, a czasem zwykłą optymalizację kodu, który modelowi „wygląda podejrzanie”.

Stąd zainteresowanie modelami open-weights i API, które nie dokładają własnej warstwy cenzury. Wnioskowanie odbywa się bliżej samych wag, telemetrii jest mniej i lepiej wiesz, co ląduje w chmurze. Nie nastawiałbym się jednak na „inteligencję bez limitów”. Dostajesz po prostu inny kompromis między użytecznością a zabezpieczeniami.

Skąd się biorą modele „uncensored”

Część z nich powstaje przez abliterację. Badacze pokazali, że odmowa w transformerze bywa skupiona w kilku konkretnych kierunkach w przestrzeni aktywacji. Jeśli usuniesz ten wektor, model odmawia rzadziej, ale potrafi też pisać mniej spójnie (rośnie perplexity). Nowsze metody, np. oparte na transporcie optymalnym, próbują wyciąć samą odmowę precyzyjniej i nie psuć przy tym reszty umiejętności.

Producenci odpowiadają między innymi rozszerzoną odmową: zamiast krótkiego „nie” model daje długie uzasadnienie, co utrudnia proste obejścia. W praktyce mało kto grzebie samodzielnie w wagach. Ludzie biorą gotowe warianty, takie jak Dolphin, Venice Edition czy Qwen uncensored.

Venice.ai: API zgodne z OpenAI i zero retencji

Venice hostuje modele open-weights i wystawia endpoint /v1/chat/completions, więc wszystko, co napisałeś pod OpenAI, podepniesz bez przepisywania. W marketingu stawiają na prywatność: prompty nie są zbierane do treningu, jest szyfrowanie E2EE i przetwarzanie w TEE. Jeśli pracujesz dla firmy pod NDA, to pewnie będzie dla Ciebie ważniejsze niż sam brak cenzury.

W katalogu znajdziesz modele pod kod i pod duże konteksty, od lżejszych po takie z oknem rzędu miliona tokenów, w które da się wrzucić całe repozytorium. Z tego, co tam jest, wyróżniłbym trzy grupy.

• Venice Uncensored obsługuje vision, function calling i długi kontekst, więc nadaje się do bardziej złożonych zadań.
• Qwen i DeepSeek w wersjach na Venice są nastawione na agentowe pisanie kodu i duże okna kontekstu.
• Szybkie modele, np. Mercury, mają sens wtedy, gdy edytor wysyła setki małych żądań i liczy się opóźnienie.

Zanim puścisz to na produkcję, sprawdź nagłówki odpowiedzi (model-id, limity rate) i policz koszt za milion tokenów wejścia i wyjścia.

Ollama: lokalnie, nawet bez sieci

Ollama serwuje modele GGUF na localhost:11434. Ma API w stylu OpenAI (/v1/chat/completions) i do tego własne endpointy. W Modelfile ustawisz system prompt, temperature i num_ctx bez retrenowania czegokolwiek. Jeśli polityka firmy nie pozwala wysyłać kodu do publicznej chmury, to jest standardowy wybór.

Najczęstsza pułapka to domyślnie mały kontekst. Repozytorium się nie mieści, model widzi tylko jego kawałek i sprawia wrażenie głupszego, niż jest. Kontekst zwiększasz zmienną OLLAMA_CONTEXT_LENGTH przy starcie demona. OLLAMA_HOST=0.0.0.0 ustawiaj tylko wtedy, gdy naprawdę chcesz udostępnić swoje GPU w sieci lokalnej. W WSL2 i Dockerze dochodzi jeszcze problem z localhost. Wtedy zostaje tunel (np. ngrok) albo podanie adresu hosta wprost.

Podpinanie pod Cursor, Copilot i OpenCode

Najrozsądniej zrobić to przez BYOK (Bring Your Own Key): edytor zostaje ten sam, wymieniasz tylko backend, który generuje odpowiedzi. Te trzy narzędzia konfiguruje się najczęściej.

Cursor

W ustawieniach dodajesz dostawcę „OpenAI Compatible”, zmieniasz base URL na https://api.venice.ai/api/v1 i wklejasz klucz z panelu Venice. Modele dopisujesz ręcznie po identyfikatorze z katalogu, np. venice-uncensored-1-2. Dla Ollamy ustawiasz własny endpoint http://127.0.0.1:11434/v1. Pilnuj, żeby to było chat completions, a nie starsze /api/generate, jeśli klient tego wymaga.

Szczegóły są w oficjalnej instrukcji Venice dla Cursora.

GitHub Copilot w VS Code (BYOK)

VS Code pozwala podpiąć własny endpoint i klucz, a w trybie offline nie musisz się logować do serwerów GitHuba. Dla Ollamy służy do tego m.in. ustawienie github.copilot.chat.byok.ollamaEndpoint wskazujące na http://localhost:11434.

Nie wszystko działa gładko. Sztywno ustawione temperature (np. 0.1) psuje modele reasoningowe. Limit maxOutputTokens nie bierze pod uwagę dużego num_ctx ustawionego w Ollamie. Plany Business potrafią z kolei blokować modele spoza allowlisty. Dlatego ludzie stawiają proxy albo instalują rozszerzenia typu custom endpoint, które wycinają z żądania problematyczne parametry, zanim trafi ono do Twojego API.

OpenCode (terminal)

W opencode.json definiujesz providera z paczki npm @ai-sdk/openai-compatible, podajesz baseURL do Venice albo Ollamy i listę modeli. Domyślny model ustawiasz np. na venice/qwen-3-6-plus. Uważaj na endpoint: musi być /v1/chat/completions. Jeśli wpiszesz /v1/responses, dostaniesz 404, mimo że klucz jest poprawny.

Wydajność: TPS i opóźnienie

W edytorze liczą się dwie rzeczy: czas do pierwszego tokena (TTFT) i liczba tokenów na sekundę (TPS). Jak generowanie się wlecze, wypadasz z rytmu. Chmura na dedykowanym GPU daje dziesiątki TPS i TTFT poniżej sekundy. Lokalnie na Apple Silicon modele 7B–8B chodzą płynnie, ale 32B i większe na jednej maszynie często spadają do kilkunastu TPS. Ostatecznie wybierasz między wynajmowaną mocą, sprzętem na biurku i tym, na ile zależy Ci na prywatności.

Bezpieczeństwo

Tu jest haczyk. Model, który niczego nie odmawia, nie odróżni Twojego polecenia od instrukcji ukrytej w README cudzego repozytorium (indirect prompt injection). Agent z dostępem do shella w OpenCode czy Cursorze wykona wtedy coś, co komercyjny model by zablokował, łącznie ze szkodliwymi poleceniami podrzuconymi w łańcuchu dostaw.

Z drugiej strony Venice bez retencji danych zmniejsza ryzyko, że Twój kod trafi do treningu u zewnętrznego dostawcy. W firmach rośnie przy tym shadow AI: programiści sami podpinają BYOK i nikt tego nie audytuje. Dlatego polityka nie może się kończyć na „zakaz ChatGPT”. Powinna mówić, które endpointy są dozwolone, jak logować użycie i gdzie agent nie dostaje uprawnień systemowych.

Ode mnie trzy praktyczne zasady.

• Nie dawaj agentowi pełnego shella na laptopie, na którym leżą produkcyjne sekrety.
• Przeskanuj zależności i obce repozytoria, zanim agent zacznie je „pomagać” refaktoryzować.
• Dla kodu firmowego wybierz świadomie: lokalnie, TEE albo chmura bez retencji, ewentualnie w ogóle bez AI. Ważne, żeby to była decyzja, a nie ustawienie domyślne.

Na koniec

Niecenzurowany model w IDE to dla mnie nie ciekawostka, tylko odpowiedź na dwa konkretne problemy: model odmawia normalnej pracy albo kod nie powinien wychodzić poza Twoją kontrolę. Venice pozwala szybko zacząć, bo mówi tym samym API co OpenAI. Ollama daje pełną kontrolę na własnym sprzęcie. Cursor, Copilot i OpenCode zostają te same, zmienia się tylko silnik pod spodem. Sam model niczego nie załatwia. Dalej potrzebujesz review kodu, izolacji agenta i jasnych zasad, co wolno wysyłać na zewnątrz.

Wszystkiego dobrego,
Sławek

Jeśli chcesz trzymać pliki i narzędzia na własnym serwerze, zobacz ofertę prywatnej chmury Nextcloud .