How much GPU memory does a large language model need?

The weights are the parameter count multiplied by the bytes per parameter: two bytes each at 16-bit, one at 8-bit, half at 4-bit. A 7-8 billion parameter model is 16 GB of weights at 16-bit, 8 GB at 8-bit and 5 GB at 4-bit; a 70 billion parameter model is 140 GB, 70 GB and 38 GB. Those figures are the weights alone and are a floor rather than a requirement -- budget a quarter to a half again on top for the runtime, the activations and the key-value cache.

What do I need to run a 70B model like Llama 3.3?

At 4-bit the weights are about 38 GB, so with serving head-room the answer is a card of 64 GB or more -- one card, one machine. At 8-bit the weights are 70 GB and an 80 GB card clears the bar. At full 16-bit precision no single card Primcast fits holds it, and it becomes a multi-card build that is quoted. The fit matrix on the page names the exact cards; the prices are at https://primcast.com/gpu.

Why does my model load but fail to serve?

Because the weights are not the only thing in card memory. The runtime and its buffers are resident, and every token in a conversation leaves an entry in the key-value cache so it does not have to be recomputed. That cache grows with the context length and again with each request served concurrently, so a model whose weights only just fit will hold roughly one short conversation. Size the card at one and a quarter to one and a half times the weights.

Which inference runtime can I install?

Any of them. The machine arrives with a clean operating system and root, and there is no vendor inference service in front of it. vLLM is the usual answer for serving real traffic because continuous batching lets one card answer many requests at once. llama.cpp is the usual answer when memory is tight or the card is older. TGI and SGLang run unchanged. Ollama is the shortest path from an empty machine to a model answering on a port -- and vLLM and Ollama both answer on an OpenAI-compatible endpoint, so existing client code points at your own machine by changing one base URL. You pin the driver, the CUDA or ROCm release and the framework to the versions your code was tested against.

Is self-hosting an LLM cheaper than a per-token API?

It depends entirely on volume, and the crossover is real: an API bills per token and costs nothing when idle; a dedicated machine is a flat monthly figure and costs nothing more when busy. Steady traffic, agents that run all day, batch pipelines and anything with a privacy requirement tend to come out ahead on their own hardware; a workload that fires ten times a day does not. The monthly figures to do that arithmetic with are at https://primcast.com/gpu -- the LLM page deliberately prices nothing.

How many tokens per second will I get?

Primcast does not publish a tokens-per-second figure, because every such number depends on the model, the quantisation, the runtime and its version, the batch size, the prompt length, the reply length and the concurrency, and changing any one moves it by a multiple. What governs it: reading the prompt is compute-bound and happens once per request; generating the reply is memory-bandwidth-bound because each token requires reading the weights; and batching amortises that reading across concurrent requests, which is what makes serving economical until the key-value cache runs out of room. Ask with the model, quantisation and expected concurrency for an answer based on what has actually been observed.

Is the GPU shared with anyone else?

No. One tenant per physical machine, and the card is passed through to your own operating system. There is no hypervisor, no MIG partition, no vGPU profile and no time-slicing scheduler, so nothing else runs on the card and inference latency does not move because of somebody else's batch job.

What if the model does not fit on one card?

Then it is a multi-card build, which is quoted rather than ordered from a checkout: how many cards fit depends on the physical width of the specific card and the power budget of the chassis. Two cards give you the sum of their memory only if the runtime can split the model across both, which every serious runtime supports at some cost in throughput. https://primcast.com/hpc covers what more than one card and more than one machine look like; 128 GB of memory the processor and GPU share in one machine is https://primcast.com/spark.

Does fine-tuning need more memory than serving?

Considerably more. Serving needs the weights; training needs the weights, the gradients and the optimiser state for every parameter being updated, all resident at once, plus the activations kept for the backward pass. A model that serves comfortably on one card can be several times too large to fully fine-tune on it. Parameter-efficient methods update a small fraction of the parameters and need a correspondingly small fraction of the extra memory, which is why most fine-tuning here uses one.

Can I run an AMD card, and does ROCm work?

