Imprastraktura ng AI at LLMOps

Arkitektura ng AI

Kapag walang sangguniang arkitektura, bawat koponan ay sarilinang pumipili ng modelo, ng vector store, ng paraan ng pag-uugnay at ng paraan ng paghawak sa mga sikreto. Tinutukoy namin ang ibinabahaging arkitektura na nagpapamura sa ikalawa at ikalimang sistemang AI kaysa sa una.

Ang suliranin sa negosyo

Walang naiipon

Mahal ang unang sistemang AI dahil bago ang lahat. Dapat sanang mura na ang ikalima ngunit karaniwang hindi, dahil magkakaiba ang paraan ng bawat koponan sa paglutas ng parehong suliranin. Ngayon ay may limang paraan ng pagtawag sa modelo, limang paraan ng pagsusuri, limang imbakan ng sikreto at walang kakayahang ilipat ang trapiko sa ibang provider. Dalawang beses binabayaran ang gastos: minsan sa dobleng pagbuo, at muli kapag may kailangang baguhin sa lahat ng lugar nang sabay.

Ang ginagawa namin

Tukuyin ang ibinabahaging bahagi at ang hangganan nito

Idinidisenyo namin ang bahaging dapat maging pareho, gaya ng pag-access sa modelo, paghahanap, pag-uugnay, pagsusuri, observability at mga sikreto, at kasinglinaw naming sinasabi kung ano ang dapat manatili sa aplikasyon, dahil ang labis na sentralisasyon ay lumilikha ng sagabal. Isinusulat ang arkitektura upang manatiling nababago ang pagpili ng provider, kaya hindi nagiging pangmatagalang pangako ang isang pasya sa modelo. Sinusubok namin ito sa dalawa o tatlong tunay na use case sa halip na maghatid ng dayagram lamang.

Arkitektura ng AI

Mga kakayahan

  • Arkitektura ng AI sa kompanya

  • Arkitektura ng LLM

  • Arkitektura ng RAG

  • Arkitektura ng agent

  • Arkitektura ng plataporma ng AI

  • Arkitektura ng AI sa cloud

  • Hybrid na AI

  • Arkitektura ng pribadong AI

Karaniwang paggamit

Karaniwang paggamit

  • Magtatag ng sangguniang arkitektura bago magsabay-sabay ang isang portfolyo ng mga proyektong AI.
  • Pagsamahin sa iisang imprastraktura ang magkakaibang implementasyon ng ilang koponan.
  • Magdisenyo para sa hurisdiksyon o paghihiwalay na pumipigil sa karaniwang daan sa cloud.
  • Suriin ang arkitekturang lumalabas na magastos baguhin.

Paano kami naghahatid

Paano kami naghahatid

  1. Suriin

    Tukuyin ang mga hadlang: lokasyon, latency, gastos at kung ano ang tumatakbo na.

  2. Idisenyo

    Idisenyo ang gateway, ruta, cache at failover upang manatiling nababago ang pagpili ng provider.

  3. Sukatin

    Ikabit ang observability, pagsusuri at pagtukoy ng gastos bago dumating ang trapiko.

  4. Patakbuhin

    Patakbuhin ayon sa napagkasunduang antas ng serbisyo, na sinusuri ang kapasidad at gastos sa bawat siklo.

Teknolohiya

Teknolohiya

  • Kubernetes
  • Terraform
  • vLLM
  • Ollama
  • LiteLLM
  • OpenTelemetry
  • Prometheus
  • Grafana
  • AWS
  • Microsoft Azure

Seguridad at pamamahala

Seguridad at pamamahala

Ang lugar kung saan maaaring iproseso ang datos ay isang setting at hindi isang palagay: maaaring tumakbo ang mga modelo sa sarili mong cloud tenancy o sa sarili mong hardware kung hinihingi ito ng lokasyon o paghihiwalay. Ang trapikong dumadaan sa gateway ay pinapatunayan, itinutugma sa isang koponan at naitatala, at iyon ang dahilan kung bakit posible ang audit trail at ang modelo ng gastos.

Mga modelo ng pakikipagtulungan

Mga modelo ng pakikipagtulungan

Proyektong AI

Kami ang may pananagutan sa pagdidisenyo at paghahatid ng isang tinukoy na solusyong AI.

Nakalaang Koponang AI

Pangmatagalang nakalaang lakas ng inhinyeriya na binuo ayon sa teknolohiya at paraan ng paghahatid mo.

Pinamamahalaang AI

Kami ang nagpapatakbo, nagbabantay at patuloy na nagpapabuti ng mga sistemang AI sa produksyon.

Bakit TeamExtension.ai

Sinusubok namin ang arkitektura sa pamamagitan ng pagbuo sa ibabaw nito

Ang arkitekturang hindi pa nagdala ng tunay na trabaho ay isang haka-haka lamang. Sinusubok namin ang disenyo sa mga tunay na use case habang tumatakbo ang proyekto, at doon lumalabas ang maling palagay habang mura pa itong itama. Napananatili rin nitong tapat ang dokumento tungkol sa kung ano talaga ang ibinabahagi at kung ano ang mukhang ibinabahagi sa dayagram lamang.

Piling mga kliyente

Mga madalas itanong

Mga madalas itanong

Dapat ba kaming bumuo ng plataporma o hayaang pumili ang bawat koponan?
Nasa gitna, at mas mahalaga ang lugar ng hangganan kaysa sa mismong pagpili. Isentro ang pag-access sa modelo, ang pagsusuri, ang observability at ang mga sikreto, dahil nakikinabang ang mga ito sa pagkakapare-pareho. Iwan sa mga koponan ang lohika ng aplikasyon at ang karanasan ng gumagamit, dahil ang pagsentro sa mga iyon ay lumilikha ng pila.
Paano namin maiiwasang makulong sa isang vendor?
Sa pamamagitan ng pagruruta ng mga tawag sa modelo sa isang gateway na may matatag na panloob na interface, kaya nagiging setting lamang ang pagpili ng provider. Hindi maaabot ang ganap na paglilipat dahil magkakaiba ang asal ng mga modelo, ngunit kayang gawing isang linggo ang gastos ng paglipat sa halip na isang kwarter.
Kailangan ba namin ng nakalaang vector database?
Kadalasan hindi. Kaya ng pgvector sa umiiral nang PostgreSQL ang maraming trabaho sa kompanya nang walang bagong imprastrakturang papatakbuhin. Nagiging sulit lamang ang nakalaang imbakan sa malaking antas o para sa tiyak na tampok, at hindi bilang default.
Gaano ito katagal?
Anim hanggang sampung linggo kasama ang pagsubok sa mga tunay na use case. Ang mas maikling proyekto ay naglalabas ng dokumento; ang pagsubok ang gumagawa ritong arkitektura.

Pag-usapan ang inyong inisyatiba sa AI

Idisenyo ang sangguniang arkitekturang ibinabahagi ng iyong mga sistemang AI: modelo, paghahanap, pag-uugnay, datos at kontrol.