Trustworthy and Controllable Professional Knowledge Utilization in Large Language Models with TEE-GPU Execution

Yifeng Cai; Zhida An; Yuhan Meng; Houqian Liu; Pengli Wang; Hanwen Lei; Yao Guo; Ding Li

Source-linked AI summary

Trustworthy and Controllable Professional Knowledge Utilization in Large Language Models with TEE-GPU Execution

Yifeng Cai, Zhida An, Yuhan Meng, Houqian Liu, Pengli Wang, Hanwen Lei, Yao Guo, Ding Li

arXiv:2512.16238v2Dec 18, 2025cs.OS

TL;DR

LLM services need professional knowledge, but providers face an imbalanced income–risk tradeoff and lack trustworthy, controllable ways to share it. PKUS keeps provider adapters separate inside TEEs while the backbone runs on GPUs, matching fine-tuning and LoRA utility with lower latency than CPU-only TEE and naive CPU-GPU execution.

Problem
Providers receive little revenue participation yet face copyright, privacy, and compliance risks, while existing approaches do not provide trustworthy, controllable knowledge use.
Source: §1 · p. 1, §2.1 · p. 3
Method
PKUS runs each provider’s compact adapter inside a TEE while keeping the backbone model on GPUs.
Source: §1 · p. 2
Results
Across three benchmarks and two representative LLMs, PKUS matches the accuracy and F1 of full fine-tuning and plain LoRA, with 8.1–11.9× speedup over CPU-only TEE and trivial CPU-GPU co-execution.
Source: §1 · p. 2
Takeaways & Limitations
PKUS provides a foundation for organizations to share and monetize proprietary expertise while maintaining control over sensitive intellectual property.
Source: §7 · p. 12
CPU and GPU TEEs lack built-in per-provider isolation and ingress-egress protection, so they do not alone provide the lifecycle control required for professional knowledge.
Source: §2.2 · p. 3

Abstract

from arXiv · show

Future improvements in large language model (LLM) services increasingly hinge on access to high-value professional knowledge rather than more generic web data. However, the data providers of this knowledge face a skewed tradeoff between income and risk: they receive little share of downstream value yet retain copyright and privacy liability, making them reluctant to contribute their assets to LLM services. Existing techniques do not offer a trustworthy and controllable way to use professional knowledge, because they keep providers in the dark and combine knowledge parameters with the underlying LLM backbone. In this paper, we present PKUS, the Professional Knowledge Utilization System, which treats professional knowledge as a first-class, separable artifact. PKUS keeps the backbone model on GPUs and encodes each provider's contribution as a compact adapter that executes only inside an attested Trusted Execution Environment (TEE). A hardware-rooted lifecycle protocol, adapter pruning, multi-provider aggregation, and split-execution scheduling together make this design practical at serving time. On SST-2, MNLI, and SQuAD with GPT-2 Large and Llama-3.2-1B, PKUS preserves model utility, matching the accuracy and F1 of full fine-tuning and plain LoRA, while achieving the lowest per-request latency with 8.1-11.9x speedup over CPU-only TEE inference and naive CPU-GPU co-execution.

1 Introduction

Professional knowledge offers important gains for LLM services, but providers face an imbalanced income–risk tradeoff and lack trustworthy, controllable ways to share it. PKUS separates provider adapters from the backbone, protects them in TEEs, and reports preserved utility with lower latency than CPU-only TEE execution and naive CPU-GPU co-execution.

Providers bear copyright, privacy, and compliance risks while receiving little downstream revenue, making them reluctant to contribute valuable professional knowledge.Providers seek confidential, verifiable use and lifecycle control, including licensing and later revocation or destruction.Source: §1 · p. 1
Existing methods leave providers without an efficient control path: cryptographic execution is costly, while fine-tuning fuses knowledge into the backbone.Fused knowledge is difficult to track, rent, or revoke after deployment.Source: §1 · p. 2
PKUS executes provider adapters inside TEEs while keeping the backbone on GPUs, structurally separating knowledge for controlled loading, sharing, suspension, or destruction.TEE execution keeps proprietary adapters visible only to their owners with auditable operations.Source: §1 · p. 2
EdgePrune, AegisProto, AlignAgg, and SwiftSched provide adapter pruning, hardware-rooted lifecycle management, multi-provider aggregation, and overlapped GPU-enclave execution.The mechanisms address compact representation, protected onboarding and management, aggregation without duplicated LLM inference, and lower runtime communication overhead.Source: §1 · p. 2
PKUS matches the accuracy and F1 of full fine-tuning and plain LoRA, with 8.1–11.9× speedup over CPU-only TEE execution and trivial CPU-GPU co-execution.The evaluation covers two representative LLMs and three benchmarks.Source: §1 · p. 2

