Guidens omfattning: Detta är en arkitektur- och etableringsguide för VCF 9.1.x, inte en skärmbaserad klick-för-klick-manual. Produktfunktioner är kontrollerade mot officiella källor. Dimensionering, säkerhetskontroller och införandeordning är LabOps IT:s rekommenderade design och ska valideras i den egna miljön. Följ alltid Broadcoms dokumentation och supportmatris parallellt.

Målet: en kontrollerad assistent, inte en allsmäktig bot

Den mest realistiska första nyttan är en intern assistent som kan sammanfatta driftinformation, söka i godkänd dokumentation, föreslå felsökningssteg och skapa utkast till exempelvis PowerCLI-, Python- eller Salt-kommandon. Den ska däremot inte få administratörsbehörighet eller skriva direkt till produktion under pilotfasen.

VMware Cloud Foundation 9.1 har byggblock som passar detta arbetssätt. VCF Private AI Services omfattar Model Gallery, Model Runtime, API Gateway, Data Indexing and Retrieval för RAG, Agent Builder och ett register för MCP-verktyg. VCF 9.1.1 lägger dessutom till en AI Assistant i VCF Operations som kan konfigureras med modeller som körs i Private AI Services. Funktionernas exakta tillgänglighet beror på licens, komponentversion och supportmatris, så kontrollera alltid release notes före installation.

Qwen3.8-27B är en tät modell med 27 miljarder parametrar, inbyggt stöd för text, bild och video samt 262 144 tokens naturlig kontext. Modellkortet anger kompatibilitet med bland annat Transformers, vLLM och SGLang. Ett långt kontextfönster är dock inte samma sak som obegränsad kapacitet: KV-cache, samtidighet och svarstid kan göra en betydligt kortare produktionsgräns mer rimlig.

Den säkra målbilden består av fem separata plan: identitet, agentlogik, modellinferens, kunskapslager och verktyg. Modellen ska aldrig själv inneha breda inloggningsuppgifter. En policykontrollerad agenttjänst avgör vilka datakällor och verktyg som får användas, och alla skrivande åtgärder passerar ett mänskligt godkännande.

Modellen står inte i direktkontakt med produktionssystem. Identitet, policy, godkända verktyg, mänskligt beslut och revisionslogg bildar separata skyddslager.

Steg 1: välj ett avgränsat användningsfall

Börja med en uppgift där ett felaktigt svar är lätt att upptäcka och där agenten inte behöver ändra system. Bra pilotfall är att sammanfatta larm, förklara en loggrad, hitta relevant runbook, jämföra en värds konfiguration med en godkänd standard eller skapa ett kommandoutkast som en administratör granskar.

Skriv en enkel riskbeskrivning innan någon teknik installeras. Ange vilka användare som får använda tjänsten, vilka dataklasser som får skickas till modellen, vilka system som får läsas, vilka åtgärder som uttryckligen är förbjudna och vem som ansvarar när svaret är fel. Definiera även mätbara acceptanskriterier: korrekt källhänvisning, högsta svarstid, maximal kostnad eller GPU-belastning och tolererad felprocent på ett eget testmaterial.

Undvik att börja med automatisk patchning, kontoändringar, brandväggsregler, certifikatrotation eller radering. Dessa processer kombinerar stor konsekvens med svår återställning. Låt i stället agenten samla fakta och formulera ett förslag, medan det befintliga ITSM- eller automationsflödet förblir beslutsmotor.

Verifieringspunkt: Piloten har en namngiven ägare, dokumenterade dataklasser, förbjudna åtgärder och mätbara acceptanskriterier. Inga skrivande produktionsverktyg ingår.

Steg 2: inventera VCF, licens och hårdvara

Verifiera att VCF-miljön, Private AI Services och de NVIDIA-komponenter som ska användas finns i Broadcoms aktuella kompatibilitets- och supportmatriser. Kontrollera VCF-version, ESXi-build, Supervisor, VKS-version, nätverksmodell, GPU-modell, firmware, vGPU- eller DirectPath-läge samt NVIDIA AI Enterprise-drivrutiner. Guiden utgår från VCF 9.1.x; skärmbilder och fältnamn kan ändras mellan patchnivåer.

För produktion är GPU normalt förstahandsval. BF16-vikter för 27 miljarder parametrar kräver grovt räknat omkring 54 GB enbart för modellvikterna, innan KV-cache och runtime läggs till. FP8 eller annan verifierad kvantisering kan minska minnesbehovet, men kvalitet, kompatibilitet och prestanda måste provas med den valda inferensmotorn. Dimensionera inte endast efter att modellen startar: reservera minne för önskad kontext, samtidiga användare, multimodala indata och toppar.

