内存也要加密的机器上云之后：SEV-SNP 与 TDX 的性能代价、迁移限制和远程证明该怎么谈

安全评审要"内存也加密"，工程上接的其实是三笔账

很多团队的机密计算项目，起点都一样：安全评审会上有人提出，磁盘是加密的、传输链路是加密的，唯独数据进了内存之后，对宿主机、对 Hypervisor、对机房运维人员是明文的；只要有人在宿主机上抓一次内存快照，或者从调试接口读一段物理页，所有加密都是白做。于是需求被写成一句很朴素的话——"内存也要加密"。评审通过，预算批下来，机器上去了，运维开始头疼：这台机器不能热迁移，宿主机要维护就得停机；规格改不了，vCPU 数量从创建那一刻起就锁死；磁盘快照不可用，镜像流水线要重做；机器 hang 住之后，外面看不到内存，排障只能从虚机内部摸；镜像里不能放密钥，启动流程要改成"证明通过之后再下发"。

这一段不是吓唬人，是机密虚机在工程上的常态。说白了，你买的是信任边界的收缩，付的是可控性的下降。安全评审关心的是"谁能读到我的数据"，工程要关心的是"我还能不能迁移、能不能扩容、能不能排障、能不能按原来的方式发版"。这两件事不是同一套语言，中间没有翻译就会出事。

先把威胁模型讲清楚，后面所有取舍才有锚点。传统虚拟机里，虚机的内存页由宿主机内核与 Hypervisor 分配和管理，Guest 的物理内存地址本质上就是宿主机的一段普通内存。这意味着能碰到宿主机的人——云平台的运维、被攻陷的 Hypervisor、同宿主机上其他租户的提权攻击——都有可能读到 Guest 的内存内容，也可以改写 Guest 的页表，把某段内存映射到别处去做重放。机密计算补的就是"使用中数据"这一环，让这块内存对宿主机变成密文，并且让页表的改动能被硬件发现。

补上这一环的代价，集中在三笔账上：第一笔是性能，内存加解密本身就是开销，IO 路径上还要多一次 bounce buffer 拷贝，越靠内存和 IO 的业务越吃亏；第二笔是弹性，热迁移、挂起恢复、热插拔、快照这些能力在机密虚机上要么没有、要么受限，宿主机维护会从"无感知"变成"看得见的停机"；第三笔是运维复杂度，镜像不能带密钥、证明流程要接进启动链路、可观测性要从外部转到内部，每一条都要改流程。三笔账算完，再决定上不上，比看安全等级宣传靠谱得多。

SEV-SNP 与 TDX 各自加密到哪一层：内存、嵌套分页与信任根的差异

AMD SEV-SNP 和 Intel TDX 都属于虚拟机级 TEE，区别在于粒度：进程级 TEE（典型的如 Intel SGX 那种 enclave 模型）要求应用自己划分可信区、改写代码调用边界，而虚拟机级 TEE 把整个虚机搬进可信边界，应用不改一行代码。这也是为什么机密虚机在企业里落地更快——改造成本几乎全在平台侧和运维侧，不在业务代码里。

但"整个虚机加密"这句话太粗，落到工程上要拆开看。AMD 这条线是 SEV、SEV-ES、SEV-SNP 三代演进：SEV 用每个虚机独立的密钥加密内存，密钥由 CPU 内的安全处理器管理，Hypervisor 拿不到；SEV-ES 进一步把寄存器状态在 VM exit 时加密保存，堵住了"通过寄存器状态偷信息"的路子；SEV-SNP 再加一层安全嵌套分页，页表的完整性由硬件校验，宿主机对页表的重映射、篡改、内存重放都会被拦下来，同时引入反向映射表，保证一个物理页在同一时刻只能属于一个虚机。这个反向映射表是 SNP 的关键——它让"两个虚机共享同一页内存"这种传统优化失效，也直接影响了后面讲的迁移与内存共享能力。