2 Background and Motivation

Professional knowledge can improve domain capability, but its sensitivity and providers’ exposure make confidentiality and lifecycle control important. Existing fine-tuning, cryptographic, and TEE approaches have limitations that motivate PKUS’s separation of compact adapters from the backbone.

2.1 Professional Knowledge in LLM Services

Professional knowledge spans domain logic and workflows; providers face little revenue participation alongside copyright, privacy, and compliance exposure, motivating confidentiality and lifecycle agency.Providers need to control which tenants or workloads may use knowledge, under what policies and for how long, and retain the ability to audit or revoke it.Source: §2.1 · pp. 2–3

2.2 Limitations of Existing Approaches

Fine-tuning fuses knowledge irreversibly, cryptographic inference scales poorly, and TEEs lack per-provider isolation and end-to-end lifecycle control.MPC and HE face high inference costs; CPU and GPU TEEs also lack built-in ingress-egress protection.Source: §2.2 · p. 3

2.3 Motivation

PKUS keeps compact knowledge adapters inside TEEs and the backbone on untrusted GPUs, making adapters a unit for provider accounting, sharing, and revocation.The design draws on TEEs’ hardware-rooted isolation and adapters’ ability to encode professional knowledge without modifying the entire model.Source: §2.3 · pp. 3–4

3 Overview

PKUS gives each provider a dedicated protected space for its adapter while running the backbone LLM on an untrusted GPU. Its mechanisms support adapter lifecycle control, multi-provider inference, and lower-latency execution.

Each provider locally derives a compact adapter and transfers it to a dedicated, attested enclave, where it can be used, shared, or revoked without exposure to the operator or other providers.Source: §3 · p. 4
The GPU performs most transformer computation, while enclave logic handles only the computation dependent on protected knowledge.This split keeps sensitive logic inside hardware-isolated enclaves tied to provider identity and policies.Source: §3 · p. 4
EdgePrune prepares adapters, AegisProto manages provider enclaves and sharing policies, AlignAgg aggregates multiple providers without multiple backbones, and SwiftSched reduces cross-boundary interactions.SwiftSched parallelizes GPU and enclave execution to improve inference latency.Source: §3 · p. 4

4 Design

PKUS separates provider-owned professional knowledge from the GPU-hosted backbone: each provider’s adapters run inside an isolated TEE. Its design combines compact adapter pruning, attested lifecycle control, multi-provider aggregation, and split-execution scheduling.

4.1 Abstraction and Execution Model

PKUS keeps most inference computation on an untrusted GPU and applies provider adapters inside isolated, provider-bound TEEs that retain lifecycle control.Providers can update or revoke adapters, while enclaves do not expose internal state or merge adapters into the backbone.Source: §4.1 · p. 4

4.2 Design of EdgePrune

EdgePrune progressively removes low-ranked adapters while checking a validation-metric threshold, producing compact enclave-suitable adapters with fewer parameters and GPU–TEE round trips.Its pruning can be more aggressive for over-parameterized tasks and backbones while retaining more adapters for harder tasks.Source: §4.2 · p. 5

4.3 Design of AegisProto

AegisProto binds enclaves to ownership and policy plans, supports authenticated adapter lifecycle transitions, and couples revocation with attested cleanup and erasure.Enclave preparation establishes a verifiably clean starting state for subsequent onboarding and cleanup.Source: §4.3 · pp. 6–7

4.4 Design of AlignAgg

AlignAgg combines authorized providers’ adapter effects in one inference pass while running the backbone once and keeping each adapter separate.Removing a provider from the authorized set excludes its deltas without retraining or changing the backbone.Source: §4.4 · p. 7

4.5 Design of SwiftSched

SwiftSched overlaps GPU and enclave work, batches boundary crossings, and schedules provider enclaves adaptively to reduce split-execution overhead.It is designed to maintain near-native GPU throughput even with many data providers.Source: §4.5 · pp. 7–8

5 Evaluation

The evaluation measures PKUS utility, EdgePrune, AlignAgg, SwiftSched, and security across two LLM backbones and three professional-knowledge benchmarks.

5.1 Experiment Configurations

Experiments use GPT-2 Large and Llama-3.2-1B on SST-2, MNLI, and SQuAD, reporting accuracy for classification and token-level F1 for SQuAD.The evaluation compares PKUS with full-model fine-tuning and plain LoRA; reported metrics are averaged over three runs.Source: §5.1 · pp. 8–9

