Skip to main content

2 docs tagged with "confidential inference"

View all tags

Confidential inference: hand your prompt to the cloud without letting the cloud see it — the routes that ship, and what they don't solve

In one sentence what actually ships today is mainly the hardware isolation + remote attestation route — e.g. GPU confidential computing on NVIDIA H100/H200, and Apple Private Cloud Compute as a private cloud architecture with a verifiable transparency log (same mechanism family, different shapes — don't conflate them); the cryptographic route (HE / MPC) is still too expensive at LLM scale. But "confidential" is a marketing word — the real boundary isn't "the vendor says confidential," it's whether you (or your device) verified the attestation, who the threat model covers, and what it still doesn't solve (side channels, trusting the chip vendor, legal orders). This entry takes Volume 1's TEE and HE·MPC foundations down to "can you actually run private inference."

On-device inference as a privacy posture: the prompt really doesn't leave the device — but here's what "on-device" doesn't cover

In one sentence on-device means "the device doesn't send it out." But "on-device" is a word that's easy to over-read — the real boundary isn't "the vendor says on-device," it's which requests still fall back to the cloud, how much capability you trade away because the on-device model is smaller, and the telemetry / diagnostics / model-download channels. Bottom line first: "on-device" ≠ "nothing leaves the device." What's verifiable is that a given request completes on the local device and its prompt didn't leave the device for that path; but which requests run on-device versus fall back to the cloud is a deployment fact to check, not a model promise. For the fall-back-to-cloud portion, you go back to confidential inference to verify it.