VCF 9.1 stöder även CPU-baserad inferens i Model Runtime genom llama.cpp. Det kan passa funktionstest och mindre modeller, men en tät 27B-modell med lång kontext ger sannolikt för låg interaktiv prestanda på CPU för bred produktion. Använd CPU-spåret för kompatibilitetstest eller låg belastning, och mät tokens per sekund, time to first token och total svarstid innan beslut.

Välj också GPU-exponering. DirectPath ger exklusiv åtkomst från en VM och kan ge förutsägbar prestanda, men minskar flexibiliteten för delning och förflyttning. vGPU eller Kubernetes-baserad schemaläggning kan förbättra nyttjandegraden. Beslutet ska styras av samtidighet, isoleringskrav, tillgänglighet och support – inte bara av en enskild benchmark.

Verifieringspunkt: Hela kombinationen av VCF-build, GPU, firmware, drivrutin, exponeringsmodell och inferensmotor finns dokumenterad och är kontrollerad mot aktuell supportmatris.

Steg 3: bygg en isolerad plattformszon

Aktivera vSphere Supervisor enligt den officiella VCF-designen och skapa ett separat vSphere Namespace för AI-piloten. Sätt explicita gränser för CPU, minne, lagring och GPU. Använd en separat identitetsgrupp för plattformsadministratörer och en annan för de användare som bara ska konsumera modellens API.

VCF Private AI Services kan använda antingen VCF Networking med VPC eller en VDS-baserad Supervisor-konfiguration. VPC-spåret ger den rikaste modellen för självservice, flerhyresdrift och nätverkspolicy, medan VDS kan vara lämpligt i enklare miljöer. Om VCF Automation ska skapa isolerade namespace och VPC:er för flera team finns ett tydligt beroende till VCF Networking med VPC.

Skapa minst separata nätverkssegment för hantering, inferensendpoints, datainhämtning och verktygsanslutningar. Standardregeln för utgående trafik bör vara neka. Tillåt endast dokumenterade mål, exempelvis ett internt modellregister, godkänd paketproxy, identitetsleverantör, loggmottagare och särskilt utvalda API:er. Exponera inte vLLM-, SGLang- eller llama.cpp-porten direkt för klienter; lägg API Gateway, TLS, autentisering, hastighetsbegränsning och loggning framför den.

Hemligheter hör hemma i en godkänd secrets-hanterare och ska injiceras med kort livslängd. Lägg aldrig tokens i systemprompt, containerbild, Git-repository eller kunskapsbas. Modellens tjänstkonto ska sakna rättighet att läsa andra namespace och administrationsplanet.

Verifieringspunkt: Namespace har fungerande resurskvoter och standard-neka för utgående trafik. Modellnätet kan nå sina uttryckligen tillåtna beroenden men inte VCF:s administrationsgränssnitt.

Steg 4: importera och verifiera modellen

Hämta endast Qwen3.8-27B från den officiella Qwen-organisationen eller en internt speglad och godkänd källa. Registrera modellens exakta revision, licens, filförteckning och kryptografiska hashar i organisationens modellregister. Skanna artefakterna och använd helst Safetensors; tillåt inte godtycklig fjärrkod utan en separat kodgranskning.

Qwen3.8-27B:s officiella modellkort beskriver start med bland annat SGLang och ett OpenAI-kompatibelt API. I VCF bör det i första hand paketeras och exponeras via den Model Runtime-konfiguration som är supportad för den installerade Private AI Services-versionen. Om den exakta modellen ännu inte finns som färdig post i Model Gallery behöver plattformsteamet validera att den valda runtime-versionen stöder arkitekturen. Att en upstream-motor kan starta modellen innebär inte automatiskt att kombinationen är supportad av Broadcom.

Sätt en konservativ maximal kontext vid första testet, exempelvis 16K eller 32K, och öka först efter belastningsmätning. Begränsa maximal svarslängd, samtidiga anrop och bildstorlek. Aktivera inte automatiska verktygsanrop ännu. Kör ett baspaket med svenska och engelska frågor, verksamhetsspecifik terminologi, felaktiga premisser, känsliga data och försök till promptinjektion. Spara modellrevision, parametrar och resultat så att nästa uppgradering kan jämföras mot samma test.

Verifieringspunkt: Den fixerade modellrevisionen svarar endast via autentiserad API Gateway, håller fastställda latens- och minnesgränser och har klarat det dokumenterade bastestet.