Intel TDX 走的是另一条路：在 CPU 里引入一个 TDX 模块作为可信中间层，虚机的私有内存由支持多密钥的内存加密引擎加密，密钥由 TDX 模块管理；虚机进出时寄存器状态被保护，Hypervisor 只负责调度和资源分配，看不到私有内存的内容。远程证明走的是基于 SGX DCAP 体系的 quote 生成与验证路径。两者信任根不同——一个在 AMD 的安全处理器，一个在 Intel 的 TDX 模块与 CPU 认证密钥体系——但对外呈现的能力模型高度相似：内存加密、状态保护、可出具硬件签名的证明报告。

有一点是共通的，而且比性能数字更值得记住：Hypervisor 依然掌握调度权。它决定你的 vCPU 跑在哪、什么时候被抢占、IO 队列怎么处理。机密计算让它"读不到、改不了页表"，但没有让它"不能停机、不能降速、不能把你排队"。换句话说，机密虚机防的是窃听和篡改内容，不防拒绝服务。高可用设计不能因为上了 TEE 就放松，反而要更保守，因为平台侧的自动恢复手段变少了。

选型层面还有一个容易被忽略的差异：两者在 vCPU 规格、内存上限、可用实例族、以及是否支持某些加速特性上并不对齐。同一家云厂商的机密实例族往往限定在特定代次的 CPU 上，可选规格比通用实例族窄。采购前要确认的是"我需要的规格在这条机密实例线上有没有"，而不是"这家厂有没有机密计算"。

性能开销从哪来：内存加解密、IO 路径与 bounce buffer，为什么内存密集业务更吃亏

先说一个必须反复强调的前提：公开基准的差异相当大，只能作为量级参考，实际开销以自家业务实测为准。第三方汇总里常见的口径是，AMD SEV-SNP 在计算密集场景约 2%–5%、内存密集场景约 5%–10%；Intel TDX 在计算密集场景约 3%–8%、内存密集场景约 8%–15%。也有报告给出 TDX 约 4%、SEV-SNP 约 7% 的整体口径。这些数字之间并不矛盾，因为它们测的东西不一样——编译类负载、数据库类负载、网络转发类负载的结果能差好几倍，NUMA 拓扑、大页配置、IO 设备类型也会放大或缩小差距。谁要是拿单一数字当结论签合同，后面大概率要返工。

开销的构成可以拆成三块。第一块是内存加解密本身。加密引擎在内存控制器一侧，数据出缓存、进内存时加密，回来时解密，硬件流水线做这件事的吞吐很高，但延迟不是零，缓存行级别的加解密会反映在访存延迟上。对计算密集、数据能留在缓存里的负载，这部分几乎感知不到；对内存带宽打满、访存局部性差的负载，这部分会被放大。

第二块是控制平面开销。页表管理、嵌套分页的额外一层地址翻译、SNP 的反向映射校验、TDX 模块的介入，都让缺页处理、页表变更、VM exit 与 entry 的路径变长。最典型的放大场景是那些频繁触碰大量内存的负载：大内存数据库的 buffer pool 扫描、JVM 的大堆垃圾回收、大页表在多 NUMA 节点上的迁移。这类业务在机密虚机上的表现往往比"计算密集"差一截，原因就在这里。

第三块是 IO 路径，也是很多团队实际踩到的坑。机密虚机的内存对设备是密文，而传统 DMA 要求设备能直接读写内存，两边的语义是冲突的。工程上的解法是用 bounce buffer：在虚机可见的地址空间里划一段共享缓冲，数据进出设备时先在这段缓冲里做一次拷贝，再拷进加密内存。代价很清楚——多一次内存拷贝、多一次同步、CPU 占用上升、延迟上升、吞吐上限下降。网络大流量（10G 以上）、NVMe 高 IOPS、高 PPS 的小包转发，对这层拷贝最敏感。共享缓冲的大小也是个要调的参数，给小了会在高负载下耗尽导致 IO 报错，给大了又吃掉本可以给业务的内存。

正确的测法不是拿公开数字套自己的业务，而是起压：用真实流量或尽量接近真实流量的压测脚本，在同规格的普通虚机和机密虚机上各跑一遍，看 P99 和 P999 而不是平均值，盯四个指标——网络吞吐与小包转发能力、磁盘 IOPS 与写延迟、GC 或内存回收的停顿时间、以及业务尾延迟。压测要跑满你规划的单机容量，而不是跑个轻量基准就下结论。很多团队是在上线后晚高峰才发现 IO 路径撑不住的，那时候再退回普通虚机，迁移成本已经付过一次了。

