一台机器能开多少个安卓实例：云手机多开的密度卡在哪一层

一台 64 核 256G 的物理机，装好安卓容器之后开到第 20 个实例，画面就开始糊、点击延迟明显变长，偶尔还有实例直接被杀掉重启。登上去看监控，CPU 总利用率只有 40% 出头，负载也不算高，硬盘还剩大半个 T。这时候几乎所有人的第一反应都是"核够了，是不是内存给少了"，于是把每实例内存从 2G 加到 4G，结果开到 14 个就满了，密度反而更低。

这个现象在云手机、容器化安卓实例这类场景里非常普遍，而且它指向一个反直觉的结论：单机密度从来不是"总核数除以每实例核数"算出来的，它是被最短的那块板决定的，而那块板通常不是 CPU。把预算全砸在核数上，多半会得到一个"核很多、实例很少、钱花了没效果"的配置。下面是这篇文章的核心判断，先列出来：

① 一个安卓实例至少背着五份开销：用户态进程与虚拟机运行时、图形栈与帧缓冲、音视频编码解码、系统镜像的随机读、以及实例私有的应用数据读写。核数只是其中最表面的一份。

② 内存是最常见的一号瓶颈，单实例常驻量的公开经验区间大致在 2G 上下到 4G 以上，随安卓版本、目标应用、是否跑图形栈而大幅变化，必须用自己那套镜像实测，不能照抄别人的数。

③ 帧缓冲与编码会话是两条隐形闸门。软件渲染时 CPU 吃掉大头；换 GPU 之后压力转移到并发编码会话数上，部分消费级显卡驱动对同时进行的编码会话数存在限制，数据中心级/专业级通常不做此限制（以厂商最新说明为准）。GPU 不是万能钥匙，它只是把"能不能开这么多"往后推一档。

④ 磁盘上能省的和不能省的是分开的：系统镜像可以被内核 page cache 共享，十个实例读同一份镜像基本只付一份代价；但每个实例的应用数据、缓存、数据库各写各的，随机读写压力随实例数线性叠加，这部分一分都省不掉。

⑤ 还有一个密度之外的上限——出口 IP 与带宽。三十个实例共用同一个公网出口，在很多跨境业务里意味着账号在平台侧看起来是同一台设备同一条线路，这个坑跟性能无关，但会直接决定你这台机器到底敢开多少个实例。

CPU 还剩一半却开不进去：先把"实例"拆开看它由什么组成

要算密度，先得说清楚"一个安卓实例"到底是个什么东西。市面上常见的云手机/安卓容器方案，基本都是跑在 Linux 宿主上的容器化隔离：借助内核的命名空间与控制组能力，把进程、网络、挂载点、用户等资源视图隔离开来，内核本身是共享的，每个实例有自己的一套 Android 用户态进程树和私有数据目录。它跟虚拟机最大的区别就在这里——没有独立内核，没有虚拟 BIOS，启动快、内存开销小，代价是隔离强度依赖内核实现，一个实例把内核踩出问题，同机其他实例跟着遭殃。

拆开看，一个实例稳定跑着的时候，背的是下面五份开销：

用户态运行时的常驻成本。Android 的应用运行时（ART 也好，早期的 Dalvik 也好）每个进程都要占一份堆、一份 JIT/预编译代码缓存、一堆线程池和 binder 通信缓冲。系统服务进程、应用进程、守护进程加起来，典型的空载实例就有几十个进程在跑。这部分的特点是"不干活也占着"，跟你在屏幕上点不点没关系。

CPU 突发的成本。安卓界面动画、应用冷启动、ART 的即时编译、GC 回收，这些都不是持续负载，而是短时间把某几个核打满。密度估算最容易被骗的地方就在这：均值看起来很低，但突发会叠加。二十个实例同时冷启动同一个应用，CPU 可能瞬间从 40% 顶到 100%，这段时间的表现就是"卡"，而监控图上取的是五分钟均值，压根看不出来。