Yes. The AMD Instinct parts are among the largest-memory cards fitted and are frequently the best value per gigabyte, but your stack has to support ROCm rather than CUDA. Most current inference runtimes do; some surrounding tooling still does not. Ask before ordering and it will be checked against your specific runtime rather than answered in general.

选型工作表 · 裸机上的语言模型 · 始于 2004

在裸机上运行一个语言模型需要什么。

从上往下填写，就像做决定的过程一样：模型决定权重，精度对权重进行缩放，余量覆盖运行时和对话，总数决定用哪张卡。订单表单上其他任何选项都不会改变这个答案 — 一张少两 GB 显存的卡不会跑得慢，它根本加载不了。

绘制方: Primcast LLC，成立于 2004 年
核对依据: 订单目录，在服务时核对
在册显卡 · 最大: 56 · 96 GB GDDR7 ECC
本页价格: 无 — 见 /gpu

填写工作表为什么能装下仍可能失败我在上面安装什么

把您的 GPU 变成每月被动收入

有闲置的服务器或台式机 GPU 配置吗？今天就上架到 Primcast 市场，从需要生产级算力的 AI 团队、开发者和企业那里赚取稳定的月租。

前往市场

工作表

四行，一个结论。

模型

精度

负载

70B: 38 GB × 1.5 = 57 GB

Smallest card on the schedule that clears it (3 larger ones also do):

Instinct MI21064 GB HBM2e

The link opens the machine it goes in. What it costs is on /gpu — not on this sheet.

第 1 行 × 第 2 行是权重；第 3 行是本网站公布的“四分之一到一半”余量规则，以算术形式表达 — 在 llama.cpp 或 Ollama 上一次服务一个用户，再加四分之一；在 vLLM 或 TGI 上以连续批处理服务流量，再加一半。结论会给出订单目录中能容纳这个总数的最小显卡，并链接到它所安装的机器。那台机器的价格刻意不写在本页上：所有数字都在 /gpu 上，对应它所属的确切机器。

图 1

权重有多重。

参数量乘以每个参数的字节数，这就是全部计算。十六位权重每个两字节，八位每个一字节，四位每个半字节。量化就是把一台装不下模型的机器变成装得下的机器；它要付出质量代价，而代价多大，更多取决于模型和方法，远不止位数本身。如果精度是这件事的目的，在确定硬件之前两种都测一下 — 现在发现差异比交货后再发现便宜得多。

这些数字只是权重，不含其他任何东西。它们是下限，不是要求 — 图 2 才是让人栽跟头的部分。

Weights only — the runtime, the activations and the conversation are extra, and are the subject of the next section.
Model	16-bit	8-bit	4-bit
7-8 billion parameters	16 GB	8 GB	5 GB
13-14 billion parameters	28 GB	14 GB	8 GB
30-34 billion parameters	68 GB	34 GB	19 GB
70 billion parameters	140 GB	70 GB	38 GB

图 2 · 交互式

一张卡的显存，按比例绘制 — 以及为什么一个能装下的模型仍可能拒绝服务。

GPU 采购出错最常见的方式，每次都是同一种：模型三十八 GB，显卡四十 GB，它加载了 — 然后大约只能进行一段很短的对话。权重在里面并不是独自存在的。拖动工作负载，看看对话会怎样。

权重 · 固定

运行时

键值缓存 · 增长

空闲

一张卡的显存，100 %

对话 · 上下文长度 × 同时请求数

单用户，短上下文：紧凑乘数（×1.25）覆盖这种情况。

对话中的每个 token 都会在键值缓存中留下一个条目，以免重新计算。缓存随上下文长度增长，也随同时服务的每个请求再次增长。
在权重之上，为一次一个用户预留再加四分之一，为服务流量预留再加一半 — 这就是工作表上的两个乘数，也是本网站自己公布的规则。
如果很接近，购买前先问：模型、量化、上下文、并发。我们宁愿现在帮您选一张合适的卡，也不愿接下一张第一周就变成退款请求的订单。

图 3

适配矩阵：哪张卡能容纳哪个模型。