真正的硬伤是弹性：热迁移、改规格、挂起恢复与快照的受限清单

性能那笔账好歹是"慢一点"，弹性这笔账是"做不到"。机密虚机的内存加密密钥与平台绑定，虚机状态的可信性建立在启动时的度量之上，这两件事和"把一台机器的内存搬到另一台机器上继续跑"、"随时给机器加两根内存"天然冲突。主流云厂商公开的机密虚机限制里，下面这些是高概率会遇到的：不支持或受限的热迁移，宿主机维护会带来可见停机，重启后需要重新完成证明；创建后 vCPU 数量通常固定，改规格要新建；不支持虚机内部重启与挂起恢复；不支持热插拔内存、网卡与磁盘；部分平台不提供 cloud-init，定制内容要打进镜像；启动盘快照能力可能不可用，镜像与构建流水线要在虚机外管理；存储只能扩容，文件系统要自己在虚机内扩。

逐条翻译成运维语言。热迁移没了，意味着宿主机固件升级、硬件预警、机架维护这些常规动作，对你来说都是一次计划内停机，而且不是秒级。硬件故障从"自动漂移到另一台宿主机"变成"重启或重建"，恢复时间从分钟级变成十分钟级甚至更长。改规格要新建，意味着容量规划必须前置，按峰值预留，不能再靠"先开小了不够再升"。挂起恢复不支持，意味着不能靠休眠做成本优化。快照不可用，意味着你失去了一个最常用的回退手段，发布和变更的风险敞口变大。

对应到平台层，容器集群的节点池、自动扩缩容、节点自动修复这些机制都要重新设计。节点不能热迁移，节点自动修复的策略就得改成"重建节点 + 重新调度 Pod"，而重建节点要重新走证明流程，时间不再是秒级。对有状态服务来说，副本数与 quorum 的设计要按"一次计划内维护会同时摘掉若干节点"来算，而不是按"节点随时被无感知漂移"来算。

这张表里最该被拿去开会的不是"哪些不支持"，而是最后一列。同一项能力，不同厂商、不同实例族的实现程度不一样，文档上写"受限"两个字，实际可能是"完全不可用"，也可能是"可用但要走工单"。采购阶段把这些逐条问成可验收的条款——停机提前多久通知、停机时长怎么算、重建期间数据怎么搬、备份谁负责——比事后在故障现场争论有用得多。

可观测性下降之后，故障怎么排：宿主机侧看不到内存意味着什么

机密虚机把内存对宿主机变成密文，这在安全上是收益，在运维上是明确的损失。以前排查一台 hang 住或者反复 OOM 的虚机，一条常见路径是让平台侧抓一次内存转储，或者从宿主机挂调试器进去看进程状态、看内核栈、看锁。这条路在机密虚机上被关掉了——不是"不推荐"，是"做不到也不该做"，因为能做就意味着加密没意义。

后果很具体。内存泄漏看不到现场，只能靠虚机内的指标曲线推断；死锁与内核 hang 没有宿主机侧的栈可查，只能靠虚机内的事先埋点；异常重启之后，如果虚机内没有把 core dump 落盘，现场就是永久丢失。更麻烦的是响应流程：很多团队的故障处置手册里写着"先让云厂商抓内存快照再决定要不要重启"，这套流程在机密虚机上行不通，重启之前拿不到外部证据，重启之后内部现场可能也丢了。

能做的准备要在上线前做完，而且是纯 guest 侧的：监控与日志采集 agent 跑在虚机内，指标、日志、链路追踪全部从内部上报到外部可观测平台；核心转储落到虚机内的持久化盘，并配置好自动上传，保证重启之后还能拿到现场；健康检查做两层，外部用网络层探活判断存活，内部用进程级探针判断可用，两者结论不一致时优先按内部状态处理；配置看门狗与自动重启策略，把"hang 住"的恢复时间压到可接受范围；保留带外控制台与串口日志，这是唯一不依赖虚机内部代理的取证通道，要确认供应商提供并且有权限用。