图形栈与帧缓冲的成本。没有 GPU 的时候，图形命令要靠 CPU 软件渲染后端（SwiftShader 这一类）转成像素，这一步非常吃 CPU；有 GPU 的时候，每个实例要在显存里给帧缓冲留位置。帧缓冲的大小可以直接算：分辨率乘以每像素字节数。720p 的 RGBA 缓冲大概是 1280×720×4 字节，一帧 3.5MB 左右；1080p 就是 1920×1080×4，一帧 8MB 上下。再乘以双缓冲或三缓冲，再乘以合成器还要的一份副本，单个实例的图形内存占用就以几十 MB 起跳了。

编解码会话的成本。云手机之所以叫"云手机"，是因为画面要通过网络传回来，那么视频编码就是每个在线实例躲不掉的一份固定开销。编码要么走 CPU（非常贵），要么走 GPU 上的专用编码引擎（便宜，但并发会话数有上限）。

磁盘 IO 的成本。系统镜像的读、应用的读写、SQLite 数据库的落盘、日志与崩溃堆栈，全部落在宿主机的存储栈上。这部分在后面讲磁盘那一章单独展开，因为它决定了磁盘该选什么、怎么分层。

把五份加起来你会发现，核数只直接参与了第二份和第三份的一部分。拿核数去除 2 或者 4，得到的数字在系统空载时看着很美，一旦真正跑起来，剩下的四份会一起把你拉回现实。

内存这一关：单实例常驻、zRAM 与交换的代价

内存是绝大多数人第一次卡住的位置，因为它最容易量、也最容易改。先把结论放出来：内存估算不能只看"跑起来要多少"，要按"峰值 + 余量"来算，并且要预留宿主机自己、容器管理面、缓存三块的开销。

单实例到底要吃多少：先看版本，再看应用，最后才能谈数字

安卓版本是第一个分水岭。较新的安卓大版本对用户态内存的要求明显高于老版本，同样的空镜像，跑 10、11 和跑 13、14，空载常驻量能差出明显一截——具体差多少要自己压测，不同容器方案对框架的裁剪程度也不一样。第二个分水岭是目标应用：一个只用来挂着定时器同步数据的轻量工具类应用，和一个内置 Chromium 内核、自带 WebView 与广告 SDK 的内容类应用，进程内存画像完全不是一回事。第三个分水岭是是否启用图形栈、屏幕密度设为多少、有没有开着常驻的前台服务。

公开经验里，单实例内存常见落点在 2G 上下到 4G 以上，这是一个很宽的区间，宽到几乎没有直接参考价值。合理做法是：拿你自己的镜像，在目标安卓版本上跑你真正要跑的应用，跑满业务典型动作之后，读容器内存控制组的峰值，再加两成到三成余量。别人的 2G 是别人的，你的 2G 只能自己压出来。

zRAM 不是免费内存，它是拿 CPU 换空间

内存不够的第一反应是上 zRAM——在内存里划一块区域做压缩交换，"看起来"多了一半可用内存。这个思路没错，但代价要说清楚：压缩和解压都吃 CPU，而且随着压缩比上升，碎片整理和查找的开销也会上升。你每救回来 1G 内存，就是往已经可能被图形栈压着的 CPU 上再加一份负载。

怎么判断自己是不是已经在依赖 zRAM 了？看压实的比例和 CPU 的 iowait/系统态占比有没有同步抬头。如果 zRAM 里已经放了几 G，同时 CPU 系统态占用明显上升，那说明你其实不是在"扩容"，而是在用 CPU 换内存，密度收益会很快被吃掉。

怎么开才合理？经验上没有统一答案，主流发行版常见的默认做法是取物理内存的一小部分（例如四分之一上下）作为压缩池，这在云手机这种"进程多、匿名页多、冷数据多"的场景下通常偏保守，可以适当上调，但每次上调都应该重新压一遍密度，别凭感觉改。判断标准很简单：加了 zRAM 之后，单核能撑的实例数是变多还是变少？变少就说明买亏了。

交换到 NVMe：比不交换好，比加内存差

