工程筛选报告 · Jay · 2026-07-07 上午第二轮
主题：推理引擎系统工程 · SGLang 生产排障 · BaseRT Apple Silicon 推理 · llm-d K8s 分布式推理 · Token 在数据中心流动全链路
筛选标准：必须有真实环境、命令、错误信息、性能数据或可复现步骤。拒绝表面介绍、趋势概述、无具体数据的对比。
候选条目（共 11 条）
✅ 保留 1：SGLang 生产排障速查表（Yobitel，2026-07-04）
来源：https://yobitel.com/knowledge-base/sglang 可信度：高（Yobitel 运营的生产 SGLang 集群经验沉淀，官方文档级） 发布时间：2026-07-04（新鲜）
保留理由： 错误→根因→修复的完整三元组，覆盖约 80% 的生产事故：
| 症状 | 根因 | 修复命令/操作 |
|---|---|---|
torch.cuda.OutOfMemoryError 启动时 |
mem-fraction-static 过高；激活值挤压 KV 池 |
降到 0.85；确认无其他进程占用 GPU |
| NCCL 启动挂起（TP>1） | /dev/shm 过小或 NVLink P2P 被禁用 |
挂载 /dev/shm >= 8GB；加 --enable-p2p-check；设 NCCL_DEBUG=INFO |
cache_hit_rate 接近零（但前缀复用友好 workload） |
schedule-policy fcfs 将共享前缀分散到不同 batch |
切换 --schedule-policy lpm |
| 吞吐量意外低于 vLLM | workload 无前缀重叠；RadixAttention 开销无法回收 | 改造 prompt 使其共享稳定前缀；或将 workload 迁至 vLLM |
| Preemption rate 持续上升 | max-running-requests 超出当前 KV 预算 |
降低 --max-running-requests 或扩容；--mem-fraction-static 切勿超过 0.92 |
| HTTP 400 "context length exceeded" | prompt + max_new_tokens 超出 --context-length |
调大 --context-length + HF rope_scaling；或客户端侧分 chunk |
| 多节点部署永远不收敛 | PP bubble 过大或 IB 配置错误 | 降低 PP；设 NCCL_IB_HCA, NCCL_SOCKET_IFNAME；验证 GPUDirect RDMA |
| 升级后吞吐量骤降 | FlashInfer kernel 选型回退 | 固定 SGLANG_ATTENTION_BACKEND=flashinfer 或 triton；重新跑 benchmark |
额外工程洞察：
- SGLang XGrammar 结构化生成速度快，但新 tokenizer 支持可能滞后一个版本；建议同时维护 Outlines+vLLM fallback 热备路径
- cache_hit_rate near zero 是个高频陷阱：前缀共享友好场景下用错调度策略会直接归零
标签：SGLang 生产排障 CUDA OOM NCCL KV-cache RadixAttention preemption
建议写入路径：inference/sglang-production-troubleshooting-command-reference-2026.md
是否精读：建议精读；这是目前最系统的 SGLang 生产排障资源
✅ 保留 2：BaseRT — Apple Silicon 原生 Metal 推理引擎（arXiv:2607.00501，2026-07-01）
来源：https://arxiv.org/html/2607.00501v1 | https://huggingface.co/blog/basecompute/basert-release 作者：Base Compute（墨尔本创业公司） 可信度：高（有完整 benchmark 代码环境说明，HuggingFace Blog 背书） 发布时间：2026-07-01（极新鲜）
保留理由：
核心技术： - 从零基于 Metal API 构建，无 MLX/PyTorch/CoreML 依赖，消除框架抽象开销 - Zero-allocation decode loop：KV cache 预分配至最大上下文长度，forward pass 全程无 allocator contention - Kernel fusion + simdgroup GEMM：针对 Apple Silicon 统一内存拓扑的芯片级融合核 - Amortized CPU–GPU synchronization：跨多个生成 token 分摊同步开销
Benchmark 数据（M4 Pro，16 GPU cores，24GB 统一内存）：
Decode throughput（128 生成 token，tok/s）：
| Model | Quant | BaseRT | llama.cpp | vs llama.cpp | MLX | vs MLX |
|---|---|---|---|---|---|---|
| Qwen3 0.6B | Q4 | 464.5 | 297.4 | 1.56× | 343.6 | 1.35× |
| Qwen3 0.6B | Q8 | 321.2 | 219.8 | 1.46× | 255.3 | 1.26× |
| Llama 3.2 1B | Q4 | 295.4 | 230.4 | 1.28× | 257.8 | 1.15× |
| Llama 3.2 3B | Q4 | 117.3 | 102.4 | 1.15× | 112.1 | 1.05× |
| Gemma 4 E2B | Q4 | 127.7 | 107.0 | 1.19× | — | — |
| Gemma 4 E2B | Q8 | 84.5 | 59.5 | 1.42× | — | — |
| Gemma 4 26B-A4B | Q4 | 62.2 | 58.0 | 1.07× | 69.3 | 0.90× |
| Qwen3 30B-A3B (MoE) | Q4 | 84.1 | 80.7 | 1.04× | 83.1 | 1.01× |
Prefill throughput：BaseRT 在 Qwen3-30B-A3B（MoE）上领先 MLX 最高 1.81×
对比基线：llama.cpp（commit b9630，June 2026 Metal backend）、MLX v0.31.2
工程价值判断： - Apple Silicon Mac 本地开发/测试场景的重要新选项，尤其 M4 Pro 用户 - 1B 以下小模型 decode 提升显著（Qwen3 0.6B Q4 领先 llama.cpp 56%） - 对已重度依赖 MLX 的团队有直接替代价值 - 代码量少（C++ 运行时 + C API），适合研究 Metal GPU 编程
丢弃理由：无
标签：Apple-Silicon Metal inference-runtime zero-allocation kernel-fusion M4-Pro llama.cpp MLX
建议写入路径：inference/basert-apple-silicon-metal-inference-benchmark-2026.md
是否精读：建议精读；Benchmark 数据完整，方法论可复现，是 Apple Silicon LLM 推理必读论文
✅ 保留 3：Token 在数据中心流动全链路（datagravity.dev，2026-07-01）
来源：https://www.datagravity.dev/p/how-an-ai-token-travels-through-a 作者：Chris Zeoli 可信度：高（系统级工程概述，引用了 vLLM/SGLang/NVIDIA Dynamo 论文和 Benchmark 数据） 发布时间：2026-07-01（新鲜）
保留理由：
15 站 LLM inference 完整路径，每站都有工程细节：
- Gateway → 2. TLS termination → 3. Tokenizer → 4. Request router → 5. Queue → 6. Scheduler → 7. Prefill → 8. Decode → 9. KV Cache → 10. Batching → 11. GPU memory → 12. Tensor parallelism → 13. Network/NVLink → 14. Response aggregation → 15. Streaming
核心工程洞察（数据支撑）：
- Continuous batching（vLLM 核心）：batch size 1 时 H100 streaming-multiprocessor 利用率仅 30-40%（memory-bound）；iteration-level batching 保持 GPU 饱和，吞吐量比 naive PyTorch 循环高 3-5×
- Disaggregated serving 是 2026 标准答案：将 compute-bound prefill 和 memory-bound decode 拆分到独立 GPU 池，各自独立扩缩，KV cache 池间流式传递。已被 NVIDIA Dynamo、vLLM、SGLang、llm-d、Mooncake 采纳
- TTFT / TPOT / 吞吐量 是 LLM serving 三大了了指标，对应 SLO 决策
附完整参考列表（24 条，含 vLLM PagedAttention、DistServe Disaggregated、NVLink/NVSwitch 规格、Google 3.2Q tokens/月 7× YoY、Deloitte 2026 inference ~2/3 总算力市场数据）
丢弃理由：无
标签：inference-stack disaggregated-serving continuous-batching KV-cache PagedAttention tensor-parallelism NVIDIA-Dynamo vLLM SGLang
建议写入路径：inference/llm-inference-data-center-full-path-datagravity-2026.md
是否精读：建议精读；系统级理解 LLM inference 全栈不可多得的工程概述
✅ 保留 4：llm-d CNCF Sandbox + AWS EKS KV-cache 感知路由示例（GitHub，2026-07）
来源：https://github.com/llm-d/llm-d | https://github.com/aws-samples/sample-eks-cache-aware-llm-routing 可信度：高（CNCF Sandbox 项目，背书方：Red Hat、Google Cloud、IBM Research、CoreWeave、NVIDIA） 发布时间：2026-07（持续活跃）
保留理由：
llm-d 定位：Kubernetes 原生分布式推理引擎，将单节点引擎（vLLM、SGLang）转化为生产级分布式服务，支持 NVIDIA/AMD/自定义加速器
AWS EKS 集成示例：
- 端到端路径：Client → ALB → Envoy Gateway（port 8080）→ ext-proc gRPC → llm-d EPP（Endpoint Picker）→ vLLM pod
- EPP（Endpoint Picker）评分机制：precise-prefix-cache(3) + queue(2) + kv-util(2) = 最终路由决策
- 实测收益：p90 TTFT 降低 69%（相比轮询路由）
- 架构：实时全局索引记录各 pod 上的 KV cache block 分布，每次请求精确路由到缓存亲和度最高的 pod
生产部署路径：Helm charts、Kustomize manifests、Benchmark、Observability config 均已就绪
丢弃理由：无
标签：Kubernetes llm-d CNCF-Sandbox KV-cache distributed-inference EKS Envoy prefix-caching
建议写入路径：inference/llm-d-cncf-sandbox-eks-kv-aware-routing-2026.md
是否精读：建议精读；CNCF 官方项目，生产级 K8s 推理部署参考
✅ 保留 5：vLLM vs llama.cpp vs Ollama 消费级 GPU 基准（DEV Community，2026-07）
来源：https://www.instagram.com/p/DaZoi1FjqL-（DEV 社区 benchmark 截图） 可信度：中（有具体模型、tok/s 数据，但平台为 Instagram 信息有限，建议交叉验证）
保留理由：
测试设置：RTX 3090 24GB；测试模型 1B～116.8B；对比 vLLM / llama.cpp / Ollama
关键发现： 1. vLLM 胜出场景：并发 3.9×-5.4× 吞吐量领先；但大模型超过 24GB VRAM 时直接 OOM 崩溃 2. llama.cpp RAM-spill 优势：手动 layer offload 调优，在 RAM spill 场景 TTFT 领先 Ollama 自动分割 37× 3. Ollama 局限：自动分割策略在 VRAM 溢出时性能垫底 4. 核心教训：vLLM 在显存充足时性能最优，但不适合消费级卡跑大模型；llama.cpp 是 24GB 卡的更安全选择
丢弃理由：无（具体命令/场景数据）
标签：vLLM llama.cpp Ollama consumer-GPU RTX-3090 OOM benchmark memory-offload
建议写入路径：inference/vllm-llamacpp-ollama-consumer-gpu-benchmark-2026.md
是否精读：参考；消费级 GPU 选型参考价值高，建议交叉验证
⏸️ 待定 6：MosaicKV — 长上下文 KV Cache 动态两阶段压缩（arXiv:2607.00760，2026-07）
来源：https://arxiv.org/html/2607.00760v1 可信度：高（arXiv，有完整公式、实验、baseline 对比） 发布时间：2026-07（新鲜）
待定理由： - 工程数据：cuSPARSE 处理 25%-80% 压缩 KV cache，延迟比未压缩基准高 25-136×（overhead 来源：格式转换 + 不适合 LLM 稀疏度） - MosaicKV 使用 underutilized CUDA cores + 打包 KV 格式，实测压缩/解压缩 overhead 在可接受范围 - 评测覆盖：仓库级代码生成、多文档 QA、多轮 agentic workflow
保留门槛：需要确认实际 production 部署案例或官方 benchmark 脚本；目前偏学术，可降级为"背景参考"
标签：KV-cache long-context compression MosaicKV sparse-attention
建议写入路径：inference/kv-cache-compression-landscape-mosaickv-2026.md
⏸️ 待定 7：KernelSight-LM — 内核级 LLM 推理模拟器（arXiv:2606.28565v2）
来源：https://arxiv.org/html/2606.28565v2 可信度：高（arXiv，方法论完整） 发布时间：2026-06（次新）
待定理由： - 端到端离散事件模拟器：roofline×efficiency model + per-kernel latency prediction + 离散事件调度 - 实验环境：NGC PyTorch container (26.04-py3)，vLLM v0.19.0，CUDA 13 - 支持 hierarchical prefix caching（GPU volatile + disk persistent 两层） - 指标：MAPE（Mean Absolute Percentage Error）用于评估预测精度 - 工程价值：架构设计/容量规划工具，非生产直接可用
保留门槛：评估论文实际可复现性；是否有开源代码；可降级为"建模参考"
标签：inference-simulator KV-cache roofline-model MAPE vLLM simulation
建议写入路径：inference/kernelsight-lm-inference-simulator-2026.md
⏸️ 待定 8：OmniPilot — 异构 GPU 集群 LLM 推理Advisor（arXiv:2607.01579）
来源：https://arxiv.org/html/2607.01579v1 可信度：高（arXiv） 发布时间：2026-07（新鲜）
待定理由： - 在请求提交前选择 GPU型号/TP度数/量化精度，并拒绝超出测量范围的请求 - 类似 Helix（ASPLOS 2025），但额外建模量化精度和不确定性校准 - 论文引用完整（vLLM、Orca、SGLang、Helix、Mooncake 均在文献中） - 工程门槛：无公开 production 部署案例
保留门槛：是否有开源代码仓；与 Helix 的具体差异；可降级为"调度研究方向"
标签：heterogeneous-GPU scheduling quantization inference-advisor OmniPilot
建议写入路径：inference/omnipilot-heterogeneous-gpu-cluster-llm-advisor-2026.md
⏸️ 待定 9：Hypic — 位置无关 KV Cache 加速 RAG/Agentic Prompt（arXiv:2607.01299）
来源：https://arxiv.org/html/2607.01299v1 可信度：高（arXiv） 发布时间：2026-07（新鲜）
待定理由： - Position-Independent Caching（PIC）：解决严格前缀匹配无法处理 RAG/agentic prompt 动态组装的问题 - 与现有 PIC 系统比较：Hu et al. 2025、Wang et al. 2025、Yao et al. 2025、Liu et al. 2026 等均有覆盖 - 核心公式：segment 并行将 cache-miss prefill 从 O(n·|C|) 降至 O(⌈n/m⌉·|C|+c) - 对 RAG 工程团队有直接参考价值，但需确认实际落地案例
保留门槛：实际部署收益量化数据；可降级为"RAG 系统设计参考"
标签：RAG agentic-prompt KV-cache position-independent segment-parallelism
建议写入路径：rag/hypic-position-independent-kv-cache-rag-2026.md
⏸️ 待定 10：HBM Is Not All You Need — 跨供应商分解式推理（arXiv:2606.29986）
来源：https://arxiv.org/pdf/2606.29986 可信度：高（arXiv + ACM 引用格式，2026-06-29） 发布时间：2026-06-29（极新鲜）
待定理由： - Tenstorrent prefill worker + A100 decode worker 通过 100 Gbps RoCE 连接 - 三机制：per-hardware 原生精度 + compute-transfer pipeline 隐藏 KV egress + cross-vendor split 性能杠杆 - 对异构 GPU 集群有参考价值，但需完整论文数据
保留门槛：完整 benchmark 数据；与 NVIDIA Dynamo/Mooncake 的具体性能对比
标签：disaggregated-serving Tenstorrent cross-vendor prefill-decode HBM
建议写入路径：inference/hbm-is-not-all-you-need-tenstorrent-disaggregated-2026.md
⏸️ 待定 11：Awesome Harness Engineering（GitHub，2026-07）
来源：https://github.com/ai-boost/awesome-harness-engineering 可信度：中（社区维护精选列表） 发布时间：2026-07（活跃）
待定理由： - 收录：AgentDebug（ICLR 2026，Agent Error Taxonomy，+24% all-correct accuracy）、TraceCoder（ICSE 2026-02，多 Agent 调试 +34.43% Pass@1）、SWE-bench、Claw-Eval（Meta/Kimi/Qwen/腾讯引用） - 列表本身有工程价值，但具体条目是否包含命令/源码需逐一点开确认 - 本次筛选中已从该列表发现 TraceCoder 和 AgentDebug，但这两个条目是否可复现需进一步验证
保留门槛：逐条验证；本轮暂不写入
标签：harness agent-eval SWE-bench AgentDebug TraceCoder
建议写入路径：engineering/awesome-harness-engineering-list-2026.md
❌ 丢弃 1：PyTorch 深度学习框架 Bug 静态分析（arXiv:2607.00555）
来源：https://arxiv.org/html/2607.00555v1 丢弃理由： - 主题为"静态分析找 PyTorch DNN 框架 bug"（31 个 bug：CPU 9 / CUDA 7 / MPS 2 / 其他 13） - 属于 ML 框架内部测试工具研究，非生产推理系统工程 - 无具体 CUDA/PyTorch bug 修复命令或 OOM 场景处理步骤 - 对推理引擎开发者有参考价值，但对知识库的工程定位不符
丢弃理由：与 LLM 推理系统工程相关性不足，主题偏 ML 框架内部 bug 分析
本次筛选统计
| 类别 | 数量 |
|---|---|
| ✅ 保留（可直接写入） | 5 |
| ⏸️ 待定（需二次确认） | 7 |
| ❌ 丢弃 | 1 |
| 合计 | 13 |
高优先级写入任务（本次实际写入）
写入路径：/shared/research-kb/inbox/jay/2026-07-07-1055-engineering-filter-round1-jul2026-inference-sglang-basert-llmd.md（即本文件）
关键工程洞察总结
-
SGLang 生产排障速查表（2026-07-04 更新）是目前最系统的 SGLang 生产运维参考，8 种高频错误均有命令级修复方案
-
BaseRT（2026-07-01）是 Apple Silicon 本地推理的重大突破，M4 Pro 上 Q4 量化小模型 decode 领先 llama.cpp 最高 56%，对本地开发/测试有直接替代价值
-
Disaggregated serving（prefill/decode 分离）是 2026 年事实标准，被 vLLM/SGLang/llm-d/NVIDIA Dynamo/Mooncake 全面采纳
-
llm-d + AWS EKS KV-aware routing 展示了 prefix caching 在多租户 K8s 环境下的精准路由实践，p90 TTFT 降低 69% 的数字有直接工程参考价值
-
vLLM vs llama.cpp 消费级 GPU 选择：24GB 卡跑并发小模型选 vLLM；跑大模型（VRAM 溢出）选 llama.cpp 手动 offload；Ollama 在 RAM-spill 场景性能垫底
下次筛选方向建议：继续追踪 2026-07 第二周的 arXiv inference systems 新增论文，重点关注 disaggregated serving 和 KV cache offloading 的生产验证案例