一支做企业知识库问答的团队，租了一台带24GB显卡的服务器，把一个8B参数的开源模型部署上去试用。一个人提问，回答几乎秒出，大家都挺满意。产品正式上线以后，同时在线的人数涨到二十来个，反馈跟着来了：回答说到一半就停住，偶尔还直接报错。登录机器一看，显存快被占满，而模型权重本身只占了其中一部分。

这种情况在上线初期很常见，毛病通常不出在显卡品牌上。模型“放得下”和业务“跑得动”是两笔账：前一笔看权重大小，后一笔还要加上上下文长度、并发人数和推理框架自身的开销。服务如果放在香港、面向亚太用户，接入层、带宽、前端和管理系统怎么跟GPU配合，也得提前想好。

一、为什么在香港部署AI大模型，需要先考虑GPU配置？

原因很直接：模型能不能跑起来，先由GPU显存决定，速度是之后的事。CPU和内存配得再高，显存装不下权重，服务连启动都做不到。所以在谈香港节点、带宽和价格之前，GPU这一项要先算清楚。

AI模型训练和AI模型推理，对服务器的要求有什么不同？

训练要反复做前向计算和反向传播，还要更新参数、持续读取大量数据。以常见的Adam优化器配合混合精度训练为例，每个参数对应的显存开销能达到推理时权重占用的好几倍，多卡之间的通信速度和存储吞吐也都会成为瓶颈。推理只做前向计算，关心的东西少一些，但每一项都直接影响用户体验：模型加载要多久，请求发出后多久出第一个Token，之后每秒能稳定生成多少Token，同时能接待多少人。

企业在香港落地的AI业务，绝大多数是推理，或者在现成基础模型上做轻量微调。拿训练集群的规格去配推理服务，钱花得冤枉；反过来拿推理的配置去做训练，又会一开始就卡在显存上。两类任务不能共用同一套配置思路。

香港云主机适合哪些AI部署场景？

从实际项目看，香港节点比较常见的用法集中在几类。一类是AI应用的前端和推理服务一起部署，用户在亚太各地访问；一类是面向东南亚、港澳台用户的智能客服和AI问答；还有一类是对外提供AI API，其中Embedding和重排序这两种服务很容易被忽略，它们用的模型通常只有几亿到数十亿参数，小显存的GPU甚至CPU就能撑住，常常和主力大模型分开部署。最后是把香港作为业务接入层的AI平台，推理算力放在别处，香港这一层负责域名、鉴权、限流和日志。

使用普通云主机和GPU云主机有什么区别？

普通云主机没有GPU，也能跑模型，靠的是CPU推理，一般配合量化过的小模型使用（例如llama.cpp这类工具加载GGUF格式的4bit模型）。它适合功能验证、内部低频工具和离线批处理，生成速度明显慢于GPU，并发能力也有限。GPU云主机把模型权重和KV Cache放进显存，由GPU完成矩阵运算，才谈得上给多人同时提供服务。

不过GPU只是其中一环。请求解析、分词、调度、流式输出，以及知识库场景里的文档切分和向量检索，大多还是在CPU上完成；模型文件要先从磁盘读到内存，再送进显存。这几项配得太低，GPU再好也会闲着等数据。

二、部署AI大模型，首先要弄明白GPU显存需求

模型参数量与显存之间有什么关系？

最基础的算法只有一行：权重占用的显存，约等于参数量乘以每个参数占用的字节数。

权重显存 ≈ 参数量 × 每个参数的字节数

7B模型按FP16存储：70亿 × 2字节 ≈ 14GB；13B模型 ≈ 26GB；70B模型 ≈ 140GB。

FP16、BF16、INT8、INT4量化分别是什么？

这几个名称指的是每个参数用多少位来存。FP16和BF16都是16位，每个参数2字节，两者的区别在数值范围和精度的分配上，BF16的数值范围更宽，在较新的GPU架构上用得更多。INT8是8位整数，每个参数1字节。INT4是4位，每个参数约0.5字节，实际因为要额外存储缩放系数，会略多一点。常见的量化方案有AWQ、GPTQ，以及llama.cpp使用的GGUF格式。

