Spór o open-weight AI nie mieści się już w haśle “open kontra closed”. Dla firmy ważniejsze jest pytanie: które workloads powinny zostać przy zamkniętych API, które mogą przejść na open-weight models, kiedy użyć managed inference, a kiedy self-hosting.

Drzewo decyzji dla open-weight AI, managed inference, self-hosting i closed APIs

27 lipca Dario Amodei opublikował stanowisko Anthropic po krytyce, że firma rzekomo chce zakazu open-weight models. Wątek Hacker News urósł błyskawicznie; Firebase pokazywał 914 points i 1,332 comments. Tłem były Kimi K3, listy startupów i dużych firm przeciw szerokim restrykcjom oraz wpisy developerów pokazujące praktyczne użycie open models.

Stanowisko Anthropic jest węższe niż internetowa karykatura. Amodei napisał, że firma nigdy nie postulowała zakazu open-weights models, a modele bez dangerous capabilities są public good. Obawy dotyczą potężnych modeli w rękach autorytarnych rządów, cyber lub biological misuse, alignment failures, industrial-scale distillation i wag, których po publikacji nie da się wycofać.

Builders bronią open weights z praktycznych powodów: koszt, kontrola, latency, customization i mniejsza zależność od API provider. Managed open-weight endpoint może być tańszy. Self-hosted model może trzymać dane w wybranym środowisku. Mały fine-tuned model może wygrać z frontier API w wąskim workflow, jeśli są dobre przykłady i metryka.

To nie jest darmowe. Open weights przenoszą pracę do MLOps: GPUs, serving, quantization, logging, evaluation, patches, access control, provenance i fallback. Rachunek z API usage zmienia się w infrastrukturę i czas inżynierów.

Closed APIs nadal pasują do broad reasoning, general assistants, małych eksperymentów i regulated workflows, gdzie ważne są vendor controls. Managed open-weight inference pasuje do produktów wrażliwych kosztowo i portability. Self-hosting ma sens tylko przy mocnych wymaganiach data residency, latency, privacy lub TCO.

Checklist zaczyna się od provenance i license. Potem internal evals: quality, hallucinations, refusal behavior, latency, cost i failure modes. Trzeba też ustalić, jakie dane może zobaczyć model, gdzie działa inference, kto czyta logs i jak długo są trzymane.

Rozsądna odpowiedź to nie odruchowy ban i nie zachwyt. Open-weight AI jest dziś tematem procurement, architektury i operacji. Decyzję podejmuje się workload po workloadzie.