还有一条容易被忘的：eBPF 这类依赖内核可观测性的工具，在机密虚机里要在 guest 内核内跑，宿主机侧的采集一律无效。如果你们的安全审计、性能分析、入侵检测链路里有依赖宿主机侧采集的组件，这些组件会在机密虚机上静默失效——不是报错，是"看起来还在，其实没数据"。上线前把所有采集点盘一遍，比事后排查"为什么这段时间的监控是空的"省事。

远程证明与密钥释放：镜像不能带密钥，启动链路要重做

远程证明是机密虚机最核心、也最容易低估工作量的部分。流程本身不复杂：虚机启动时，硬件基于启动状态的度量值生成一份签名报告；证明方把报告交给依赖方验证，验证内容包括签名链是否可信、度量值是否等于预期、平台固件与安全版本号是否达到要求、安全策略配置是否正确；验证通过之后，才把密钥、证书、数据库连接串这类机密下发给虚机。验证不通过，就不下发，虚机等于起了一个没有凭证的空壳。

由此推出一条硬规则：镜像里不能预置明文密钥。传统做法里，把配置或密钥打进镜像、由 cloud-init 注入环境变量，是最省事的方案，但在机密虚机上这套逻辑直接和安全目标冲突——镜像一旦被复制或泄露，密钥就跟着走了，加密了内存也没用。正确做法是把密钥放在 KMS 或 HSM 里，虚机启动后先完成证明，凭证明结果去申请释放。这也意味着启动链路多了一个外部依赖：证明服务与密钥服务不可用时，虚机无法完成启动，批量扩容会全部卡住。

真正让团队吃苦头的是度量值的稳定性。度量值是对启动状态做哈希的结果，只要镜像内容、内核、启动参数、甚至某些固件状态变了，度量值就变。于是"打一次安全补丁"会导致"所有虚机的度量值变化"，如果验证策略里写死的是旧度量值，结果就是整机群启动失败。所以度量值不能手工维护，必须做成流水线：镜像可复现构建、构建产物签名、度量值自动计算并登记到白名单、白名单与证明服务联动更新、灰度批次验证通过后再全量。这套流水线本身就是个项目，工期和人力要算进预算。

平台侧还有一层：微码与固件补丁会改变平台的安全版本号与 TCB 版本。验证策略如果写死"等于某个版本"，平台升级后同样会全量失败；合理写法是"不低于已批准的最小安全版本号"，并保留一个可审计的批准清单。谁负责跟踪厂商公告、谁负责批准新版本、批准流程要走多久，这些都要在上线前定死，否则第一次平台固件升级就会变成一次生产事故。

还有一个现实问题：证明服务本身的位置与可用性。跨地域部署时，虚机在一个区域、证明服务在另一个区域，跨境链路的时延与合规边界都要考虑；离线或私有化部署场景下，证明服务要能在内网自建，证书链与吊销名单的分发也要有内部方案。灾备演练要覆盖"重建一个区域"的场景——不只是把虚机拉起来，而是重新走一遍证明与密钥释放，确认信任链能重建。

GPU 要不要一起纳入：数据出 CPU 边界的那一刻

这是 AI 与大模型场景下最尖锐的一个问题。CPU 侧的内存加密只覆盖 CPU 能直接寻址的内存，而数据一旦要通过 PCIe 送到 GPU，就离开了 CPU 的加密边界。GPU 有自己的显存、自己的固件、自己的驱动栈，如果这些不在可信边界内，那么"内存加密"只保护了数据到达 CPU 内存之后的状态，数据在 GPU 显存里、在 PCIe 链路上仍然是明文，也仍然可能被能够接触设备的人读到。只加密 CPU 内存，覆盖的是"别人 dump 我内存"这一类威胁，覆盖不了"数据经过的设备"这一类。

要把 GPU 纳入，前提是 GPU 本身支持机密计算模式。英伟达在 Hopper 架构上提供了 GPU 侧的机密计算能力，通过与 CPU 侧 TEE 配合、加密 PCIe 链路、保护显存，让数据从 CPU 加密内存到 GPU 显存的整条路径保持在可信边界内。工程上的约束也很直接：支持的卡型有限，驱动与固件版本有要求，可用机型与云上可选规格都比较窄，功能与性能上也可能有额外限制。采购前要确认的不是"有没有机密计算 GPU"，而是"我需要的卡型、驱动版本、实例规格在这个组合里是否都成立"。

