1. 全链路适配到底在解决什么问题
1.1 为什么我选了沐曦曦云C500
聊到国产GPU跑大模型，很多人的第一反应还是“生态不行、算子不全、跑不通”。我最早也是这个心态，直到在真实业务里接触了沐曦曦云C500，才发现这代卡和之前的“PPT显卡”已经完全是两回事了。它是一块面向数据中心和智算场景的GPGPU，单卡显存64GB，支持FP16、BF16这些大模型训练常用的精度，功耗和尺寸也符合标准PCIe服务器插槽，对于我们这种既要自建集群、又不想绑定单一新架构的团队来说，是很自然的候选对象。
但硬件参数只是一个起点。真正让我下单采购的原因，是沐曦在软件栈上把“全链路”这件事认真做了，从开发环境、训练调度、推理服务到网关入口，CubeStudio相当于把整条生产线都给你搭好了。我之前跑其他国产加速卡时，最痛的还不是贵，而是“模型代码切过来就报算子不支持”“跑起来只能单卡不能多卡”“训练好了想上线推理，又要重新写一套服务”。C500配合CubeStudio，至少让我看到了一个可以完整交付的路径：开发、训练、推理、网关全链路打通，而不是只给你一块卡然后剩下全靠自己搓。
1.2 CubeStudio在整条链路里到底扮演什么角色
一句话概括：CubeStudio是沐曦生态里的“一站式AI开发与交付平台”。它不是一个单独的运行时，也不是简单的容器管理工具，而是把开发、训练、微调、推理、服务发布整合成了一个统一工作流。你可以在里面建项目、写代码、跑Jupyter Notebook、提交训练任务、看日志、做模型版本管理，再把模型发布成一个带鉴权和负载均衡的在线推理服务。
从我实际的体验来看，最值钱的部分还不是某个单点功能，而是“约定优于配置”：平台默认帮你做好驱动适配、容器镜像、资源配额和网络配置。团队里的算法工程师不需要关心底层驱动和卡调度，只需要选择一个带好PyTorch版本的镜像，代码里指定设备，就能把原本在NVIDIA卡上跑的脚本平滑地迁过来。对于管理者来说，多卡训练的资源分配、推理服务的弹性伸缩、网关入口的流量管理，都能在同一套系统里看到，省掉了多套系统拼盘的麻烦。
所以这篇文章我想按一条真实项目推进的顺序，完整记录我用沐曦C500跑大模型全流程的实操过程。从环境初始化开始，到开发调试、分布式训练、推理部署，再到网关发布，每一步都给出我踩过的坑和现在沉淀下来可用的配置。如果你所在团队正在评估国产GPU，或者已经拿到C500但不知道从哪下手，这篇文章应该能帮你省掉一个多月的试错时间。
2. 初始化环境：三步装好驱动和运行时
2.1 硬件、操作系统和前置软件的基本要求
先把硬性条件列清楚。曦云C500是一块PCIe接口的主动散热GPU，适合标准机架式服务器，供电走PCIe 8pin或12VHPWR，具体看卡上的供电接口。我这边使用的主板是常见的双路Xeon平台，BIOS里需要把Above 4G Decoding和Resizable BAR开启，否则高版本内核的驱动加载可能会异常。
操作系统我推荐Ubuntu 20.04或22.04 LTS，内核版本只要保持在5.4以上基本没什么问题。如果是CentOS系，尽量用8.0以上版本。更关键的是确认服务器没有安装其他品牌的GPU驱动，至少在新卡驱动的设备节点上不要冲突。另外，因为CubeStudio本身基于容器和Kubernetes体系，所以我预先装了Docker、Kubernetes相关命令行工具，并把节点加入一个测试集群。当然，如果只是单机跑，不装K8s也能开工，但后面要上网关和弹性伸缩，集群化是更省心的路线。
安装前建议把所有数据盘和系统盘分区规划好。大模型训练和推理缓存最吃的是磁盘IO，模型权重动辄几十GB，如果放在普通机械盘上，加载一次等十几分钟很正常。我的做法是给/opt/mxdata单独挂一块NVMe SSD，所有模型、数据集、日志都放到这个路径下，避免根目录被撑爆。
2.2 安装驱动与容器运行时，别忘了校验设备节点
驱动的安装过程其实不复杂，难题主要在“别装错版本”。沐曦官方提供的驱动包一般是一个.run或.tar.gz，解压后会看到install.sh脚本。执行前先确认平台架构和内核头文件是否匹配，否则编译模块的时候直接报错。
安装命令大致是这样：
tar xzf MXDriverPackage.tar.gz cd MXDriverPackage sudo ./install.sh --prefix=/usr/local/mxdriver驱动装完之后，最关键的一步是确认设备节点是否正常产生。不同版本的驱动工具名可能不一样，可能是mx-smi，也可能是metax-smi，以节点上实际命令为准。执行后看到类似下面的输出，就说明驱动层没问题：
mx-smi +-------------------+-------------------+ | Device 0 | Device 1 | +-------------------+-------------------+ | Name: MX C500 | Name: MX C500 | | Memory: 64GiB | Memory: 64GiB | | Utilization: 0% | Utilization: 0% | +-------------------+-------------------+接下来是容器运行时。国产GPU的容器方案通常不是直接把设备挂载进标准Docker，而是通过驱动里自带的Container Runtime Hook来实现。你需要在Docker配置里启用对应的runtime，并确保Container Runtime 的二进制路径和驱动安装路径一致。这一步如果配置不对，后面用docker run --runtime=mx拉容器时会提示找不到设备。
注意：设备文件在宿主机上的位置通常是
/dev/mx*一类，不是常见的/dev/nvidia*。做故障排查时不要拿NVIDIA的习惯去套。
2.3 拉取CubeStudio基础镜像并跑通冒烟测试
CubeStudio安装完成后，平台会提供一个带PyTorch的基础镜像。第一次拉取镜像可能有点慢，建议先配置好容器镜像加速，或者在局域网内搭一个私有镜像仓库。下面这个命令可以用来验证GPU是否能在容器里正常访问：
docker run --rm --runtime=mx --gpus all \ registry.cubestudio.local/ai-base:pytorch-2.1-mx \ python -c "import torch; print('GPU count:', torch.cuda.device_count())"注意这里虽然代码里写的是torch.cuda，但在国产卡上通常是通过厂商提供的兼容层把设备映射成了CUDA类接口。实际Pytorch版本可能是厂商定制过的，也可能是通过插件方式支持。跑通这个冒烟测试后，我习惯再跑一个简单的矩阵乘法，确认计算子系统和显存都没问题：
import torch a = torch.randn(1024, 1024, device='cuda') b = torch.randn(1024, 1024, device='cuda') c = torch.matmul(a, b) print(c.sum().item())如果这一步能输出一个数值而不是报错，说明你的环境已经具备跑大模型的基础条件。到这里，硬件层和容器层就绪，接下来可以进入开发环节。
3. 开发与模型迁移：把旧代码改到C500上
3.1 设备名与张量迁移的正确写法
很多团队拿到新卡后问的第一个问题是：我的PyTorch代码要怎么改？如果只是改device = 'cuda'，在兼容层做得比较完善的情况下确实能跑，但我不建议这么粗暴。更好的做法是把设备抽象成一个配置项，同时把原有的CUDA专属依赖拆出来。
推荐在代码开头做一次统一设置：
import os import torch DEVICE = os.getenv("MX_DEVICE", "cuda") torch.cuda.set_device(int(os.getenv("MX_DEVICE_ID", "0"))) model.to(DEVICE)如果你的脚本里有类似torch.backends.cudnn.benchmark = True的语句，在沐曦平台上也建议保留，因为兼容层会把它映射到对应的底层加速库。但要注意部分高阶API不一定有一一对应关系，比如torch.cuda.amp.GradScaler，厂商适配版一般会支持，但如果你在源码里直接引用了torch.version.cuda并据此判断是否使用AMP，就会在国产卡上得到一个奇怪的结果。判断计算能力的正确方式应该是看当前环境下算子库是否支持混合精度，而不是死盯CUDA版本号。
迁移代码时我还总结了一条经验：先把模型参数初始化和前向推理跑通，再碰训练循环。因为前向推理能验证算子覆盖度，而训练循环里混入了反向传播、梯度累加、分布式通信，一旦报错很难定位。
3.2 常见算子的兼容性检查与替换建议
虽然沐曦的算子库对原生PyTorch算子覆盖度已经很高，但大模型里总有几个算子容易出问题。我实际遇到过的问题主要集中在以下两类：
- 自定义CUDA Kernel（尤其是FlashAttention这类需要写底层kernel的算子）。这种算子没法直接在非N卡上跑，需要替换成厂商适配的高性能实现，或者在兼容层里找到映射版本。
- 某些Transformer组件里的
torch.nn.functional.scaled_dot_product_attention，不同PyTorch版本实现路径不同，需要确认当前镜像是否走的是加速实现。
我给的调试思路是：在训练前先用一个小的随机张量跑一次相同配置的前向，把报错算子所在的模块打印出来。比如：
from torch.utils.collect_env import collect_env print(collect_env())另外，可以把模型切到芯片规格要求的最小输入（比如batch_size=1、seq_len=64）做一次全前向，即使业务上不会用到这么小的尺寸，至少能快速扫出算子兼容问题。一旦遇到不支持的算子，优先去CubeStudio内置的算子清单里查有没有替代实现。如果确实没有，就用纯PyTorch原语重写该模块，虽然性能可能差一点，但能保证链路通起来。
3.3 用一个小规模模型完成开发冒烟
在正式微调8B模型之前，我强烈建议先用一个几十M的小模型把开发链路完整走一遍。这里说的“完整”，指的是数据加载、模型初始化、前向、反向、优化器更新、日志上报这几个步骤全部过一遍，而不是只跑个前向就完事。
我当时用BERT-base做冒烟测试，配置大概是这样：
- batch_size 32
- seq_len 128
- 优化器 AdamW
- learning rate 2e-5
- 训练步数 100
跑完这100步，至少要确认三点：loss有下降趋势、GPU利用率能跑到60%以上、显存没有被异常吃满。如果这里的任何一步过不去，先不要急着上大模型，因为大模型只会把这些基础问题放大。
我在这个阶段还养成了一个习惯：把容器内的Python环境导出一份requirements列表，单独保存一份到代码仓库。因为CubeStudio镜像升级后，依赖版本很可能会变导致结果复现不了。有了一份锁定的依赖，后续排查问题会轻松很多。
4. 训练实操：Llama 3.1 8B 微调的完整配置
4.1 全参微调还是LoRA，资源约束下的选型
沐曦C500单卡64GB显存，理论上一张卡就能跑Llama 3.1 8B的全参微调。但注意全参微调不仅吃显存，还吃显存带宽和训练稳定性。批量稍大一点，显存和通信压力都会上来。我个人的建议是：如果你希望尽快看到业务效果，优先上LoRA/QLoRA，把显存留给更大的batch size和更长的上下文；如果你确实需要全参数调整，再评估多卡并行方案。
下面是我的资源评估逻辑：
- 8B模型权重在FP16下约16GB，全参微调时每张卡还需要保存梯度、优化器状态和激活值。用AdamW优化器时，梯度加状态大约是参数量的12到16倍开销，单卡总需求很容易超过48GB。这意味着单卡全参微调虽然理论可行，但batch size会被压得很小，训练效率未必高。
- LoRA微调时冻结原模型，新增参数量通常不到1%，反向传播只需要计算LoRA分支的梯度，激活值依然占大头，但整体显存压力能下降30%以上。
- 如果目标是让模型学会某种风格或格式，LoRA的效果已经足够；如果要做领域知识的深度增强，全参微调的效果会更好，但前提是你有足够的算力和时间。
最终我采用的是4卡LoRA微调，这样既能利用多卡并行缩短训练时间，又不需要改动太多代码。
4.2 在CubeStudio中提交训练任务的关键参数
CubeStudio的训练任务界面本质上是一个“容器启动参数生成器”。你填好镜像、资源、启动命令后，平台会帮你拉起一个分布式训练Pod。我第一次提交任务时踩了个坑：平台默认只请求了1张卡，分布式训练脚本一跑就报“world size mismatch”。所以要先把资源配额和并行组设置好。
以4卡为例，训练启动命令大概是这样的：
torchrun --nproc_per_node=4 \ train_lora.py \ --model_name /opt/mxdata/models/llama-3.1-8b \ --data_path /opt/mxdata/dataset/alpaca_zh.json \ --output_dir /opt/mxdata/output/llama31-lora \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 16 \ --learning_rate 2e-4 \ --lr_scheduler_type cosine \ --logging_steps 10 \ --save_steps 200 \ --gradient_checkpointing \ --bf16 True关键参数我解释一下：
per_device_train_batch_size设成2，是因为8B模型即便用LoRA，激活值依然很大。4卡一共8的等效batch size，再配合梯度累积16步，每次实际更新用到的样本数是128。gradient_checkpointing必须开，它是在用少量重复计算换显存，能显著降低激活值占用，代价是训练速度下降15%到20%。如果显存还紧张，可以配合gradient_accumulation_steps再加大累积倍数。bf16 True是选择训练精度。C500上BF16的数值范围比FP16更适合大模型，不容易出现loss不稳。
这里有个计算经验：batch size × 梯度累积步数 = 单次更新可见样本数。很多人只知道这个公式，但没意识到梯度累积步数设置过大（比如超过64）会让模型收敛变慢且波动变大。实际调参时，我一般把单次更新样本数控制在128到512之间，然后在这个范围内找显存和收敛速度的平衡点。
4.3 混合精度与分布式策略的实际效果
训练开始后，首先通过日志确认每个rank是否正确绑定了对应的GPU。如果出现“rank 0 uses GPU 0, rank 1 uses GPU 1”等字样，说明通信组已经建好。接着要注意观察loss曲线。LoRA微调时，初始loss一般会略低于预训练模型的原始loss，因为很多数据任务比预训练语料简单。
在4卡场景下，LoRA + DeepSpeed。虽然现在的代码不一定需要显式配置DeepSpeed，但如果你用torchrun启动，并且模型来自HuggingFace Transformers，建议开启DeepSpeed ZeRO Stage 3，把模型参数、梯度和优化器状态切分到多张卡上。C500的NVLink或PCIE互联在多卡训练时直接决定通信效率。我实测下来，4卡场景如果走PCIe通道，通信占比大约在10%到15%；如果是高速互联，能压到5%以内。所以组建多卡训练时，尽量选主板和拓扑支持高带宽互连的方案，否则4卡并行可能跑不出2倍的加速比。
混合精度方面，bf16是我强烈推荐的默认选项。FP16在大模型里常碰到loss溢出，而BF16几乎不会。不过要确保CubeStudio镜像里的优化器内核支持BF16的混合精度缩放，否则会出现“梯度裁剪失效”这类隐藏问题。做法很简单：看训练日志里是否有“Gradient scaling”相关告警，如果有，就把bf16改成fp16并加一个初始缩放因子试试。
4.4 训练过程中的监控与调优记录
训练过程中的监控我分三层看：
- 第一层是物理层，看GPU利用率、显存、温度、功耗。推荐在CubeStudio监控面板里设置告警，比如显存超过90%或GPU温度超过85℃就通知。
- 第二层是性能指标，看每步耗时和吞吐量。8B模型在4卡C500上做LoRA，较长上下文（2048 tokens）下每步耗时如果能稳定在2秒左右，说明算力利用得还行。
- 第三层是训练质量，看loss和梯度范数。如果loss不降或收敛很慢，优先检查学习率和数据预处理，不要急着怀疑硬件。
有一次我训练时发现四张卡里三张利用率只有40%，只有一张在90%左右。查了一圈发现是数据加载的num_workers设置成0，导致DataLoader把预处理任务全压在了主进程上。把num_workers改成8之后，四卡利用率立刻拉齐。这类问题在N卡上也会有，但在新平台上更容易被误判成“适配不行”。
最后，训练结束不要急着发布模型，先把LoRA权重合并回基础模型，再跑一组测试集，确认没有出现灾难性遗忘。我用HuggingFace的peft库合并权重后，会自动生成一个合并后的模型目录，记得把这个目录单独归档到模型仓库，后续推理部署直接拉这个归档就够了。
5. 推理部署：从权重导出到高性能服务
5.1 模型导出与量化，哪些钱值得花
训练完的模型要上线推理，第一步是决定继续用PyTorch原生模型，还是导成更轻量的格式。如果只是内部使用，直接用原生PyTorch加载喂给一个FastAPI服务也能跑；但如果要支撑线上并发，就得考虑推理框架层做连续批处理和显存管理。
我在C500上优先走的是vLLM的适配版本。启动推理服务时，可以直接指定合并后的HuggingFace目录，也可以先把模型导出成SafeTensors格式再加载。后者能加快冷启动速度，并且避免PyTorch的版本兼容问题。导出命令可以用以下方式：
from transformers import AutoModelForCausalLM model = AutoModelForCausalLM.from_pretrained("/opt/mxdata/models/llama31-lora-merged", torch_dtype="auto") model.save_pretrained("/opt/mxdata/models/llama31-final", safe_serialization=True)关于量化，我建议视显存和并发要求分场景处理。C500有64GB显存，8B模型完全不需要AWQ/GPTQ 4bit量化，直接用FP16/BF16就能跑得很稳。如果业务方要求更高的并发吞吐，可以做8bit或4bit量化，但一定先在评测集上跑一遍精度对比。我见过不少团队为了省显存把模型量化到4bit，结果业务指标掉了一截，最后只能回滚。
5.2 启动推理服务时的关键参数设置
在CubeStudio里启动推理服务，本质上也是拉起一个常驻容器，并暴露一个内部Service端口。我用的vLLM启动参数大致如下：
python -m vllm.entrypoints.openai.api_server \ --model /opt/mxdata/models/llama31-final \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --port 8000这里的tensor-parallel-size需要特别说明：不是显存不够就一定要设成2。把模型切到两张卡，会增加一层通信开销。如果一张卡能装下模型且并发要求一般，就别用多卡推理；只有单卡显存装不下，或者单卡吞吐确实成为瓶颈时，才值得上张量并行。
gpu-memory-utilization设置成0.9的意思是允许推理框架最多占用90%的显存，剩下10%留给算子临时缓冲和碎片化开销。这个值不能设成1.0，否则高并发时大概率OOM。第一次上线时，我建议保守一点设成0.85，跑一天看峰值再往上调。
启动完成后，可以发一个/v1/completions请求简单验证：
curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"/opt/mxdata/models/llama31-final","messages":[{"role":"user","content":"你好，介绍一下你自己"}],"max_tokens":128}'5.3 性能测试与batch策略调整
推理服务上线前，必须做压力测试。我用的是简单的Python脚本，模拟10个并发用户，连续发30分钟请求，观察三个指标：首token延迟、生成token速率、GPU利用率。
实测之后发现，如果不对max-token做限制，长回答会占用很长的时间片，导致并发用户排队。解决方式是在业务侧限制max_tokens，把几百字和几十字的请求分开调度。vLLM这类框架支持连续批处理，它会在一个batch内的生成结束后立刻插入新请求，所以请求长短混跑反而更高效。为了让这种调度更生效，我把应用层的超时时间设成30秒，不能让客户端一直挂起。
性能调优时还可以关注--max-num-seqs参数，这是单个批次内允许同时处理的序列数量。默认值往往偏保守，如果单卡显存有富余，可以逐步从32调到64，观察显存和延迟曲线。我最终调到了64，吞吐提升了约40%，尾延迟没有明显恶化。
6. 网关环节：把推理能力开放给业务方
6.1 网关选型与API定义
模型推理服务本身只是一个运行在集群内部的Pod，不能直接把端口暴露到公网。这里就需要网关层做统一入口。我选择的方案是APISIX + 自定义路由，也可以按团队熟悉度选Kong或Nginx，但对容器化环境来说，APISIX这类云原生网关在配置管理和服务发现上更省心。
网关层需要做的第一件事是把内部推理服务抽象成对外API。比如：
- 路径
/api/v1/chat/completions - 请求体保持OpenAI兼容格式
- 响应体也保持统一格式
这样做的好处是所有已经接入OpenAI接口的业务方，只需要把base_url从OpenAI官方地址改成你的网关地址，其他代码几乎不用动。
网关配置里我建议加入“上游超时”和“重试”两个参数。推理请求的特点是耗时长，默认HTTP超时往往不够。我把连接超时设为5秒，读取超时设为120秒，同时禁止网关自动重试POST请求。因为推理请求不是幂等的，重试一次用户会得到两个回答，体验反而更差。
6.2 负载均衡与弹性伸缩，别把请求打到僵掉的卡上
网关后面的推理服务可以部署多个副本，但要注意副本数和显存的关系。如果一张卡能扛住20路并发，你部署2个副本可能把两张卡的显存打满，却没有显著降低尾延迟。正确做法是先在网关层做并发数限制，比如单副本最大并发16，超过的请求排队等待，而不是无限放行让GPU自己崩。
弹性伸缩方面，CubeStudio支持基于GPU指标的HPA。我设置的策略是：当GPU利用率连续5分钟超过70%时，自动扩容一个副本；当利用率连续15分钟低于30%时，自动缩容。注意冷启动时间：模型文件如果在本机有缓存，拉起一个新服务大约需要20秒；如果每次都要重新从远端拉权重，可能需要两三分钟。所以我对模型目录做了持久化缓存，避免每次扩容都拉一遍几十GB的权重文件。
6.3 日志、鉴权与灰度发布
网关的另一项关键工作是鉴权。我在APISIX里启用了KeyAuth插件，业务方用预先分配的API Key访问，网关校验通过后才把请求转发给推理服务。如果业务方私密性要求高，可以再加一层JWT校验。这里要提醒一个细节：不能把鉴权只做在网关层，推理服务内部也要做一次身份校验。因为集群内部服务之间有可能绕过网关直接访问，只信网关一层会给内网攻防留下漏洞。
日志方面，我会把网关访问日志和推理服务运行日志汇总到统一的ELK或Loki，按request_id串联。用户报障“模型回答很慢”时，通过request_id就能查到这个请求在队列里等了多久、GPU生成用了多久、网关转发耗时多少。这三个时间点基本能定位大部分性能问题。
上线新模型时，我在网关层做灰度发布：先在内部路由里配置10%的流量指向新版本，跑一天观察错误率和延迟，确认平稳后再切全量。CubeStudio里模型版本支持多版本共存，回滚只需要改一下路由目标权重，很方便。
7. 常见问题与排查实录
7.1 显存OOM，到底是谁吃了我的显存
显存不足是训练和推理中最常见的问题。排查的第一步是把物理显存占用量和模型理论占用量分开看。物理显存可以通过厂商状态命令看，模型理论占用量可以用PyTorch的torch.cuda.max_memory_allocated打印。如果物理显存远大于模型申请量，说明显存碎片化或缓存占用过多。处理办法是调大PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True之类的环境变量，新版PyTorch里这种设置能明显减少碎片。
如果确实是模型需求太高，优先做三件事：开梯度检查点、缩小batch size、降低序列长度。在这之后还OOM，再考虑多卡拆分。
7.2 算子不支持，如何处理“脸红”的第一行报错
在国产卡上遇到最多的问题是某个算子没有实现。我的处理流程是：
- 通过报错信息确认是哪个算子、哪个模块。
- 去CubeStudio的算子兼容列表里搜索。
- 如果列表里没有，先用纯PyTorch原语重写该模块。
- 重写后跑一次小规模对比测试，验证输出和原实现一致。
举个例子，如果某个注意力实现调用了一个自定义CUDA kernel，而这个kernel没有C500版本，我通常会把attention切换成原生PyTorch SDPA，训练慢一点没关系，至少能继续跑下去。上线前再决定是否用厂商优化库替换。
7.3 训练速度上不去，通信瓶颈还是数据瓶颈
训练速度不达标，我先看数据加载环节。最简单的方法是把模型训练代码里的每次迭代耗时打出来，如果前几步和第二十步耗时差不多，说明数据加载正常。如果每步耗时有明显毛刺，大概率是数据加载IO和预处理卡住了。
如果数据没问题，再看通信和计算比例。开DeepSpeed的profiler日志，能看到通信算子等待耗时。如果等待超过20%，说明多卡通信是瓶颈，要么减少通信频率（比如增大梯度累积步数），要么检查物理拓扑是否跨CPU访问。我遇到过一次四张卡被分配到两个不同的PCIe switch下，跨switch通信非常慢，后来调整卡的插槽位置就解决了。
7.4 网关504超时的排查顺序
网关504是最常见的对外服务故障。我建议按这个顺序排查：
- 先看网关日志，确认请求到底有没有到达上游推理服务。
- 如果到达了，看推理服务日志，确认是否在处理后超时。
- 如果服务在处理，用状态命令看GPU利用率和显存，大概率是显存满了导致新请求排队。
有一次全员反映服务不可用，我排查到最后发现是模型推理服务因为OOM被频繁重启，而网关还在不断发新请求进来。处理办法是在网关层增加熔断，如果上游连续5个请求超时或返回5xx，自动熔断30秒，不再转发新流量，给服务一段恢复时间。
8. 最后一小段，聊聊这套链路怎么长期跑稳
我把沐曦曦云C500和CubeStudio这套组合用了几个月之后，最大的体会是“全链路打通”并不是一句宣传语，而是真的能减少团队在不同系统间的搬运工作。开发和训练在同一套镜像体系里，训练产物能直接进入模型仓库，推理服务和网关也能在同一个平台里管理，这些在NVIDIA生态里被默认认为“应该有”的能力，在国产GPU平台上其实还需要软件团队认真补齐。C500现在做到了，这才是它真正的价值所在。
如果你刚拿到C500，我的建议是先别急着上8B模型。老老实实从一个小模型开始，把驱动、容器、训练、推理、网关这套流水线完整跑一遍，再上大模型会顺利很多。卡好、工具好，也要有一份耐心。踩过前期这些坑，后面就是纯获取算力收益的过程了。
