算力卡与推理卡：从概念到13B代码模型部署完全指南

算力卡与推理卡——从硬件选型到13B代码模型私有化部署完全指南。

这篇文章覆盖两个层次：第一，把行业里"算力卡"和"推理卡"这两个被混用的概念说清楚；第二，给一个具体场景——10人团队，13B代码模型，64K上下文， OpenClaw/Claude Code Agent私有化部署——提供可执行的三套硬件方案。

一、核心概念：算力卡 vs 推理卡

行业日常对话里，"算力卡"和"推理卡"各有所指，但它们都是泛称，不是严格的分类命名。

算力卡（训练卡）——代表：H100、A100、H200、A800

用来做一件事：从零训练或微调大模型。执行完整的前向传播 + 反向传播 + 梯度更新，显存同时存放模型权重、激活值、梯度、优化器参数，数据量极大。属于离线重型计算，不面向终端用户的实时请求。

推理卡（推理算力卡）——代表：T4、L4、L40、A10、昇腾310P、思元370

用来做另一件事：加载已经训练好的模型，接收用户请求，给出结果。只执行前向传播，不需要计算梯度。显存主要存放模型权重和KV缓存。面向7×24小时在线服务（AI对话、图像识别、智能审核），看重并发、响应延迟、电费成本。

二者的计算流程差异可以用一个简单对比说明：

训练：前向传播 → 反向传播 → 梯度更新 → 重复 推理：前向传播 → 输出结果

一个来回打满，一个只走单程。这是本质区别。

二、硬件设计关键差异

典型型号举例：

训练卡：NVIDIA V100、A100/A800、H100/H800、H200、GB200；国产昇腾910B/910C、壁仞BR100

推理卡：NVIDIA T4、A10、L4、L40、L20；国产昇腾310/310P、寒武纪思元370/290、摩尔线程MTT S3000（可兼顾推理）

中间地带有L40S——全能卡，既能小规模微调训练，又适合推理，介于两者之间。

三、非常重要的使用误区

误区一：算力卡（A100/H100）当然能跑推理，但极不划算。 电费和硬件采购成本高出推理卡数倍，同等预算下推理卡可以部署更多并发服务。

误区二：推理卡可以跑小规模微调，但不适合大模型训练。 没有高速互联、显存带宽规格不足、高精度算力不够，训练速度非常慢，很难支撑70B/100B以上模型全参数训练。

误区三：算力越高推理越快。 大模型自回归推理的瓶颈往往不是算力，而是显存带宽。挑选推理卡要重点看显存带宽 + 显存容量，而不是只看TFLOPS。

一句话快速选型：

• 要训练大模型、预训练、全参数微调 → 选算力卡（H100/A100）
• 要上线对外提供AI服务、部署聊天机器人、图像识别、视频分析 → 选推理卡（L4、T4、L40）

四、具体场景：13B代码模型 + OpenClaw/Claude Code Agent私有化部署

场景描述：10人团队，13B代码大模型（DeepSeek-Coder系列或Qwen2.5-Coder系列），硬性要求支持64K上下文，本地私有化部署，配合OpenClaw / Claude Code Agent使用。

OpenClaw这类智能体会持续加载大量代码文件、进行多轮链式思考。64K长上下文场景下，显存的最大瓶颈是KV缓存，远大于模型权重本身。

RTX 4090 24GB直接排除

24GB显存不足以稳定承载13B模型 + 全局开启64K上下文 + 多用户并发KV缓存。高峰期极易OOM、触发swap、速度暴跌、Agent任务超时。

最低起步标准：单卡48GB显存

下面做精确测算。

五、显存量化测算

以vLLM + FlashAttention2为工业实测标准，使用13B原生支持64K上下文的代码模型。

模型权重占用：

• FP16/BF16精度：约26GB
• AWQ INT4量化：约7.5～8GB

单条64K会话KV缓存：

• vLLM PagedAttention优化后约18～22GB

关键结论：只要同时存在2条64K长会话，24GB卡直接爆显存。10人团队多人同时加载完整代码库，几乎一定会出现多条长上下文。

两种精度下的并发上限（稳定运行，无Swap）：

AWQ INT4（工程折中首选，代码能力损耗极小）

• 权重：8GB；单路64K KV：18GB
• L40S 48GB：稳定支持2～3路完整64K并发；轻量短会话可容纳6～8人在线

FP16原生高精度（追求最佳代码理解、长文档逻辑）

• 权重：26GB；单路64K KV：18GB
• L40S 48GB：仅支持1路完整64K长会话同时运行

实际情况是：团队里不会所有人持续占满64K，但经常会2～3名开发者同时加载完整项目代码库触发超大上下文。

六、三套最终硬件方案

