2026-04-22 · architecture / ai-infra
【大模型基础设施工程】03：CUDA 生态——cuBLAS、cuDNN、NCCL、Triton、CUTLASS
从 nvcc 到 Triton，把 NVIDIA 软件栈的每一层拆给大模型工程师看，顺便谈谈 ROCm、CANN 为什么一直追不上。
前两篇讲了 Agent 与工具调用，本质是”应用层”。再往下一层，是支撑所有 Agent / Chat / 向量检索 rerank 的推理服务层（Serving Layer）。单机跑一个
vllm serve谁都会，但当你要同时托管 20 个模型、800 个 LoRA、每秒 2 万条请求、SLO p99 < 3s、成本要可预测，工程复杂度会陡然上升一个数量级。这一篇把”把推理引擎做成服务”这件事拆开：服务层选型（Triton / Ray Serve / KServe / vLLM OpenAI Server …）、多 GPU 拓扑、自动扩缩容、LoRA 多租户热加载、PD 分离部署、流量路由、K8s GPU 调度、Serverless GPU、国产云厂商的托管方案，以及灾备多活。
把
python -m vllm.entrypoints.openai.api_server
跑起来，和把它变成公司级推理平台，中间差的远不只是
Dockerfile。生产化至少要回答下面这些问题：
前面 11、12、13 篇关心的是”单 GPU 把 token 吐得多快”；这一篇关心的是”一整个集群能不能稳定、便宜、可维护地吐 token”。
┌───────────────────────────── Client / Agent ─────────────────────────────┐
│ OpenAI SDK · Anthropic SDK · LangChain · 业务微服务 │
└──────────────────────────────────┬──────────────────────────────────────┘
▼
┌──────────────────── LLM Gateway（下一篇 22）────────────────────────────┐
│ 多租户鉴权 · 限流配额 · 路由 · 审计 · 内容审核 · 成本统计 │
└──────────────────────────────────┬──────────────────────────────────────┘
▼
┌──────────────────── 推理服务层（本篇）──────────────────────────────────┐
│ KServe / Ray Serve / Triton / BentoML / K8s Deployment │
│ 自动扩缩 · 模型仓库 · PD 分离 · LoRA 多租户 · Session Affinity │
└──────────────────────────────────┬──────────────────────────────────────┘
▼
┌──────────────────── 推理引擎（第 13 篇）────────────────────────────────┐
│ vLLM · SGLang · TensorRT-LLM · TGI · MindIE · XServe │
└──────────────────────────────────┬──────────────────────────────────────┘
▼
┌─────────────────── 硬件底座（第 2–4 篇）────────────────────────────────┐
│ GPU · NVLink · IB/RoCE · 昇腾 / 寒武纪 / 燧原 │
└─────────────────────────────────────────────────────────────────────────┘网关（Gateway）和服务层（Serving）经常被混在一起，其实职责不同：网关关心”谁”和”多少”（身份、配额、合规），服务层关心”在哪”和”怎么跑”（拓扑、实例、KV cache、GPU）。很多团队早期放在一个进程里，规模上来一定会拆。
为了让上面 12 个问题具象化，这里复盘一次 2024 年末我们团队亲历的事故（细节脱敏）：
--enable-prefix-caching，历史 KV
无法复用。num_requests_waiting 扩容、在网关层按
input 长度拆到两个池。教训：推理服务的稳定性，80% 来自路由和拓扑的正确性，20% 才是引擎参数。
Triton 是老牌推理服务框架，设计目标是”模型无关”，支持 TensorRT、TensorRT-LLM、vLLM、PyTorch、ONNX、Python、FIL 等多个 backend。它的几个杀手级特性：
LLM 场景下，Triton 主要作为 TensorRT-LLM 的官方
server（tensorrtllm_backend）使用，适合
Nvidia
全家桶用户。缺点是配置文件（config.pbtxt）偏繁琐、Python
生态不如 Ray Serve 灵活。
目录结构示例：
model_repository/
├── qwen3-72b/
│ ├── config.pbtxt
│ └── 1/
│ └── model.plan # TRT-LLM engine
└── ensemble_rag/
├── config.pbtxt
└── 1/
└── model.py # BLS 脚本Ray Serve 是 Anyscale 出品的 Python-first 服务框架，和 Ray（任务 / 集群）深度集成。适合：
@serve.deployment +
ingress.bind(rag_chain)。缺点：对 K8s 原生语义不够好（Ray 自带集群管理），跨语言支持弱，对 SRE 团队”Ray 集群”本身是新的运维对象。
KServe 脱胎于 KubeFlow 的 KFServing，目标是在 K8s 上用标准 CRD 描述推理服务。核心资源：
InferenceService：最顶层资源，描述一个服务（transformer
+ predictor + explainer）。ServingRuntime /
ClusterServingRuntime：引擎运行时模板（vLLM、Triton、Hugging
Face TGI、TorchServe 等）。KServe 的定位类似”K8s 原生的 SageMaker Endpoint”。对大部分想在 K8s 上跑推理又不想自己写 Operator 的团队，是默认选择。下文有 YAML 示例。
Seldon Core 是 KServe 的”兄弟项目”（历史更早），也是 K8s CRD。v2 版本叫 Seldon Core v2，架构更偏流水线和多模型编排（model mesh），适合大量小模型的场景——比如几千个推荐模型。LLM 场景用得少。
PyTorch 官方的模型服务器。API 简单、对 Torch 生态友好，但 LLM 专用优化（连续批处理、Paged Attention）需要自己造或走 PyTorch / Meta 系的发行版（TorchServe + vLLM）。国内 LLM 场景很少单独用 TorchServe。
BentoML 强调”Python 开发者友好”：用装饰器把推理函数包成
Service，bentoml build 打成 OCI
镜像，bentoml deploy 到 K8s（Yatai）或
BentoCloud。对初创团队、算法同学自助上线小型服务非常友好。OpenLLM
是他们针对 LLM 的子项目，支持 vLLM / TensorRT-LLM。
这是 2024–2025 年的事实默认：直接起一个
python -m vllm.entrypoints.openai.api_server --model ...，加一个
nginx / Envoy
前面当负载均衡，就是一个”够用”的生产服务。SGLang 的
python -m sglang.launch_server 类似。
什么时候它不够用？
满足这些时就要上 KServe / Ray Serve 之类。
| 场景 | 推荐 |
|---|---|
| 单模型、快速上线、OpenAI 协议 | vLLM / SGLang 自带 server + Envoy |
| K8s 原生、标准化、需要 GitOps | KServe + vLLM ServingRuntime |
| Python 复杂 DAG、多模型组合 | Ray Serve |
| Nvidia 全家桶、TRT-LLM 重度用户 | Triton + tensorrtllm_backend |
| 算法同学自助打包 | BentoML / OpenLLM |
| 托管省心 | 云厂商（PAI-EAS / 火山 / Bedrock / Vertex） |
第 6 篇讲了训练并行策略，推理这边简单一些，但同样重要。
单节点 8×H100 SXM（NVLink 900 GB/s 互联），跑 72B、110B
模型的首选是 Tensor Parallel（TP）。vLLM
里就是 --tensor-parallel-size 8。TP
的通信模式是 all-reduce / all-gather，对 NVLink
友好，跨节点会显著掉性能（IB 200 Gbps ≈ 25
GB/s，比 NVLink 慢一个数量级）。
经验公式：
跨节点时：
典型拓扑：DeepSeek V3 671B 推理，单副本跨 2 机 16 卡
H20，TP=8, PP=2, EP=16。
同一个模型配置，多个独立副本，前面挂负载均衡——这是”水平扩容”。副本数由 QPS 决定，不由模型大小决定。
┌── Replica 1 (8×H100, TP=8) ──┐
LB ──┬────┼── Replica 2 (8×H100, TP=8) ──┤──► Clients
│ └── Replica 3 (8×H100, TP=8) ──┘K8s 默认调度器对 GPU 拓扑无感知。你需要：
nvidia.com/gpu。HPA 默认只能基于 CPU / Memory，不够。KEDA（Kubernetes Event-Driven Autoscaler） 支持 40+ 种 scaler：Prometheus、Kafka、Redis、SQS 等。LLM 场景常用：
vllm_num_waiting_requests >
阈值就扩容。DCGM_FI_DEV_GPU_UTIL。apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: vllm-qwen3-scaler
spec:
scaleTargetRef:
name: vllm-qwen3
minReplicaCount: 2
maxReplicaCount: 32
pollingInterval: 15
cooldownPeriod: 120
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus.monitoring:9090
query: |
avg(vllm:num_requests_waiting{service="qwen3"})
threshold: "8"Knative Serving 能把无流量的模型缩到 0 副本——但 LLM 推理场景慎用。模型权重几十到几百 GB，冷启动 5–15 分钟，用户第一个请求就超时了。Knative 适合：
min-scale=1）的非主力模型。这是 LLM serving 最大的工程痛点之一。一个权重 140 GB 的 Qwen3-72B，冷启动时间分解：
总冷启动 ≈ 10 分钟
├── Pod 调度 + 镜像拉取 ~60s → 镜像加速
├── 权重下载（S3 → 本地 NVMe） ~180s → 本地缓存 / pre-pull
├── 权重 mmap 到 HBM ~120s → fast loader
├── CUDA graph 构建 ~60s → 持久化
├── warmup（生成几条假请求） ~30s → 保留优化手段：
torch.load(mmap=True)：加载阶段 3–5
倍加速。--enforce-eager=False
首次构建慢，可落盘复用。N+1
副本 warm，哪怕有 5% 冗余也值。第 19、20 篇讨论了业务层面经常需要”一个基座模型 + 几十到几千个小微调”的模式：某客服场景、某风控场景、某领域术语各一份 LoRA（几十 MB 到几百 MB）。如果为每个 LoRA 起一副 72B 副本，成本爆炸。
解决方案：共享基座 + 动态加载 LoRA adapter。
--enable-lora --max-loras 16 --max-lora-rank 64，请求头带
model: qwen3-lora-finance，vLLM 查表命中对应
adapter。Adapter 可以在 S3 / OSS 上，动态拉下来。python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen3-32B \
--enable-lora \
--max-loras 32 \
--max-lora-rank 64 \
--lora-modules \
finance=s3://bucket/loras/finance-v3 \
legal=s3://bucket/loras/legal-v2LMCache 把 KV cache 外置到 CPU 内存 / NVMe / 对象存储，让相同 prefix 在不同副本间也能复用。典型用途：
vLLM v0.6+ 已原生集成
--kv-transfer-config。
LLM 推理两阶段差异极大：
| 阶段 | 计算特征 | 瓶颈 | 批处理 |
|---|---|---|---|
| Prefill | 一次 prompt、大矩阵乘 | 算力 bound | 喜欢大 batch |
| Decode | 每次一个 token、KV 查表 | 访存 bound | 喜欢小步快 |
同一个 GPU 上混跑，prefill 的尖峰会抢占 decode 的带宽，造成 ITL（inter-token latency）抖动。经典连续批处理用 “chunked prefill” 缓解（见 12 篇），但没根治。
PD 分离 的思路：把 prefill 和 decode 放到不同 GPU 池，prefill 完成后把 KV cache 通过高速网络传给 decode 节点。
--kv-transfer-config，可配合 NIXL、Mooncake
Store、LMCache 做 KV 传输。
不要过早上。判据：
小规模集群，老老实实用 vLLM + chunked prefill 就够了。
PD 分离不是”各 50%“。实测中，比例与负载高度相关：
| 业务形态 | 平均输入 | 平均输出 | 典型 P:D 比 |
|---|---|---|---|
| 短 Chat | 500 | 300 | 1 : 3 |
| 文档 QA | 12k | 500 | 3 : 1 |
| 代码补全 | 6k | 200 | 4 : 1 |
| Agent 多轮 | 8k（含历史） | 1k | 2 : 1 |
工程上，Prefill 池用算力强的卡（H100 SXM）、Decode 池用带宽强成本低的卡（H20 / L20 / MI300X） 能得到最优的 TCO。DeepSeek V3 推理就是这个配方。
KV 从 Prefill 到 Decode，要跨节点搬数据。几种典型通道：
前面讲了 KV cache 复用：同一用户同一会话的多轮对话要尽量命中同一副本，否则 prefix cache 失效，每轮都要重算 system prompt + 历史。
做法：
hash(session_id) mod N。hash_policy: header: x-session-id。混部长请求（输入 32k+、输出 4k+）和短请求（输入 500、输出 100）会严重拖慢短请求的 p99。分流策略：
多模型场景下，可以做 model cascade：
这本质是网关层的事（下一篇讲），但服务层要提供不同模型的同构 API 和一致的 metric 口径。
权重从哪里来？
huggingface-cli download、LFS、safetensors。s3://models/qwen3-72b/v1.2.0/）。最佳实践：私仓 + 哈希校验 + 不可变版本。不要依赖”latest”，上游偶尔会覆盖。
/dev/nvidia* 和 GPU 当成 K8s 可调度资源。resources.limits.nvidia.com/gpu: 8。A100 / H100 支持把一张卡切成 7 份（1g.10gb、2g.20gb、3g.40gb、7g.80gb）。适合：
不适合：LLM 推理（fragmentation，MIG 之间不能 NVLink）。
rdma/hca
resource + SR-IOV，让 Pod 能用 IB。@app.function(gpu="A100")
直接上线。冷启动秒级（靠镜像快照 + 权重 FS 层）。不适用：核心在线主链路（冷启动风险）、超大模型（权重分发成本）。
阿里 PAI 平台的推理服务产品。特点：
字节旗下，方舟（Ark）对外主要是大模型 API（豆包、DeepSeek 托管），veMLP 则是底层 ML 平台。火山在 RDMA 网络 / 高性能对象存储（TOS）方面投入很大，PD 分离、KV 外存等特性上线较早。
TI-ONE 是腾讯的 ML 平台，TI-ACC 是推理加速产品，支持混元系列和开源模型。与 TDMQ / COS / TKE 集成。
华为 CANN 生态的上层服务框架，把 MindIE 引擎（第 13 篇提到）包成 OpenAI 兼容 API，部署在昇腾 910B/910C 集群上。盘古、通义千问昇腾版、DeepSeek 昇腾版均走这个栈。昇腾集群上的事实标准。
字节内部大模型推理服务平台，外部可以通过火山方舟看到它的能力外溢。强调端到端全链路优化、PD 分离、超大规模多租户。
LLM 推理的 DR（Disaster Recovery）有两大难点：权重大 + GPU 稀缺。
当主模型（例如 405B）某 region 完全不可用：
这需要网关层能做：SLA 检测 → 自动切流 → 回切，且对客户端保持 API 兼容。
KServe 官方有 vllm-openai ServingRuntime
模板。先定义运行时：
apiVersion: serving.kserve.io/v1alpha1
kind: ClusterServingRuntime
metadata:
name: kserve-vllm-runtime
spec:
annotations:
prometheus.kserve.io/path: /metrics
prometheus.kserve.io/port: "8080"
supportedModelFormats:
- name: huggingface
version: "1"
autoSelect: true
protocolVersions: [v2]
containers:
- name: kserve-container
image: vllm/vllm-openai:v0.9.0
args:
- --model=/mnt/models
- --port=8080
- --served-model-name={{.Name}}
- --tensor-parallel-size=2
- --max-model-len=32768
- --enable-prefix-caching
resources:
limits:
nvidia.com/gpu: "2"
memory: 64Gi
requests:
nvidia.com/gpu: "2"
memory: 32Gi
ports:
- containerPort: 8080
protocol: TCP再定义 InferenceService：
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: qwen3-32b
annotations:
serving.kserve.io/autoscalerClass: keda
spec:
predictor:
minReplicas: 2
maxReplicas: 16
model:
modelFormat:
name: huggingface
runtime: kserve-vllm-runtime
storageUri: s3://my-bucket/models/qwen3-32b/
resources:
limits:
nvidia.com/gpu: "2"
nodeSelector:
nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3验证：
kubectl apply -f qwen3-32b.yaml
kubectl get isvc qwen3-32b
# 等待 READY=True 后：
ENDPOINT=$(kubectl get isvc qwen3-32b -o jsonpath='{.status.url}')
curl -H 'Content-Type: application/json' \
-d '{"model":"qwen3-32b","messages":[{"role":"user","content":"hello"}]}' \
$ENDPOINT/v1/chat/completions一个同时挂 Qwen3（主 LLM）、bge-m3（embedding）和一个路由器的 deployment：
import ray
from ray import serve
from fastapi import FastAPI
from pydantic import BaseModel
from vllm import LLM, SamplingParams
from sentence_transformers import SentenceTransformer
app = FastAPI()
class Query(BaseModel):
text: str
mode: str = "auto" # auto | llm | embed
@serve.deployment(
ray_actor_options={"num_gpus": 2},
autoscaling_config={"min_replicas": 1, "max_replicas": 8, "target_ongoing_requests": 4},
)
class Qwen3LLM:
def __init__(self):
self.llm = LLM(model="Qwen/Qwen3-8B", tensor_parallel_size=2, gpu_memory_utilization=0.9)
self.params = SamplingParams(max_tokens=512, temperature=0.2)
async def __call__(self, prompt: str) -> str:
outs = self.llm.generate([prompt], self.params)
return outs[0].outputs[0].text
@serve.deployment(ray_actor_options={"num_gpus": 0.5})
class BgeEmbedding:
def __init__(self):
self.model = SentenceTransformer("BAAI/bge-m3", device="cuda")
async def __call__(self, text: str):
return self.model.encode(text, normalize_embeddings=True).tolist()
@serve.deployment
@serve.ingress(app)
class Router:
def __init__(self, llm, embed):
self.llm = llm
self.embed = embed
@app.post("/infer")
async def infer(self, q: Query):
if q.mode == "embed" or (q.mode == "auto" and len(q.text) < 64):
vec = await self.embed.remote(q.text)
return {"type": "embedding", "vector": vec[:8], "dim": len(vec)}
text = await self.llm.remote(q.text)
return {"type": "text", "answer": text}
llm_handle = Qwen3LLM.bind()
embed_handle = BgeEmbedding.bind()
app_handle = Router.bind(llm_handle, embed_handle)
# ray start --head
# serve run serving:app_handle启动：
ray start --head --num-gpus=3
serve run serving:app_handle
curl -X POST http://localhost:8000/infer -H 'Content-Type: application/json' \
-d '{"text":"解释一下 KV cache","mode":"auto"}'关键点：LLM 是 num_gpus=2（TP=2），embedding
用 num_gpus=0.5（共享半张卡），Ray Serve
自动帮你把两者放到合适的节点，Router 负责路由。
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen3-32B \
--tensor-parallel-size 2 \
--enable-prefix-caching \
--enable-lora --max-loras 32 --max-lora-rank 64 \
--lora-modules finance=/models/loras/finance legal=/models/loras/legal \
--kv-transfer-config '{"kv_connector":"LMCacheConnector","kv_role":"kv_both"}' \
--max-model-len 32768 \
--gpu-memory-utilization 0.9SGLang 提供的 Router 组件可以做 cache-aware routing，按 prompt prefix 命中哪个副本有 KV 来分发：
# 启动 3 个 SGLang worker
for port in 30000 30001 30002; do
python -m sglang.launch_server --model Qwen/Qwen3-8B --port $port &
done
# 启动 Router（同机或独立）
python -m sglang_router.launch_router \
--worker-urls http://localhost:30000 http://localhost:30001 http://localhost:30002 \
--policy cache_aware \
--cache-threshold 0.5 \
--balance-abs-threshold 32 \
--port 8000
# 请求打到 8000，Router 决定具体发哪个 worker
curl -X POST http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"qwen3","messages":[{"role":"user","content":"hello"}]}'相比一致性哈希，cache_aware 在 RAG / agent 场景命中率能高出 15–40 个百分点。
上线前必做容量评估。推荐工具链：
vllm bench serve /
benchmark_serving.py：官方脚本，支持
ShareGPT、LongBench、合成 trace。genai-perf（NVIDIA）：Triton
体系的标准压测工具，也能压任何 OpenAI 兼容 API。llmperf（Anyscale
维护）：多 tenant / 多并发场景的方便封装。k6 + OpenAI
plugin：写自定义业务 trace 的首选。关键指标至少采集：TTFT p50/p99、ITL（每 token 间隔）p50/p99、吞吐（tokens/s）、GPU 利用率、HBM 利用率、prefix cache 命中率、排队时长。
python benchmarks/benchmark_serving.py \
--backend vllm \
--model Qwen/Qwen3-32B \
--dataset-name sharegpt \
--dataset-path ShareGPT_V3.json \
--num-prompts 2000 \
--request-rate 40 \
--host localhost --port 8000 \
--save-result --result-filename qwen3-32b.json输出的 p99 TTFT、p99 TPOT（time
per output token）、mean_throughput 就是你给
SRE / 业务方承诺 SLO 的依据。
LLM serving 不都是 72B 巨兽。一个典型平台还要跑：embedding（300M–2B）、rerank（500M）、safety classifier（100M）、ASR/TTS。如果每个都独占一张卡，钱包会爆。
Nvidia MPS 允许多个进程共享一块 GPU 的
SM，比默认的时分复用（context switch）开销更低。K8s 里通过
nvidia.com/gpu.shared = true 或 HAMi /
TimeSlicing Plugin 接入。适合：
不适合：高 QPS LLM 主推理（干扰严重，p99 抖动大）。
| 特性 | MIG | Time-Slicing | MPS |
|---|---|---|---|
| 隔离 | 硬件级 HBM / SM | 无（时分） | SM 共享，显存共享 |
| 卡支持 | A100/H100 | 所有 | 所有 |
| 性能干扰 | 无 | 有 | 有（低） |
| 适合 | 多租户、小模型 | 开发环境 | 低并发推理 |
国内常用 HAMi（由第四范式等维护，原 4paradigm/k8s-vgpu-scheduler），可以把一张卡按 显存 + 算力百分比 切给多个 Pod。它是 MPS 之上的调度层，对昇腾、寒武纪也有适配。
不需要。直接 vllm serve + systemd / Docker
Compose + 前面一个 nginx 足够撑很久。等团队有 ≥ 10
副本、需要 GitOps、多租户、金丝雀时再迁移。
vLLM 的 --enable-prefix-caching
是副本内的 HBM 级 KV 复用；LMCache
是跨副本 / 分层（HBM → DRAM → NVMe →
对象存储）的 KV
复用。前者零成本开启，后者需要额外网络和存储。
可以，且常见。Triton 跑 CV / ASR / TTS / embedding（强 batching），vLLM 跑 LLM。前面用同一个网关屏蔽差异。
有。吞吐下降大约 5–15%（依 adapter 数、rank、SGMV kernel 优化程度），但比起每个 LoRA 起一副基座副本节省 10–100 倍显存，性价比极高。
可以。用华为的 MindIE Service 镜像作为 ServingRuntime
即可。注意 device plugin 要换成
ascend-device-plugin，资源名是
huawei.com/Ascend910。
DCGM 报告的 GPU_UTIL 只看”SM
是否在活动”，不代表算力打满。LLM decode 阶段是访存 bound，SM
大多时候在等 HBM，GPU_UTIL 可能长期
40–60%，但HBM
带宽利用（DCGM_FI_PROF_DRAM_ACTIVE）已经
90%+。排查时同时看算力利用、带宽利用、NCCL
通信时长、vllm:kv_cache_usage_perc、vllm:num_requests_waiting。
强烈建议”镜像 + 权重 + 配置”一起锁版本，按 KServe / K8s 标准 RollingUpdate 做滚动。新版本先用 1 副本承接 1% 流量，跑 30 分钟没 error rate / p99 异常再放量。不要在高峰期升级，vLLM 偶尔有 kernel 兼容性回退（如 FlashAttention 版本）。
网关层（下一篇）做 QPS / token/s /
并发三维限流；服务层可按 tenant 在 vLLM 启动参数里给
--max-num-seqs
限制，或者干脆给大客户独占副本。
给出一组经验值，作为起点而非教条：
SLO 要和网关、业务双向对齐：业务提诉求 → 服务层给出可行性 → 网关兜底降级路径。
推理服务化的本质，是把 11–16 篇“引擎”变成”云”。你在单机上关心的 paged KV、continuous batching、speculative decoding，到了集群里就变成了自动扩缩、session 路由、PD 分离、多租户 LoRA、跨 region 灾备。引擎是发动机，服务层是底盘。
这一层有三条重要趋势：
下一篇我们抬高一层，看大模型网关：鉴权、配额、路由、审计、合规、成本——所有和”谁在用、用多少、合不合规”相关的事都在那里。
ray.serve.llm（Ray 2.40+）原生
LLM 抽象，比自己写 deployment 更方便。这些都是本文没法展开但强烈建议读的”下一步”。
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / ai-infra
从 nvcc 到 Triton，把 NVIDIA 软件栈的每一层拆给大模型工程师看，顺便谈谈 ROCm、CANN 为什么一直追不上。
2026-04-22 · architecture / ai-infra
面向工程师的大模型基础设施开篇地图，覆盖 2022 到 2026 的工程分水岭、五层工程栈、训练与推理的工程差异、中国与全球行业版图以及成本曲线。
2026-04-22 · architecture / ai-infra
从 CPU 与 GPU 的架构差异出发，讲清楚 SM、Warp、Tensor Core、HBM、NVLink 的工程含义，并结合 Roofline、FlashAttention 与国产算力栈，给出大模型工程师能直接上手的 GPU 心智模型。
2026-04-22 · architecture / ai-infra
从 NVLink / NVSwitch / NVL72 到 InfiniBand NDR 与 RoCEv2，再到华为 CloudMatrix、阿里 HPN、腾讯星脉，系统梳理万卡集群互联的工程选型与踩坑。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。