位数越低，占用的显存越少，推理时读取权重的数据量也更小，速度往往也有提升。代价是精度可能有损失，损失多少因模型、量化方法和任务类型而异。写作、闲聊这类任务通常不太敏感，代码生成、数学推理、严格的信息抽取则要用自己的评测集对比后再决定。

为什么模型权重显存不等于实际推理显存？

因为推理过程中，显存里除了权重，还要装一份随着对话增长的KV Cache（键值缓存）。模型生成每个Token时，要回看前面所有Token的中间结果，这些结果缓存下来就是KV Cache。它的大小可以粗略估算：

KV Cache ≈ 2 × 层数 × KV头数 × 头维度 × 每元素字节数 × Token数 × 并发序列数

以一个常见的8B级模型为例（32层、8个KV头、头维度128，FP16缓存），每个Token的KV Cache约128KB。一条8K上下文的对话就是1GB左右，同时有20条这样的对话在跑，仅缓存就要20GB。回头看开头那支团队：24GB显存，扣掉约16GB的FP16权重，再按推理框架常见的显存预占比例留出余量，真正给KV Cache的只剩五六GB，并发一上来自然撑不住。当然，用户的问题不一定都用满8K，但知识库问答要把检索到的文档片段塞进提示词，上下文长度往往接近上限。

除此之外还有两项开销。一是推理框架的预留：vLLM这类框架默认会按一个比例（常见默认值为0.9）预先占住显存，用来管理缓存块；二是CUDA运行环境和中间激活值，通常也要占几百MB到数GB。四项加在一起，才是一块卡真正需要承担的显存：权重、KV Cache、框架预留、运行开销。

单卡显存不足时，可以采用哪些解决方式？

量化模型。 最直接的办法，把FP16换成INT8或INT4，权重占用减半或更多。有些框架还支持对KV Cache本身做FP8量化，可以再省一部分缓存，同样要实测精度。

降低上下文长度。 把最大上下文限制在业务真正需要的范围内，比如客服问答用4K，不必按模型支持的最大长度开放。

多卡模型切分。 通过张量并行或流水线并行把模型拆到多张卡上，缺点是增加卡间通信，对互联带宽和部署经验都有要求。

优化批处理和显存管理。 使用支持连续批处理和分页式缓存的推理框架，限制最大并发序列数，开启前缀缓存复用相同的系统提示词，能把同样的显存用得更充分。

三、不同规模的AI模型，GPU服务器应该怎么选择？

下表把常见规模的模型放在一起，列出权重的大致占用和单卡规划方向。再次提醒，这里的数值只是初步规划参考，没有包含全部推理开销，实际显存还要受量化方式、上下文长度、KV Cache和并发数影响。

7B模型部署，24GB显存是否足够？

够用，前提是别把“够用”理解成“随便用”。7B或8B模型按FP16加载约占14到16GB，24GB的卡扣完权重和框架预留，剩给KV Cache的空间有限。如果是内部使用的知识库，上下文控制在8K以内，同时在线的人数是个位数，这样的配置能稳定运行。一旦对外开放、并发明显上升，就该考虑换成INT8或INT4量化，或者选更大显存的卡，也可以多开几个实例做横向扩展。

13B模型适合单卡还是双卡？

FP16下13B模型约26到28GB，24GB的单卡放不下。可选的路径有三条：量化到INT8或INT4后仍用24GB单卡；换成32GB、40GB或48GB的单卡直接跑FP16；用两张24GB卡做切分。三条路里，第三条通常最不省心，卡间通信带来额外延迟，部署和排障也更复杂。能用一张大显存卡解决的，一般不建议拆成两张小卡。

70B模型为什么不能只看显卡数量？