再往后一步就是把匿名页换到磁盘。NVMe 固态做交换设备比机械盘好太多，但安卓实例里有大量"不活跃但随时会被唤醒"的进程和映射页，一旦被换出去，用户点击一下就是一次随机读回，延迟直接体现在操作体感上。对交互型场景（真人远程操作、脚本在界面上点击），落到磁盘交换基本等于体验降级。

所以这里的取舍很清楚：交互型业务宁可减少实例数，也不要让实例长期泡在磁盘交换里；纯后台挂机型业务对延迟不敏感，可以用少量交换盘做兜底防 OOM，但不能指望它提密度。真要靠这条路提升密度，答案是加物理内存——这也是为什么第 6 章那张总账表里，内存那一行的优先级排在最前面。

图形栈与帧缓冲：软件渲染和硬编各自吃掉什么

图形这一层，是常被人误判为"加张卡就能解决"的部分。先把两种路径的成本摊开。

软件渲染路径：容器里没有可用的 GPU 设备时，OpenGL/Vulkan 的调用会落到 CPU 渲染后端（比如 SwiftShader 这一类）上去执行。它的好处是绝对兼容、不需要直通、不需要驱动，任何机器都能跑；代价是把本来应该由 GPU 干的活——顶点处理、光栅化、纹理采样、像素合成——全部搬到通用 CPU 上。这不是"慢一点"的问题，而是同一个界面动画在多实例并发时，CPU 占用会成倍抬升，直接把第一章说的那个"CPU 还有一半空闲"的局面翻转过来。软件渲染的机器，密度几乎完全由 CPU 核数与主频决定，GPU 相关的话题在这条路上不成立。

硬件渲染路径：给容器暴露 GPU 设备（直通或者虚拟化的方式），图形命令由 GPU 处理，帧缓冲落在显存里。这时候 CPU 松了一大口气，压力转移到两处：显存容量和并发编码会话数。显存这一项可以直接按帧缓冲算账，前面已经给过公式——分辨率乘以 4 字节乘以缓冲数量，再加上合成器和应用层自己的纹理缓存。按这个口径，一块 16G 显存的卡，理论上看着能放下几十份 720p 的帧缓冲，但显存从来不是先耗尽的那一块。

真正先到的是第三样东西：并发编码会话。这一点下一章单讲。

这里还有个不太起眼但很实在的问题：分辨率设定本身就是密度杠杆。把实例的虚拟屏幕从 1080p 降到 720p，帧缓冲、编码器输入、网络码率三条线同时下降，通常能换来可观的密度提升，代价是清晰度。对兼容性测试、批量挂机、自动化脚本这类场景，720p 或者更低往往完全够用，没必要按旗舰手机的分辨率去配置。反过来，做应用兼容性测试要给客户看 UI 细节，或者要做真机录屏交付的，就得接受密度下降。这是业务取舍，不是技术参数，别让"看起来更高清"悄悄吃掉三成实例。

并发编码会话数才是 GPU 那道隐形闸门

每一个在线的安卓实例，理论上都在做同一件事：把屏幕内容压成视频流，通过网络送到用户端。这个编码动作可以走 CPU（x264 一类的软编码器），也可以走 GPU 上的专用硬件编码单元（NVENC 这类）。前者 CPU 成本很高，在多实例下几乎不可行；后者便宜得多，是绝大多数云手机方案的默认选择。

问题在于：硬件编码引擎能同时处理多少路会话，是有上限的。业内比较常见的说法是，部分消费级显卡驱动层对并发编码会话数存在限制，达到上限之后新的会话会失败、降级到软编，或者直接报错；而数据中心级/专业级的同类产品通常不施加这种驱动层面的会话数限制。这个差别对密度的影响是决定性的——一张卡核数、显存、编解码单元看着都够，但会话数被卡住，密度就停在那里，再买第二张同样的卡也只是在另一组会话上重复同样的上限。

必须强调：具体是多少路、哪些型号受限、哪些固件版本之后放开，一律以厂商最新官方说明为准，不同驱动版本和不同厂商政策都可能变化，网上流传的具体数字往往过时。规划时正确的做法是：先确定候选型号，去查厂商当前文档里的会话数说明，再按最坏情况做冗余。

