2026-04-22 · architecture / ai-infra
【大模型基础设施工程】17：RAG 工程全景
从文档解析、切片、嵌入、索引、检索、重排到生成与评估，系统梳理 RAG 的工程流水线、进阶范式与国内外生态
上一篇讲了 RAG 的端到端工程。这一篇把视角下沉到存储与检索层：向量索引算法怎么选、量化怎么压、产品生态怎么看，以及 2024—2026 年工业界最热的图增强 RAG（GraphRAG）怎么把知识图谱与向量检索缝合起来。
全文按”算法底层 → 产品选型 → 工程实操 → 图 RAG 与趋势”四段展开，尽量给能直接落地的参数与代码。
阅读提示：本篇偏工程向，配置参数、代码和决策树较多；图 RAG 部分建议结合前一篇 RAG 工程全景一起看；最后的案例与排错手册可作为实施时的 checklist。
本文涉及的所有参数推荐值都是起点，实际生产需要用自己的数据做 A/B 后调优。
向量检索的核心矛盾是：维度 d 通常 768~4096，库大小 N 通常 106~1010，要在毫秒级返回 top-k。暴力扫的复杂度是 O(N·d)，十亿规模根本过不去，所以工程上 99% 用 ANN（Approximate Nearest Neighbor）。
下表是主流索引算法的工程视角速查：
| 算法 | 复杂度 | 内存 | 召回率 | 典型场景 |
|---|---|---|---|---|
| Flat（暴力） | O(Nd) | 100% | 100% | <1M、离线评测 baseline |
| IVF-Flat | O(√N·d) | 100% | 95~99% | 10M~100M、需 GPU |
| IVF-PQ | O(√N·d/m) | 5~25% | 85~95% | 100M~10B、内存受限 |
| HNSW | O(log N·d) | 120~150% | 95~99% | 1M~1B、毫秒级、主流默认 |
| DiskANN / Vamana | O(log N·d) | 5~10% | 93~97% | 10B+、磁盘驻留 |
| SPANN | O(log N·d) | 10~15% | 93~97% | 10B+、Microsoft 方案 |
| ScaNN | O(√N·d) | 30~60% | 96~99% | Google 内部、学术 SOTA |
Flat 就是把所有向量摊平，查询时挨个算相似度。它的唯一作用是：给其它索引算法做 recall 基线。工程上几乎不用它上线，但离线调参必须用它跑一遍 ground-truth。
FAISS 里 IndexFlatL2、Milvus 里
FLAT、pgvector 不建索引直接
<-> 就是暴力。100 万 × 768 维 fp32 就 3
GB、查询几百毫秒，10 亿就别想了。
IVF（Inverted File）的思路很朴素：先用 k-means 把向量聚成 nlist 个簇，查询时只扫距离最近的 nprobe 个簇。N=10^8、nlist=4096、nprobe=32，扫的量从 10^8 降到 10^6，快 100 倍。
调参经验：
IVF 对 GPU 友好：大 batch 查询时，每个簇独立算，可以打满 H100 的 HBM 带宽。Milvus GPU 版、NVIDIA RAFT 都走这条路。
HNSW（Hierarchical Navigable Small World）是 2016 年 Malkov 提出的分层图，目前所有主流向量库（Milvus、Qdrant、Weaviate、Elasticsearch、pgvector）的默认索引。
核心思想：
关键参数：
M=16
是工业默认，高维稠密可以到 32~64；内存估算：mem ≈ N · (d·4 + M·2·4 + 8)
字节。10^8 × 768 dim fp32 + M=32 ≈ 335
GB，这就是为什么十亿级上要配合量化或 DiskANN。
微软 2019 年的 DiskANN 解决了一个痛点：HNSW 内存吃不消。它的 Vamana 图构造算法产生的图连通性更好，平均路径短，使得即便把大部分图放在 SSD 上，查询也只需要几十次随机 IO。
工程形态：
10 亿向量、768 维、NVMe SSD 上，DiskANN 能做到 P99 < 10 ms、内存只需 32~64 GB，成本比全内存 HNSW 降一个数量级。Milvus 2.4+、Weaviate、Pinecone serverless 都内置了 DiskANN 形态。
量化是把 fp32 向量压成更少比特，本质是”用精度换内存和带宽”。
RaBitQ（SIGMOD 2024）把向量二值化到 1 bit/维，配合随机旋转和理论上可控的误差界，实测压缩 32× 的同时召回几乎无损。Milvus 2.5+、Qdrant 都在集成。它的核心是有保证的无偏估计，不像过去 BQ（Binary Quantization）那样召回崩塌。
| 压缩 | 方案 | 召回损失 | 何时用 |
|---|---|---|---|
| 2× | fp16 | 0 | 默认、显存敏感 |
| 4× | int8 SQ | <1% | 通用 |
| 8~16× | PQ/OPQ | 2~5% | 亿级内存受限 |
| 32× | RaBitQ | <2% | 百亿级、2025 推荐 |
| 64×+ | BQ（朴素） | 5~15% | 仅粗排，需精排 |
2026 年向量数据库市场大致分四类：专用、扩展、云托管、国产。
国内选型的一般建议：中小规模在 PG 生态（pgvector / PolarDB）；海量专用选 Milvus；OLAP + 向量分析选 StarRocks。
2024 年 Turbopuffer、Qdrant Cloud 等把 “对象存储 + 按查询计费” 做到极致：冷数据驻 S3、查询时按需加载 + LRU 缓存，成本做到 每百万向量每月 <$1。这对传统”买 n 台内存机常驻”的模式是降维打击。Lance、Pinecone Serverless、pgvectorscale 都在向这个方向演进。
工业 RAG 里，纯稠密检索的召回一般打不过 hybrid。混合检索的基本配方：
示例：SPLADE 把 query 和 doc 都映射到 30000 维稀疏向量（BERT vocab），点积 = 语义 BM25。Milvus 2.4+、Elastic 8.x、Qdrant 1.10+、Vespa 都原生支持稀疏向量。
# Milvus 2.4 Hybrid Search 示例
from pymilvus import MilvusClient, AnnSearchRequest, RRFRanker
client = MilvusClient(uri="http://localhost:19530")
dense_req = AnnSearchRequest(
data=[dense_query],
anns_field="dense",
param={"metric_type": "IP", "params": {"ef": 128}},
limit=50,
)
sparse_req = AnnSearchRequest(
data=[sparse_query],
anns_field="sparse",
param={"metric_type": "IP"},
limit=50,
)
res = client.hybrid_search(
collection_name="docs",
reqs=[dense_req, sparse_req],
ranker=RRFRanker(k=60),
limit=10,
)纯 ANN 之外，生产里 90%
的查询带过滤：tenant_id = X AND created_at > Y AND lang = "zh"。实现方式有三：
在 Milvus 和 Qdrant 里配合按 tenant 分 partition/shard 可以把多租户场景的 filter 成本压到 0，这是 SaaS 架构的必修。
单向量（dense bi-encoder）把整段文本压成一个向量，损失大。ColBERT 把每个 token 都存成向量，查询时做”token 级”MaxSim：
score(q, d) = Σ_i max_j <q_i, d_j>这叫 Late Interaction。召回率比单向量高 5~10 个点，代价是存储膨胀 20~100×。
纯向量 RAG 的两个死穴：
GraphRAG 的核心思路：用 LLM 预先把语料抽取成图（实体 + 关系），查询时沿图游走或用图摘要。2024 年 Microsoft GraphRAG 把这条路线带火。
流程（离线索引 + 在线查询）：
(entity, relation, entity) + 描述；
Microsoft GraphRAG 最大的痛点是索引成本高：对中型语料就要烧几百刀 token。社区出现一批更轻的方案：
工程上最务实的做法：
这对金融、医疗、法律场景特别有效，因为这些领域有明确的 schema 和可验证的关系。
| 产品 | 模型 | 语言 | 典型规模 | 特点 |
|---|---|---|---|---|
| Neo4j | Property Graph | Cypher | 单机亿级 | 生态最全、企业版分布式 |
| NebulaGraph | Property Graph | nGQL | 分布式千亿 | 国产、vesoft、字节在用 |
| TigerGraph | Property Graph | GSQL | 分布式千亿 | 商业、并行计算强 |
| JanusGraph | Property Graph | Gremlin | 分布式 | 基于 Cassandra/HBase |
| ArangoDB | 多模（图+文档） | AQL | 单机亿级 | 多模方便 |
| Neptune | Property / RDF | Cypher/Gremlin/SPARQL | AWS 托管 | 兼容性广 |
| GraphDB / Stardog | RDF | SPARQL | 知识图谱 | 推理能力强 |
属性图 vs RDF：属性图（LPG）灵活、工程友好，适合业务；RDF / SPARQL 语义严格、可推理，适合学术和本体管理。2026 年 Neo4j、Nebula 主导 LLM + 图的生产场景；RDF 主要在学术和特定行业本体里。
| 场景 | M | ef_construction | ef_search | 备注 |
|---|---|---|---|---|
| 平衡默认 | 16 | 200 | 64 | 大多数中小规模 |
| 高召回 | 32 | 400 | 128~256 | 金融、医疗 |
| 内存紧张 | 8 | 200 | 64 | 小集群 |
| 大规模 + PQ | 16 | 200 | 64 | 10^9、配 IVF-PQ 粗排 |
| Filter 重 | 32 | 400 | 128 | 补偿过滤掉的邻居 |
N < 1e6 → Flat / pgvector 默认
1e6 ~ 1e7 → HNSW 全内存（默认）
1e7 ~ 1e8 → HNSW + fp16 / int8 SQ
1e8 ~ 1e9 → IVF-PQ（GPU）或 HNSW + RaBitQ
1e9 ~ 1e10+ → DiskANN / SPANN / 对象存储形态共同经验：
from pymilvus import MilvusClient
import numpy as np
client = MilvusClient("http://localhost:19530")
client.create_collection(
collection_name="demo",
dimension=768,
metric_type="IP",
index_type="HNSW",
index_params={"M": 16, "efConstruction": 200},
)
docs = [{"id": i, "vector": np.random.rand(768).tolist(),
"tag": "tech" if i % 2 == 0 else "news"} for i in range(1000)]
client.insert("demo", docs)
res = client.search(
"demo", data=[np.random.rand(768).tolist()],
filter='tag == "tech"', limit=5,
search_params={"params": {"ef": 64}},
)
print(res)from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct, Filter, FieldCondition, MatchValue
import numpy as np
qc = QdrantClient("http://localhost:6333")
qc.recreate_collection("demo",
vectors_config=VectorParams(size=768, distance=Distance.COSINE))
qc.upsert("demo", points=[
PointStruct(id=i, vector=np.random.rand(768).tolist(),
payload={"tag": "tech" if i % 2 == 0 else "news"})
for i in range(1000)])
hits = qc.search("demo",
query_vector=np.random.rand(768).tolist(),
query_filter=Filter(must=[FieldCondition(key="tag", match=MatchValue(value="tech"))]),
limit=5)
print(hits)CREATE EXTENSION vector;
CREATE TABLE docs (id bigserial, content text, tag text, embedding vector(768));
CREATE INDEX ON docs USING hnsw (embedding vector_ip_ops)
WITH (m = 16, ef_construction = 200);
SET hnsw.ef_search = 64;
SELECT id, content FROM docs
WHERE tag = 'tech'
ORDER BY embedding <#> $1
LIMIT 10;from neo4j import GraphDatabase
drv = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "pass"))
with drv.session() as s:
s.run("""
MERGE (a:Person {name:$a})
MERGE (b:Company {name:$b})
MERGE (a)-[:CEO_OF]->(b)
""", a="Jensen Huang", b="NVIDIA")
rec = s.run("""
MATCH (p:Person)-[:CEO_OF]->(c:Company {name:$c})
RETURN p.name AS ceo
""", c="NVIDIA").single()
print(rec["ceo"])真实 GraphRAG 工程里用 LangChain
LLMGraphTransformer 或 Microsoft graphrag
包做自动抽取。
2026 年向量 + 图 RAG 领域的几条趋势线：
落地建议的一句话版本：
前面给了速查表，这一节把几个工程里经常踩坑、面试也常问的点讲透。
一个常见坑：同一个库不能混用不同
metric。BGE 官方推荐 cosine，但如果你用 L2
存、查询时用 cosine，结果会完全错。插入前务必
x = x / ||x|| 归一化一次，然后整库统一 IP。
HNSW 的图质量在大量删除 + 插入后会退化。典型症状是：召回率随时间漂移、P99 延迟慢慢变大。原因是：
工程上两类对策：
REINDEX。按业务节奏每周或每月跑一次；IVF 的质心来自 k-means 训练，训练集的分布决定了索引质量。两个常见错误：
nlist × 39，质心不稳，召回波动；解决：用全库的分层采样（按
tenant、时间、类别）做训练集，至少 nlist × 50
个样本。生产环境强烈建议每季度重训一次。
PQ 把 d 维切 m 段，每段用 256 个质心（1 byte）。m 越大压缩率越低但召回越高：
| d | m | 压缩率 | 召回相对 Flat |
|---|---|---|---|
| 768 | 48 | 64× | 80~85% |
| 768 | 96 | 32× | 88~92% |
| 768 | 192 | 16× | 92~95% |
| 1536 | 96 | 64× | 82~88% |
| 1536 | 192 | 32× | 88~93% |
经验公式：m ≈ d / 8，再根据召回微调。维度必须能被
m 整除，且 d/m 不宜 < 4，否则每段信息太少。
HNSW / IVF 的热点是大量的点积或 L2 距离，SIMD 化收益极大：
Qdrant 的 Rust 实现、hnswlib 的 C++ SIMD 模板，是开源里 SIMD 写得最彻底的两个项目，值得读。
Filtered ANN 的性能强依赖过滤选择率 s（通过过滤的比例）：
s ≈ 1.0 → 等价于无过滤，HNSW 最优
s ≈ 0.1 → 图遍历 2~3× 减速，可接受
s ≈ 0.01 → 图遍历 10× 减速，建议切换 pre-filter
s ≈ 0.001 → 改用倒排 + 暴力
s < 1e-5 → 退化到 OLTP 等值查询，直接用 B+Tree所以生产里常见的做法是基于选择率的自适应路由：查询规划器估算选择率，动态选 pre-filter / filtered HNSW / post-filter。Qdrant 和 Vespa 都有这个优化。
模型升级换 embedding（例如从 BGE-v1 升到 BGE-M3），旧索引全部作废。工程上两种做法：
SaaS 向量库（Pinecone、Zilliz）一般提供 namespace / alias 切换，业务侧只改一个 alias 指向。
Microsoft GraphRAG 默认让 LLM free-form 抽取实体与关系，质量参差。生产里强烈建议 schema-guided：预定义实体类型和关系类型，LLM 只能在给定集合里填。
SCHEMA = {
"entities": ["Person", "Company", "Product", "Location", "Event"],
"relations": ["CEO_OF", "SUBSIDIARY_OF", "LOCATED_IN", "FOUNDED", "PARTNERED_WITH"],
}
prompt = f"""只在下列类型中抽取三元组，其它忽略。
Entities: {SCHEMA['entities']}
Relations: {SCHEMA['relations']}
Text: {chunk}
输出 JSON：[[{{"head":..,"type":..}},"REL",{{"tail":..,"type":..}}],...]
"""金融、医疗、合规场景基本都要 schema-guided，否则后续查询无法对得上。
同一实体不同写法（“OpenAI”、“Open AI”、“OpenAI Inc.”）必须合并，否则图碎成粉。典型链路：
Neo4j 的 APOC 库、LightRAG
里都内置了实体合并流水线。
GraphRAG 用 Leiden（Louvain 的改进版），对稀疏图效果好。其它常用：
社区层级数（Level）通常 3~5 层合理：Level 0 最细（几十节点一组），Level N 最粗（整图几大板块）。
Microsoft 后续在 GraphRAG 里又加了 DRIFT search：
实测在多数场景比单纯 local 或 global 好。生产里建议按 query 类型路由：
对 100 万 token 语料（约 1500 页 PDF）做一次完整 GraphRAG 索引：
对比纯向量 RAG（嵌入 ~ $0.1），贵了 500×。所以别对所有语料都跑 GraphRAG，只对高价值、多跳、全局问答需求的语料用。LightRAG 把成本压到 1/5~1/10，是中间折中。
向量库选型离不开评测。关键指标：
开源工具：
生产监控建议：
搭自己的评测集比借 BEIR 更重要，流程：
有了这份评测集后，换 embedding、换索引、调参数都能量化评估，不再靠拍脑袋。
经常见到的坑：离线评测 recall 95%，上线后用户反馈”搜不到”。常见原因：
解决：线上线下用同一份 embedding 服务与 filter 逻辑，评测集覆盖各 tenant / 各时间段。
最后给一个端到端的示例，串联本文所讲。
场景：证券公司研报库，50 万份 PDF、2 亿中文 token、每天新增 500 份。需要：
架构：
┌─────────────┐
PDF ──▶ 解析 + chunk ──▶ │ Embedding │──▶ Milvus（HNSW + filter）
│ BGE-M3 │ │
└─────────────┘ │
┌─────────────┐ │
│ LLM 抽取 │──▶ Neo4j（实体图）─┐ │
└─────────────┘ │ │
┌─────────────┐ │ │
│ 社区摘要 │──▶ Milvus 社区集合 │ │
└─────────────┘ ▼ ▼
Query Router
│
┌────────────────────┼─────────────────────┐
▼ ▼ ▼
事实查询 多跳查询 全局总结
(Local GraphRAG) (DRIFT) (Global GraphRAG)关键参数：
industry partition；company、industry、date，全部建
scalar index；成本（估算）：
效果（某真实券商案例匿名化数据）：
这个配方可以直接迁到医疗、法律、咨询等知识密集行业。核心思路不变：向量管相似、图管关系、LLM 管理解与生成。
上线一个类似系统，建议按下面的阶段推进，避免一次性上齐导致难以收敛：
不要在 Week 0 就把 GraphRAG、多模态、Late Interaction 全上，工程复杂度会吞掉所有精力，也很难定位问题到底在哪一层。
同类项目失败的常见原因：
在标准 sift-1M、glove-100、deep-1M 数据集上，2025 年的 Pareto 前沿大致长这样（recall 90%+ 下的 QPS，单核）：
| 算法 | sift-1M QPS | glove-100 QPS | 备注 |
|---|---|---|---|
| hnswlib | ~20000 | ~8000 | 社区基准 |
| Qdrant HNSW | ~18000 | ~7500 | Rust 实现 |
| Milvus HNSW | ~15000 | ~6500 | 有一层服务化开销 |
| Vamana / DiskANN 全内存 | ~14000 | ~6000 | 图略好但慢 |
| ScaNN | ~25000 | ~12000 | 学术 SOTA |
| Weaviate | ~10000 | ~4500 | Go 实现 |
| pgvector HNSW | ~8000 | ~3000 | 带 PG 开销 |
| Faiss IVF-PQ | ~12000 | ~5000 | CPU，GPU 更快 |
需要注意：单核 benchmark 不等于生产性能。生产里 P99、filter、并发、写入混合、冷热分层才是主题。
2023—2025 年学术界探索用神经网络替代 k-means 质心或图结构：
工业落地不多，原因是 HNSW / IVF-PQ 已经非常强，Learned Index 的增益在 5% 以内但引入模型维护复杂度。值得关注，但短期不会替代。
稀疏检索从 BM25 走到 SPLADE，背后有几代演进：
生产建议：BM25 + 稠密两路 RRF 是最低成本的 hybrid；对质量要求高可加一路 SPLADE。
向量库作为有状态系统，CAP 取舍非常现实：
对高写入场景（日志型、IM 型），最终一致 + WAL 的设计更合理；对金融、医疗等一致性要求高的，pgvector 或 OceanBase Vector 可能更合适。
工程里遇到过的典型问题，汇总成表方便排查：
| 症状 | 可能原因 | 排查手段 |
|---|---|---|
| 召回骤降 | 删除墓碑累积 / segment 碎片 | compact、观察 segment 数 |
| P99 突增 | ef_search 太大 / 过滤选择率低 | 调 ef_search、查选择率 |
| 内存 OOM | HNSW M 过大 / 未量化 | 降 M、加量化、分 shard |
| 写入 backlog | HNSW 实时插入 / segment 未 flush | 改批量写、加 flush 频率 |
| 查询结果错乱 | metric 不一致 / 未归一化 | 统一 metric、插入前归一化 |
| 多租户泄漏 | filter 漏写 / partition 未生效 | 强制 partition key、审计 |
| 升级 embedding 召回崩 | 新旧索引未切换 | 双写双查 + 灰度 |
| GraphRAG 实体爆炸 | free-form 抽取 / 未消歧 | 加 schema、加消歧流水线 |
| 社区摘要答非所问 | 社区过大 / 层级过浅 | 调 Leiden 参数、加层 |
| 成本飞起 | 全量 GraphRAG / 密集 ef_search | 精选语料、调 ef |
| 查询结果乱序 | 未归一化 + IP 度量 | 归一化 / 改 cosine |
| 冷启动召回低 | 训练样本不足 | 补样本、重训 IVF |
| 多语言召回差 | 单语模型 | 换 BGE-M3 / multilingual-e5 |
某电商的商品检索库，某天突然 P99 延迟从 80 ms 飙到 800 ms，召回率也降到 78%。排查步骤：
教训：HNSW 最怕高频 upsert。如果业务要求高频更新 payload 但 embedding 稳定，把 payload 和向量分离存储是正解。
CLIP、SigLIP、BLIP、Qwen2-VL、InternVL 等跨模态模型产出的向量可以直接塞进同一个向量库，实现”文搜图、图搜图、图搜文”：
工程坑：不同模态的向量分布方差不一致，直接混在同一 index 里，文搜文容易被图干扰。解决：按 modality 分 partition，或者用带 modality 字段的 filtered ANN。
视频检索常把视频切成 shot 或 2 秒 clip，对每 clip 出一个向量。问题是一个视频产生上百向量，库规模膨胀百倍。常见优化：
快手、YouTube、TikTok 内部的视频检索都是这种层次化架构。
推荐、LBS 场景会把地理位置、时间和语义向量一起检索。三类做法：
score = α·sim + β·exp(-d/σ) + γ·exp(-|t|/τ)。Vespa、Elastic、Milvus 都支持这种 hybrid scoring。
你的规模?
├── <100 万：Chroma / pgvector / LanceDB（笔记本 / 小业务）
├── 100 万~1 亿：
│ ├── 已用 Postgres？→ pgvector + pgvectorscale
│ ├── 需要 hybrid / filter？→ Qdrant / Milvus / Weaviate
│ └── 已用 ES？→ Elasticsearch / OpenSearch
├── 1 亿~10 亿：
│ ├── 自建：Milvus / Qdrant（配 PQ 或 RaBitQ）
│ ├── 云上：Zilliz / Qdrant Cloud / Pinecone / DashVector
│ └── 强 OLAP 需求：StarRocks Vector / Vespa
└── 10 亿+：
├── 极致成本：DiskANN / SPANN / Turbopuffer / LanceDB on S3
├── 百度级延迟：Milvus + GPU + 分层存储
└── 国内合规：OceanBase / TiDB / TencentVectorDB
是否多跳 / 全局问答?
├── 不需要 → 纯向量即可
├── 少量高价值语料 → LightRAG / Nano-GraphRAG
└── 生产级知识库 → Microsoft GraphRAG / Neo4j + 向量库
是否多模态?
├── 纯文本 → BGE-M3 / text-embedding-3
├── 图文 → SigLIP / Qwen2-VL + 向量库
└── 视频 → 层次向量 + Vespa 或自建向量库是 LLM 时代的”数据库”，图 RAG 是它的”多跳拓展”。选型先看规模与成本，再看 filter 与 hybrid 需求，最后看是否需要多跳与全局问答——用对工具比堆参数重要得多。
如果只能记三条：
剩下所有事情——hybrid、filter、multi-vector、多模态——都是在这三条基础上的增量优化。保持”能回到最简基线”的心态，比追最新算法重要得多。
上一篇：RAG 工程全景 下一篇：Agent 框架工程
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / ai-infra
从文档解析、切片、嵌入、索引、检索、重排到生成与评估，系统梳理 RAG 的工程流水线、进阶范式与国内外生态
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
从 nvcc 到 Triton，把 NVIDIA 软件栈的每一层拆给大模型工程师看，顺便谈谈 ROCm、CANN 为什么一直追不上。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。