最新资讯
dev.to 我们在 DolphinBench 上测试记忆检索:纯关键词搜索暴露了自身回归 dev.to 别再把 Agent 写成 while 循环,把它建模为状态机 bloomberg.com Rightmove 与 Scout24 借 AI 产品应对低迷房市并上调展望 stackoverflow.blog 欢迎来到芯片时代:半导体制造、AI 数据中心与芯片设计的未来 www.youtube.com AI Agent 总犯同样的错:CentralAgent AI 将记忆重构为经验系统 pub.towardsai.net Netflix 科学家建议重采样 LLM 评判:5 次仅将误差棒缩小 13% pub.towardsai.net Jev 作为 LLM 前的静默层:构建提示感知的模型路由器 reddit.com OpenAI 称 Astra 仅满足 10% 安全任务标准 dev.to FreeToken:在自有 GPU 上运行前沿 MoE 模型及其内存需求 dev.to 当 AI Agent 说“完成”时,究竟完成了什么? dev.to 部署 Underdog Bark 3.0 Pro:逐字转写、自定义后端与分块设置 dev.to 为艰难对话构建 AI:五个 Agent、一条安全正则与一位盲评监督者
多元动态
登录 注册
算力商业 engineering.fb.com · @Engineering at Meta

Meta 将 Private Processing 机密计算引入 AI 眼镜

原文 我的收藏

Meta 工程博客介绍把面向 AI 负载的机密计算基础设施 Private Processing 扩展到 AI 眼镜:由于高级功能需要远超眼镜本地算力的模型,且助手需具备有状态、深度个性化的云端能力,Meta 在云端机密虚拟机(CVM)内执行 AI 模型,使 Meta 自身也无法访问用户数据。文章解释了机密计算、TEE 与 Private Processing 的关系,并称该方案延续 2025 年 WhatsApp 和 Meta AI 应用的实践。

AI推荐理由 Meta 工程博客官方披露将 Private Processing 机密计算基础设施扩展到 AI 眼镜,正文具体说明云端 CVM 执行模型、TEE 硬件原语,并回顾 2025 年 WhatsApp 与 Meta AI 应用的既有实践,属于可验证的官方技术细节;但摘要未给出性能、延迟或部署规模数据,落地效果仍待观察。

78

正文