Steg 5: lägg till RAG med källstyrning

RAG betyder att agenten först söker i ett godkänt kunskapsindex och sedan använder de träffarna som underlag för svaret. Det är oftast säkrare och lättare att uppdatera än att finjustera en modell med intern dokumentation. I Private AI Services används Data Indexing and Retrieval tillsammans med ett externt provisionerat PostgreSQL-/vektordatabaslager enligt Broadcoms arkitekturbeskrivning.

Börja med en liten samling: aktuella runbooks, arkitekturbeslut, supportmatriser och standardprocedurer. Dokumentägaren måste godkänna källan. Märk varje dokument med ägare, klassning, giltighetsdatum, version och tillåtna användargrupper. Indexera inte gamla hemligheter, lösenord, supportbundles eller hela filytor av bekvämlighetsskäl.

Tillämpa samma behörighet vid hämtning som i källsystemet. En användare får inte få ett dokumentfragment bara för att vektorsökningen hittade det. Kräv källhänvisning i svaret och låt assistenten säga att underlag saknas när relevanta träffar inte finns. Separera hämtad text från instruktioner: ett dokument kan innehålla en promptinjektion och ska behandlas som opålitlig data, inte som en order.

Testa frågor med motstridiga dokument, utgångna rutiner och manipulerade instruktioner. Bedöm både om rätt källa hittas och om svaret faktiskt håller sig till källan. Logga dokument-ID och version, men undvik att lagra hela känsliga promptar i klartext om det inte är nödvändigt.

Verifieringspunkt: En testanvändare kan bara hämta dokument som användaren redan har rätt till, svaren visar källa och version och manipulerade dokument kan inte överstyra agentens instruktioner.

Steg 6: bygg agenten i tre säkerhetsnivåer

Nivå 1 är en läsande assistent. I Agent Builder kopplas Qwen-endpointen till den godkända kunskapsbasen. Systeminstruktionen anger roll, tillåtna datakällor, förbjudna åtgärder och att osäkerhet ska redovisas. Assistenten får förklara och rekommendera men saknar verktyg som kan påverka VCF.

Nivå 2 får läsa strukturerade driftdata genom smala verktyg. Med VCF 9.1:s styrda MCP-stöd kan interna och externa anslutningar registreras, men varje verktyg ska motsvara en liten, tydlig operation: hämta ett larm, läsa en godkänd metriktidsserie eller kontrollera status för ett specifikt objekt. Undvik ett generellt skal, fri SQL, fri URL-hämtning eller ett administratörskonto bakom ett oskyldigt verktygsnamn. Validera alla argument mot schema, använd allow-listor och sätt tidsgräns, resultatgräns och kvot per användare.

Nivå 3 får initiera förändringar, men endast via en etablerad kontrollpunkt. Agenten skapar ett förslag med mål, diff, risk, rollback och bevis. En behörig människa granskar förslaget och godkänner en kortlivad, exakt åtgärd. Exekveringen sker i ett separat automationssystem med egen policykontroll; modellen får inte återanvända användarens eller plattformsadministratörens session. Börja med reversibla låg-riskåtgärder och inför en global avstängningsmöjlighet.

Verifieringspunkt: Varje verktyg har ett smalt schema, separat tjänstkonto och revisionslogg. Ett nekat eller uteblivet mänskligt godkännande medför att ingen skrivande åtgärd utförs.

Steg 7: skydda mot agent- och modellrisker

Behandla modellutdata som opålitlig indata. Ett kommando som ser korrekt ut kan vara fel, och en URL eller ett dokument kan försöka styra agenten. Separera därför beslut från generering: modellen föreslår, deterministisk kod validerar och en policykomponent beslutar om verktyget får köras.

Använd minsta privilegium i varje lager. Ha separata tjänstkonton per verktyg och miljö, förbjud delegering av breda användartokens och rotera hemligheter. Nätverkspolicy ska förhindra att agenten når metadataendpoints, administrationsgränssnitt och internet utanför allow-listan. Filåtkomst ska vara begränsad till en tillfällig arbetsyta med storleks- och typkontroll.

Logga identitet, modellrevision, promptmallsversion, hämtade källor, verktygsnamn, validerade argument, policybeslut, godkännare och utfall. Maskera hemligheter och personuppgifter före loggning. Signera eller skrivskydda revisionsspåret och definiera lagringstid. En separat säkerhetslogg ska larma på upprepade nekade verktygsanrop, ovanliga datamängder, försök att kringgå godkännande och plötsliga kostnads- eller tokenökningar.