除了会话数，还有三个跟 GPU 相关的参数要在选型时一起看：一是单卡能同时支撑的编码分辨率与帧率组合，高分辨率高帧率的会话会折算成更多资源消耗；二是显存总量，前面说的帧缓冲账要在这里结；三是虚拟化方式，如果方案要求把 GPU 切成多份给多个容器（比如 SR-IOV 一类的虚拟功能），切分粒度和份数上限本身就是密度的硬约束。

所以 GPU 在这个场景里的角色要摆正：它不是让你"能开更多实例"的开关，而是把瓶颈从 CPU 挪走之后，用一组新的、更贵但不那么容易撞到的限制替换掉原来的限制。预算有限时，先算出目标密度需要的编码会话数，再倒推是上一张数据中心级卡、还是多张消费级卡分摊，后者往往会因为单卡会话上限而变成"买了卡却开不满"的尴尬局面。

磁盘这一关：系统镜像能共享，实例数据不能共享

磁盘是最容易"看着够用、跑起来崩"的一层，因为它有两个方向完全相反的特性混在一起。

能共享的那部分：系统镜像。多个实例来自同一个基础镜像时，它们读的是同一批文件。宿主内核会缓存文件页，第一批读进内存之后，后续实例的读多数能命中缓存，不需要再打到底层磁盘。这意味着镜像体积本身不是问题——哪怕镜像有好几个 G，三十个实例同时启动，真正落到磁盘上的读量远小于体积乘以实例数。这也是为什么"开机风暴"通常没有想象中那么可怕，前提是第一次读的性能撑得住，并且缓存不被挤掉。

不能共享的那部分：实例私有数据。每个实例有自己的应用数据目录、自己的缓存、自己的 SQLite 数据库、自己的偏好设置和本地下载。这部分读写一定是各写各的，实例数翻倍，IOPS 压力就翻倍，没有折扣。更要命的是，这类负载以小块随机读写为主，而随机读写恰恰是最依赖设备本身 4K 性能与队列深度的地方。三十个实例各自在前台疯狂写数据库日志，磁盘再大也没用，掉的是 IOPS 和延迟。

由此能推出几条很实在的做法：

把可写的私有层放在最能打随机写的设备上。企业级 NVMe 固态是这里的默认答案，SATA 固态勉强能用，机械盘基本别考虑——不是容量不够，是随机 IOPS 撑不住。容量反而通常在几十 G 到一百多 G 每实例这个量级就能覆盖多数场景，真正要紧的是稳态下的写延迟和写放大。

系统镜像与实例数据分层。只读的镜像层放便宜的大容量介质，可写的私有层放高性能介质，既省钱又不牺牲 IOPS。这也是容器化方案天然友好的地方——镜像层和可写层本来就是分开管理的。

注意写放大的放大效应。镜像更新看起来是"只写一份"，但如果方案给每个实例都保留了一份完整的可写副本，一次升级就是 n 份写。用支持写时复制的文件系统或者分层镜像，可以让升级只写差量，这里面省下来的写入量在三十个实例以上规模时非常可观。

给宿主机留 IO 余量。日志采集、监控打点、快照备份、容器自身的元数据更新，都在跟实例抢同一条通道。规划时按"实例 IO 需求加三成"留兜底余量，至于具体取多少，用实际业务的典型负载压一次最准。

单实例资源与 30 实例总账对照

前面几层拆完，可以落成一张可以直接用的账表了。下面这张表按"单实例经验占用 → 30 实例总账 → 先撞上限的表现 → 怎么缓解"的顺序排列，所有数字都是公开经验区间或者需要实测确认的量级参考，不是跑分，不能当成采购依据，它的价值在于告诉你各项的优先级顺序，以及在目标密度下该先去哪一项。

这张表读下来，优先级其实非常清楚：内存在最前面，接着是图形与编码，然后是磁盘，最后才是那个看起来最像答案的 CPU。如果容积不够，加内存带来的密度提升，通常比再加一颗 CPU 更直接也更便宜。