向下找到您的模型，横向找到精度。每个单元格都会给出零件清单上能容纳这些权重并留有服务余量的最小显卡，并链接到它所安装的机器。如果没有任何单卡能容纳，单元格会明确说明，而不是留空。

The smallest card we fit that holds the weights with room left to serve — that is 1.5× the weights, the generous end of the quarter-to-a-half head-room rule below. No prices here on purpose: GPU dedicated servers holds every one.
If you want to run	at 16-bit	at 8-bit	at 4-bit
7-8 billion parameters	TESLA P40 / QUADRO P600024 GB16 GB of weights	TITAN V12 GB HBM28 GB of weights	TESLA P48 GB GDDR55 GB of weights
13-14 billion parameters	RTX A600048 GB GDDR6 ECC28 GB of weights	TESLA P40 / QUADRO P600024 GB14 GB of weights	TITAN V12 GB HBM28 GB of weights
30-34 billion parameters	More than one cardNothing we fit holds it alone68 GB of weights	Instinct MI21064 GB HBM2e34 GB of weights	Tesla V100 32GB32 GB HBM219 GB of weights
70 billion parameters	More than one cardNothing we fit holds it alone140 GB of weights	More than one cardNothing we fit holds it alone70 GB of weights	Instinct MI21064 GB HBM2e38 GB of weights

能装下的最小显卡并不总是您想要的显卡。显存决定模型能否运行；显卡的其他一切决定它跑多快、能同时服务多少人。如果吞吐量比预算更重要，就在清单上再上一档。
较旧的显卡不支持较新的数字格式。清单上有几款早于 FP8 和 bfloat16，因此期望这些格式的运行时要么回退到更慢的方案，要么直接拒绝。下单前值得就具体显卡和具体运行时问一下。
AMD 显卡跑 ROCm，不是 CUDA。Instinct 系列每 GB 性价比极高，在不止一个单元格里都是答案，但您的技术栈必须支持 ROCm。大多数当前运行时都支持；围绕它们的一些工具链还不支持。检查您的环境，或者问我们，我们会和您一起检查。
“多卡”是我们报价的定制方案，不是结账选项 — 能装多少张卡取决于具体显卡的宽度和机箱的供电预算。多 GPU 和多节点是那一页。这个规模下的另一个答案是处理器和 GPU 共享的 128 GB 内存，装在一台机器里：租用 NVIDIA DGX Spark。

清单 A

零件清单：我们适配的每一张卡，附已公布的显存数字。

从最大开始 — 这一页回答“我能运行的最大东西是什么”，与 GPU 独立服务器相反，后者按最便宜的整机对同一目录排序，因为它回答的是“这要花多少钱”。制造商未公布显存的显卡会被排除，而不是猜测。

有几款零件出现在不止一个机箱上，有时价格不同，而且底层机器的总线代际会影响现代显卡实际能做什么 — 两者都在 GPU 独立服务器上。此刻已上架并随时可用的又是另一个问题，由即时服务器回答。

参考

具名模型，映射到各行。

人们带到这里的开放权重系列，附发布方公布的参数量，它决定图 1 中哪一行适用。参数量是发布方自己的数字；模型的其他任何方面都与适配问题无关。不在这个列表上的模型，选型方式完全一样 — 参数量 × 每参数字节数，再加余量。新系列每月发布；算术不会变。

注 1 · 混合专家

一个“30B 参数、3B 激活”的模型需要 30B 模型的显存，运行速度接近 3B 模型的速度：每个专家都必须驻留，因为不同的 token 会唤醒不同的专家。始终按总参数量来选型。

系列	规模	行
Llama 3.1 / 3.3 Meta	8B · 70B	7–8B，3.3 版本为 70B
Qwen3 阿里巴巴	8B · 14B · 32B	前三行
DeepSeek-R1 蒸馏版	7B – 70B	每行一个 — 选您的卡能装下的那个蒸馏版
Mistral Small 3 Mistral AI	24B	在第 2 行和第 3 行之间；按算术选型，不要按标签
Gemma 3 Google	12B · 27B	第 2 行，以及略低于第 3 行
Phi-4 Microsoft	14B	第 2 行
gpt-oss OpenAI	20B · 120B	原生以 4 位发布：一张 16 GB 卡，以及一张 80 GB 卡

