跑AI应用用VPS怎么选：显存与带宽

一、先分清推理和训练，两者的机器完全是两种东西

AI服务器VPS 的第一个分岔路口是用途。推理是拿训练好的模型去回答请求，训练是用数据去更新模型权重，这两件事对硬件的要求几乎是相反的。推理是显存瓶颈，模型权重加载进显存后能塞下多大的模型决定了它能服务多大的请求量，而 CPU 和磁盘基本只影响首次加载速度。训练则是算力瓶颈，需要的是能并行跑海量矩阵乘法的 GPU 张量核心，显存只用来暂存中间激活值。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

这个差别决定了你该看什么参数。推理场景下单卡显存是最硬的约束，七十亿参数的模型用半精度加载大约需要十四 GB 显存，十四十亿参数大约需要二十八 GB，三百亿以上基本要上多卡或者做量化。训练场景下显存决定的是批次大小和序列长度，而实际的墙钟时间由卡数和算力决定。

还有一个常被搞混的点是量化。量化不是训练，而是把模型权重从半精度压到八位甚至四位，显存占用直接降到原来的四分之一到二分之一。对推理来说这是把消费级显卡变成可用方案的关键手段，对训练来说量化主要用于降低通信开销和显存占用，精度损失在微调任务里是敏感的。

# 查看模型加载后的实际显存占用，用 nvidia-smi 实时观察
nvidia-smi --query-gpu=memory.total,memory.used,utilization.gpu --format=csv -l 5

# 检查模型各层的精度设置和总参数量
python -c "from transformers import AutoConfig; c=AutoConfig.from_pretrained('模型路径'); print(c.num_parameters, c.torch_dtype)"

一句话总结：推理买显存，训练买算力，混合场景两者都要算进去。

判断自己属于哪一类有个简单的问法：你的代码里有没有反向传播和优化器。如果没有，只做前向推理，买显存；如果你要微调或者从零训练，那优化器状态、梯度和激活值都要占显存，训练用的显存通常是推理的三到四倍。

混合场景在企业里非常普遍，比如用别人的大模型做检索增强，先微调一个小模型做领域适配，再用大模型做最终生成。这时候配置需求是两段式的，最省钱的做法是训练阶段短时租用高算力实例，推理阶段长期用显存足的大显存实例，两种机型不用买同一台。

# 判断当前任务是否涉及训练，看有没有梯度相关的关键标志
grep -rn "backward()\|optimizer.step()\|requires_grad=True" /opt/app/ --include=*.py | head

# 如果确认是纯推理，可以在加载时关掉梯度，省显存也省时间
python - <<'EOF'
import torch
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("模型路径",
        torch_dtype=torch.float16, device_map="cuda")
model.eval()
with torch.no_grad():
    out = model.generate("测试", max_new_tokens=64)
print("推理正常，显存:", round(torch.cuda.memory_allocated()/1024**3, 2), "GB")
EOF

还有一个跟选型直接相关的细节是批量推理的效率。推理框架支持连续批处理，也就是把不同时间到达的请求拼成一批一起算，这样显卡利用率能明显高于一个一个处理。这意味着同样一张卡，在高并发下的总吞吐可能远高于单请求速度，选型时应该按目标并发下的总吞吐来判断，而不是按单请求延迟。

二、CPU和内存：真正被低估的那一半

AI服务器VPS 的选型讨论几乎都在 GPU 上，但真正让应用卡住的往往是 CPU 和内存这两个不起眼的指标。一个常见的误区是把所有算力都指望给 GPU，觉得 CPU 随便配。实际情况是，GPU 算得再快，如果前处理、序列化、检索这些环节卡在 CPU 上，整条链路的速度就由最慢的那段决定。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

CPU 在 AI 应用里的作用主要有三块。第一是数据预处理，包括文本分词、图像解码和缩放、音频重采样，这些操作在数据量大时非常吃 CPU，而且必须是整数运算为主，GPU 的浮点单元在这类分支密集的任务上反而是浪费。第二是推理框架的调度，包括批处理组装、请求路由、多路流量的队列管理。第三是外围服务，比如向量数据库的查询、缓存的读写、结果的后处理和格式化。