落到采购层面时，可以拿公开明示的配置档做横向比选。以一万网络官网明示的几档为例（均以官网实时价为准）：T4 ¥900/月适合先小规模试跑、验证单机的实际编码与密度表现；RTX3090 24G ¥1750/月在需要更多编码资源时是个跳得动的档位，A100 40G ¥2800/月则面向对并发会话与显存都更苛刻的场景；如果你的密度测算结论是"瓶颈全落在内存和磁盘上，跟显卡没关系"，那么裸金属 E5-2698v4×2 ¥3999 起这类大内存物理机反而更划算——它把钱花在了先耗尽的那一层上。需要说明的是，一万网络提供的是服务器与 GPU 资源，本文讨论的安卓容器软件需要由用户自行部署，选型时把它当成一个"同样预算下哪种资源组合更贴近我的瓶颈"的比选对象即可。

出口 IP 与带宽：密度之外的第二道上限

性能账算完之后，还有一道跟性能完全无关、却经常决定最终实例数的上限：网络出口。

带宽这一侧比较容易算。每个在线实例的画面要靠视频流回传，码率取决于分辨率、帧率、画面复杂度，通常每实例在数 Mbps 量级；一批三十个实例全部活跃时，下行带宽需求会叠到百 Mbps 甚至更高。这份账要在选机型的时候跟磁盘 IO 一起看——很多高性价比的物理机默认给的带宽并不宽裕，谈预算时把公网带宽也算进去，别等到密度上来了才发现网卡先饱和。优化手段也有：给静态画面自动降帧、限制单实例码率上限、把实例之间的数据同步放到内网口而不是公网。

出口 IP这一侧更麻烦。多实例共用同一个公网出口地址时，目标平台上看到的所有请求都来自同一个 IP。对跨境电商店铺运营、社媒多账号、试玩分发这类业务，这往往意味着账号在平台侧呈现出高度的来源相似性，被判定关联的风险显著上升。这类业务通常需要给每个实例（或每个账号组）配独立的代理出口，地址和轮换策略的成本要单独列一笔。这里必须说清楚：业务运营需遵守目标平台的用户协议与所在司法辖区的相关规则，本文不讨论任何规避平台规则的做法，配独立出口只是为了让每个账号的身份归属清晰、可管理、可审计，属于合规运营的基础设施范畴。

于是出现一个很容易被忽略的连锁反应：IP 的数量会反过来打利用率。如果你为了让成本好看买了足够多的 IP，但机器只能撑二十个实例，那多出来的 IP 就闲置了；反过来，机器能撑五十个但只配了二十个出口，多开的那三十个实例等于白付电费。密度规划和 IP 规划必须一起做，这一点在第 11 章展开。

密度估算的四步算法与必须实测的三个参数

把上面的分析收敛成一个能用的算法，是四步。

第一步：压准单实例峰值。只开一个实例，跑完整的业务动作序列——冷启动目标应用、保持前台、跑一遍典型交互、切后台再切回来——读内存控制组峰值、读 CPU 占用曲线、读这期间的磁盘写量与网络下行量。峰值而不是稳态值，才是密度计算要用的数。这一步得到的是"一个实例要多少"，后面所有乘法都基于它。

第二步：确定共享与独占的分界。明确哪些是可以被 page cache 共享的（系统镜像、只读资源包），哪些是每实例独占的（应用数据、缓存、数据库、私有写入）。磁盘那一栏只按独占部分乘以实例数，共享部分只算一次预热成本。这一步做错的话，磁盘预算会虚高一截。

第三步：把宿主机自己扣掉。容器管理面、宿主操作系统、日志与监控、zRAM 可能带来的压缩开销、以及保留一部分空闲页的余量——这些要先从总资源里减掉，剩下的才是能分给实例的池子。很多人算密度时忘了这一步，导致理论密度比实际能跑的高出一成。

第四步：逐项取最小值。用池子除以单实例占用，得到五个候选密度：内存密度、CPU 密度（含突发系数）、图形密度、编码会话密度、IOPS 密度。最终密度等于这五个数里最小的那个，再乘一个 0.7 到 0.85 的实操折减系数，用来吸收突发叠加、垃圾回收抖动、以及你在第一步没测到的边缘场景。别舍不得这个折减——实测里让人翻车的从来不是均值，是峰值叠加。