安装说明

运行时是您的。这正是裸机的意义。

机器交付时带有干净的操作系统和 root 权限。模型前面没有厂商推理服务，也没有会在截止日期前一周自行升级的托管运行时。vLLM 和 Ollama 都在 OpenAI 兼容端点上应答 — 针对某个 API 提供商编写的代码，只需改一个基础 URL 就能指向您自己的机器。把驱动、CUDA 或 ROCm 版本以及框架固定到您的代码测试过的版本；您脚下不会有任何东西变动。如果您希望在交付前装好驱动，请在订单上说明并指定版本。

vLLM — 服务真实流量。连续批处理和分页注意力让一张卡能同时应答多个请求：这是演示和服务之间的区别。需要一张比较现代的卡。
llama.cpp — 显存紧张，或显卡较旧。它的量化格式正是大模型能装进小卡的原因；当权重不太装得下时，它会同时使用处理器和显卡。
TGI · SGLang — 同一家族的生产服务器，在结构化输出、前缀复用和多模型服务方面各有优势。在这里原样运行。
Ollama — 从一台空机器到一个模型在端口上应答的最短路径。十分钟就能告诉您选型是否正确。

现场条件

您自己的机器能做到而 API 做不到的事。

提示词永不离开大楼

权重、提示词、检索到的文档和每一个生成的 token 都只留在只有您能登录的硬件上。阿姆斯特丹或布加勒斯特，数据就留在欧盟；纽约、迈阿密或旧金山，数据就留在美国。对于要向隐私官交代的工作负载，这句话就是整个商业论证。

计费器永不转动

按 token 计费的 API 对每个 token 收费，而一个智能体或批处理流水线整天都在生成 token。专用机器在任何流量下每月都是同一个数字，底下还有不限流量带宽 — 权重进、token 出，除了端口之外不花一分钱。这个数字是多少，是 /gpu 那一页要填的，不是本页的。

没有人对您限流、弃用或悄悄换掉模型

您固定的模型六个月后原样应答。没有每分钟请求上限，没有在别人高峰时段排队，没有停用通知。这笔交易是诚实的：升级是您的事，按您的时间表来。

模型旁边的工作有安身之处

检索需要嵌入模型、向量存储和快速磁盘；智能体需要运行工具的空间。NVMe 给存储，处理器核心给流水线，显卡给 token — 一台机器承载全部。

注 2 · 性能指标

本页不出现每秒 token 数。

这是刻意的。每一个这样的数字都取决于模型、量化、运行时及其版本、批大小、提示长度、回复长度和并发 — 改变其中任何一个，它都会成倍变动。一个不附带所有这些条件的头条数字，就是一个为了好看而选的数字，而我们会被引用。决定它的是什么：读取提示是计算受限的，每个请求发生一次；生成回复是显存带宽受限的，因为每个 token 都需要读取权重；批处理把这次读取分摊到并发请求上，直到键值缓存耗尽空间。又是余量。

不如要一个真实答案

告诉我们模型、您打算用的量化、上下文长度以及大致多少并发请求。如果我们跑过类似的东西，我们会说看到了什么、在什么上看到的。如果我们没跑过，我们也会直说。

每天每时每刻 — 电话、聊天和工单。支持页面有书面承诺的响应时间。

注 3 · 微调

训练需要的空间比服务大得多。

服务只需要权重。训练需要权重、梯度以及每个被更新参数的优化器状态，全部同时驻留，再加上为反向传播保留的激活值 — 一个在一张卡上舒适服务的模型，要在这张卡上完整微调，可能大出好几倍。参数高效方法只更新一小部分参数，因此只需要相应一小部分的额外显存，这就是这里大多数微调都采用这类方法的原因。训练循环还会持续通过处理器到显卡的链路流式传输批次，所以底层机器的 PCIe 代际在那里是真正的约束，而在服务场景中并非如此 — 哪个平台给哪张卡什么链路，在 GPU 独立服务器上。告诉我们模型、方法、序列长度和数据集大小，我们会帮您选型，而不是让您在交货后才发现；多卡是多 GPU 和多节点那一页的内容。