70B模型的FP16权重约140GB，四张40GB的卡合计160GB，看上去够了，实际却未必好用。每张卡都要各自留出框架开销，KV Cache也要分摊；张量并行对头数能否被卡数整除有要求；卡间走PCIe还是NVLink，推理速度会差出很多。同样是四张卡，四张带高速互联的80GB卡和四张24GB的PCIe卡，不是一个体验级别。把70B量化到INT4，权重降到35到40GB，单张48GB卡可以跑起来，但长上下文并发只能做得很有限：按前面的算法，每条8K上下文大约还要占2.5GB左右缓存。

多卡GPU部署需要注意哪些硬件条件？

先看主板和机箱能否提供足够的PCIe通道、插槽间距和供电，单张高端卡的功耗从三四百瓦到七百瓦不等，多卡机器对散热和电源冗余的要求很高。再看互联：有没有NVLink，卡间带宽能差一个量级，PCIe 4.0 x16的理论单向带宽约32GB/s，而NVLink的总带宽按卡型号可达几百GB/s。软件层面，驱动、CUDA、NCCL版本要对得上，多卡最好是同型号同显存。如果是租用云实例，还要向服务商确认：GPU是整卡直通还是虚拟化切分，多卡实例的卡是否位于同一台物理机上。

四、GPU服务器除了显存，还需要关注哪些配置？

显存决定能不能跑，下面这几项决定跑起来之后顺不顺。

CPU核心数如何影响推理服务？

推理计算主要在GPU上，但请求解析、分词、调度、流式输出的拼装，以及RAG场景下的文档解析、向量检索，都吃CPU。CPU核心太少，GPU会出现“等任务”的空档，利用率上不去。常见的做法是每张GPU至少配数个到十几个vCPU作为起点；如果同一台机器上还跑向量数据库或文档处理，要把这部分另外算进去。

系统内存是否需要与GPU显存匹配？

模型权重加载时，通常要先读进系统内存，再传到显存。系统内存比权重还小，加载过程中就可能触发交换甚至内存溢出。不少团队的经验做法是让系统内存不低于GPU显存总量，多模型并存、带向量库的知识库系统则要给得更宽裕。这是经验值，不是硬性规定，以实际加载时的内存曲线为准。

为什么建议关注NVMe SSD？

模型文件动辄十几GB，大的有上百GB，每次服务重启、扩容新节点、切换模型，都要把它读一遍。以140GB的权重为例，按500MB/s的顺序读速度需要将近5分钟，换成3GB/s左右的NVMe只要不到1分钟（均为理论值，实际会更慢）。除了权重，镜像、日志和向量库也在同一块盘上，磁盘慢，整套服务的启动和恢复都跟着慢。

PCIe带宽和NVLink对多GPU任务有什么影响？

只用一张卡的推理服务，这一项基本可以忽略。多卡做张量并行时，每一层计算之后都要在卡间同步数据，互联带宽低，GPU就要花大量时间等通信，卡越多，性价比下降越明显。消费级显卡一般没有NVLink，数据中心级的卡才普遍具备，所以同样“四卡”的描述，背后的互联条件要问清楚。如果只是多卡各跑各的模型副本来提升并发，对互联的依赖就小得多。

公网带宽如何匹配AI API访问量？

纯文本的流式输出，每个Token只有几个到几十个字节，一路连接的带宽占用在KB/s的量级，所以文本类AI接口很少出现带宽不足。真正需要关心的，一是并发连接数和长连接的保持，二是多模态场景，比如用户上传图片、文档、语音，入口带宽才会明显抬高。另外要留意，推理本身的耗时通常是几百毫秒到数秒，网络往返只有几十毫秒，所以为了省下几毫秒去追求更贵的线路，往往不如把预算花在显存上。

需要补一句，接入层和GPU层不必在同一台机器上。域名解析、HTTPS、鉴权、限流、日志和管理后台，这些内容不需要GPU，用香港云主机承载即可。恒讯科技提供香港云主机和海外服务器资源，业务如果走“香港接入层加后端推理算力”的架构，接入层这一块可以直接放在香港节点，按普通Web服务的规格去配，成本也比整机GPU低得多。

五、香港GPU云主机与普通香港云主机有什么区别？

GPU算力与普通CPU计算资源的差别