评估的路径可以这样走，属于典型部署思路，并非特指某一真实客户：先明确要保护的资产到底是什么——是模型权重、是训练数据、是推理请求里的个人信息，还是三者都要。如果核心资产是模型权重，且推理请求本身敏感度不高，那么威胁模型的重点是"权重不被导出"，GPU 侧是否纳入取决于能不能接受权重在显存中明文驻留；如果推理请求里带个人信息，那么数据必然要进 GPU，CPU 侧加密的意义就被大幅稀释，GPU 必须一起纳入，否则整条链路的可信性在 PCIe 那一跳就断了。

退一步说，如果 GPU 侧暂时不具备条件，也不是完全没得做：把敏感数据最小化（只传必要的张量、请求侧做脱敏与匿名化）、把密钥与权重的使用限制在 CPU 侧完成、用物理隔离与访问控制代替技术隔离、并在安全评审里把这些补偿措施和残余风险写清楚，让决策建立在明确的残余风险之上，而不是建立在"我们上了机密计算"这句话之上。

顺带说一句算力侧的现实：无论走哪条路，GPU 物理机与裸金属都是这类项目最容易落地的载体，因为物理边界的隔离不依赖机密虚机的那些限制条件。一万网络官网明示的锚点价里，Tesla T4 ¥900/月、RTX 3090 24G ¥1750/月、A100 40G ¥2800/月是常见的起步档（均以官网实时价为准），更高规格的整机与集群方案需实时询价。把"要不要 GPU 侧机密计算"和"算力怎么配"这两件事分开决策，通常比绑在一起更省时间。

一万网络在这类需求里能接住哪一段

把前面几节的问题摊开看，会发现相当一部分团队其实并不真的需要机密虚机——他们需要的是"能向评审和审计交代的隔离边界"，而机密虚机只是达成这个目标的手段之一，而且是最贵、限制最多的那一种。物理隔离、独占裸金属、独立 VPC 与访问控制、密钥与数据分离管理，在很多场景里已经能把威胁模型交代清楚，代价却小得多。

一万网络深耕 19 年（成立于 2007 年），遇到这类合规驱动的需求，通常会先把物理机与裸金属的可用性讲清楚：有些场景与其上机密虚机去换一个受限的弹性能力，不如把隔离做在物理边界上——具体方案与价格以官网实时信息为准。

物理机与裸金属这条路的好处是，你不需要改镜像流水线，不需要接证明服务，不需要放弃热插拔和快照，宿主机侧排障能力也保留着，运维还是原来那套。一万网络在裸金属方向上有明示档位，E5-2698v4×2 这档 ¥3999 起（以官网实时价为准），弹性云侧一万云 ¥25 起（以官网实时价为准），可以作为非敏感计算部分与敏感部分分离的载体。

能明确写进方案的服务承诺只有官网明示的这些：7×24 中文工单、平均 5 分钟响应，硬件故障 10 分钟内自动迁移，免费提供系统盘每日 3 份快照、30 秒回滚，免费协助网站备案，5–20G 免费流量防护，自营机柜最快 1 分钟上架，工程师 1 对 1 部署 CUDA/cuDNN/TensorRT/PyTorch/TensorFlow，开机即用。涉及等保、行业合规这类要求时，一万网络能提供的是合规架构建议与协助对接，不替代客户自身的合规申报与测评结论——这句话采购时说清楚，比事后扯皮强。

真正需要机密虚机的场景，一万网络的价值在于把边界划清楚：哪部分业务必须进 TEE，哪部分放在物理隔离里就够，两者之间的数据怎么走、密钥怎么管、灾备怎么演练。这种"先做减法再做加法"的思路，比整站搬进机密虚机省钱，也比整站搬进去之后的运维负担轻。具体能不能做、做到哪一层、价格多少，一律需实时询价，以签约时最新报价与合同为准。

关于机密虚拟机的常见疑问

Q1：机密虚机到底能不能热迁移？宿主机要维护时怎么处理？

