Amy青梅最近半年，问我“自己买卡还是租卡”的人明显多了，而且问题的后半句正在从“租4090还是A100”慢慢变成“能不能租国产卡”。一开始我还得解释半天为什么要考虑国产GPU，后来我发现这种变化不是个例，而是算力市场切切实实在转向。2026年国产GPU服务器租用已经不是“能不能用”的问题，而是“怎么租、租哪家、怎么把模型跑起来”的问题。这篇文章我就围绕国产GPU租用这条线，结合我对昇腾、寒武纪、海光、摩尔线程等加速卡的实际体验，把成本账、型号梯队、软件栈差异、实操流程和常见坑一次性讲透，顺便聊聊奇点算力这类租赁平台的机会到底在哪里。
1. 为什么国产GPU服务器租用开始“真香”：我的成本账单推演
1.1 从“没人用”到“开始排队”的转折点在哪
前几年提到国产GPU，绝大多数开发者的第一反应是别碰。我自己刚接触昇腾时，光是装驱动就折腾了一整天，装完换个镜像又得再来一遍，更别提让PyTorch正确识别NPU。当时所有框架都默认CUDA，国产卡就像在一个全是英文的办公室里突然放了一张看不懂中文的人，效率自然起不来。
但2025年下半年以后，情况明显变了。几个关键信号同时出现：一是大模型从单纯的预训练慢慢转向推理和微调，推理负载对算子覆盖的要求比训练低，国产卡更容易接住；二是主流厂商的适配层逐渐成熟，社区里能搜到的踩坑帖比前几年多了好几倍，说明真的有人在用；三是租赁平台开始做“预置环境”这件事，把过去需要用户自己折腾的驱动、算子库、框架版本全部打包成镜像，开机就能用。
对中小团队和个人开发者来说，这个转折非常关键。以前租国产GPU意味着你要同时当算法工程师、运维工程师和底层编译工程师，光是把环境配出来的时间成本就劝退了一大半人。现在平台把这些脏活累活接过去之后，剩下的问题就只有一个：同一笔钱，租国产卡能跑多少小时，效果是不是够用。
1.2 自建服务器和租用之间差的不只是钱
算力账不能只看单价，要算总成本。我们假设一个做AI应用的团队需要一台能够跑7B到13B模型微调的服务器。如果自己采购硬件，一张主流国产AI加速卡的市场价并不便宜，凑齐8卡服务器还要配套CPU、内存、高速硬盘、机柜、电力冗余和散热，整机下来肯定是六位数起步。这还没算机房托管或者公司内部改造电力线路的费用，以及设备交接维护的人工成本。
更要命的是折旧和闲置。很多项目周期只有两三个月，项目结束以后服务器就吃灰了。你买的算力不是资产，是每天都在贬值的消耗品。而租赁模式天然规避了这个问题：按小时、按天、按周租用，项目结束就释放，不用考虑二手残值。短平快的AI实验用租的，长期稳定且能拉满利用率的场景才适合自建，这是我给所有来问我的朋友都强调的一句话。
还有一类成本经常被忽略，就是试错成本。国产GPU的软件栈各家不一样，华为昇腾是CANN，寒武纪是CNToolkit+CNNL，海光走ROCm路线，摩尔线程的MUSA也在快速更新。同一个模型在不同厂商的卡上跑，可能要改不同的配置甚至不同的推理框架。自己买卡等于把试错成本全部扛在自己身上，租赁平台通常会把常见的模型镜像都提前验证过一遍，踩坑概率小很多。算上这部分，租赁在财务上的优势就更明显了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 2026年租得到的国产GPU有哪些：主流型号与算力梯队一览
2.1 我调研过的几家加速卡和它们的定位
目前市面上能通过租赁渠道用到的国产GPU/加速卡，主要就是下面表格里这几类。需要先说明的是，这些参数都是公开资料的参考值，不同批次、不同软件栈版本下实际表现会有波动，具体以你租到的那台机器的官方参数为准。
| 厂商 | 型号 | 显存参考 | 软件栈/适配路线 | 常见租用场景 |
|---|---|---|---|---|
| 华为昇腾 | Ascend 910B | 约64GB HBM | CANN + torch_npu | 大模型推理、LoRA微调 |
| 华为昇腾 | Ascend 910C | 新一代HBM | CANN + torch_npu | 大模型推理、部分训练 |
| 寒武纪 | 思元590 | 96GB | CNToolkit + PyTorch适配 | 训练、微调、多模态 |
| 海光 | 深算三号（DCU） | 约64GB | ROCm兼容路线 | CUDA代码迁移、推荐系统 |
| 摩尔线程 | MTT S4000 | 48GB | MUSA | 推理、渲染 |
| 沐曦 | 多款产品 | 不等 | 自研工具链 | 推理、科学计算 |
华为昇腾在国内租用市场里属于成熟度最高的一档。910B的HBM显存容量和带宽都是为AI设计的，PyTorch的适配层torch_npu已经能覆盖多数常见算子，MindIE推理引擎也把vLLM的很多能力扩展到了昇腾上。910C在2025年逐步放量以后，租用平台很快跟进，我在实测里能明显感受到推理吞吐比910B强一档。
寒武纪思元590的记忆里最让我印象深刻的点就是96GB显存。大模型微调阶段，显存就是生命线，96GB意味着17B参数模型全量微调也能有更大的余量，不用一上来就想着量化。它的训练侧适配一直在更新，PyTorch生态里已经有不少成功案例。
海光深算走的是ROCm兼容路线，等于说大部分本来在AMD卡上能跑的ROCm算子，在海光DCU上也能跑。这对于有CUDA代码迁移需求的团队比较友好，毕竟从CUDA搬到ROCm的动作比从CUDA搬到CANN要小。
摩尔线程的MTT S4000主打推理场景，48GB显存对于14B以下模型做INT4/INT8量化推理很够用。它的问题不是卡本身，而是生态年轻，遇到不在MUSA算子覆盖范围内的操作就可能要走CPU回退。租来做小模型推理是划算的，做大规模训练还不太建议。
2.2 推理、训练还是微调：不同负载怎么选卡
很多朋友第一次接触国产算力，上来就问“哪家最强”。这个问法其实不严谨，因为不同负载对算力的要求完全不同，不存在一张卡通吃所有场景。
如果主要做推理，比如开源对话模型、Agent服务、RAG应用，我建议优先考虑昇腾910B或910C。推理场景吃的是显存带宽和推理引擎的适配程度，昇腾的MindIE和vLLM适配在国产卡里做得最早，社区资料也最多。跑一个14B模型，用bf16精度部署，910B通常能跑得比较顺滑。
如果要做微调，寒武纪思元590会是个更稳的选择。96GB显存可以让你在不触碰量化的前提下，用LoRA甚至部分全量参数训练的方式把模型跑起来，省去很多因为量化带来的精度调试问题。昇腾910B也能微调，但需要在batch size和序列长度之间做更多妥协。
如果目标是快速把一段CUDA代码迁到国产平台验证效果，海光深算DCU的迁移成本最低。ROCm生态里有不少现成工具，PyTorch官方也维护了ROCm版本，代码迁移主要处理的是库接口差异。如果你手头有一套本来在AMD卡上跑通的代码，海光几乎是无痛迁移。
轻量级推理，摩尔线程是性价比选择，但对它的生态要有一点心理准备。跑开源社区里已适配过的模型，比如某些专门做MUSA适配的ChatGLM分支，表现还可以；一旦遇到需要自己写算子的冷门模型，就比较痛苦。
3. 租用之前必须搞懂的软件栈差异：不是插上CUDA就能跑
3.1 CUDA不是通用标准：各家加速卡有各自的“语言”
这是国产GPU租用里最容易被误解的一环。很多人以为国产卡只是性能和NVIDIA卡有差距，软件层面应该是通用的，于是拿到实例第一件事就是pip install torch，运行报错以后再开始怀疑人生。
实际上CUDA是NVIDIA的闭源生态，别的厂商没法直接让CUDA程序跑在自己的硬件上。所谓兼容，都是通过翻译层或者适配层实现的。我用一个比喻来解释：CUDA是英语，国产卡各自是日语、德语、法语，适配层就是翻译。常见的工作指令翻译得很利索，但遇到方言、俚语、专业冷门词汇，翻译就卡壳了。模型代码里一个不常见算子没有被适配层收录，整段代码可能就回退到CPU执行，性能直接崩掉。
所以租国产GPU之前，先问自己三个问题：我用的模型框架是什么？这个框架对我要租的卡有没有官方适配版本？模型里有没有冷门算子？这三个问题比卡本身的浮点算力数字重要得多。
3.2 从PyTorch到国产卡的四条路线
目前让一个PyTorch模型在国产GPU上跑起来，主要就四条路。
第一条是用厂商提供的算子库和对应适配层，比如昇腾的CANN+torch_npu、寒武纪的CNNL、摩尔线程的MUSA。这是最常用也最推荐的路线，因为厂商会持续维护算子覆盖，遇到问题时能查到官方文档。
第二条是走ROCm兼容。海光深算和部分AMD卡共用ROCm软件栈，PyTorch官方发布的ROCm版本可以直接用在上面。这条路的好处是你不需要专门找“国产专用”的PyTorch，用标准的pytorch-rocm构建即可。
第三条是用推理引擎来绕开训练框架复杂适配。比如vLLM、MindIE、SGLang这些推理框架，已经对昇腾等国产卡做了专门支持。你用vLLM启动一个模型服务，框架内部自己处理算子和显存分配，对开发者来说黑盒程度高很多，少操很多心。
第四条是用国产原生框架，比如昇腾生态里的MindSpore、百度飞桨PaddlePaddle。如果模型本来就是用这些框架训练的，那在对应国产卡上几乎是原生适配，兼容性最好。缺点是如果你手里的模型权重是PyTorch格式，要先做一次格式转换。
对绝大多数人来说，最优路线是先看推理引擎和适配层能不能解决问题，解决不了再考虑迁移框架。
3.3 为什么平台预装镜像能省掉一整天
我自己踩过无数次环境坑之后，终于明白了为什么奇点算力这类租赁平台会把预置镜像当作卖点。因为国产卡的软件栈版本兼容关系非常严格，驱动、固件、CANN版本、torch_npu版本、Python版本、PyTorch版本，这六个东西必须精确匹配，差一个版本号都可能启动失败。
以昇腾为例，CANN 8.0对应torch_npu 2.1，CANN 8.1可能对应torch_npu 2.2。你如果直接在官方PyTorch镜像里pip install torch_npu，大概率会因为CANN版本不匹配直接跑不起来。平台预置镜像的核心价值，就是把这些版本关系已经调试好了，你拿到手只有一个干净的conda环境，torch_npu.npu.is_available()直接返回True。
有人觉得预置镜像是“省事”，我用过之后感觉更准确的说法是“把复杂度隔离了”。真正需要自己编译CANN算子或者手动排查版本冲突的场景，本来就不是普通项目该承担的。
4. 实战：从SSH登录到在国产GPU服务器上跑通大模型推理和微调
4.1 第一步：租实例与连接服务器
现在主流的国产算力租赁平台流程都差不多：注册账号、实名认证、选择实例配置、按小时付费开通。选配置时注意看两点，一是加速卡型号和数量，二是是否预置了你需要的大模型镜像。如果你完全是个新手，直接选带“PyTorch+昇腾/CANN”标签的镜像，比自己从裸操作系统开始装省太多时间。
拿到实例IP和登录密码以后，推荐直接用SSH连接：
bash复制ssh root@<服务器IP>
登录后第一件事不是跑模型，而是先确认你到底拿到了什么环境：
bash复制npu-smi info
这个命令的作用相当于NVIDIA机器上的nvidia-smi，能看到当前有几张NPU卡、每张卡的显存占用和温度，也能看到驱动版本。如果输出正常，说明底层硬件没问题，继续第二步。
4.2 第二步：验证PyTorch是否真正用上了NPU
有了预置镜像以后，验证环境只需要四行命令：
bash复制conda activate npu_env # 具体名字看镜像说明
python -c "import torch"
python -c "import torch_npu"
python -c "print(torch_npu.npu.is_available())"
输出True，说明PyTorch已经能正确识别NPU，可以直接开始跑模型。这一步看着简单，但它是整个国产算力使用的分水岭：在没踩过坑的人眼里这只是个布尔值，踩过坑的人知道这意味着驱动、固件、算子库、适配层、框架版本全都对齐了。
如果输出False，最常见的原因是conda环境没激活对，或者激活的环境里装的torch_npu和当前CANN版本不匹配。先不要急着卸载重装，去平台文档里找对应镜像的环境说明，看哪个conda环境是官方验证过的。
4.3 第三步：跑通大模型推理
环境准备好以后，推理部署就快多了。以昇腾910B上部署Qwen2.5-7B为例，如果平台镜像里预装了适配昇腾的vLLM，启动流程和NVIDIA机器几乎一样：
bash复制conda activate npu_env
vllm serve Qwen/Qwen2.5-7B-Instruct \
--dtype bfloat16 \
--max-model-len 8192
需要注意，这里用的vLLM不是官方主分支，而是昇腾适配分支或者内置了昇腾后端的版本，这也就是为什么预置镜像重要，因为版本已经帮你选好了。
启动成功以后，可以用一个简单的Python请求做测试：
bash复制curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{"model": "Qwen/Qwen2.5-7B-Instruct", "prompt": "你好，介绍一下你自己", "max_tokens": 200}'
如果返回正常的文本结果，说明推理链路已经通了。我个人经验是：跑通这一步以后，记得顺手测一下并发吞吐，比如用简单脚本发20个并发请求，看看耗时和显存占用，这样你就知道这台机器大概能支撑什么量级的线上服务。
4.4 第四步：7B模型的LoRA微调
微调比推理麻烦不少，但也是不少团队租国产卡的核心诉求。这里我以昇腾上跑LoRA微调为例，因为这套流程我实际走过。
最稳妥的方式是用LLaMA-Factory这类支持多后端的开源微调工具。在国产卡上使用它，需要先确认后端是适配昇腾的版本。如果租用的平台已经预置了相应镜像，直接执行：
bash复制llamafactory-cli train \
--model_name_or_path Qwen/Qwen2.5-7B \
--stage sft \
--finetuning_type lora \
--dataset alpaca_zh_demo \
--output_dir ./qwen7b_lora \
--per_device_train_batch_size 2 \
--gradient_accumulation_steps 8 \
--learning_rate 2e-4 \
--num_train_epochs 3.0
这里面有几个参数值得展开说。per_device_train_batch_size设成2，是为了在7B模型bf16精度下不爆显存；gradient_accumulation_steps设成8，相当于用8个小batch合成一个大batch，保持训练稳定性的同时降低单次显存峰值。如果你手上的卡显存小，比如只有48GB，建议把模型加载时的精度改成int8，或者开启gradient checkpointing，代码里加一行--gradient_checkpointing True，用额外计算量换显存空间。
如果租的是寒武纪思元590，96GB显存跑7B LoRA会从容很多，batch size可以提到4甚至6。需要留意的是，不同加速卡的分布式通信库不一样，昇腾用的是HCCL，寒武纪有自己的CNCL，如果之后要上多卡训练，这几个通信库怎么选也要提前确认好。
5. 排障记录：驱动版本、算子兼容与SSH断连这些坑是怎么一个个填上的
5.1 坑一：CANN/torch_npu版本对不上，NPU直接不可用
我在昇腾机器上遇到最无语的一次报错，是torch_npu.npu.is_available()返回False，同时终端打印一大串AclExec相关错误。排查过程其实不复杂，但很费时间。
先用npu-smi info -t board查看驱动和固件版本，再查看当前conda环境里torch_npu的版本号：
bash复制pip show torch_npu
对比昇腾官方给出的适配矩阵以后发现，我的CANN已经被平台升到了新版，但conda环境里还是旧版torch_npu，两者不兼容。解决方案是把torch_npu升级到和CANN匹配的版本：
bash复制pip install torch_npu==对应版本号
这个坑的本质是国产卡软件栈的“全链路一致性”要求比NVIDIA高得多。NVIDIA的驱动和CUDA版本切换相对灵活，昇腾的CANN、驱动、torch_npu三者之间是强绑定关系。所以结论是：在国产算力平台上，永远不要单独升级其中一个组件，要升级就整个镜像一起换。
5.2 坑二：算子不支持导致模型回退CPU，性能慢到怀疑人生
有一次我把一个在A100上正常跑的模型切到昇腾上，显存占用看着正常，但每token生成速度慢到无法接受。开始以为是驱动问题，折腾半天才发现是模型里用了一个比较冷门的自定义算子，CANN适配层没覆盖，框架默默把包含这个算子的整段计算丢回了CPU执行。
排查这类问题最有效的方法是看profiling输出。昇腾自带的分析工具可以导出每个算子在NPU或者CPU上的执行时间分布，一眼就能看出来哪些算子没有落到NPU。看到某个算子标记为CPU执行后，去昇腾算子清单里查是否支持，不支持就找替代实现。很多国产卡适配过的模型分支，比如社区里改好的ChatGLM、Qwen脚本，核心工作往往就是替换这些不兼容算子。
这个坑提醒我：用国产卡跑模型之前，先查一下目标模型有没有厂商或社区验证过的适配版本，比自己从零开始撞算子省心得多。
5.3 坑三：显存OOM，以及降低GPU占用的几种方案
国产卡显存没有NVIDIA大卡那么好说话，尤其是48GB档位，跑13B模型稍微调大batch就会OOM。我整理了自己常用的几种降显存方案，按优先级排序：
第一是量化，模型加载时用bitsandbytes或AutoGPTQ把权重压到INT8或者INT4，显存占用直降一半以上，推理场景影响很小。第二是gradient checkpointing，微调时不用保存所有中间激活值，用的时候重新算一遍，显存跟计算时间交换。第三是减小batch size和序列长度，看似简单但很多人就是没调整。第四是模型并行或者流水线并行，多张卡分担一层或者一段模型，适合单卡放不下的模型。
如果跑的是推理服务，还可以用vLLM自带的分块KV cache机制，它本身就降低了对显存峰值的需求。
5.4 坑四：SSH断连让训练中断，vscode远程连接也不稳定
长期训练最怕的事情就是夜里跑了一半，突然SSH断开导致进程被杀。我在国产卡上遇到过两次，一次是本地网络波动，一次是服务器端的空闲超时。
最直接的解法是用tmux托底。训练命令在tmux会话里跑，就算SSH断开，进程在服务器端依然活着，重新连接以后tmux attach就能回去。
bash复制tmux new -s train
训练命令放进去以后，按Ctrl+b再按d脱离会话，随时可以用tmux attach -t train回来。
如果是vscode Remote-SSH频繁断连，可以在本地~/.ssh/config里加两行保活配置：
text复制Host *
ServerAliveInterval 60
ServerAliveCountMax 10
每60秒发一次心跳包，这样本地网络波动就不会马上触发会话断开。另外建议不要直接在vscode终端里起训练任务，vscode的终端和本地SSH客户端相比有更多中间层，稳定性差一些。
6. 平台视角：奇点算力们的2026年机会在哪里
6.1 国产算力的“碎片化”反而成就了租赁平台
国产GPU市场最突出的特征就是碎片化：硬件厂商多，软件栈各不相同，适配版本参差不齐。对用户来说，这种碎片化是一种巨大的认知负担；但换一个角度看，碎片化恰恰是租赁平台存在的最大理由。
用户不想知道CANN和CNNL有什么区别，不想研究HCCL还是CNCL，用户只想开一台机器，把模型跑起来。平台方如果把所有碎片化的适配工作集中处理掉，给用户提供一个统一入口和几套验证过的镜像，那这层服务本身就很有价值。奇点算力如果我理解没错的话，走的就是这条路：不强调自己有多少卡，而是强调把这套复杂的国产算力环境封装好，让用户以更低成本用起来。
我更愿意把这类平台理解为国产算力生态的“集成商”，做的是华为、寒武纪，以及下游用户之间的翻译层。这个角色在前几年纯卖硬件的时代不存在，因为那时候国产卡的用户主要是能做深度适配的大机构，不需要中间层。现在用户群体扩展到中小开发者和AI创业团队以后，集成商的价值才开始体现。
6.2 平台接下来的竞争点：不是便宜，是“跑得通”
2026年如果国产GPU租用平台开始互相卷价格，我觉得会是一个误区。因为国产算力的瓶颈从来不是单价贵不贵，而是跑不跑得通、跑起来之后稳不稳定。平台囤一堆卡但用户开机以后报错，再便宜也没人会续费。
平台真正的差异化应该在三个方向。第一是模型库的丰富度，预置的主流开源模型越多，用户开箱即用的概率越大。第二是适配效率，一个新的开源模型发布以后，平台多久能出一个在该家国产卡上验证过的镜像，这个响应速度很关键。第三是排障支持，普通用户卡在一个算子不兼容的报错里，如果没有平台侧的工程师帮忙定位，可能永远走不下去。
如果你打算在2026年用国产算力做正经项目，我看平台的标准就两个字：可复现。平台上跑通的东西，你拿到本地或者其他平台也能按文档复现出来，这就说明人家的环境封装是干净的。
6.3 我对2026年国产GPU租用趋势的几点判断
第一，推理租用会成为绝对主流。随着开源模型越来越多，很多应用团队只需要部署推理服务，不需要从零训练。推理场景对软件栈的要求相对可控，国产卡完全能承接，价格也比NVIDIA卡有优势。
第二，微调需求会快速上升。模型底座不再需要自己训练之后，微调就是最有价值的定制手段。国产卡在微调场景的适配会越来越成熟，尤其是LoRA这类参数高效微调，对算力要求不高，显存够用就能跑，正好卡位国产卡的能力区间。
第三，混合算力会成为常态。一个团队可能前几轮实验用NVIDIA卡做基准，后面大规模推理切到国产卡降低成本；也可能模型训练用NVIDIA，推理服务全部放在昇腾上。租用平台的弹性正好支持这种混合使用方式，而且很多平台已经开始做跨品牌任务调度了。
第四，价格会继续降，但不会崩盘。国产算力的成本优势是结构性的，不是单纯补贴烧出来的。随着上机率提升和运维自动化程度提高，平台有能力把价格逐步做到比NVIDIA实例低三到五成的水平。这个价格区间会让更多个人开发者和早期项目愿意尝试。
我个人在实际项目里的体会是，2026年讨论的不再是“国产卡行不行”，而是“怎么把国产卡用得更聪明”。先花几个小时在租赁平台上跑通一个7B推理，再选一块适合的卡做一次LoRA微调，你对国产算力的理解会完全不一样。踩过几次坑以后就会明白，国产GPU租用本质上不是NVIDIA的替代品，而是一个让算力成本继续下降、让更多人有条件做AI实验的新选择。