这个算法里有三个参数必须自己测，抄别人的一定会出问题：

参数一：单实例内存峰值。它随安卓版本、容器方案、目标应用三重变化，区间的宽度大到没有迁移价值。

参数二：目标 GPU 的并发编码会话上限。以厂商当前官方说明为准，不要采用社区流传的过时数字；如果候选型号在厂商文档里查不到明确说法，就要求服务商提供同型号的实际会话验证。

参数三：稳态随机写 IOPS。跑满业务十分钟以上，取稳态而不是开头的爆发值，看写延迟是否随实例数非线性上升——一旦开始非线性上升，说明已经撞到设备的队列深度或者写放大瓶颈了。

多开密度测算里最容易估错的五个参数

坑一：按核数除以 2 算密度，结果一半预算白花

为什么坑：核数是最显眼的参数，也是最不常用到耗尽的那一项。内存、帧缓冲、编码会话通常先到上限，多买的核一直在睡觉。
怎么判断：满载压测时如果 CPU 均值在五成以下而实例已经起不来或被杀，说明瓶颈不在 CPU，核数配置偏大。
怎么避：按第 8 章的四步算密度，找到最小的那个约束项，把预算挪过去。同样预算下，加内存或换数据中心级卡的密度收益通常比加核更明显。

坑二：以为加了 GPU 就一定能多开

为什么坑：GPU 把 CPU 从渲染里解放出来，但引入了并发编码会话、显存总量、虚拟化切分份数三个新上限，其中任何一个都可能比原来的 CPU 上限更早到。
怎么判断：观察到实例数停在某个整数不再增长、新实例起不来但监控上显存和 CPU 都很空，八成是会话数撞墙。
怎么避：选型前查厂商当前文档确认会话数政策；会话数按最坏情况留冗余；确认虚拟化方式允许的切分份数能满足目标密度。

坑三：把几十个实例塞进同一条公网出口

为什么坑：多实例共用出口会让目标平台看到的来源高度一致，跨境电商与社媒类业务的账号关联风险因此显著上升，单机密度算得再高也没意义。
怎么判断：在目标平台侧检查账号登录地、设备指纹相关信息是否已经出现重合迹象；需要合规运营，不讨论任何规避平台规则的做法。
怎么避：按账号组规划独立出口或独立代理，把 IP 数量与轮换策略作为独立预算项，与机器密度一起规划。

坑四：zRAM 开得越大越好

为什么坑：压缩和解压都要 CPU，过量使用会把瓶颈从内存挪到 CPU，而且 CPU 是跟图形栈、编码争抢的同一份资源。
怎么判断：zRAM 占用持续上涨、CPU 系统态占比同步抬头、单核支撑实例数反而下降，就说明开过头了。
怎么避：每次调整都重新压密度，只有一个标准——单核能撑的实例数是变多还是变少。交互型业务优先加物理内存而不是靠压缩。

坑五：只看首次开机，不看运行三天之后

为什么坑：容器刚起时各项都干净，缓存还没堆积、数据库还没膨胀、日志还没滚起来；跑几天之后内存占用、磁盘占用、IOPS 都会明显漂移，原本稳稳的密度开始翻车。
怎么判断：对比第 1 小时和第 72 小时的单实例内存与磁盘用量，差值大的就是不稳定的地方。
怎么避：预算时按"稳定期峰值"而不是"开机峰值"计算；给日志与缓存配清理策略；留出足够余量让实例能扛几天不重启。

关于安卓实例密度的几个高频问题

一个安卓实例到底该给几 G 内存？

公开经验里常见落点在 2G 上下到 4G 以上，但这个区间宽到几乎没有直接引用价值。它至少被三个变量同时影响：安卓大版本、目标应用的复杂度、是否启用了完整图形栈。较新的安卓版本对用户态内存要求明显高于老版本；自带 WebView 和广告 SDK 的应用比纯工具类应用重得多。正确的做法是先定你的镜像和版本，跑真实业务动作，读容器内存控制组的峰值，再加两到三成余量。这里给的是公开经验区间，实际数值请用你自己的镜像实测确认。

