Cały stos na Twoich serwerach
Uruchom DialPress tam, gdzie muszą być Twoje dane. Zacznij od jednego serwera z Linuxem, przejdź na kontenery i dorośnij do Kubernetes, z tymi samymi aplikacjami i trasami na każdym etapie.
W skrócie
Twoje dane
Połączenia, nagrania i transkrypcje zostają na infrastrukturze, którą kontrolujesz.
Ten sam kod
Aplikacje i trasy są takie same w chmurze DialPress i na Twoich serwerach.
Na moduł
Dodawaj moc tam, gdzie jest obciążenie, a nie wszędzie naraz.
Bez zrywania połączeń
Zatrzymywane instancje są najpierw opróżniane, więc aktualizacje nigdy nie rozłączają rozmówcy.
Wdrażaj
Wybierz, gdzie działa
Każdy etap używa tych samych modułów. Przejdź wyżej, gdy wymaga tego obciążenie.
- Step 1
Chmura DialPress
Zacznij w naszej chmurze. Numery, operatorzy i mowa w cenie.
$ export DP=https://api.dialpress.ai/v1 $ curl -X POST $DP/agents/front-desk/calls \ -H "Authorization: Bearer $TOKEN" \ -d '{"to": "+15550100", "from": "+15550199"}' { "id": "c_8f2c", "state": "initiating" } $ curl "$DP/calls/c_8f2c?wait=answered&timeout=30s" { "id": "c_8f2c", "state": "answered" } - Step 2
Jeden serwer z Linuxem
Jeden instalator konfiguruje bramę, mowę i agentów jako utwardzone usługi systemd, z TLS dla Twojej domeny.
# hardened systemd units, TLS for your domain $ deploy/linux/install.sh install --build \ --domain voice.yourcompany.com --email [email protected] ✓ dialpress ✓ dialpress-speech ✓ dialpress-agents # or every module as a container $ docker compose -f docker-compose.yml \ -f docker-compose.modules.yml up -d --wait - Step 3
Kubernetes
Chart Helm uruchamia każdy moduł jako osobny workload i autoskaluje go według metryk na żywo. Zatrzymywane pody są najpierw opróżniane, więc wdrożenia nigdy nie zrywają połączeń.
$ helm upgrade --install dialpress deploy/helm/dialpress \ -f deploy/helm/dialpress/values-production.yaml Release "dialpress" has been upgraded. Happy Helming! $ kubectl get deploy -n dialpress dialpress 3/3 dialpress-api 2/2 dialpress-speech 4/4 dialpress-agents 3/3 - Step 4
Maszyny z GPU
Mowa i agenci działają na maszynach z GPU przez wzajemne TLS, z równoważeniem według modelu i obciążenia.
# balanced by model and load, over mutual TLS $ export DIALPRESS_SPEECH_RECOGNITION_BALANCED=true $ export DIALPRESS_SPEECH_RECOGNITION_ENDPOINTS=\ gpu1.example.com:7071;models=whisper-small;weight=2,\ gpu2.example.com:7071;models=whisper-small|parakeet $ dialpress ✓ speech-recognition: 2 endpoints healthy
Stworzone do skalowania
Każda warstwa skaluje się niezależnie.
01
Modułowe z założenia
Każdy moduł (brama, mowa, agenci, wiadomości, nagrywanie) działa w jednym procesie, jako osobny proces albo na własnych maszynach przez wzajemne TLS.
02
Bramy skalowane poziomo
Uruchom tyle instancji bramy, ile potrzebujesz. Rejestracje są współdzielone, połączenia zachowują przypisanie dialogu, a ruch rozkłada się zgodnie z polityką.
03
Mowa rozłożona na GPU
Żądania mowy i agentów trafiają do najmniej obciążonego, sprawnego endpointu obsługującego dany model, z wagami dla każdego GPU.
04
Autoskalowanie
Na Kubernetes każda grupa modułów skaluje się według metryk na żywo i CPU, w granicach ustawionych dla każdego modułu.
05
Wdrożenia bez zrywania połączeń
Zatrzymywane instancje są najpierw opróżniane: bez nowych połączeń, a trwające się kończą. Aktualizacje i skalowanie w dół nigdy nie rozłączają rozmówcy.
06
Ten sam kod, dowolna skala
Jedna binarka na laptopie, stos Compose na VPS albo flota na Kubernetes. Twoje aplikacje i trasy się nie zmieniają.
Częste pytania
Dlaczego self-hosting?
Rezydencja danych, kontrola nad modelami i GPU oraz przewidywalne koszty przy dużej skali.
Czego potrzebuję na start?
Jeden serwer z Linuxem i domena. Instalator konfiguruje TLS.
Czy mowa może działać na osobnych maszynach?
Tak. Mowa i agenci działają na maszynach z GPU przez wzajemne TLS.
Jak wyceniany jest self-hosting?
Wdrożenia self-hosted wyceniamy w ramach umowy enterprise.
Uruchom DialPress na swoich serwerach.
Powiedz nam, gdzie ma działać, a inżynier pomoże Ci dobrać skalę.