5.2 RQ1: Utility

Across six tasks, PKUS is within 1.0 point of better Full-FT or LoRA; mean latency is 12.0 sec (GPT-2 Large) and 8.3 sec (Llama-3.2-1B).Compared with GPU-only inference, mean latency rises from 7.1 sec to 12.0 sec for GPT-2 Large and from 5.2 sec to 8.3 sec for Llama-3.2-1B.Source: Table 1 · p. 9, Table 2 · p. 9, §5.2 · p. 9

5.3 RQ2: Effectiveness of EdgePrune

EdgePrune removes 63.0%–79.0% of GPT-2 Large adapter parameters and 61.0%–80.0% for Llama-3.2-1B without systematic accuracy or F1 degradation.Across tasks, it retains about 30.0% and 31.0% of the original adapter parameters on average, respectively.Source: Table 3 · p. 10, §5.3 · p. 10
EdgePrune yields 1.7×–2.3× speedups on GPT-2 Large and 1.8×–2.4× on Llama-3.2-1B over dense adapters, reducing communication and enclave computation while GPU time stays constant.Communication decreases by 2.0× and enclave computation by 3.6× for GPT-2 Large; the corresponding reductions for Llama-3.2-1B are 1.9× and 4.6×.Source: Figure 2 · p. 10, §5.3 · p. 10

5.4 RQ3: Effectiveness of AlignAgg

With four providers, AlignAgg raises SST-2 accuracy from 78.0% to 93.8% for GPT-2 Large and from 78.8% to 95.7% for Llama-3.2-1B, while MNLI and SQuAD retain gaps to full-data PKUS.On MNLI and SQuAD, four-provider results remain 5.2–12.1 percentage points below the full-data PKUS upper bound across the reported model-task pairs.Source: Figure 3 · p. 10, §5.4 · pp. 10–11
Latency rises sublinearly from k=1 to k=32 enclaves: 12.0 to 32.4 sec for GPT-2 Large and 8.3 to 27.7 sec for Llama-3.2-1B.SwiftSched keeps GPU–TEE round-trips per token fixed and parallelizes enclave calls; latency increases only about 4% and 6%, respectively, from k=16 to k=32.Source: Table 4 · p. 10, §5.4 · p. 11

5.5 RQ4: Effectiveness of SwiftSched

SwiftSched reaches 10.4 sec per request, versus 83.8 sec for CPU-only PKUS and 124.2 sec for naive pipelining; batching, work-stealing, and overlap address communication bottlenecks.The evaluation shows GPU acceleration alone is insufficient when fine-grained boundary communication dominates.Source: Table 5 · p. 11, §5.5 · pp. 11–12

5.6 RQ5: Security Analysis

Under the TEE trust model, PKUS provides confidentiality comparable to MPC and HE, with stronger support for policy-based access, fine-grained revocation, and auditable lifecycle management.AegisProto enables role-, context-, and time-based restrictions; revocation can erase an adapter in seconds without affecting other users or the backbone.Source: §5.6 · p. 12

6 Discussion and Related Work

Prior encrypted-computation and TEE approaches face scaling or LLM-specific limitations. PKUS instead protects per-provider adapters in enclaves while keeping LLM inference practical through split execution.

Encrypted or secret-shared inference costs grow quickly with model size and depth, limiting scale for autoregressive LLMs and interactive workloads.Source: §6 · p. 12
Prior TEE techniques are not optimized for LLMs or multi-provider professional-knowledge use.Source: §6 · p. 12
PKUS protects adapters in per-provider enclaves and keeps enclave computation small to make split execution practical for LLM inference.Source: §6 · p. 12

7 Conclusion

PKUS executes compact LoRA adapters within TEEs while keeping backbone models on GPUs. Across diverse benchmarks, it matches full fine-tuning utility while reducing adapter parameters and latency versus naive TEE baselines.

63-80% adapter-parameter reduction and 8-12× latency improvement over naive TEE baselines accompany PKUS’s utility-preserving evaluation.Source: §7 · p. 12
PKUS matches the utility of full fine-tuning across diverse benchmarks.Source: §7 · p. 12
PKUS executes compact LoRA adapters within TEEs while keeping backbone models on GPUs.Source: §7 · p. 12
PKUS provides a foundation for organizations to share and monetize proprietary expertise while maintaining control over sensitive intellectual property.Source: §7 · p. 12