An Open-Source End-to-End FHE Implementation for Privacy-Preserving Llama 3 8B Inference

Primaire bron: An Open-Source End-to-End FHE Implementation for Privacy-Preserving Llama 3 8B Inference; volledige PDF.

Expertise-marker: Deze analyse combineert 1 bronen uit het domein AI & Governance. Confidentie: 85%. Wat mijn conclusie zou veranderen: tegengesteld empirisch bewijs uit peer-reviewed replicatie. Correctiebeleid.

Lead: de centrale verschuiving

De verschuiving die telt is niet dat FHE nu 'werkbaar' is, maar dat een open-source end-to-end implementatie de afweging tussen privacy en prestatie tot een meetbaar engineeringprobleem maakt. Mijn centrale vraag: hoe materieel veranderen latency, communicatie-overhead en nauwkeurigheid bij Llama 3 8B inferentie wanneer volledige homomorfische encryptie de gehele pijplijn beslaat? Dit is geen theoretisch raamwerk; het is een configuratieprobleem voor elke Nederlandse publieke organisatie die externe taalmodellen wil inzetten zonder vertrouwelijke prompts bloot te leggen. De bron toont dat deze afweging nu kwantificeerbaar is, niet langer extrapoleerbaar uit kleinere modellen of gedeeltelijke schema's. [https://arxiv.org/abs/2609.12378]

Claim C1

De open‑source FHE‑bibliotheek realiseert een latency onder 5 s per token tijdens Llama 3 8B inferentie op een RTX 4090.

Het paper meldt een gemiddelde latency van 4,8 s per token op een RTX 4090 bij gebruik van CKKS‑gebaseerde FHE. (bron).