内存则决定你能同时服务多少路请求。推理服务的显存放不下模型时会溢出到内存，如果主机内存不足，框架要么拒绝服务要么开始大量换页，换页会让延迟从几十毫秒跳到几百毫秒甚至几秒。经验值是内存至少要能装下模型权重的一半再加上并发请求的 KV 缓存，再加上系统和框架本身的开销。

# 观察推理服务的内存占用，区分是模型占用还是 KV 缓存增长
ps -o pid,rss,vsz,%mem,cmd -C python | grep -i server

# 实时追踪内存与 swap，确认有没有发生换页
watch -n 2 'free -m; echo; vmstat 1 2 | tail -1'

# 找出换页的罪魁祸首，si/so 持续非零就说明内存不够
vmstat 1 10 | awk '$16>0 || $17>0 {print "换页:", $0}'

模型推理时，每路请求都要占用一份 KV 缓存，它的大小和上下文长度成正比。上下文从四千 token 拉到三万二千 token，单路请求的 KV 缓存可能涨到十倍以上。所以如果你计划做长文档处理，内存必须按最长的上下文算，而不是按平均长度算。

# 推理时打印 KV 缓存显存占用，这个数就是并发上限的约束条件
python - <<'EOF'
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained("模型路径", torch_dtype=torch.float16, device_map="cuda")
tok = AutoTokenizer.from_pretrained("模型路径")
inputs = tok("测试文本", return_tensors="pt").to("cuda")
with torch.no_grad():
    out = model(**inputs, output_attentions=True)
print("最大注意力层:", out.attentions[0].shape)
print("当前显存:", torch.cuda.memory_allocated() / 1024**3, "GB")
EOF

一个务实的配置原则是：CPU 核数不低于 GPU 数量的两倍，内存至少是显存的同等字节数再多加四到八 GB 用于 KV 缓存和框架开销。

三、带宽在AI应用里到底吃多少

AI服务器VPS 的带宽需求由三部分构成：模型文件下载、用户输入输出、以及最容易被忽略的中间数据回传。很多人以为 AI 应用是流量黑洞，其实不然，除非你在做视频生成或者大规模批量推理，否则稳定运行的推理服务带宽压力通常在几 Mbps 量级。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

模型下载是唯一一次性的带宽高峰。七十亿参数的模型在半精度下大约十四 GB，下载完就基本不占带宽了，但首次下载时如果带宽只有十 Mbps，需要跑将近三个小时。这个时间成本在选型时经常被忽略，实际会影响上线节奏。判断方法很简单，看商家给的带宽峰值乘以实测能不能覆盖模型体积。

# 实测下载带宽，用模型文件做一次实际测速比看标称准
wget -O /dev/null https://example.com/model.safetensors

# 统计一段时间内的实际网络吞吐，看稳态带宽
sar -n DEV 1 60 | awk 'NR>2 {rx+=$2; tx+=$3} END {print "平均接收 KB/s:", rx/60, " 发送 KB/s:", tx/60}'

# 查看推理服务的入站出站流量分布
iftop -n -i eth0 -f 'net'

出站带宽的峰值往往出现在并发高的时段。假设单次请求输入两千 token、输出五百 token，按每个 token 约四字节的传输量算，一次请求的响应体只有几 KB。但如果有几十路并发同时返回，再加上日志和健康检查，峰值也就几 Mbps 量级。所以带宽这一项对推理型应用往往不是瓶颈，除非你的场景是长上下文或者批量处理。

真正吃带宽的是两类场景。第一类是视频和图像生成，输入输出都是大文件，一张图几 MB 到几十 MB，一个请求就可能吃掉几十 Mbps。第二类是批量推理任务，比如离线跑几十万条数据做标注，这种场景带宽和磁盘吞吐会同时吃紧。

# 批量推理时限制并发数，避免带宽和显存同时被打爆
python - <<'EOF'
from concurrent.futures import ThreadPoolExecutor
import time

def process(item):
    # 单条推理调用
    time.sleep(0.1)
    return item

items = list(range(1000))
start = time.time()
with ThreadPoolExecutor(max_workers=8) as ex:
    list(ex.map(process, items))
print("总耗时:", time.time() - start)
EOF