We believe glasses are the best form factor for having AI help throughout your day. They can understand your personal context better than other kinds of devices and keep you present without picking up a mobile phone. Most of the time, glasses are helping you see well, protecting your eyes and complementing your look, and that’s it. But AI glasses have the capacity to provide superpowers like translating a conversation or summarizing notes or a conversation. Many directions people give their glasses today, like placing a call or answering a text hands-free, occur entirely on device, though more advanced features would require larger, more capable AI models – far larger than can be packed into a pair of glasses. And compute is only half the problem. For an AI assistant to be truly useful in everyday life, it must also be stateful and deeply personal — understanding your context, connecting ideas across days or weeks, and working proactively in the background to get things done for you. Taken together, these demands mean the work has to happen in the cloud. AI glasses present a challenge that traditional cloud architectures were never built to solve: How do you build a hyper-personalized AI that knows your world deeply with enhanced privacy? Our answer is Private Processing, Meta’s confidential computing infrastructure for AI workloads. It extends the trust boundary of AI glasses directly into cloud data centers, executing AI models inside confidential virtual machines (CVMs) such that even Meta cannot access your data. This isn’t a new idea for us. In 2025, we introduced Private Processing for WhatsApp and the Meta AI app, allowing you to have completely private chats with Meta AI, without Meta or WhatsApp ever seeing the data. We’ve learned from that initial approach and we’re expanding it to bring these same privacy benefits to our AI glasses. This blog highlights how we engineered a cloud runtime that processes personal context at scale. “Personal devices like glasses that understand our context — because they can see what we see, hear what we hear, and interact with us throughout the day — will become our primary computing devices.” — Mark Zuckerberg, Personal Superintelligence, July 2025. What are Confidential Computing, the TEE, and Private Processing? Confidential Computing is the paradigm. Historically, the industry encrypted data in two states: at rest (on disk) and in transit (over the network). The vulnerability has always been the third state: in use. Data had to be decrypted in memory to be computed on, leaving it exposed to the host operating system, the hypervisor, and the infrastructure operator. Confidential computing is the industry-wide movement to close that gap, ensuring data remains protected even while being processed. The Trusted Execution Environment (TEE) is the hardware primitive. The TEE is a hardware capability in certain CPUs and GPUs that enables confidential computing. The processor encrypts the memory of a special virtual machine, a CVM, under a key held by dedicated security hardware on the chip. That key is never released to the host operating system, the hypervisor, or anyone operating the machine. This capability spans host CPUs and GPUs, so a workload that needs both of these compute targets stays inside the trust boundary across them. To the host operating system, the hypervisor, and the infrastructure administrator, the CVM memory is ciphertext. As defined by the Confidential Computing Consortium (CCC), a TEE physically enforces three strict guarantees: Data Confidentiality: No one outside the CVM, including Meta and the host operating system, can read data in CVM memory while it is in use. Data Integrity: No one outside the CVM can add, remove, or alter that data. Code Integrity: No one can modify the code executing inside the CVM once it has loaded. The client demands a remote attestation report, signed by a key that exists only inside that chip, carrying a measurement of the software image the CVM loaded. It then checks that the signature chains back to a root key the chip vendor publishes, and that the measurement matches one we published to an append-only ledger witnessed by an independent third party. If either check fails, the client refuses to connect and no data is sent. Private Processing is Meta’s confidential computing infrastructure, built on TEEs with verifiable transparency. On top of the confidentiality and attestation the hardware provides, it adds non-targetability and encrypted storage. Private Processing for AI Glasses: Extending the Device Boundary The more you use an AI assistant, the more useful it gets as it learns your style, preferences and context. Wearable AI assistants will help you in similar ways, including with everyday life. To do that they need to know you and your context. That can include connecting ideas across days or weeks, and working proactively in the background to get things done for you without requiring rework from you. This would demand compute capabilities beyond what an ergonomic form factor like a pair of glasses can host locally. That’s where Private Processing comes into the picture. Traditional cloud architectures encrypt data in transit and at rest, but must decrypt it in host memory during processing — potentially exposing it to the underlying system while in use. Private Processing helps us solve this problem, ensuring off-device data stays inaccessible to anyone including Meta. To make this work, we built Private Processing for AI glasses on five engineering requirements, all designed so that we can safely offload intensive AI workloads like streaming transcription, contextual search, and long-term recall: Hardware Isolation: User data must be cryptographically unreadable to host operating systems, hypervisors, and Meta in transit, in use, and at rest. Fail-Closed Guarantees: An attempt to modify the confidential processing guarantee must either cause the system to fail closed, or become publicly discoverable through verifiable transparency. Public Verifiability: Every CVM image running in production is registered to an append-only, publicly witnessed transparency ledger. Non-Targetability: An attacker or malicious actor must be incapable of targeting a specific individual’s session or storage without attempting to compromise the entire Private Processing System. Encrypted Storage: When a product needs to store data for Private Processing to access later, it is encrypted and only accessible with a user-provided key. We’ve designed this multi-regional, fault-tolerant system to handle large amounts of data with high reliability. Private Processing defends against a specific set of threats. The foundational threat model is documented in the Private Processing whitepaper. How Private Processing Works for AI Glasses 1. Decoupling Identity (Non-targetable Routing) Before data even leaves your glasses we have to solve a metadata problem. If we know who is sending a request, the operator can possibly route your traffic to a compromised machine. During session establishment, we use anonymous credentials — blind-signed tokens fetched on randomized schedules — so that when your device makes a request, our authentication service cannot tie it back to your account. Next, your device connects to our gateways through a third-party OHTTP relay (Fastly or Cloudflare) to select a TEE node. An incoming request is serviced by a TEE that was selected based on non-user-identifiable heuristics. 2. Remote Attestation (Verification) Before your glasses send any context, they verify our servers. Your device initiates a remote attestation and TLS (RA-TLS) session, demanding a hardware-signed certificate from the server’s TEE. Your glasses cross-check the TEE’s binary hashes against an independent, public transparency ledger. If the CPU/GPU vendor certificate check fails, or the binary hash does not match the ledger, the handshake fails and your device does not connect. 3. Processing (Execution) Once the server proves it is trustworthy, your device communicates securely over TLS. Our infrastructure routes the encrypted blob, but cannot read it. Inside the TEE, AI models go to work in an isolated environment, where even Meta cannot access your data. If our models need to communicate with other models, the TEEs must attest to over the same strict RA-TLS protocols before transferring the data. 4. Stateful Memory (Encrypted Storage) When a feature requires persistent memory, the output is encrypted with user-provided keys before it ever leaves the TEE. Meta’s infrastructure stores the ciphertext. When you need to retrieve a memory later, your device provides the key and the TEE decrypts the data and processes your query. Storage Inside the Boundary: Encrypted Storage The experiences people want from AI on their glasses, like picking up across sessions or recalling a moment from earlier, only work if the system can retain information over time. Building stateful experiences for AI glasses forces an architectural choice. The obvious approach is to encrypt user data on the device and store it in a standard cloud database. That approach breaks down under scrutiny for two reasons: Access patterns leak behavior: Even if the contents of a database are strongly encrypted, an external database still observes when you read and write data, how frequently you query it, and which records are accessed together. That metadata alone maps your daily routine and behavioral patterns. Encryption protects payload content; it does not hide execution patterns. Remote encrypted queries do not scale: Running complex operations like semantic vector search or multi-session joins over traditional encrypted storage requires pulling massive ciphertext payloads out of the database, transferring them across the network into a secure TEE, and decrypting them just to run a single query. As a user’s context grows, latency spikes and performance collapses. To solve both problems, we built the storage engine directly inside the TEE. We have extended the trust boundary so that data isn’t just processed confidentially; it is stored confidentially. Your data remains encrypted. It is accessible only from within the TEE across CPUs and GPUs; ready to be recalled by you, and completely inaccessible to anyone else – including Meta. Instead of treating the cloud as a distant database, stateful Private Processing on demand co-locates execution and state inside processor-encrypted memory. Query engines run directly within the TEE boundary. Read Write transactions are fast because reads never cross an external network boundary. Debugging in the Dark: Operational Observability When you build an infrastructure that cryptographically locks out operators, you create a fundamental operational challenge: How do you maintain a high-availability system when engineers are unable to look inside? Standard engineering diagnostics are useless inside a TEE: Engineers cannot attach a debugger to a running TEE. Systems cannot dump memory stacks or log model inputs and outputs during a crash. Teams cannot inspect the specific payload that triggered an operational fault. Operational visibility must be achieved entirely out-of-band. We architected our observability layer to rely on aggregate health signals — CPU utilization, memory allocation, network latency, and aggregate hardware failure rates. These signals give us the telemetry required to maintain service health and uptime without ever exposing a single byte of user data. Verifiable Transparency Security claims are meaningless if they depend on trusting the provider. Private Processing is designed so that every architectural guarantee we make can be verified independently by external researchers. Binary Transparency via Public Ledgers Every CVM image deployed in production is registered to an append-only, publicly-witnessed transparency ledger. If we ever attempted to deploy code that differed from what was published, client devices and external monitors would be able to discover the mismatch. What that establishes is tamper-evidence. Because every deployed image is recorded, we cannot substitute different binary without the change being visible in a record we do not control. Binary access is what lets a researcher go further and confirm that a recorded image behaves as we describe. The ledger and the measurements it records are publicly visible. The corresponding binaries are available to researchers in our security program under agreement. Third Party Validation This design assumes an adversarial environment inside our own data centers. Traditional cloud security draws its boundary at the edge: It protects servers from the outside world while trusting the hypervisor, the host operating system, and the administrators who run them. Private Processing moves that boundary inward and puts all three outside it. To validate this stance, we don’t rely solely on internal reviews. We actively partner with independent security firms (like NCC Group) and researchers to audit our architectural design, review our attestation logic and probe the boundaries of our isolation model. Meta’s Bug Bounty Program: External Auditing and Research Transparency requires open avenues for validation. To enable further independent security research into Private Processing’s design and implementation, we are expanding our Bug Bounty program to explicitly cover Private Processing on AI glasses. We’ll be providing external researchers with the tools, CVM binaries, and documentation needed to audit our implementation, test our attestation chains, and hold our platform accountable. Private Processing for an Agentic Future To date, Private Processing has focused on discrete tasks, like summarizing a message. But the future of AI is agentic and multimodal. In the future, your glasses will have the capacity to take actions on your behalf across different sessions, in a range of real-world contexts. As we work towards launching the kinds of experiences that will help you throughout your day, Private Processing will serve as our foundation. AI on glasses is going to become increasingly stateful, multimodal, and agentic, which means that the trust boundaries also become more complex. An agent holding a sensitive state requires strict isolation, verifiable data provenance, and inter-CVM communication. Our Private Processing infrastructure is the foundation for that future. AI capabilities will grow, but the security and privacy boundary will remain intact. The post Bringing Private Processing to Meta AI Glasses appeared first on Engineering at Meta.

来源报道 · 3 篇 · 以下链接均前往原始媒体

rss:Meta Engineering Meta 将 Private Processing 机密计算引入 AI 眼镜 09-24 · 原文发布
opmlrss::Engineering at Meta Meta 将 Private Processing 机密计算引入 AI 眼镜 09-24 · 原文发布
Engineering at Meta Meta 将 Private Processing 机密计算引入 AI 眼镜 09-24 · 原文发布
← 返回精选动态 原文

更多内容