方案A｜生产机架首选（推荐）：单卡L40S 48GB

适用：机房7×24小时不间断运行；推理为主，偶尔13B QLoRA微调；标准机架部署。

整机参考配置：

• 机箱：4U机架服务器
• CPU：双路AMD EPYC / Intel Xeon
• 内存：256GB DDR5（必须，防止CPU内存瓶颈、模型卸载swap）
• 存储：4TB PCIe4.0 NVMe SSD（存放模型 + 代码向量库）

优势：

• 48GB显存是13B + 64K上下文最低安全底线
• NVIDIA数据中心卡，驱动稳定、持续满载、FlashAttention原生兼容
• 功耗300W，风冷方案可行
• 预留扩容空间，未来可再加第二张L40S做双卡张量并行

局限：FP16模式只能支持单条完整64K长会话，日常部署建议采用AWQ INT4量化平衡显存与代码精度。

方案B｜高配扩容方案：双卡L40S 48GB（总96GB）

适用：团队经常多人同时打开大型代码仓库、多人常驻64K上下文；希望FP16原生精度。

能力上限：

• FP16：同时支持2条完整64K长会话
• AWQ INT4：稳定支持4～6条完整64K会话，10人团队高并发无压力

适合中长期不打算再次升级硬件、预算充足的团队。

方案C｜备选方案（不优先推荐）：双卡RTX6000 Ada 48GB

优势：带ECC显存，内存出错自动纠错；工作站形态。

短板：

• 价格普遍高于L40S
• 面向工作站生态，运维和集群生态弱于数据中心L40S
• 机架散热适配不如原生服务器显卡

明确排除方案

• 所有24GB显卡（RTX4090、L4、A10）：单卡无法稳定承载2条64K长上下文，多人同时载入大型代码项目时持续显存溢出、推理延迟飙升，Agent极易超时失效。
• A100 80GB：完全不推荐。采购价和电费极高，13B模型推理无法发挥训练卡NVLink和HBM优势，纯浪费预算。

七、软件部署优化

推理后端：vLLM（必须），PagedAttention大幅降低KV缓存显存占用。

vLLM启动核心参数：

--model 13B-coder-AWQ
--quantization awq
--max-model-len 65536
--gpu-memory-utilization 0.88
--enable-prefix-caching   # 代码场景大量重复文件，极大节省KV显存
--tensor-parallel-size 1  # 双卡修改为2

OpenClaw / Claude Code侧配置：

• 设置上下文上限64000，禁止模型自动无限扩展上下文
• 开启上下文自动压缩（CLAUDE_CODE_AUTO_COMPACT_WINDOW），长时间会话主动精简历史，减少KV占用
• 单用户会话限制最大输出token 8192，避免单次生成疯狂消耗显存

量化策略建议：

首选AWQ INT4。代码大模型对AWQ量化鲁棒性很强，相比GPTQ，长上下文精度衰减更低，显存直接减半，是小团队64K场景最优平衡点。

不推荐GGUF（Ollama）。多并发长上下文场景下，vLLM的吞吐量和显存利用率显著优于Ollama；OpenClaw对接vLLM的OpenAI API兼容性完美。

八、扩容路线规划

1. 预算有限：先上单卡L40S 48GB，AWQ INT4部署
2. 并发压力上涨：直接增加第二张L40S，开启张量并行，显存合并
3. 未来需要34B代码模型：双卡L40S刚好满足34B + 32K/64K场景，硬件复用不浪费

极简选型一句话：

预算适中、标准机房、10人开发团队、13B + 64K代码智能体 → 单卡L40S 48GB（AWQ INT4部署）

追求高并发、多人同时完整64K长上下文、需要原生FP16精度 → 双卡L40S 48GB

GPU Compute Cards vs Inference Cards: A Practical Guide for 13B Code Model Private Deployment

This article covers two layers. First, clarifying the industry jargon around "compute cards" and "inference cards." Second, providing a concrete, actionable hardware guide for a specific scenario: a 10-person team running a 13B code model with 64K context for OpenClaw/Claude Code Agent private deployment.

Quick Definitions

In everyday industry conversations, "compute card" and "inference card" are loosely used terms:

Compute (Training) Cards — H100, A100, H200, A800 Task: training or fine-tuning large models from scratch. They execute full forward + backward + gradient update cycles. VRAM must hold model weights, activations, gradients, and optimizer states — enormous data requirements. Offline heavy compute, not serving real-time user requests.

Inference Cards — T4, L4, L40, A10, Ascend 310P, Cambricon Siyuan 370 Task: loading a trained model and serving user requests. Only forward pass — no gradient computation. VRAM mainly holds model weights + KV cache. Designed for 24/7 online services (chatbots, image recognition, content moderation). Priority metrics: concurrency, latency, power cost.