并发数不是越高越好，它要受显存约束。并发数乘以单路的 KV 缓存占用不能超过可用显存，超了就会触发换页或直接 OOM。所以带宽的峰值实际上是被显存间接限制住的。

带宽还有一个隐藏变量是延迟，而不是带宽量本身。很多 AI 应用的用户体感来自首字响应时间，也就是从发出请求到拿到第一个字的等待。这个时间由三段组成：网络往返、请求排队、模型预填充计算。前面已经算过网络往返通常只有几十毫秒，排队时间取决于并发是否超过服务能力，而预填充计算才是大头，它消耗的是算力不是带宽。所以想改善首字延迟，加带宽往往没用，要加的是显存和算力。

# 测量首字响应时间与完整响应时间，这两个数的差值能看出是排队还是计算慢
python - <<'EOF'
import time, requests
url = "http://127.0.0.1:8000/v1/chat/completions"
payload = {"model": "本地模型", "messages": [{"role": "user", "content": "写一段介绍"}],
           "stream": True, "max_tokens": 256}
t0 = time.time()
first = None
total = 0
with requests.post(url, json=payload, stream=True) as r:
    for line in r.iter_lines():
        if not line:
            continue
        total += 1
        if first is None:
            first = time.time() - t0
print("首字延迟:", round(first, 3), "秒")
print("完整响应:", round(time.time() - t0, 3), "秒")
print("生成段数:", total)
EOF

如果首字延迟很高但完整响应很快，说明是排队时间太长，要降并发或者加机器；如果两者都高，那才是算力不够，升级显卡才有效。

需要强调的是，这些延迟数字都必须在真实并发下测，因为单请求测出来的延迟和线上完全不一样。测的时候要按线上实际的请求到达曲线来压。

四、GPU VPS的现实：价格、类型和隐藏限制

AI服务器VPS 选型绕不开的一个现实是，带 GPU 的云主机和普通 VPS 是两个完全不同的价格体系。普通入门级 VPS 的月租在几美元到十几美元这个量级，而带一张消费级或专业级 GPU 的云主机月租通常从几十美元起步，上千美元也很常见，因为 GPU 的采购成本、机房供电散热和折旧都要算进去。具体报价以各商家官网当日报价为准。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

GPU 云主机大致分三类。第一类是按需计费的实例，最灵活，用一小时算一小时，适合调试和不确定负载的场景。第二类是预留实例或者包年包月，价格有折扣但要预付，适合负载稳定的长期服务。第三类是 Serverless 或者按秒计费的推理专用实例，平台帮你做模型常驻和冷启动管理，用量小的时候比开一台整机便宜得多。

选这类服务时有几个隐藏限制必须提前问清楚。第一个是 GPU 是否独占，如果标称的是共享实例，实际可用显存和算力会被切分，你以为有二十四 GB 显存，实际可能只有八 GB。第二个是计费是否包含磁盘和带宽，有些主机套餐只算 GPU 费，磁盘和流量另计，账单会超预期。第三个是持久化存储的可靠性，临时盘上的数据实例释放就没了，模型每次重装都要重新下载。

# 确认拿到的卡是什么型号、显存多少、是否被切分
nvidia-smi --query-gpu=name,memory.total,compute_mode --format=csv

# 检查是不是 vGPU 切分环境，看显存上限是否符合预期
nvidia-smi -q | grep -A3 "Max Operating Temperature\|Fabric State\|Persistence-M"

# 看实际可用显存与框架预留的差值
nvidia-smi --query-gpu=memory.total,memory.used --format=csv,noheader

第四个限制是最容易翻车的：长时间运行的稳定性。消费级显卡在数据中心环境下的散热设计往往不如专业卡，很多实例在连续满载几小时后会因为温度墙降频，表现为前两小时跑得快，后面越来越慢。这个现象很坑，因为它会让你的压测结论失真。

# 连续压测并记录温度与频率，观察有没有降频
nvidia-smi --query-gpu=temperature.gpu,clocks.sm,power.draw --format=csv -l 10 | tee /tmp/gpu_thermal.log

# 压测结束后统计平均温度与最高温度
awk -F', ' 'NR>1 {t+=$1; if($1>max) max=$1} END {print "平均温度:", t/(NR-1), "最高:", max}' /tmp/gpu_thermal.log