相邻页面

这一页两边的页面。

本页只负责一个问题：运行一个模型需要什么。相邻的一切都有自己的页面，这里就是全部。

提出的疑问

本页此前版本中被问及的问题。

取自人们在聊天和工单中实际向我们提出的问题，大致按提问顺序排列。前三个问题决定了购买是否可行。

大语言模型需要多少 GPU 显存？: 权重等于参数量乘以每参数的字节数：16 位精度下每参数两字节，8 位下每参数一字节，4 位下每参数半字节。一个 7–8 亿参数的模型，16 位精度下权重为 16 GB，8 位下为 8 GB，4 位下为 5 GB；一个 70 亿参数的模型，则分别为 140 GB、70 GB 和 38 GB。这些数字仅指权重本身，是下限而非要求 — 还需在此基础上再预留四分之一到一半的空间，用于运行时、激活值和键值缓存。
运行 Llama 3.3 这样的 70B 模型需要什么配置？: 4 位精度下权重约为 38 GB，加上推理服务的余量，答案是一张 64 GB 或更大显存的显卡 — 一张卡、一台机器即可。8 位精度下权重为 70 GB，一张 80 GB 的显卡即可满足。若采用完整的 16 位精度，我们所能安装的任何单卡都无法容纳，此时需要多卡方案，我们会提供报价。上方图 3 列出了具体显卡型号；价格见 GPU 独立服务器。
为什么我的模型能加载却无法正常提供服务？: 因为权重并非显卡显存中唯一的内容。运行时及其缓冲区常驻显存，对话中的每个 token 都会在键值缓存中留下记录，以免重复计算。该缓存会随上下文长度增长，并随每个并发请求进一步扩大，因此一个权重刚好能装下的模型，大约只能维持一段较短的对话。请按权重的一点二五倍到一点五倍来规划显卡容量。
我可以安装哪些推理运行时？: 任何一款都可以。机器交付时带有干净的操作系统和 root 权限，前面没有任何供应商推理服务。vLLM 是处理真实流量的常见选择，因为连续批处理能让一张卡同时响应多个请求。llama.cpp 是显存紧张或显卡较旧时的常见选择。TGI 和 SGLang 可直接运行。Ollama 是从空机器到模型在端口上应答的最短路径 — 而且 vLLM 和 Ollama 都提供 OpenAI 兼容端点，因此现有客户端代码只需修改一个基础 URL，就能指向你自己的机器。你可以将驱动、CUDA 或 ROCm 版本以及框架固定到代码测试时所用的版本。
自托管 LLM 比按 token 计费的 API 更便宜吗？: 这完全取决于使用量，而且交叉点是真实存在的：API 按 token 计费，空闲时不产生费用；独立服务器则是固定的月费，繁忙时也不会增加额外成本。持续流量、全天运行的智能体、批处理流水线以及任何有隐私要求的场景，通常在自己的硬件上更划算；而每天只触发十次的工作负载则不然。用于计算的月度费用见 GPU 独立服务器 — 本页有意不标注任何价格。
我能获得每秒多少 token 的速度？: 我们不公布每秒 token 数，因为任何此类数字都取决于模型、量化方式、运行时及其版本、批大小、提示长度、回复长度和并发数，改变其中任何一项都会使数字成倍变化。其决定因素在于：读取提示受计算能力限制，且每个请求只发生一次；生成回复受显存带宽限制，因为每个 token 都需要读取权重；而批处理将这种读取分摊到并发请求上，这正是服务在经济上可行的原因，直到键值缓存耗尽空间为止。请提供模型、量化方式和预期并发数，我们将根据实际观察到的数据给出答案。
GPU 会与其他人共享吗？: 不会。每台物理机只有一个租户，显卡直通到你自己的操作系统。没有虚拟机监控程序、没有 MIG 分区、没有 vGPU 配置文件，也没有时间片调度器，因此显卡上不会运行其他任何东西，推理延迟也不会因别人的批处理作业而波动。
如果模型一张卡装不下怎么办？: 那就需要多卡方案，这类方案需要报价而非直接从结账页面订购：能装多少张卡取决于具体显卡的物理宽度和机箱的供电预算。只有当运行时能够将模型拆分到两张卡上时，两张卡才能提供其显存之和，而所有主流运行时都支持这一点，但会以一定的吞吐量损失为代价。多卡或多机方案介绍了这种配置的具体情况。
微调比推理需要更多显存吗？: 需要多得多。推理只需要权重；训练则需要权重、梯度以及每个被更新参数的优化器状态，所有这些都要同时驻留显存，此外还要为反向传播保留激活值。一个在单卡上能轻松完成推理的模型，可能比能在该卡上完整微调的规模大出数倍。参数高效方法只更新一小部分参数，因此所需的额外显存也相应少得多，这也是此处大多数微调都采用此类方法的原因。
我可以使用 AMD 显卡吗？ROCm 能用吗？: 可以。AMD Instinct 系列是我们所能安装的显存最大的显卡之一，而且通常每 GB 性价比最高，但你的技术栈需要支持 ROCm 而非 CUDA。大多数当前推理运行时都支持；部分周边工具仍不支持。请在订购前咨询，我们将针对你的具体运行时进行核实，而不是笼统地回答。