一定要上 GPU 吗？软件渲染能撑多少实例？

取决于你的业务是否需要流畅画面。软件渲染路径下，顶点处理、光栅化、纹理采样全部落到通用 CPU 上，多实例并发时 CPU 占用会成倍抬升，密度基本由核数和主频决定，跟实例数量接近成反比。如果你的场景是纯后台挂机、无界面脚本执行、批量数据同步，软渲染完全可以胜任，省下来的钱加内存更划算。如果业务是真人远程操作、需要展示界面、需要录屏交付，那就得走 GPU。判断方法很简单：把 CPU 压到七成，看单核能撑几个实例还保持操作不黏。

消费级卡和数据中心级卡在这个场景里差别在哪？

最关键的差别不是算力，是厂商对并发编码会话数的政策。业内较常见的说法是，部分消费级显卡的驱动层对同时进行的编码会话数存在上限，达到上限之后的会话可能失败或者静默降级，而数据中心级/专业级产品通常不施加这类限制。此外还有虚拟化切分支持、长时间满载运行的稳定性设计、以及驱动的长期维护周期上的差异。具体会话数以厂商最新官方说明为准，网上流传的数字常有过时。选型时把目标实例数换算成所需会话数，再去比对候选型号的官方说明。

zRAM 开多大比较合适？有没有默认值可以参考？

主流发行版常见的默认做法是取物理内存的一小部分作为压缩池，量级通常在四分之一上下，这在"进程多、匿名页多"的容器场景里一般偏保守，可以适当上调。但不存在一个放之四海皆准的比例，因为你的压缩收益取决于实例内存里有多少是可压缩的冷数据，而你的压缩代价取决于 CPU 是否还有余量。判断标准只有一条：调整之后重新压密度，看单核能撑的实例数是变多还是变少。交互型业务宁可直接加内存，也不要让 CPU 长期泡在压缩解压里。

实例之间怎么隔离才算安全？

容器化安卓实例依赖内核命名空间与控制组实现隔离，内核是共享的，这一点要心里有数。资源视角的隔离（进程、网络、挂载、文件系统）通常足够，强度视角则不如完整虚拟化。实务上有几件事值得做：给每个实例设置明确的 CPU 与内存配额和上限，避免单实例失控拖垮整机；IO 层做限速或权重分配，防止某个实例写爆 IOPS；网络侧给每个实例独立的网络命名空间与出口策略。如果业务对隔离强度有更高要求，可以考虑把它放在虚拟机里再跑容器，代价是牺牲一部分密度与启动速度。

镜像更新会不会让写盘量翻倍？

取决于你的存储分层怎么做。如果每个实例都持有一份完整的可写副本，那一次镜像升级就是 n 份写入，三十个实例意味着三十倍，这个量级很容易在一瞬间压垮写入通道。如果用支持写时复制的文件系统或者分层镜像管理，多个实例可以共享同一份只读底层，升级时只写差量，实际写入量接近于一份。容器化方案在这件事上天然有优势，因为镜像层和可写层本来就是分开管理的。采购时确认系统盘是否支持这类能力，比单纯看容量数字重要得多。

单机开太多实例会不会被平台风控？

会被风控的通常不是"实例数量"本身，而是这些实例在外部呈现出来的痕迹是否高度重合——同一个出口 IP、同一组设备特征、高度一致的操作节律，这些信号叠在一起就容易被判定为来源集中。业务运营需遵守目标平台的用户协议与所在司法辖区的相关规则，本文不讨论任何规避平台规则的做法。合规的做法是让每个身份的来源清晰、可管理、可审计：按账号组规划独立出口、独立配置轮换与访问策略、控制批操作的节律。这套东西属于基础设施范畴，成本要提前算进预算。

为什么按核数算出来的密度总是偏大？