如果最高温度接近八十多度并且频率明显下降，就说明这个实例在持续负载下会降频，评估性能时要按降频后的数值算。

五、GPU之外的替代路线：CPU推理也不是不行

AI服务器VPS 的另一条常被忽略的路是纯 CPU 推理。对于文本类的中小模型，配合量化，CPU 推理在实际业务里完全够用。前提是并发不高、延迟要求不苛刻。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

CPU 推理的实际能力取决于模型规模、优化程度和指令集支持。带向量扩展指令的 CPU 在整数和低精度浮点运算上的吞吐差别很大，同一个七亿参数模型，在支持相应指令集的机器上和不支持的机器上，速度可能相差三到五倍。选择机器时要看处理器是否支持 AVX2 或者 AVX-512 这类向量指令，这是纯 CPU 跑模型的关键。

# 检查 CPU 是否支持向量扩展指令和 AVX-512
lscpu | grep -i "flags" | tr ' ' '\n' | grep -E "avx|amx" | sort -u

# 跑一个纯 CPU 的推理基准，看每秒能处理多少 token
pip install llama-cpp-python
python - <<'EOF'
from llama_cpp import Llama
import time
llm = Llama(model_path="ggml-q4_0.gguf", n_ctx=4096, n_threads=8)
t = time.time()
out = llm("写一段关于云服务器选型的说明", max_tokens=256)
dt = time.time() - t
print("生成 token 数:", out.usage.completion_tokens)
print("每秒 token:", round(out.usage.completion_tokens / dt, 1))
EOF

上面那段代码的输出是判断这台机器跑 CPU 推理行不行的直接依据。每秒能出二三十个 token 的机器，做后台批处理、内部文档问答、分类任务完全够用；如果你的场景需要每秒上百 token 或者用户就在等回复，那就得上 GPU。

判断该不该用 CPU 推理，可以用一个简单的算式：如果你的日请求量乘以平均响应时间除以每秒吞吐，得出的排队时间在几十秒以内且用户能接受，那 CPU 方案成立。用上面实测的每秒 token 数、预估的日请求量和平均输出长度代入即可。

CPU 推理还有一个常被低估的优势：弹性和成本。普通 VPS 的月租低到你不会去纠结利用率，凌晨三点和下午三点价格一样。而 GPU 云主机闲置时你也在付全价，所以要么保证高利用率，要么选按需计费。CPU 方案没有这个顾虑。

另外要提到的是纯 CPU 推理的批处理优势。在低并发场景下 GPU 的大部分算力是闲着的，而 CPU 推理在多进程并行下能把空闲核心吃满。跑离线任务时，把任务切分成多份分给多个进程，吞吐可能反而超过一张低端 GPU。

# 多进程并行跑量化模型，验证 CPU 方案的批量吞吐上限
python - <<'EOF'
from multiprocessing import Pool
import time, os

def worker(_):
    from llama_cpp import Llama
    llm = Llama(model_path="ggml-q4_0.gguf", n_ctx=2048, n_threads=2)
    t = time.time()
    llm("总结这段文字", max_tokens=128)
    return time.time() - t

if __name__ == "__main__":
    print("CPU 核数:", os.cpu_count())
    t0 = time.time()
    with Pool(4) as p:
        p.map(worker, range(8))
    print("8 条任务总耗时:", round(time.time() - t0, 1), "秒")
EOF

还有个现实问题是噪音和电费。如果你在家用旧机器跑推理，散热和噪音会直接影响办公环境，而且机器折旧和电费长期算下来未必比租 GPU 便宜。家用场景更适合验证，不适合长期承载。

# 估算家用机器跑推理的月度电费，按每瓦特小时电价折算
python - <<'EOF'
power_w = 180          # 推理时整机功耗，瓦
hours_per_day = 8      # 每天实际运行小时
price_per_kwh = 0.6    # 每度电价格，按当地实际电价调整
monthly = power_w / 1000 * hours_per_day * 30 * price_per_kwh
print("月度电费估算:", round(monthly, 2), "元")
print("这还没算机器折旧和噪音打扰")
EOF

六、什么时候干脆该用API而不是自己扛服务器

AI服务器VPS 选型的最终答案往往是：不该买服务器。这是很多团队在踩过坑之后才承认的事实。判断依据不是技术先进程度，而是经济账和机会成本。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

