Paikalliset kielimallit.
Tarkoituksenmukaisesti mitoitetut.
Sopivasta mallista ylläpidettyyn tekoälypalveluun: DAXS suunnittelee paikallisen LLM-infrastruktuurin, testaa laitteiston todellisella kuormalla ja integroi ratkaisun nykyiseen IT-ympäristöönne.
Tekoälypalvelin alkaa kuormitusprofiilista.
Paikallinen kielimalli voi valmistella sisäisiä tekstejä, tukea koodiluonnoksia tai toimia tiedonhaun osana. Käyttökelpoinen ratkaisu edellyttää mallin laadun, sallittujen tietovirtojen ja odotetun käytön yhteensopivuutta. DAXS kartoittaa vaatimukset, suunnittelee infrastruktuurin ja hoitaa asennuksen, integraation sekä sovitun ylläpidon yhdessä IT:nne kanssa tai rajattuna palvelukokonaisuutena.
Tehtävä ja laatu
Mitä kysymyksiä, kieliä, asiakirjoja tai koodaustehtäviä ratkaisun tulee hallita? Lyhyt keskustelu ja pitkien asiakirjojen analyysi tarvitsevat erilaiset mallit ja kontekstit.
Käyttö ja odotusaika
Kuinka monta pyyntöä saapuu samanaikaisesti? Kuinka nopeasti ensimmäisen reaktion on alettava ja kauanko kokonainen vastaus saa kestää? Satunnaiset yksittäiset pyynnöt ja jatkuvasti käytetty tiimipalvelu tarvitsevat erilaiset vararesurssit.
Tiedot ja ylläpito
Mitkä lähteet ja toiminnot on hyväksytty? Missä malli, hakuindeksi, lokit ja varmistukset saavat sijaita? Kuka hoitaa päivitykset ja virheet, ja millainen paluureitti tarvitaan?
Yhdistä sovellus, päättely ja ylläpito selkeästi.
Käyttöliittymä on vain yksi osa. Sen edessä ovat identiteetin ja pääsyn kontrollit. Taustalla toimivat päättelypalvelu, mallivarasto sekä tarvittaessa tiedonhaku tai yritysrajapinnat. Valvonta, päivitykset ja palautus kuuluvat samaan suunnitelmaan.
Kaavio esittää mahdollista arkkitehtuuria, ei todellista asiakasverkkoa. Käänteinen välityspalvelin voi suojata TLS-yhteyden ja sisääntulon. Sovelluksen on silti toteutettava käyttäjäoikeudet. Mallirajapinnat rajataan tarvittaviin verkkoihin ja toimintoihin. Tavoitettava päättelyportti ei vielä ole valmis yrityspalvelu.
Enemmän kuin mallitiedoston koko.
Valinnassa tarkastelemme painoja, ajoympäristön tarvetta, kontekstia, rinnakkaisuutta ja koko tietovirtaa. GPU:ssa voi olla riittävästi muistia, vaikka se ei sovellu haluttuun vastausaikaan. Toisaalta pienempi, hyvin valittu malli voi ratkaista tehtävän taloudellisemmin.
| Osa | Mitä tarkastamme | Miksi se on tärkeää |
|---|---|---|
| GPU ja näyttömuisti | Arkkitehtuuri, ajurit, päättelyn taustajärjestelmä, tuetut laskentamuodot, muistin koko ja kaistanleveys. | Painot ja KV-välimuisti tarvitsevat tilaa. Laskentateho ja muistinsiirrot vaikuttavat eri työvaiheisiin. Pelkkä mainostettu TOPS-arvo ei kuvaa sovellusta. |
| Yksi tai useampi GPU | Mallin jakaminen, GPU:iden välinen yhteys, PCIe-liitäntä, energia ja jäähdytys. | Näyttömuisti ei yhdisty automaattisesti vapaasti käytettäväksi yhteiseksi muistiksi. Valitun ohjelmistokokonaisuuden on tuettava jakoa ja synkronointia. Lisä-GPU:t voivat synnyttää uusia pullonkauloja. |
| CPU ja keskusmuisti | Ajoympäristö, tokenisointi, tietojen valmistelu, rinnakkaiset prosessit sekä tarvittaessa CPU-päättely tai kuorman siirtäminen. | Mallin osien siirtäminen voi mahdollistaa suorituksen, mutta muuttaa suorituskykyprofiilia. Siirrot keskusmuistin ja GPU:n välillä voivat hidastaa vastausta. Myös GPU-palvelin tarvitsee sopivat CPU- ja keskusmuistivarat. |
| NVMe ja tallennus | Malliversiot, latausajat, hakuindeksi, tuontitiedot, lokit, vapaa kapasiteetti ja varmistukset. | Nopeat NVMe-SSD:t auttavat mallin latauksessa ja tietyissä tietotoiminnoissa. Kokonaan GPU-muistiin mahtuvan mallin tokenituotanto määräytyy ennen kaikkea laskennan, muistin ja ajoympäristön tekijöistä. |
| Verkko ja sähkönsyöttö | Yhteydet, sallitut tietovirrat, tila, sähkönkulutus, hukkalämpö ja huoltopääsy. | Paras yksittäinen laskentakomponentti auttaa vähän, jos palvelua rajoittaa todellisella kuormalla lämpötila, organisointi tai pääsy tietoihin. |
Laskenta-apu, ei ostosuositus.
Pelkkien painojen teoreettista alarajaa voidaan arvioida karkeasti kaavaa parametrien määrä × bittiä painoa kohden ÷ 8 käyttäen. Kuvitteellinen kahdeksan miljardin parametrin malli neljällä bitillä painoa kohden antaa laskennallisesti neljä gigatavua eli noin 3,73 GiB.
Lisäksi tarvitaan kvantisoinnin metatiedot, mahdolliset suuremman tarkkuuden malliosat, KV-välimuisti, työalueet ja ajoympäristö. Tämä arvo ei siis kerro, mikä näyttömuistikapasiteetti riittää sovellukseenne. Asiantuntija-arkkitehtuurin malleissa on lisäksi erotettava aktiiviset laskentaosuudet ja kaikki säilytettävät painot.
Lyhyt vastaus ja tiimipalvelu ovat erilaisia testejä.
Konteksti-ikkuna sisältää tiedot, jotka malli voi huomioida yhdessä pyynnössä. Sovelluksen mukaan niihin kuuluvat ohjeet, keskusteluhistoria, haetut asiakirjaosat ja suunniteltu tuloste. Nimellisesti suuri konteksti-ikkuna ei takaa sopivaa laitteistoa eikä tietojen luotettavaa hyödyntämistä.
KV-välimuisti
Avain-arvovälimuisti säilyttää huomiointimekanismin välitiloja. Sen tarve riippuu muun muassa malliarkkitehtuurista, tietotyypistä, todella käytetystä kontekstista ja samanaikaisesti aktiivisista sekvensseistä. Laajempi konteksti ja suurempi rinnakkaisuus lisäävät usein muistitarvetta huomattavasti.
Prefill ja decode
Prefill-vaiheessa malli käsittelee syötekontekstin. Decode-vaiheessa syntyy lisää tokeneita. Vaiheet kuormittavat laitteistoa eri tavoin. Pitkät asiakirjat voivat pidentää aikaa ensimmäiseen tokeniin, vaikka seuraava tulostus vaikuttaisi sujuvalta.
Eräkäsittely ja jono
Yhteinen käsittely voi kasvattaa kokonaisläpäisyä. Samalla yksittäiset käyttäjät voivat odottaa pidempään. Varattu kapasiteetti, jonot, rajat ja sopiva rinnakkaisuuden suunnittelu kuuluvat siksi toteutukseen.
Mittaamme todellisen käyttötapauksen.
Pilotti sisältää tyypilliset lyhyet ja pitkät pyynnöt sekä samanaikaisen käytön. Tarkastelemme aikaa ensimmäiseen tokeniin, kokonaisvastausaikaa, tulostusnopeutta, jonoa, virheosuutta ja muistinkäyttöä. Tokenia sekunnissa on mielekäs vertailuarvo vain malliversion, kvantisoinnin, kontekstin, kuorman ja mittausolosuhteiden kanssa.
Ohjelmistokokonaisuus valitaan mallin ja käytön mukaan.
Ollama, llama.cpp ja vLLM ovat mahdollisia osia. Valinta ja määritykset riippuvat mallituesta, laitteistosta, halutusta rinnakkaisuudesta, ylläpidosta ja integraatiosta. Tarkastamme konkreettisen version sen sijaan, että yleinen asennuskomento määrittäisi tuotantoarkkitehtuurin.
Ollama
Mahdollinen aloitus mallien hallintaan ja paikalliseen tarjoamiseen. Mallivaraston, hyväksyttyjen mallien, kontekstin, rinnakkaisuuden ja palvelun suojauksen on sovittava ympäristöön.
llama.cpp
Joustava osa sopiville malleille eri CPU-/GPU-taustajärjestelmissä, kvantisoiduilla muodoilla ja palvelinkäytössä. Laitteistotuki, jakaminen ja todella tarvittavat API-toiminnot testataan käytännössä.
vLLM
Vaihtoehto sopiviin palvelinpuolen päättely- ja kuormitusprofiileihin. Ajoitus, KV-välimuisti, eräkäsittely ja tarvittaessa useat GPU:t sovitetaan yhteen. Suurempi kokonaisläpäisy ei tarkoita jokaisen yksittäisen pyynnön lyhyempää odotusta.
Kontti, virtuaalikone vai oma palvelin?
Kontit voivat paketoida ohjelmistoversiot toistettavasti. Virtuaalikone voi lisäksi rajata ympäristöä organisatorisesti ja teknisesti. Sopiva tapa riippuu laitteiden läpiviennistä, ajureista, huollosta ja nykyisistä ylläpitomenettelyistä. Yhteensopiva API helpottaa liittämistä, mutta ei korvaa toimintatestiä sovelluksellanne.
Milloin Proxmox ja GPU-läpivienti sopivat?
GPU-läpivienti liittää sopivan fyysisen GPU:n virtuaalikoneeseen. Muun muassa alustan ja laiteohjelmiston, IOMMU-ryhmien, isäntä- ja vierasajurien sekä laitteen nollauskäyttäytymisen on sovittava yhteen. Tarkastamme konkreettisen yhdistelmän ennen sitoumusta.
Liitetty GPU ei jakaudu automaattisesti joustavasti usean virtuaalikoneen kesken. vGPU ja suora läpivienti ovat eri ratkaisuja omine edellytyksineen ja mahdollisine lisenssiehtoineen. Myös huolto, varmistus ja mahdollinen isäntäpalvelimen vaihto tarvitsevat sopivan menettelyn. Yleinen lupaus suorasta migraatiosta kesken käytön olisi perusteeton.
Infrastruktuuri ja virtualisointi · Arvioi Proxmox-migraatio
Sopivan mallin on selvittävä tehtävästä.
Vertailemme malleja myöhemmän käytön hyväksytyillä esimerkeillä, kuten saksankielisillä ammattikysymyksillä, asiakirjaotteilla, monikielisillä pyynnöillä tai konkreettisella skriptitehtävällä. Koodausmalli ja upotusmalli hoitavat eri tehtäviä. Tiedonhaussa haun, vektoriesitysten ja vastausmallin on sovittava yhteen.
Kvantisointi vähentää usein muistitarvetta. Vaikutukset vastausten laatuun, työkalukutsuihin ja nopeuteen tarkastetaan valitulla muodolla. Suurempi malli ei automaattisesti ole parempi tai taloudellisempi valinta. Myöskään pitkä enimmäiskonteksti ei osoita, että malli käyttää luotettavasti jokaista siihen sisältyvää tietoa.
- Lisenssi: tarkasta valitut mallipainot, kaupallinen käyttö, edelleenluovutus ja tarvittavat ilmoitukset konkreettisesti. Helppo lataus ei korvaa tarkastusta.
- Versio: kirjaa malli, kvantisointi, tokenisoija ja ajoympäristö jäljitettävästi.
- Hyväksyntä: testaa toiminnallinen soveltuvuus, kielletyt vastaukset, kielen laatu ja virhetilanteet toistettavalla kysymysjoukolla.
- Muutokset: testaa uudet malliversiot ensin, säilytä käyttökelpoinen paluureitti ja rakenna hakuindeksit uudelleen tarvittaessa vektoriesitysten muuttuessa.
Paikallisesti, ulkoisesti tai sopivana yhdistelmänä.
Oma laitteisto voi olla perusteltu sopivalla käyttöasteella, selkein tietovaatimuksin ja olemassa olevilla ylläpitoresursseilla. Ulkoinen palvelu voi sopia paremmin vaihtelevaan käyttöön, erityisiin mallikykyihin tai vähäiseen omaan ylläpitokapasiteettiin. Hybridi yhdistää kohdennetusti rajatut tehtävät ja tietovirrat.
Vertailu sisältää hankinnan tai käytön, sähkön ja jäähdytyksen, lisenssit, integraation, päivitykset, ylläpidon, vararesurssit ja häiriöiden seuraukset. Paikallinen käsittely ei takaa automaattisesti turvallisuutta tai tietosuoja-asetuksen noudattamista. Myös mallien, vektoriesitysten, telemetrian, päivitysten, ulkoisten työkalujen ja lokien on sovittava sovittuun tietomalliin.
Suunnittelemme ensin rajatun pilotin mitattavilla vaatimuksilla. Tulosten perusteella päätetään laajentamisesta, mukauttamisesta tai yksinkertaisemmasta vaihtoehdosta. Lisätietoa löytyy sivulta Pilvipalvelut ja SaaS.
Ylläpidetty palvelu tarvitsee selkeät vastuut.
DAXS voi suunnitella ja asentaa laitteiston sekä ohjelmiston, yhdistää ne nykyisiin identiteetteihin ja sovelluksiin sekä hoitaa sovitun jatkuvan ylläpidon. Mukaan kuuluvat tavoitettavuuden ja resurssien seuranta, versioiden ylläpito, virheenkäsittely ja dokumentointi. Tarvittavasta käytettävyydestä ja reagointitavoista sovitaan konkreettisesti.
Määrittelemme varmistettavat asetukset, sovellusosat, indeksitiedot ja tarvittaessa mukautetut mallit. Uudelleen hankittavat mallipainot ja suojattavat operatiiviset tiedot tarvitsevat erilaiset varmistukset. Palautustesti kuuluu sopivaan käyttömalliin.
Vaatimusten kartoitus, arkkitehtuuriehdotus, malli- ja kuormitustesti, dokumentoidut tietovirrat sekä perusteltu suositus laitteistosta, käyttömallista ja seuraavista integraatiovaiheista.
Selvitämme nämä keskustelussa.
Kuinka paljon näyttömuistia paikallinen kielimalli tarvitsee?
Se riippuu mallista ja kvantisoinnista, ajoympäristöstä, kontekstista sekä samanaikaisista pyynnöistä. Pelkkä mallitiedosto ei riitä perusteeksi. Testaamme halutun tehtävän pitkine pyyntöineen ja kuormitushuippuineen ennen konkreettisen varustelun suosittelemista.
Onko toinen GPU automaattisesti nopeampi?
Ei. Valitun ohjelmistokokonaisuuden on tuettava jakamista. GPU:iden väliset yhteydet, synkronointi ja malliarkkitehtuuri vaikuttavat tulokseen. Lisämuisti voi mahdollistaa suorituksen nopeuttamatta jokaista yksittäistä vastausta.
Voiko nykyistä Proxmox-palvelinta käyttää?
Se voi sopia, jos laitteisto, IOMMU-ryhmät, ajurit ja GPU-läpivienti soveltuvat tehtävään. Lisäksi muiden palvelujen vararesurssien sekä huolto-, varmistus- ja palautusmenettelyjen on oltava kunnossa. Tarkastamme nykyisen alustan konkreettisesti.
Koulutetaanko sisäiset asiakirjat malliin?
Tiedonhaussa sitä ei usein tarvita. RAG hakee sopivat ja sallitut asiakirjan osat ja antaa ne mallille kontekstiksi. Mallipainojen muuttaminen on eri toimenpide, joka perustellaan erikseen.
Milloin ulkoinen palvelu on taloudellisempi?
Ulkoinen palvelu voi sopia paremmin vähäiseen tai voimakkaasti vaihtelevaan käyttöön, erityisiin mallivaatimuksiin tai puuttuvaan ylläpitokapasiteettiin. Vertailemme kustannukset, tietovirrat, laadun ja ylläpidon suunnitellulta käyttöajalta.
Seuraa malleja, kuormitusta ja kustannuksia yhdessä.
GPU-käyttöasteen ja vastausajan lisäksi tarkastelemme kustannuksia käyttökelpoista tehtävää kohden. Mallipäivitys verrataan hyväksyttyyn testiaineistoon ennen käyttöä. Virheosuudet, jonot, muistirajat ja häiriöt tarvitsevat nimetyt vastuuhenkilöt ja paluureitin. Ulkoinen varapalvelu tulee kyseeseen vain, jos tietoluokka ja hyväksyntä sen sallivat.
Keskustellaan käyttötapauksestanne.
Minkä pitäisi helpottua, mitä tietoja siihen liittyy ja mitä järjestelmiä on jo käytössä? Näiden perusteella kehitämme tarkoituksenmukaisen aloituksen ja rajattavissa olevan seuraavan vaiheen.