因为核数只直接决定了 CPU 突发这一项，而密度是五项约束取最小值的结果。按核数算的时候，你默认内存无限、默认图形不占资源、默认编码想开几路就开几路、默认磁盘 IOPS 随实例数线性扩展——四条假设在现实里都不成立。更隐蔽的问题是突发叠加：冷启动、JIT 编译、GC 回收这些短时尖峰会同时落在多个实例上，均值监控完全看不见，但用户体验实实在在地掉了。所以除了取五项最小值，还要再乘一个 0.7 到 0.85 的实操折减系数，把峰值叠加也算进预算。

密度算完之后，实例数量与出口 IP 该怎么一起规划

走到这里，正确的顺序应该是：先算出单机密度，再按业务规模倒推需要几台机器，最后才算出口资源——但绝大多数人把 IP 预算放在最后一步单独审批，于是出现两头对不上的局面。

一个比较稳的做法是按"账号组"而不是按"实例"来配出口。把实例先按业务账号分组，每个账号组对应一个独立出口和一个独立的访问策略，组的规模取决于业务对来源清晰度的要求。这样做的好处是成本可控、出问题能快速定位到组、审计也清楚；代价是 IP 数量会高于"每实例一个"的粗算方式之外的直觉值，所以这一步必须在采购前敲定，不能事后补。

第二个要一起规划的是机器的地理分布。密度够不代表全塞在一台机器上合适。把实例分散到两三台机器、甚至两三个不同的机房，除了规避单机故障的爆炸半径，还有一个现实好处：不同机房的出口段不同，来源的多样性天然更好安排。同时这也意味着每台机器都要单独配一套监控、镜像分发和出口管理，分散部署带来的运维复杂度要提前评估，别最后省了机器钱却搭进去三个人力。

第三个是扩容逻辑。密度确定了之后，扩容应该"横向加机器"而不是"纵向提密度"——除非你明确知道新的瓶颈在哪并且确认自己还留有余量。横向扩容的好处是风险可控、回滚容易、成本线性；纵向提密度则要求你重新跑一遍完整的压力验证，而且往往要用更贵的单卡或者更大内存规格。经验上，把密度定在机器稳定承载能力的七到八成，剩下的用横向扩容补，是最划算的组合。

最后落到资源选型上，选供应商时值得看的是几件很具体的事：能不能提供足够容量的大内存物理机、GPU 型号是否覆盖了你需要的数据中心级档位、以及部署阶段有没有真正懂行的工程师帮你把驱动和运行时环境装好，这一层往往决定了密度测算的结论能不能落地。要开安卓实例，先问内存和 GPU 而不是核数；一万网络深耕 IDC 19 年（成立于 2007 年），支持按配置定制，CUDA 一类环境可由工程师 1 对 1 部署，具体规格与价格以官网实时报价为准。。价格方面以官网实时价为准。

本篇安卓实例密度测算的参考来源与需要实测确认的部分

本文关于安卓容器形态的描述，参考 Linux 内核命名空间与容器化隔离机制的公开技术文档，以及主流 Android 容器化项目的公开说明；关于多实例共享内核、每实例独立用户态与数据目录的表述，属于这类方案的通行实现方式。

关于实例内存占用区间、分辨率与帧缓冲的计算方法、软件渲染后端对 CPU 占用的影响，均来自公开技术社区的工程经验与通用计算方法，文中未给出任何实测跑分数据，所有相关数值请以自己环境的压测结果为准。

关于 GPU 并发编码会话数的表述，参考 NVIDIA 等厂商公开的编解码能力与相关政策说明，具体会话数限制、受限型号范围、驱动与固件版本的影响，一律以厂商最新官方文档为准，不同厂商与不同时期政策可能存在差异。

关于出口 IP 与账号关联的讨论，属于跨境业务合规运营的行业公开共识，本文不讨论任何规避平台规则的做法，相关业务请遵守目标平台用户协议与所在司法辖区的法律法规。

文中涉及的一万网络服务器与 GPU 配置价格来自其官网公开明示信息（T4 ¥900/月、RTX3090 24G ¥1750/月、A100 40G ¥2800/月、裸金属 E5-2698v4×2 ¥3999 起），具体以签约时最新报价与合同为准。