A1：多数平台对机密虚机的热迁移是不支持或严格受限的，因为内存密钥与平台绑定、虚机状态的可信性建立在启动度量之上，迁移会破坏这条链。实际处理方式是停机重启或重建，重建后要重新完成远程证明。采购时要问的不是"能不能迁移"，而是"维护窗口提前多久通知、停机时长按什么口径算、有没有可预约的低峰窗口"，把这些写进 SLA 条款。高可用设计要按"一次维护会同时摘掉若干节点"来做，而不是按"节点随时无感知漂移"来做。

Q2：机器挂了怎么恢复，能不能像普通虚机那样从快照拉起来？

A2：这是最容易踩的一点。机密虚机的启动盘快照能力在很多平台是不可用的，镜像与构建流水线要在虚机外管理，也就是说"回滚到昨天的快照"这条路可能根本不存在。可行的替代方案是：镜像与配置全部版本化放在流水线里，虚机本身做成无状态的，数据放在外部存储或数据库里，故障后重建虚机并重新挂载数据。恢复时间取决于重建加证明的总时长，要提前实测一次，不要等真出事才知道要多久。

Q3：镜像怎么做进流水线？改一次配置是不是度量值就要重算？

A3：是的。度量值是对启动状态的哈希，镜像内容、内核、启动参数任一变化都会让它改变，验证策略里写死旧值会导致整机群启动失败。所以镜像必须走可复现构建，构建产物签名，度量值由流水线自动计算并登记到白名单，白名单与证明服务联动更新，灰度验证通过后再全量。平台固件与微码升级也会改变安全版本号，验证策略建议写成"不低于已批准的最小安全版本号"，而不是写死某个版本。

Q4：远程证明失败会怎样，业务是直接起不来吗？

A4：取决于你怎么设计。默认语义是证明不通过就不释放密钥，虚机起来了但拿不到凭证，业务无法对外提供服务。有两种失败要分开处理：一种是"度量值变了"这类预期内的变更失败，应该由流水线在灰度阶段拦住；另一种是"证明服务不可用"这类基础设施故障，要有明确的降级策略——是允许使用本地缓存的短期凭证启动，还是宁可不启动。后者必须由业务方拍板，因为它是安全与可用性之间的直接取舍，而且要把证明服务当作关键依赖做冗余与监控。

Q5：GPU 要不要一起加密？只做 CPU 内存加密算不算过关？

A5：算不算过关取决于你向评审承诺的威胁模型覆盖到哪里。数据走 PCIe 到 GPU 的那一刻就离开了 CPU 的加密边界，如果 GPU 显存与链路不在可信边界内，那么训练数据、模型权重或推理请求在 GPU 侧仍是明文。要覆盖这一跳，需要 GPU 本身支持机密计算模式（例如 Hopper 架构上提供的 GPU 机密计算能力），同时驱动、固件、实例规格都要匹配。如果暂时不具备条件，就把残余风险写成书面说明，用最小化数据、脱敏、物理隔离与访问控制做补偿，让决策建立在明确的残余风险上。

Q6：能不能先小规模上一批试，不合适再退回普通虚机？

A6：可以，但要把试错成本算清楚。退回的成本不在虚机本身，而在你已经改造的部分：镜像流水线、证明与密钥下发链路、监控与排障方式、发布流程、以及为绕开热迁移和快照限制而重做的高可用设计。建议的试法是先挑一个无状态、容量固定、业务 peak 可预测的服务做试点，跑满一个完整的变更周期（至少经历一次补丁升级和一次平台维护），把"打补丁后度量值变化""维护停机时长""故障重建耗时"这三件事实测出来，再决定要不要扩大范围。

Q7：现有的监控、日志和安全审计工具还能用吗？

A7：跑在虚机内部的部分基本都能用，依赖宿主机侧采集的部分会失效——内存转储、外部调试、宿主机侧的内存取证、宿主机侧 eBPF 采集，这些要么不可用，要么采集到的是密文。上线前要把所有采集点盘一遍，确认哪些会静默失效。需要补的是虚机内的指标与日志上报、core dump 落盘与自动上传、双层健康检查、看门狗与自动重启策略，以及带外控制台与串口日志这条不依赖虚机内部代理的取证通道。

Q8：机密实例的溢价大概是什么量级？