用 API 的成本结构很简单，按 token 计费，没有硬件折旧，没有运维负担，没有模型加载的冷启动等待。你不需要懂 GPU 型号，不需要处理显存溢出，不需要担心散热降频，只需要在代码里改几行调用方式。代价是数据要出你的服务器，不能完全自主，而且长期高频调用时账单会持续增长。

自建的成本结构则是固定的。无论你一天用一千次还是一百万次，月租不变，所以使用量越大自建越划算。有一个粗略的临界点参考，当月调用量稳定在几十万次以上、或者对数据出域有硬性要求、或者需要微调自己的模型时，自建开始体现出明显优势。这个数字只是估算，因为 API 价格和你的输出长度强相关，需要按自己实际用量算。

# 用一个简单脚本估算自建和 API 的月度成本对比
python - <<'EOF'
monthly_calls = 300000
avg_input_tokens = 1500
avg_output_tokens = 400
# API 单价请按所选服务商的官网当时报价替换
api_price_in = 0.000002    # 每千输入 token
api_price_out = 0.000008   # 每千输出 token
api_cost = monthly_calls * (avg_input_tokens/1000*api_price_in
                            + avg_output_tokens/1000*api_price_out)
print("API 月度估算:", round(api_cost, 2))
# 自建侧：把 GPU 云主机的月租填进来对比
gpu_monthly = 180
print("自建月度固定成本:", gpu_monthly)
print("结论:", "自建更省" if gpu_monthly < api_cost else "API 更省")
EOF

除了钱，还有三个常被低估的因素。第一是工程时间，团队里要有人懂模型部署、监控、扩容，如果这个人不存在，服务器买回来也是闲置。第二是可用性，自己搭的服务在机器宕机时需要有人值班恢复，而 API 背后是对方的冗余集群。第三是模型更新的滞后，模型升级要自己下载、验证、灰度，API 那边通常几天内就跟上。

# 如果决定自建，先做好服务的高可用基础：健康检查与自动重启
cat > /etc/systemd/system/inference.service <<'EOF'
[Unit]
Description=AI Inference Service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /opt/app/server.py
Restart=always
RestartSec=10
WatchdogSec=300

[Install]
WantedBy=multi-user.target
EOF

# 用 curl 做存活探测，连不上就触发重启
curl -sf http://127.0.0.1:8000/health || systemctl restart inference

七、成本对比与选型决策表

AI服务器VPS 的成本不能只比月租，要比一个月的总账。下面这张表把三条路线的成本结构和风险点列出来，硬件参数是按需求侧的估算区间给的，具体机型和报价以各商家官网当日报价为准。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

选型决策可以直接按这张表走：

把这张表和自己的三个数字对照：日请求量、平均上下文长度、对延迟的容忍度。这三个数决定了上面哪一行是你的落点。

# 估算你的峰值并发，这决定了显存能撑多少路请求
# 公式：并发 = 每秒到达率 × 平均响应时间
python - <<'EOF'
rps = 2.0            # 平均每秒到达的请求数
avg_latency = 3.0    # 平均响应时间，秒
concurrency = rps * avg_latency
print("所需并发路数:", concurrency)
# 经验值：单路 7B 模型半精度 4K 上下文约需 1.2 GB 显存
need = concurrency * 1.2
print("所需显存约:", round(need, 1), "GB")
print("加上权重和框架开销，建议显存:", round(need + 16, 0), "GB 以上")
EOF

这张算式比任何厂商的套餐表都管用，因为它用的是你自己的真实负载假设，而不是别人的平均值。

评估方案时还有一个容易漏掉的成本项是数据搬运。模型文件几十 GB，放在对象存储上每次加载都要拉一次；向量数据库的数据集往往有几百 GB，搬迁一次要按流量计费。这些隐性成本在对比 API 和自建时经常被忽略，导致估算偏低。

# 统计自建方案的数据搬运成本，按流量计费
python - <<'EOF'
model_gb = 14          # 模型文件大小
restart_per_day = 3    # 每天重启次数
days = 30
egress_gb = model_gb * restart_per_day * days
price_per_gb = 0.05    # 每 GB 出站流量价格，按服务商当时报价替换
print("月度出站流量:", egress_gb, "GB")
print("月度流量成本:", round(egress_gb * price_per_gb, 2))
EOF