Training: forward → backward → gradient update → repeat Inference: forward → output

Hardware Design Comparison

Typical Models: Training: V100, A100/A800, H100/H800, H200, GB200; domestic Ascend 910B/910C, Biren BR100 Inference: T4, A10, L4, L40, L20; domestic Ascend 310/310P, Cambricon 370/290, Moore Threads MTT S3000 Hybrid: L40S

Common Misconceptions

Myth 1: Use A100/H100 for inference. Technically yes, but extremely cost-inefficient — several times the power and purchase cost for the same concurrent capacity.

Myth 2: Inference cards can handle full training. Not for 70B+ models — lack of interconnect, memory bandwidth, and high-precision compute.

Myth 3: Higher FLOPS = faster inference. The bottleneck in autoregressive LLM inference is usually memory bandwidth, not compute.

Quick Selection:

• Training/fine-tuning → Training card (H100/A100)
• Serving chatbots, image recognition, video analysis → Inference card (L4, T4, L40)

Scenario: 13B Code Model + OpenClaw Private Deployment

A 10-person team deploying a 13B code model (DeepSeek-Coder or Qwen2.5-Coder) requiring 64K context, private deployment, with OpenClaw/Claude Code Agent integration.

Key insight: For long-context code agents, the VRAM bottleneck is KV cache, which far exceeds model weights.

RTX 4090 24GB is immediately excluded. 24GB can't handle 13B model + 64K context + multi-user concurrent KV cache. Expect OOM, swap, and agent timeouts under real usage.

Minimum entry: single card 48GB VRAM.

VRAM Budget (vLLM + FlashAttention2, validated in production)

Weights:

• FP16/BF16: ~26GB
• AWQ INT4: ~7.5-8GB

Single 64K session KV cache (PagedAttention): ~18-22GB

Conclusion: Two concurrent 64K sessions exceed 24GB. A 10-person team will almost certainly have multiple developers loading full codebases simultaneously.

Concurrency limits (stable, no swap):

AWQ INT4 (recommended):

• Weights: 8GB; single 64K KV: 18GB
• L40S 48GB: 2-3 full 64K sessions; 6-8 users on light tasks

FP16 native (max quality):

• Weights: 26GB; single 64K KV: 18GB
• L40S 48GB: 1 full 64K session

In practice: not everyone hits 64K simultaneously, but 2-3 developers frequently do when loading large projects.

Three Hardware Plans

Plan A (Recommended): Single L40S 48GB

Spec: 4U rack server, dual AMD EPYC/Intel Xeon, 256GB DDR5, 4TB PCIe4.0 NVMe

Pros: 48GB minimum safe capacity for 13B+64K; stable data-center GPU with FlashAttention support; 300W air-cooled; expandable to dual L40S later

Limitation: FP16 supports only one full 64K session; deploy with AWQ INT4 as default

Plan B (High-end): Dual L40S 48GB (96GB total)

For teams with frequent multi-user full-context load, or requiring FP16 native precision.

Capacity:

• FP16: 2 full 64K sessions
• AWQ INT4: 4-6 full 64K sessions, comfortable for 10-person team

Plan C (Alternative, not preferred): Dual RTX6000 Ada 48GB

Pros: ECC memory, workstation form factor Cons: More expensive than L40S, weaker cluster ecosystem, worse rack cooling

Explicitly excluded:

• All 24GB cards (RTX4090, L4, A10) — insufficient VRAM
• A100 80GB — wasteful for inference-only 13B deployment

Software Stack

Backend: vLLM (mandatory) — PagedAttention is essential for KV cache efficiency.

vLLM launch parameters:

--model 13B-coder-AWQ
--quantization awq
--max-model-len 65536
--gpu-memory-utilization 0.88
--enable-prefix-caching
--tensor-parallel-size 1

OpenClaw/Claude Code configuration:

• Hard cap context at 64000
• Enable auto-compact for long sessions
• Limit single-generation output to 8192 tokens

Quantization: AWQ INT4 preferred. Code models handle AWQ well; long-context accuracy degradation is minimal. Avoid GGUF/Ollama for multi-concurrent long-context deployments — vLLM's throughput and VRAM efficiency are significantly better.

Upgrade Path

1. Budget limited: single L40S 48GB with AWQ INT4
2. Higher concurrency: add second L40S, enable tensor parallelism
3. Future 34B model: dual L40S handles 34B + 32K/64K without hardware replacement

Bottom line: Standard rack, 10-person team, 13B + 64K code agent → single L40S 48GB (AWQ INT4) High concurrency, native FP16, multiple simultaneous long contexts → dual L40S 48GB