For the record

Everything on this sheet, as figures.

Card memory is the manufacturers’ published figure; which cards exist is read from the order catalogue when this page was served. No monthly price appears here on purpose — GPU dedicated servers holds every one, against the exact machine it belongs to.

What decides whether a model runs: Card memory, and almost nothing else on the order form. The weights either fit or they do not — a card a couple of gigabytes short does not run slower, it fails to load. Clock speed and core count decide how fast it is once it fits.
How much memory a model needs: Parameters multiplied by bytes per parameter: two bytes each at 16-bit, one at 8-bit, half at 4-bit. That is the WEIGHTS. The runtime, the activations and the key-value cache for the conversation live in the same memory, so budget a quarter to a half again on top before choosing a card.
Largest model on a single card here: 70 billion parameters at 4-bit, with room left to serve. Past that the answer is more than one card in one machine, which is a build we quote rather than a checkout option — multi-GPU and multi-node is the page for it.
Biggest card we fit: RTX PRO 6000 Blackwell 96GB, 96 GB GDDR7 ECC. Card memory figures are the manufacturers' published ones; a card whose figure we could not source is left out of the comparison rather than guessed at.
Which runtime: Yours. The machine arrives with a clean operating system and root, and you install vLLM, llama.cpp, TGI, SGLang, Ollama or anything else, pinned to the version your code was tested against. Nothing upgrades underneath you, and there is no vendor runtime you have to go through.
Throughput: We publish no tokens-per-second figure, deliberately, because we have not measured one under conditions we would be willing to have quoted back at us. What governs it is the card's memory bandwidth while generating, its arithmetic while reading the prompt, and how many requests you batch. Ask with the model, the quantisation and the expected concurrency and we will say what we have actually seen.
Fine-tuning and training: Both are ordinary work here, and both need considerably more memory than serving the same model: gradients and optimiser state sit alongside the weights. A parameter-efficient method needs a fraction of what a full fine-tune does. Tell us the method and the model and we will size it rather than have you find out after delivery.
Tenancy: One tenant per physical machine and the card passed straight through to your operating system. No hypervisor, no MIG partition, no vGPU profile, no time-slicing scheduler, and nobody else's workload on the card. What you measure on the first afternoon is what you keep.
Bandwidth: Unmetered in both directions at every port speed, with no transfer allowance and no egress line on any invoice. Pulling weights down and serving tokens back out costs nothing beyond the port.
What this page does not price: Cards, or anything else. Every card we fit, what each adds per month and what the machine under it costs are on GPU dedicated servers, each figure against the exact machine it belongs to.