还有一个决策维度是退出成本。用 API 随时可以停，自建的机器如果模型选型或者框架路线要换，迁移成本不小。做技术选型时留一条退路是有价值的，尤其是团队规模小、依赖单一供应商的时候。

八、常见误区：这五个坑几乎所有人都踩过

AI服务器VPS 的选型误区有共性，都是拿别的场景的参数套自己的场景。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一个误区是按训练需求买机器。训练和推理的账完全不同，训练要的是算力和多卡互联带宽，推理要的是显存和低延迟。很多团队一上来就想微调，结果买了一台单卡高算力的机器，做推理时显存不够，做训练时单卡又慢得没法用。

第二个误区是忽略冷启动时间。模型从磁盘加载到显存里，几十 GB 的文件在普通磁盘上要几分钟，在高速 NVMe 上也要几十秒。如果服务需要频繁重启或者做滚动更新，这段冷启动会频繁出现在用户面前。解决办法是让框架支持模型常驻，或者用支持预热的服务形态。

# 测量模型加载耗时，这直接决定了重启窗口期有多长
python - <<'EOF'
import time
t0 = time.time()
from transformers import AutoModelForCausalLM
import torch
model = AutoModelForCausalLM.from_pretrained("模型路径",
        torch_dtype=torch.float16, device_map="cuda",
        low_cpu_mem_usage=True)
torch.cuda.synchronize()
print("模型加载耗时:", round(time.time() - t0, 1), "秒")
EOF

第三个误区是只看标称带宽不看实测。宣传页上的带宽往往是端口上限，实际共享后能跑多少要实测，尤其是深夜和业务高峰两个时段差异会很明显。

第四个误区是以为显存越大吞吐就线性增长。显存装下模型只是门槛，吞吐还受显存带宽和算力限制，而且并发上去后收益会递减。用批处理把多个请求合并成一批，往往比单纯加并发更有效。

# 压测不同批大小下的吞吐，找出性价比最高的配置
for bs in 1 4 8 16 32; do
  echo "batch_size=$bs"
  # 用你的推理脚本跑这个批大小，记录每秒请求数
done

第五个误区是忽略数据盘的读写速度。模型加载慢往往不是网络问题而是磁盘问题，机械盘读几十 GB 文件可能要十几分钟，而 NVMe 几十秒就完了。

# 用 dd 测顺序读速度，模型加载主要吃这个指标
dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=direct
# 再测随机读速度，数据库和向量库更关心这个
fio --name=randread --ioengine=libaio --direct=1 --filename=/tmp/test \
    --rw=randread --bs=4k --iodepth=32 --size=1G --runtime=30 --group_reporting

九、给不同阶段的选型路径

AI服务器VPS 的选型路径，按你现在所处的阶段来看最清楚。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

如果你是刚起步的个人开发者，方案只有一个：直接用商业 API。这个阶段你的瓶颈是产品本身而不是算力，把精力花在优化提示词和评估效果上，回报远高于折腾部署。等有真实用户和稳定调用量了再考虑迁移。

如果你是有了产品雏形但用量还不确定的团队，方案是先用 API 跑通，同时租一台按需 GPU 做对比测试。用真实流量测出单请求成本和延迟，再和 API 账单对账，这个数据就是决策依据。

如果你的日调用量已经稳定在几十万次以上，或者有数据合规要求，方案是上 GPU 云主机包月。这时候要重点做三件事：确认独占显存、验证持续满载不降频、把监控和自动扩缩容配好。

如果你要做的是图像、视频这类重度生成，方案是独立 GPU 主机加对象存储分离架构。生成任务通常耗时长、要排队，适合用异步任务队列而不是同步请求，配合按需或竞价实例降低成本。

下面这张表是按阶段的行动清单：

不管落在哪一行，选型时都记住一条原则：先用最便宜的方式验证需求成立，再用最稳的方式承载流量。中间最忌讳的是在需求还没验证时就买贵的机器，然后因为用不起而把服务降级。