大模型的计算核心是大规模矩阵乘法，GPU有成千上万个并行计算单元，CPU只有几十个核心，两者在这类任务上的差距是数量级的。更关键的是显存带宽：生成每个Token都要把整套权重读取一遍，这个阶段的速度主要受内存带宽限制。数据中心GPU的显存带宽通常是每秒数百GB到数TB，普通云主机的内存带宽一般在每秒几十到几百GB。这也是同样的模型放在CPU上，生成速度会明显落后的原因。

本地GPU计算和远程API调用的成本差异

自己部署GPU，成本基本是固定的，不管有没有人调用，月费都要付；调用第三方的模型API，则是按Token计费，用多少付多少。两者谁划算，取决于GPU的实际利用率。下面这个公式可以拿来算：

每百万Token成本 ≈ 实例月费 ÷（持续吞吐 × 月秒数 × 平均利用率 ÷ 1,000,000）

假设某实例月费为10,000元（仅为演示数字，不代表任何报价），在目标并发下持续吞吐为1,000 Token/秒，月秒数按259.2万计。平均利用率为30%时，月产出约7.8亿Token，折合约12.9元/百万Token；利用率提高到80%，约4.8元/百万Token。

利用率差一倍多，单位成本也差了一倍多。请求量波动大、高峰集中在白天几个小时的业务，自建GPU往往空转得很厉害，API更合适；请求量稳定、需要数据留在自己控制的环境、或者要部署定制微调模型的业务，自建更有优势。也有不少团队采用混合方式，核心业务自建，突发流量走API。

香港节点对亚太业务访问的价值

香港的国际出口带宽条件好，到东南亚、日韩、台湾以及港澳的网络路径通常比较短，适合做面向亚太用户的接入点。另外一个实际好处是，在香港节点下载Hugging Face上的模型权重、GitHub代码和Docker镜像，一般不需要额外处理网络问题，部署效率有保障。但各运营商线路质量差别较大，访问延迟以实际测试为准，不要只看机房地点。如果用户主要集中在北美或欧洲，则要重新考虑部署地，香港并不是所有场景的最优选择。

GPU云主机的计费模式与资源使用成本

计费方式大体有三类：包月或包年，价格相对低，适合稳定业务；按小时计费，适合测试、压测和短期任务；还有一部分平台提供价格更低但可能被回收的抢占式实例，一般不适合线上服务。需要留意的细节包括：实例关机后GPU是否继续计费，数据盘和公网IP是否另行收费，流量按量计费还是固定带宽，快照与镜像占用的存储费用。这些规则每家服务商不同，下单前以订单页和合同条款为准。比较稳妥的节奏是：测试期按量，稳定之后转包月。

接入层和GPU层分开以后，两边的计费和扩缩也是各算各的，这是这种架构的好处，也意味着要把两份账单分别看。GPU层可以是同一服务商提供的GPU实例，也可以是另行租用的GPU服务器或算力，具体取决于各自的库存和合规条件；接入层放在恒讯科技的香港云主机上即可，规格按普通Web服务来配。

六、AI推理服务器部署后，如何测试实际性能？

模型成功加载不代表推理性能达标

服务启动成功、单次提问能回答，只能说明权重装得下。上线之前还要回答几个问题：真实的提示词长度下，首个字多久出来；多人同时用，速度掉多少；连续跑几个小时，显存会不会越用越高。下表是比较常用的一组观测指标。

测试首Token延迟

首Token延迟包含请求排队、提示词预处理（也叫预填充）和第一个Token的生成，输入越长越慢。测试时要用接近线上的提示词长度，不能拿“你好”两个字去测，那样得到的数字对知识库场景毫无参考价值。

测试每秒生成Token数

这一项决定用户看到文字“流出来”的快慢。普通阅读速度下，每秒几十个Token的输出体验已经很顺畅；低到每秒个位数，用户就会感觉卡。要注意区分单请求速度和整机总吞吐，两者经常此消彼长。

测试不同并发用户下的吞吐量

