15 篇博文 含有标签「AI Infra」

公司那台 K8s worker 是台「三无」机器：无 GPU、4 核 8 线程（AMD EPYC 9754）、30GB 内存，CentOS 7 + nerdctl，还要兼顾集群负载。我在上面用 llama-server 跑了一个给 IDE 用的代码补全/问答服务，模型从 16B 的 DeepSeek-Coder-V2-Lite 到 135M 的 SmolLM2 随意切换。这篇把选型账本和踩坑记录写下来：量化怎么选、KV Cache 每个 token 到底吃掉多少内存、CPU 上 prefill 为什么比 decode 还慢、KV cache 满载时日志长什么样。上一篇讲了 CentOS 7 + nerdctl 编译 llama.cpp 的完整流程，这篇是运行期的优化。GPU 侧的理论对比（Continuous Batching、PagedAttention）见 vLLM 推理面试题，投机解码 是另一条优化路线，这里只谈 CPU 上最现实的三个杠杆：量化、KV Cache、并发槽位。

云服务器上搭 LLM 推理环境，最怕的不是模型本身，而是操作系统太老。本文记录在一台 CentOS 7 + nerdctl（containerd 系容器运行时）的服务器上，从裸系统到跑通 llama.cpp 编译、推理、HTTP 服务的完整过程，包括一个可复现的 Dockerfile 和全部踩坑记录。

先给结论：大模型训练并行只有三件事——显存放不下、算力不够用、通信不能成为瓶颈。数据并行（DP）摊算力、张量并行（TP）摊单层显存、流水线并行（PP）摊层数，ZeRO/FSDP 是数据并行的显存优化形态，实际生产（GPT-3、Llama、Qwen 系列）都是把它们叠成 3D/4D 并行来用。选型的本质是一道通信开销的算术题：每步训练要搬多少字节，你的互联带宽扛不扛得住。

上一篇讲了参数高效微调 LoRA/QLoRA，那是"少训点参数"的路线；这篇是"多卡一起训"的路线，两者互补。集群怎么调度 GPU 见K8s GPU 调度。

推理引擎选型是 LLM 服务化里最容易被低估的架构决策。同样的模型、同样的 GPU，换一个引擎吞吐可能差 2-3 倍；但反过来，厂商 benchmark 里好看的引擎，落到你的真实负载上可能反而更慢。这篇文章把 vLLM、SGLang、TensorRT-LLM、TGI 四个主流引擎放在一起对比，从调度机制、前缀缓存、结构化输出、量化、MoE 支持五个维度拆，最后给选型决策表和生产踩坑记录。

聊 LLM 应用的工程，大家津津乐道的是推理优化、RAG、Agent 编排，但真正决定一个 ToB/ToC 产品能不能赚钱的，往往是没人愿意写的计量与计费。模型调用不像 MySQL 查询——没有免费的 EXPLAIN，每一次 API 调用都是真金白银的流出；而一旦你开始对用户收费、对开发者分成，计费就从「省钱工具」升级成「信任地基」：计量错了，不是亏钱就是信任崩塌。

这篇文章从后端工程师视角，把「一次模型调用 → 一条 usage 事件 → 一张账单 → 一笔分账」的完整链路拆开：usage 从哪来、按什么价、怎么记、怎么算、怎么对账。基于真实平台（以 DeepSeek 2026-08 官方计价为例）的实操经验，有 schema、有代码、有坑。

PD 分离（Prefill/Decode Disaggregation）是这两年推理集群改造里回报最高的一步。DeepSeek-V3 技术报告在部署章节明确写了 "separates the prefilling and decoding stages"；Kimi 的 Mooncake 平台靠它多扛了 75% 的真实流量；vLLM、SGLang、NVIDIA Dynamo 都把它做成了一等公民。

但这项技术有个反直觉的点：它几乎不提升峰值吞吐，买的是延迟的可控性。vLLM 官方文档第一句就是 "Disaggregated prefill DOES NOT improve throughput"。本文拆解它为什么成立、KV cache 传输这笔账怎么算、两级调度怎么设计，最后给一个可运行的模拟器和一份踩坑清单。

推理集群的利用率为什么普遍只有 30%-50%？大多数时候不是模型不够强，而是调度层把 GPU 当成了「特别大号的 CPU」。这张卡该不该给、给多少、和谁共享、抢占了谁——每一步都决定你是多跑一倍任务，还是天天看着显存碎片和排队干瞪眼。

上一篇Linux VRAM overcommit 与显存超卖讲了单机层面的显存管理，这篇往上一层：K8s 集群里 GPU 是怎么被调度、切分和排队的。面向要搭推理集群的 SRE / 平台工程师，从 Device Plugin 讲到 Kueue、Volcano，附可直接抄的 YAML。

2026 年 8 月，两条看起来不相关的新闻放在一起读，信息量很大：

1. Tom's Hardware 报道 DRAM 价格 12 个月涨了约 500%，HBM/GDDR 的供应紧张让"显存"成了整个 AI 产业链最贵的消耗品；
2. 一位 Linux 图形栈开发者（pixelcluster.dev）多年打磨的 VRAM 管理补丁合入主线、随 Linux 7.3 发布：当 GPU 显存被"超卖"（overcommit）时，系统不再随机崩溃，而是尽量优雅地降速。

第一条讲的是"显存为什么不够用"，第二条讲的是"不够用了之后系统该怎么办"。第二条对 AI 推理工程师尤其有参考价值——因为 vLLM 的 CPU offload、llama.cpp 的 mmap、推理服务的显存超卖，本质上是同一个问题：物理显存放不下，被迫把数据换到 PCIe 那头的内存里，系统怎么把损失降到最小。

RAG 火了一年多，向量数据库的选型问题被问了无数次。本文基于实际使用经验，系统对比 8 款主流向量数据库，帮你做技术决策。

云服务器搭 AI 绘图/视频生成环境，网络和依赖是最大拦路虎。本文记录在 AutoDL Tesla T4（16 GB 显存）实例上，从裸 Ubuntu 20.04 到跑通 ComfyUI + CogVideoX-5B 的完整过程。