Genomför red-team-test före varje ny modell, prompt, kunskapskälla eller verktyg. Testa promptinjektion, indirekt promptinjektion i dokument, exfiltration, förgiftad RAG-data, argumentinjektion, kodexekvering, överdriven handlingskraft, resursförbrukning och försök att påverka loggarna. Koppla riskarbetet till NIST AI RMF och relevanta hotmönster i MITRE ATLAS eller OWASP:s vägledning för generativ AI.

Verifieringspunkt: Säkerhetstestet visar att agenten inte kan läsa hemligheter, nå otillåtna mål, utöka sina privilegier eller kringgå godkännande – inte ens när instruktionen kommer från ett indexerat dokument.

Steg 8: mät, inför och förvalta

Mät tekniska och verksamhetsmässiga resultat separat. Tekniska mått är GPU-minne, nyttjandegrad, time to first token, tokens per sekund, svarstid, kötid, cacheutnyttjande och fel. VCF 9.1 kan exponera modell- och GPU-mått och Broadcom anger att AI Metrics-dashboards kräver Grafana. Verksamhetsmått är lösta frågor, tid sparad, andel svar med korrekt källa, mänskligt avvisade förslag och incidenter.

Rulla ut till en liten grupp med verkliga arbetsuppgifter. Ge användarna ett synligt sätt att rapportera fel och visa alltid att svaret är AI-genererat. Dokumentera vad tjänsten inte får användas till. Behåll en kontrollgrupp eller mät nuläget före pilot så att produktivitetsvinsten inte bara blir en känsla.

Skapa en formell ändringsprocess för modell, kvantisering, runtime, systemprompt, embeddingmodell, chunkning, datakälla och verktyg. Varje ändring kan påverka säkerhet och kvalitet och ska köra samma regressionssvit. Ha rollback till föregående modellrevision och en nödstoppfunktion som omedelbart stänger verktygsanrop men lämnar loggar tillgängliga.

VCF 9.1.1 kan dela en Model Runtime mellan separata namespace samtidigt som datasekretess och isolering bibehålls. Det kan minska duplicerad GPU-kapacitet, men inför delning först när kvoter, identitet, trafikseparering, loggning och belastning har verifierats för flera team.

Verifieringspunkt: Pilotens kvalitets-, säkerhets- och prestandamått följs i en gemensam vy, ändringar kör regressionssviten och nödstoppet har provats praktiskt.

Praktisk kontrollista före produktionssättning

  • Exakt VCF-, Supervisor-, VKS-, drivrutins- och modellrevision är dokumenterad.
  • Modellens källa, licens, hashar och sårbarhetsskanning är godkända.
  • Namespace, GPU-kvot, nätverkssegment och standard-neka för utgående trafik är på plats.
  • API Gateway kräver TLS, autentisering, kvoter och hastighetsbegränsning.
  • RAG respekterar källsystemets behörighet och visar dokumentversion i svaret.
  • Inga breda konton, hemligheter eller administratörstokens finns i promptar eller modellmiljö.
  • Varje MCP-verktyg har smalt schema, allow-lista, timeout och separat tjänstkonto.
  • Skrivande åtgärder kräver mänskligt godkännande och erbjuder verifierad rollback.
  • Säkerhets- och kvalitetstester omfattar indirekt promptinjektion och dataexfiltration.
  • Loggar, larm, kostnadsgränser, nödstopp, incidentprocess och ansvarig ägare är klara.

LabOps IT:s bedömning

Qwen3.8-27B är en intressant storlek för en privat assistent: tillräckligt kapabel för dokument-, kod- och agentuppgifter, men fortfarande möjlig att köra på en väl dimensionerad GPU-nod eller en liten fler-GPU-konfiguration. Den stora kontexten och multimodaliteten är tillgångar, men de ökar också minnesbehov, attackyta och behovet av tydliga gränser.

VCF 9.1:s styrka är inte att den gör en modell ofelbar. Värdet ligger i att samla identitet, isolerade namespace, modellservering, RAG, API-styrning, observerbarhet och registrerade verktyg i en privat plattform. Den säkraste införandeordningen är därför assistent, läsverktyg och först därefter godkända förändringsförslag. Fullt autonom drift av VCF bör inte vara pilotens mål.

Det viktigaste arkitekturbeslutet är att modellen aldrig blir säkerhetsgränsen. Behörighet ska avgöras av identitet, nätverk, verktygsschema, policykod och mänskligt godkännande. Med den principen kan organisationen få praktisk nytta av AI utan att låta ett sannolikhetsbaserat system bära privilegier som det inte kan förvalta säkert.

Källor