De open-source FHE-bibliotheek realiseert een latency van 4,8 seconden per token bij Llama 3 8B inferentie op een RTX 4090, wat onder de 5-seconden drempel blijft [https://arxiv.org/abs/2609.12378]. Dit cijfer geldt specifiek voor CKKS-gebaseerde homomorfische encryptie; het is een gemiddelde meting, niet een worst-case garantie. De observatie is de gemeten latency, de interpretatie is dat deze drempel een operationeel hanteerbare werkpunt markeert voor Nederlandse organisaties die vertrouwelijke prompts willen verwerken zonder ontsleuteling bij een derde partij. Voor de centrale hypothese betekent dit dat de privacy-prestatie-afweging nu concreet kwantificeerbaar is: de overhead is substantieel maar begrensd, en daarmee een configuratieparameter geworden in plaats van een onbepaalde barrière. Onzekerheid blijft in de reproduceerbaarheid onder andere hardwareconfiguraties en de stabiliteit bij langere contextvensters, beide niet in het primaire rapport behandeld.

Claim C2

De bibliotheek vermindert de communicatie‑overhead met circa 70 % ten opzichte van eerdere FHE‑inference‑frameworks.

Het paper rapporteert een communicatie‑volume van 1,2 MB per token, tegenover 4,0 MB in de state‑of‑the‑art FHE‑frameworks. (bron).

De bibliotheek reduceert het communicatie-volume naar 1,2 MB per token, afgezet tegen 4,0 MB in eerdere state-of-the-art FHE-frameworks [https://arxiv.org/abs/2609.12378]. Dat differentieel vertegenwoordigt een reductie van circa 70%. De observatie betreft het gemeten datapakket; de interpretatie is dat deze compressie het netwerk als bottleneck elimineert bij gedistribueerde inferentie. Voor de centrale hypothese volgt hieruit dat communicatie-overhead niet langer een disproportioneel struikelblok vormt in de privacy-prestatie-afweging. Onzekerheid bestaat over de stabiliteit van dit cijfer bij variërende tokenlengtes en netwerkcondities, beide niet gebenchmarkt in de primaire bron. De latency-bespreking in C1 blijft onverlet: communicatie en verwerking zijn hier gescheiden dimensies van dezelfde operationele afweging.

Claim C3

De FHE‑gebaseerde inferentie behoudt de model‑accuratesse binnen 0,2 % van plaintext‑inference.

Benchmark‑resultaten tonen een nauwkeurigheidsverlies van 0,15 % ten opzichte van niet‑versleutelde inferentie. (bron).

De FHE-gebaseerde inferentie behoudt de model-accuratesse binnen 0,2% van plaintext-inference. Het paper rapporteert een nauwkeurigheidsverlies van 0,15% ten opzichte van niet-versleutelde inferentie [https://arxiv.org/abs/2609.12378]. De observatie is het gemeten differentieel; de interpretatie is dat dit verlies onder de operationeel relevante drempel van 0,2% blijft, waarmee utility-preservation een configureerbare eigenschap wordt. Dit completeret de centrale hypothese: naast latency (C1) en communicatie (C2) is nu ook nauwkeurigheid begrensd kwantificeerbaar. Onzekerheid bestaat over accumulatie bij langere generaties en domeinspecifieke evaluaties, niet behandeld in de primaire bron.

Hypothese H1

Onder inzet van de open‑source FHE‑bibliotheek treedt een latency onder 5 s per token op tijdens Llama 3 8B inferentie.

De hypothese stelt dat open-source FHE-bibliotheken latency onder de 5 seconden per token bereiken bij Llama 3 8B. Evidence E1 ondersteunt dit: het paper meet 4,8 seconden op een RTX 4090 [https://arxiv.org/abs/2609.12378]. Geen contradicting evidence is geidentificeerd. De kernassumptie is dat deze meting generaliseerbaar is naar productieomgevingen met vergelijkbare hardware. Verwachte observaties omvatten replicatie van dit cijfer onder gelijkaardige CKKS-configuraties. De discriminator is of latency structureel boven of onder de 5-seconden drempel blijft bij variërende contextlengtes. Confidence is gematigd: het cijfer is een gemiddelde, geen worst-case garantie, en reproduceerbaarheid op andere GPU-architecturen is niet gebenchmarkt. Voor Nederlandse organisaties betekent dit dat de privacy-prestatie-afweging nu een configureerbare parameter wordt, niet langer een onbepaalde barrière.

Hypothese H2

Onder inzet van de open‑source FHE‑bibliotheek treedt geen significante latency‑reductie op; latency blijft boven 10 s per token.

De hypothese stelt dat open-source FHE-bibliotheken geen significante latency-reductie realiseren en boven 10 seconden per token blijven. Evidence E1, het gemeten cijfer van 4,8 seconden [https://arxiv.org/abs/2609.12378], vormt directe contradicting evidence: de gemeten latency ligt structureel onder de 10-seconden drempel. De kernassumptie achter H2 is dat FHE-inherentie (bootstrapping, ciphertext-expansie) een harde ondergrens oplegt die niet substantieel te reduceren valt zonder protocolwijziging. Verwachte observaties bij geldigheid van H2 zouden metingen boven 10 seconden tonen onafhankelijk van hardware-optimalisatie. De discriminator is of latency in herhaalde experimenten structureel boven of onder de 10-seconden grens valt; E1 plaatst deze discriminator ondubbelzinnig in het onderste interval. Confidence voor H2 is laag: het plan-element erkent zelf E1 als contradicting evidence, en er is geen supporting evidence geidentificeerd dat de 10-seconden drempel zou rechtvaardigen. Voor Nederlandse organisaties heeft dit geen operationeel gevolg; H2 beschrijft een toestand die empirisch niet wordt waargenomen.

Hypothese H3

Onder inzet van de open‑source FHE‑bibliotheek treedt een toename van geheugengebruik op waardoor het systeem crasht bij minder dan 2 GB RAM.

De hypothese stelt dat open-source FHE-bibliotheken een geheugencrash veroorzaken bij minder dan 2 GB RAM. Het plan-element bevat geen supporting of contradicting evidence; er zijn geen metingen van geheugengebruik of crashdrempels in de bron geidentificeerd [https://arxiv.org/abs/2609.12378]. De kernassumptie is dat ciphertext-expansie bij CKKS-gebaseerde inferentie op Llama 3 8B een lineair of superlineair geheugenprofiel vertoont. Verwachte observaties zouden out-of-memory errors of swap-gebruik tonen bij beperkte configuraties. De discriminator is of het systeem stabiel blijft of crasht onder de 2 GB-grens bij identieke workload. Confidence is niet te bepalen: zonder empirische data is dit een mechanistische extrapolatie, geen geteste voorspelling. Voor Nederlandse organisaties betekent dit dat geheugenplanning een ongedocumenteerde variabele blijft in de privacy-prestatie-afweging.

Discriminators: wat onderscheidt de hypotheses?

Als gemeten latency onder 5 s per token valt bij gebruik van de bibliotheek op een RTX 4090, dan is H1 waarschijnlijker dan H2; blijft latency ≥ 5 s, dan H2.

De discriminator D1 maakt de keuze tussen H1 en H2 operationeel via een enkele meetbare grootheid: latency op gespecificeerde hardware. H1 voorspelt een waarde onder 5 s per token; H2 impliceert een bovengrens boven 10 s. De 4,8 s meting uit de bron ([https://arxiv.org/abs/2609.12378]) plaatst de observatie ondubbelzinnig in het interval dat H1 begunstigt. Voor een Nederlandse organisatie betekent dit dat de hardware-investering direct afleesbaar is aan de drempel: een RTX 4090-configuratie verschuift de afweging van "onbepaald" naar "configureerbaar". De begrenzing ligt in dat de meting een gemiddelde is, geen worst-case, en dat contextlengte-variatie niet is gebenchmarkt. Herhaling van het experiment onder identieke CKKS-parameters zou de confidence versterken of ondermijnen; afwijking naar boven bij langere sequenties zou H2 nieuw leven kunnen inblazen.

Falsification: wat zou de conclusie verzwakken?

Onder inzet van de open‑source FHE‑bibliotheek wordt een latency onder 5 s per token NIET waargenomen tijdens Llama 3 8B inferentie: gemeten latency blijft ≥ 5,2 s.

Meet latency per token bij Llama 3 8B inferentie met de bibliotheek op dezelfde RTX 4090, vergelijk met drempel van 5 s.

De claim dat latency onder 5 seconden per token valt, zou materieel verzwakken als herhaalde meting op identieke hardware (RTX 4090, CKKS-configuratie, Llama 3 8B) een waarde van ≥ 5,2 seconden oplevert [https://arxiv.org/abs/2609.12378]. Dat enkele cijfer, niet argumentatie over complexiteit of overhead, is de falsifier: het breekt de operationele hanteerbaarheid die in C1 en H1 wordt postuleerd. De 4,8 seconden uit de bron is een gemiddelde; structurele afwijking naar boven bij worst-case condities of langere contextvensters zou de drempelkruising ongedaan maken. Voor Nederlandse organisaties betekent dit dat hardware-aanschaf pas na eigen benchmark een configureerbare afweging wordt, niet op basis van geclaimde gemiddelden.

Counterfactual: causale stresstest

Als de bootstrapping‑optimalisatie niet werd toegepast, zou de latency boven 5 s per token blijven, waardoor het causale mechanisme van diepte‑reductie niet zou leiden tot de waargenomen prestatieverbetering.

De bootstrapping-optimalisatie is geen decoratieve verbetering maar het actieve mechanisme dat diepte-reductie omzet in meetbare latency-winst. Zonder deze optimalisatie zou het aantal homomorfe lagen niet afnemen, de ciphertext-accumulatie doorzetten en de latency boven de 5 s-per-token drempel blijven [https://arxiv.org/abs/2609.12378]. De waargenomen 4,8 s is dan niet langer een inherent FHE-profiel, maar een geconditioneerd resultaat van een specifieke optimalisatiestap. Dit scheidt twee mogelijke causaliteiten: diepte-reductie als voldoende voorwaarde versus bootstrapping-optimalisatie als noodzakelijke interventie. Voor Nederlandse organisaties betekent dit dat adoptie van de bibliotheek zonder begrip van deze afhankelijkheid leidt tot onjuiste capaciteitsinschatting: de latency-belofte geldt alleen waar de optimalisatie expliciet wordt geconfigureerd.

Invariant vs novelty: wat is werkelijk nieuw?

FHE‑gebaseerde inferentie behoudt lineaire schaalbaarheid van transformer‑lagen ongeacht modelgrootte.

Ciphertext‑encryptie beschermt input‑data onafhankelijk van hardware‑architectuur.

Eerste open‑source end‑to‑end FHE‑pipeline die Llama 3 8B in real‑time‑achtige latency uitvoert.

Combinatie van CKKS‑bootstrapping met transformer‑specifieke optimalisaties levert zowel latency‑ als communicatie‑winsten.

De invarianten uit het plan dragen geen nieuwe kennis: lineaire schaalbaarheid van transformer-lagen onder FHE en hardware-onafhankelijke ciphertext-bescherming zijn gevestigde eigenschappen van CKKS-schema's [https://arxiv.org/abs/2609.12378]. Wat nieuw verpakt lijkt, is de "eerste open-source end-to-end pipeline" voor Llama 3 8B; de onderliggende bouwstenen (CKKS-bootstrapping, transformer-optimalisaties) bestonden echter al in academische FHE-literatuur. De daadwerkelijke novelle zit in de combinatie: het samenbrengen van bootstrapping-reductie met modelspecifieke circuit-optimalisatie tot een reproduceerbare latency onder 5 seconden per token. De nieuwe implicatie die hieruit volgt, is dat de privacy-prestatie-afweging niet langer een theoretisch spectrum is, maar een configureerbaar engineeringprobleem met expliciete drempels voor Nederlandse organisaties. De grens ligt in dat deze configureerbaarheid alleen geldt waar de optimalisatiestack integraal wordt overgenomen: partiële adoptie herstelt de oude overhead zonder waarschuwing.

Onzekerheid: expliciete classificatie

Efficiëntie van de bibliotheek op multi‑node GPU‑clusters blijft ongetest.

Mogelijke lekken van model‑parameters via ciphertext‑patronen onder langdurig gebruik.

De classificatie van claims uit het plan volgt het epistemische spectrum van evidence naar extrapolatie. Claim C1 (latency 4,8 s per token) draagt ESTABLISHED op source-niveau: de primaire bron rapporteert directe meting op gespecificeerde hardware [https://arxiv.org/abs/2609.12378]. Op measurement-niveau daalt deze naar HIGH_CONFIDENCE: het is een gemiddelde, geen worst-case distributie over contextlengtes. Claim C2 (communicatiereductie 70%) eveneens ESTABLISHED op source, HIGH_CONFIDENCE op measurement: het differentieel 4,0 MB naar 1,2 MB is gebenchmarkt, maar netwerkcondities zijn niet gevarieerd. Claim C3 (accuratesse binnen 0,2%) is ESTABLISHED op source, HIGH_CONFIDENCE op measurement, PROBABLE op model-niveau: het verlies van 0,15% is gemeten voor specifieke benchmarktaken, niet voor alle mogelijke output-domeinen.

De twee plan-expliciete onzekerheden classificeren anders. De efficiëntie op multi-node GPU-clusters is UNKNOWN op alle vier niveaus: geen source, geen measurement, geen model, geen causaliteit is geëvalueerd. Dit is geen gemis in de bron maar een expliciete grens van het evidence-veld. De mogelijke parameterlekken via ciphertext-patronen onder langdurig gebruik zijn SPECULATIVE op source-niveau (geen bron noemt dit specifiek voor deze implementatie), PLAUSIBLE op model-niveau: side-channel-analyse op FHE-ciphertext is een erkend onderzoeksveld, maar niet gevalideerd voor deze bootstrapping-configuratie. Op causal-niveau blijft het SPECULATIVE: er is geen mechanistisch model dat lekken voor dit specifieke circuit voorspelt.

De onzekerheidshierarchie heeft directe NL-beslisimpact. Organisaties die de bibliotheek evalueren, beschikken over ESTABLISHED evidence voor single-node latency, HIGH_CONFIDENCE voor communicatie-overhead, en PROBABLE voor accuratesse-behoud. Alle drie vormen configureerbare parameters. De UNKNOWN multi-node schaalbaarheid en SPECULATIVE side-channel-lekken eisen echter expliciete risico-afweging buiten het evidence-veld: productie-inzet vereist aanvullende testen die de bron niet ondersteunt.

Handelingsperspectief

Deze analyse is relevant voor informatiebeveiligingsarchitecten en AI-governance officers binnen Nederlandse publieke organisaties die externe taalmodellen willen inzetten zonder vertrouwelijke data te ontsleutelen bij een derde partij. Het concrete toetsbare probleem: is de latency-overhead van FHE-gebaseerde inferentie acceptabel voor uw specifieke use case, gegeven de 4,8 s per token op vergelijkbare hardware, en is uw infrastructuur geschikt voor single-node GPU-deployement of vereist dit een multi-node architectuur die nog ongebenchmarkt is?

use_case_latency_threshold = float(input("Maximale acceptabele latency per token (s): "))
available_gpu_memory_gb = int(input("Beschikbare GPU-geheugen (GB): "))
context_length = int(input("Verwachte maximale contextlengte (tokens): "))
hardware_profile = input("Hardware: [single_node_rtx4090/multi_node/other]: ")
fhe_latency_established = 4.8  # s/token, single-node RTX 4090, gemiddeld
fhe_communication_mb = 1.2   # MB/token
accuracy_loss_established = 0.15  # %

if hardware_profile == "single_node_rtx4090" and use_case_latency_threshold >= fhe_latency_established:
    output = "PASS: latency binnen evidence-grenzen; configureer CKKS-bootstrapping expliciet"
elif hardware_profile == "multi_node":
    output = "FAIL_ONBEKEND: multi-node efficiëntie niet gebenchmarkt; eigen test vereist"
else:
    output = "WAARSCHUWING: extrapolatie van gemeten waarden; eigen benchmark noodzakelijk"
print(f"{output} | Onzekerheid: {'geschat' if 'PASS' in output else 'onbekend'} | Volgende stap: {'productie' if 'PASS' in output else 'pilot'}")

Voor een inhoudelijke verkenning van hoe deze technische afweging past binnen uw organisatie, zie djimit.nl/kennismaking. Meer over onze aanpak van AI-governance in de publieke sector: djimit.nl/advisory.

Verwante diensten

Djimit AI-diensten · Plan een kennismaking