vLLM等框架自带基准测试脚本，也可以用k6、Locust一类的压测工具模拟真实用户的请求分布。逐级提高并发，记录每一档的TTFT、单请求生成速度和总吞吐。一般会看到总吞吐先上升后趋平，而单请求速度和首Token延迟一路变差，业务可接受的最大并发，就在延迟开始超出预期的那个位置。

观察GPU利用率、显存占用和CPU负载

压测期间用 nvidia-smi 的持续刷新模式或DCGM采集数据。有两点要留意：GPU利用率显示100%，不代表已经榨干了硬件，生成阶段受显存带宽限制，实际效率可能并不高；利用率很低但延迟很高，则多半是CPU、调度或网络环节拖了后腿。显存如果在稳定负载下仍缓慢攀升，要排查是否有缓存没释放。

通过压力测试判断是否需要扩容

可以参照这几个信号：P95首Token延迟持续超过产品设定的上限（例如要求2秒内）；请求队列在高峰时段持续堆积；显存长期处于90%以上；GPU利用率长期贴近满载，同时延迟还在变差。出现其中两三项，就该规划扩容。方式可以是换更大显存的卡、增加同型号实例做负载均衡，或者对模型做量化来换取并发。

七、企业租用香港AI服务器，应该如何确定配置？

前面的内容归拢起来，其实是在回答一个问题：我的业务需要多少显存、多少并发、放在哪里、预算多少。把这几件事写成清单，再去和服务商沟通，效率会高很多，也不容易被报价单里不匹配的配置带偏。

有一项容易被忽略的问题要单独提醒：如果服务面向中国大陆境内的公众提供生成式AI能力，相关的监管要求并不会因为服务器放在香港而改变，需要事先了解并以主管部门的最新规定和专业法律意见为准。这个判断通常比选哪张显卡更早做。

配置思路定下来以后，建议先用按量方式做一轮小规模实测，用真实的提示词和并发数压一遍，把得到的数据代回上面的清单，再决定包月规格。如果你的业务已经明确采用香港节点，可以把模型规模、预期并发和目标用户区域整理好，与恒讯科技的技术人员沟通，由他们结合现有的香港云主机和海外服务器资源，一起评估接入层的配置，以及GPU算力应该从哪里获得。

常见问题

1. 香港云主机可以直接部署DeepSeek、Qwen等模型吗？

要看云主机有没有GPU，以及选哪个版本。没有GPU的普通云主机只能用CPU跑小参数量的量化模型，适合验证和低频使用，不适合多人并发。Qwen系列从不到1B到数十B都有，按前面的表格对照显存即可。DeepSeek完整版的R1、V3是6710亿参数的混合专家模型，权重在数百GB量级，需要多张高显存GPU组成的服务器，普通单台云主机承担不了；常说的蒸馏版（如7B、14B、32B、70B几个规格）显存需求与同规模模型相近。部署前也别忘了查看各模型的许可协议。

2. 7B模型需要多大的GPU显存？

FP16或BF16下权重约14到16GB，加上KV Cache和框架开销，建议从24GB起步。INT4量化后权重只有四五GB，8GB左右的卡就能跑通，不过上下文长度和并发会受限。

3. GPU服务器能不能同时运行多个AI模型？

可以，前提是总显存放得下所有模型的权重和各自的KV Cache。常见做法有三种：同一张卡上启动多个推理进程，每个限定显存比例；多卡机器按卡分配，一张卡对应一个模型；部分数据中心GPU支持把一张卡切成多个隔离的小实例（如NVIDIA的MIG）。Embedding和重排序这类小模型，经常与主力大模型共用一张卡。要避免的是多个进程互相抢显存，导致其中一个在高峰期报错退出。

4. AI推理应该优先考虑显存还是GPU算力？

先看显存。显存不够，模型放不下，算力再强也没有意义，所以显存是入场的门槛。门槛跨过以后，速度才由算力和显存带宽共同决定：处理长提示词的预填充阶段吃算力，逐个生成Token的阶段更受显存带宽限制。选型时的顺序是：先用显存把能放得下的卡筛出来，再比较带宽和算力，最后看并发需求。