A8：公开资料给出的口径差异很大，有"基础设施成本增加 15%–50%"的说法，也有"云上机密实例相对同规格溢价 20%–30%"的说法，这些都是公开资料中的市场参考区间，非一万网络报价。真正该算的不是实例单价的溢价，而是总账：性能下降带来的额外容量、失去热迁移后要多预留的冗余副本、镜像与证明流水线的建设人力、排障效率下降带来的人力成本。把这几项加进去之后的总成本，往往比单价溢价高出一截。一万网络这边的相关配置与价格一律需实时询价，以官网实时信息为准。

有立场的结论：什么样的业务值得上，什么情况下先别上

值得上的，是这几类：核心资产是密钥、模型权重或高敏感数据，且需要向外部（客户、监管、合作方）证明"平台方也读不到"的；多方协作场景，各方都不愿意把明文交给任何一方的平台；规格稳定、容量可预测、无状态或状态外置的服务，因为这类业务不在乎热迁移和热扩容。这三类业务的共同点是：弹性要求低、隔离收益高、能接受流程改造。

建议先别上的，也是三类：弹性要求高的——需要频繁扩缩容、依赖自动修复与热迁移的在线业务，上了等于自断一臂；重度 IO 且对尾延迟敏感的——网络转发、高 IOPS 存储、大内存数据库，bounce buffer 那一层拷贝会直接反映在 SLA 上；排障强依赖外部内存取证的，或者镜像流水线还不成熟的团队，改造工作量会远超预期。

还有一类要特别提醒：如果上机密虚机的唯一理由是"评审提了一句"，而没人能说清威胁模型覆盖到哪里，那先别上。把威胁模型写成一页纸——谁能碰到我的数据、我要防的是谁、机密计算能覆盖哪几跳、覆盖不了的用什么补偿——这一页纸比任何安全等级宣传都更能决定这笔钱该不该花。写完之后如果发现要防的主要是外部入侵和权限滥用，那么访问控制、密钥管理、审计、物理隔离这些基础工作的性价比，通常比机密虚机高得多。

关于机密虚拟机的限制，上机前最该问清楚的几件事

把下面这份清单直接拿去和供应商对，逐条要书面答复。热迁移与平台维护：是否支持、维护提前多久通知、停机时长按什么口径算。规格与扩容：vCPU 与内存创建后能否变更，变更是否需重建，重建期间数据怎么搬，是否支持热插拔。快照与备份：启动盘快照是否可用，数据盘快照是否可用，备份由谁负责，恢复时长实测是多少。可观测性：是否提供带外控制台与串口日志，内存转储与外部调试是否可用，有哪些替代的取证手段。证明与密钥：证明服务由谁提供、部署在哪里、是否支持内网自建，密钥释放失败时的降级策略是什么，平台固件升级后安全版本号变化怎么处理，度量值白名单的更新由谁负责。GPU：需要的卡型是否支持机密计算模式，驱动与固件版本要求，可用实例规格有哪些。采购与验收：溢价部分怎么计价，SLA 里对停机与恢复时长怎么约定，这些都需实时询价，具体以签约时最新报价与合同为准。

本文信息来源与价格说明（机密虚拟机篇）

本文关于机密虚拟机的性能开销与功能限制，来自公开的技术文档、主流云厂商公开的机密计算实例文档与第三方公开汇总，公开基准差异较大，只能作为量级参考，实际需以自家业务实测为准；文中不做任何实测跑分引用，也不涉及具体客户案例。文中提到的溢价区间（如基础设施成本增加 15%–50%、云上机密实例相对同规格溢价 20%–30% 等不同口径）为公开资料中的市场参考区间，非一万网络报价。Tesla T4 ¥900/月、RTX 3090 24G ¥1750/月、A100 40G ¥2800/月、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起为一万网络官网明示锚点价，以官网实时价为准；其余配置与方案一律需实时询价，具体以签约时最新报价与合同为准。

本文涉及的服务能力描述，仅限一万网络官网或公开文档明示提供的项目；涉及等保与行业合规要求时，一万网络可提供合规架构建议与协助对接，不替代客户自身的合规申报与测评结论。更多机型、节点与方案信息见 一万网络官网。