最后给一个落地建议：不管选哪条路，都要做一次真实的影子测试。也就是让新旧两套方案同时跑一周，用真实流量对比它们的延迟、成功率、输出质量和月度成本，再做最终切换。这比任何纸面推算都可靠，而且能提前发现你在算式里漏掉的变量。

# 影子测试期间同时记录两套方案的延迟，便于直接对比
# 在自建服务侧记录
curl -s -o /dev/null -w "自建: 状态%{http_code} 首字%{time_starttransfer}s 总耗时%{time_total}s\n" \
  -X POST http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"本地模型","messages":[{"role":"user","content":"测试"}],"max_tokens":128}'

# 在 API 侧记录同样的指标，两边输出放到同一张表里对比
curl -s -o /dev/null -w "API: 状态%{http_code} 首字%{time_starttransfer}s 总耗时%{time_total}s\n" \
  -X POST https://api.example.com/v1/chat/completions \
  -H "Content-Type: application/json" -H "Authorization: Bearer 你的密钥" \
  -d '{"model":"模型名","messages":[{"role":"user","content":"测试"}],"max_tokens":128}'

十、常见问题

跑AI应用用VPS 需要什么样的配置？ 取决于模型规模和使用方式。文本推理用普通 VPS 加 CPU 就能跑量化后的中小模型，需要 GPU 时先确认显存的绝对值能否装下模型权重，再看 CPU 核数和内存是否够撑住并发和 KV 缓存。

GPU 显存多大够用？ 七亿参数模型半精度约需十四 GB 显存，一百四十亿参数约需二十八 GB，三百亿以上需要多卡或配合四比特量化。算完之后还要额外留出显存给 KV 缓存，按并发路数乘以单路占用累加。

普通 VPS 能跑大模型吗？ 能跑小模型和经过极限量化的版本，但吞吐会明显下降。纯 CPU 推理适合内部工具、离线批处理和低并发场景，如果用户要等实时响应，还是得上 GPU。

本地部署和调用 API 怎么选？ 看调用量和合规要求。调用量小、追求快速上线，选 API；调用量大且有数据不能出域的硬性要求，选自建。中间地带建议先跑一个月真实流量拿到账单数据再决定。

模型下载太慢影响上线，怎么解决？ 提前把模型文件同步到机器的数据盘或者对象存储挂载上，避免每次重启都重新下载。用高速下载通道拉一次，之后用本地缓存，部署脚本里直接指向本地路径。

机器选的显存够用但实际报显存不足，为什么？ 通常是框架默认预留了较多显存给临时缓冲，或者模型加载时用了全精度而不是半精度。用 nvidia-smi 看已用显存和总量差值，再检查加载代码里的精度参数。

多张 GPU 的机器值得买吗？ 推理场景除非单个模型大到单卡装不下，否则多卡收益有限，因为卡间通信会吃掉一部分性能。训练或大模型多卡并行场景才真正需要，具体要看卡型是否支持高速互联。

服务器带宽要多少才不影响推理速度？ 文本推理的稳态带宽通常在几 Mbps 量级就够，真正的瓶颈是显存和算力。只有做图像视频生成或大批量离线任务时带宽才会成为约束，模型下载阶段建议至少保证百兆以上的峰值。

推理延迟高，是该加带宽还是加显存？ 先测首字延迟和完整响应的差值。差值大说明是排队时间过长，要降并发或加机器；两个都高才是算力不足，该升级显卡。带宽一般不参与这两项的计算，加带宽不会明显改善响应速度。

七十二亿参数的模型，一张二十四 GB 显存的卡够吗？ 够。半精度加载权重约需十四 GB，剩下十 GB 用于 KV 缓存和框架开销，配合四比特量化还能再省一半空间，可以支撑相当可观的并发量。

自建的模型服务怎么防止被人刷坏？ 在网关层加限流和鉴权，给每个调用方分配独立的密钥和配额，超出就拒绝。另外要设置单请求的最大 token 数和最大上下文长度，防止少数长请求把显存占满导致整台机器不可用。

模型服务需要配多少监控指标？ 至少四类：显存使用率和 OOM 次数、首字延迟与完整延迟的分布、请求成功率与错误码分布、GPU 温度与降频次数。这四类指标能覆盖容量、性能、稳定性和硬件健康四个方向，缺一项就会出现盲区。