Inference与Prediction本质区别：从模型上线到GPU显存爆掉的全链路解析

1. 这两个词天天见，但90%的人根本没分清——从模型上线第一天就踩坑的根源

“Inference”和“Prediction”在机器学习工程现场、论文答辩、技术面试、甚至日常站会里高频出现，但只要深入聊两句，很多人立刻开始含糊其辞：有人说“ inference 就是预测”，有人讲“prediction 是 inference 的结果”，还有人干脆说“不就是一回事？换着叫罢了”。我带过七支AI落地团队，亲手部署过200+个模型服务，最常听到的崩溃瞬间是：后端同学改完代码自信提交，测试环境一跑，日志里赫然报错model.inference() not implemented，而他写的其实是model.predict()；或者算法同学发来一份评估报告，标题写着《Inference Latency Analysis》，里面却全是 accuracy、F1、AUC 这些 prediction-level 指标——两边对不上频，协作卡在第一关。这不是术语考据癖，而是直接影响模型能否上线、性能能否达标、AB实验能否归因、故障能否快速定位的核心认知断层。本文不讲教科书定义，只讲我在真实产线中用血泪验证过的判断逻辑：inference 是模型在特定硬件与运行时约束下的一次完整执行过程，prediction 是该过程中产出的、面向业务目标的结构化输出结果。它像“开车”和“到目的地”——你不能说“我开车了”就等于“我到了”，也不能把“导航显示还剩5公里”当成“油箱还剩多少油”。适合刚学完 sklearn 的新手厘清概念边界，也适合已上线模型但总被SRE追问“为什么GPU显存爆了”的工程师回溯执行链路。下面所有内容，都来自我拆解过的137个失败case、42次跨团队对齐会议记录，以及在Kubernetes集群里盯着Prometheus面板调参到凌晨三点的真实经验。

2. 核心设计逻辑：为什么必须严格区分二者？——从CPU缓存行到业务KPI的全链路影响

2.1 本质差异不是语义游戏，而是计算范式的分水岭

很多初学者以为这只是命名习惯问题，实则完全相反：inference 和 prediction 分属两个不同抽象层级，强行混用会导致系统设计从根上失稳。Prediction 是纯数学/统计概念，它只关心输入X映射到输出Y的函数关系 f(X)→Y，比如一个二分类模型输出 [0.82, 0.18]，prediction 就是“类别A，置信度82%”。这个过程可以脱离任何物理载体存在——你在纸上手算、用计算器按、甚至靠心算，只要结果正确，它就是 valid prediction。而 inference 是工程实现概念，它强制绑定三个不可剥离的要素：模型权重（what）、运行时环境（where）、执行策略（how）。举个极端例子：同一个.pt文件，在 CPU 上用 PyTorch 原生model(input)调用，和在 NVIDIA T4 GPU 上用 TensorRT 优化后通过 C++ API 加载，哪怕输入输出数值完全一致，它们也是两次完全不同的 inference —— 因为内存布局、kernel 调度、数据搬运路径、甚至浮点运算精度截断方式都不同。我曾亲眼见过一个金融风控模型，在 A100 上 inference 耗时 12ms，准确率 99.23%，但迁移到客户现场的旧款 P4 服务器后，inference 耗时飙升至 89ms，且因 CUDA 版本兼容问题导致部分 batch 出现 NaN 输出——此时 prediction 结果已失效，但问题根源绝不在算法本身，而在 inference 环境的迁移失配。

提示：当你听到“这个模型 prediction 不准”，第一反应不该是重训模型，而应立即检查 inference pipeline：输入预处理是否与训练时一致？Tensor shape 是否被意外 reshape？量化参数是否在加载时丢失？——90% 的“prediction不准”实为 inference 异常的表象。

2.2 架构决策的分水岭：选错抽象层，整套系统都会“慢性死亡”

区分二者直接决定技术选型和架构走向。以一个电商推荐系统为例：如果团队将“生成用户Top10商品列表”笼统称为 prediction，那么很自然会倾向选择 sklearn 或 lightgbm 这类单机库，因为“反正只是算个分数”。但当DAU从10万涨到500万，QPS峰值突破3万时，问题就来了——单机无法水平扩展，特征实时拼接延迟高，模型版本灰度难控制。而若从 inception 就明确定义：这是 high-throughput, low-latency inference task，核心指标是 p99 latency ≤ 50ms 和 throughput ≥ 5000 req/s，那么技术栈会天然导向 TensorFlow Serving + gRPC + Kubernetes HPA 的组合，并提前规划特征服务（Feature Store）和模型编排（Model Orchestrator）。我们曾有个项目，算法同学坚持用 pickle 保存 XGBoost 模型，理由是“prediction 逻辑简单”。上线后发现单实例 CPU 利用率常年 98%，扩容后因无状态设计缺失导致 session 特征丢失，最终不得不推翻重做。后来复盘，根本症结在于：他们把 prediction 当成了终点，而忽略了 inference 才是生产环境真正的起点。

2.3 成本与可观测性的底层锚点：没有 inference 视角，一切优化都是盲人摸象

云厂商账单、GPU利用率、API响应时间分布、内存泄漏追踪……所有可观测性指标都锚定在 inference 层。Prediction 指标（如 accuracy）无法告诉你为什么 P99 延迟突然从 35ms 涨到 120ms。去年我们一个NLP服务出现间歇性超时，监控显示 GPU 显存使用率稳定在 65%，但nvidia-smi却发现显存碎片率高达 40%。排查三天后定位到：PyTorch 的torch.jit.script在动态 shape 输入下触发了隐式显存重分配，而 prediction 逻辑本身完全正确。这就是典型的 inference 层问题掩盖 prediction 表象。更残酷的是成本——AWS SageMaker 按 instance-hour 计费，但真正烧钱的是 inference duration × concurrency。我们测算过：一个 BERT-base 模型在 m5.2xlarge（CPU）上 inference 平均耗时 180ms，而在 g4dn.xlarge（GPU）上仅需 22ms，但后者每小时成本是前者的 2.3 倍。表面看 GPU 更贵，但考虑并发能力（CPU 实例最大并发 8，GPU 可达 64），实际单请求成本 GPU 反而低 40%。这种决策，必须建立在对 inference 全链路（模型加载、tensor copy、kernel launch、memory sync）的精确建模上，而非泛泛讨论“prediction 效果”。

3. 关键细节解析：从代码签名到硬件指令，拆解 inference 与 prediction 的七处关键分界点

3.1 函数签名：最直观的“身份认证”

几乎所有主流框架都通过函数签名强制区分二者。以 PyTorch 为例：

# ❌ 错误示范：混淆抽象层 class FraudDetector(nn.Module): def forward(self, x): # 这是 prediction 的数学接口 return self.classifier(x) def predict(self, x): # 这是 inference 的工程接口，但未体现环境约束 with torch.no_grad(): return self.forward(x).argmax(dim=1) # ✅ 正确实践：inference 接口显式声明运行时契约 class FraudDetectorInference: def __init__(self, model_path: str, device: str = "cuda:0"): self.model = torch.jit.load(model_path).to(device) self.device = device self.preprocessor = FeaturePreprocessor() # 绑定预处理 def inference(self, raw_input: Dict[str, Any]) -> Dict[str, Any]: """完整 inference 链路：输入校验 → 预处理 → tensor 转换 → 设备搬运 → 模型执行 → 后处理 → 结构化输出""" try: features = self.preprocessor.transform(raw_input) # prediction 不关心此步 tensor_input = torch.tensor(features).to(self.device) # inference 必须指定设备 with torch.inference_mode(): # PyTorch 2.0+ 推荐，比 no_grad 更轻量 logits = self.model(tensor_input) # 后处理：prediction 逻辑在此封装，但受 inference 环境约束 return { "prediction": logits.argmax(dim=1).item(), "confidence": torch.softmax(logits, dim=1).max().item(), "inference_latency_ms": time.time() - start_time # inference 特有指标 } except Exception as e: raise InferenceRuntimeError(f"Inference failed on {self.device}: {e}")

关键点在于：inference()方法必须显式接收raw_input（原始业务数据），内部完成全部转换，并返回包含inference_latency_ms的结构化字典。而predict()若存在，应仅为inference()的简化 wrapper，且仅用于离线评估——这正是 scikit-learn 中predict()的定位：它假设输入已是标准numpy.ndarray，且运行环境无资源约束。

3.2 输入输出契约：prediction 是数据，inference 是协议

我们曾因忽略此差异付出代价：一个图像分类服务对外提供predict(image_bytes)接口，但未做输入校验。某次上游传入损坏的 JPEG 文件，PIL 解码失败抛出OSError，而服务未捕获该异常，导致整个 gRPC stream 断连。修复方案不是加 try-catch，而是重构为inference(request: ImageRequest) -> ImageResponse，在 request schema 中明确定义image_bytes: bytes, image_format: Enum["jpeg","png"]，并在反序列化层统一拦截格式错误——这正是 inference 协议的价值：它把边界问题收束到接口定义层。

3.3 时间维度：prediction 是瞬时快照，inference 是持续过程

Prediction 是一个数学上的点操作：给定 X，求 Y。而 inference 是一个有生命周期的过程，包含明确的阶段：

1. Warm-up phase：模型加载、权重初始化、CUDA context 创建（首次 inference 永远最慢）
2. Steady-state phase：批量处理、内存复用、kernel 优化（此时 latency 才稳定）
3. Teardown phase：显存释放、连接关闭（尤其 serverless 场景）

我们在 AWS Lambda 部署 OCR 模型时发现：cold start 平均耗时 2.1s，warm start 仅 83ms。若只关注 prediction accuracy，会误判“模型太慢”；而从 inference 视角，解决方案是启用 Provisioned Concurrency（预置并发），让 Lambda 实例常驻 warm state。同样，Kubernetes 中的 HPA（Horizontal Pod Autoscaler）扩缩容依据必须是 inference QPS 和 p95 latency，而非 prediction accuracy——后者是静态指标，无法反映系统负载。

3.4 内存视角：prediction 只要结果，inference 要管全过程内存足迹

Prediction 关注输出 tensor 的 shape 和 dtype；inference 必须管理整个内存生命周期：

• 模型权重内存：FP16 vs FP32 加载差异（BERT-large FP32 约 1.3GB，FP16 仅 650MB）
• 激活内存（Activation Memory）：反向传播不需，但推理时仍需存储中间 tensor（影响 batch size 上限）
• KV Cache 内存（LLM 专属）：自回归生成中 key/value 缓存，随 sequence length 线性增长

我们部署 LLaMA-7B 时，发现 batch_size=1 时显存占用 9.2GB，但 batch_size=4 时飙升至 14.7GB——并非线性增长，因为 KV Cache 占用激增。此时调整 prediction 逻辑（如减少 max_new_tokens）无效，必须从 inference 层优化：启用 FlashAttention-2（减少 KV Cache 显存）、开启 PagedAttention（内存分页管理）、或改用 vLLM 推理引擎。这些全是 inference 层专属技术，与 prediction 数学无关。

3.5 硬件亲和性：prediction 无硬件属性，inference 天生绑定芯片

同一 prediction 逻辑，在不同硬件上可能需要完全不同的 inference 实现：

我们曾将一个 TensorFlow 模型直接部署到 Coral Dev Board，结果报错Unsupported operation: Conv2D。根源是 Edge TPU 编译器不支持某些高级 padding 模式，必须重写 inference preprocessing layer。而 prediction 逻辑（卷积计算本身）完全正确——这再次证明：prediction 是算法，inference 是工程。

3.6 安全与合规：prediction 关注数据隐私，inference 关注运行时安全

GDPR 和 CCPA 要求对 prediction 结果进行 anonymization（如差分隐私加噪），但这属于 prediction 后处理。而 inference 层的安全威胁完全不同：

• 侧信道攻击：通过 inference latency 波动推断模型结构（如 CNN 层数）
• 模型窃取：恶意客户端发送精心构造的 input，通过 prediction 输出反推权重
• 拒绝服务：发送超大尺寸 input 导致 inference 进程 OOM

我们的金融风控服务曾遭遇此类攻击：攻击者发送 10MB 的 base64 编码字符串，触发特征提取模块无限循环。修复方案是在 inference gateway 层设置 strict input validation：max_request_size=2MB,max_feature_count=500,timeout_ms=5000——这些全是 inference runtime 的防护策略，与 prediction 准确率无关。

3.7 版本管理：prediction 版本 = 模型权重，inference 版本 = 全栈快照

一个 prediction 版本（如model_v2.1.0.pt）只代表权重文件。而一个 inference 版本必须是原子化的全栈快照：

# inference_version_v2.1.0.yaml model: weight_hash: "sha256:abc123..." # 权重指纹 framework: "pytorch_2.1.0" preprocessor: version: "feature_engine_v3.2.1" config_hash: "sha256:def456..." runtime: docker_image: "inference-server:2.1.0-gpu-cuda11.8" resource_limits: memory: "4Gi" nvidia.com/gpu: 1 postprocessor: version: "score_calibrator_v1.0.0"

我们推行此规范后，线上事故平均定位时间从 47 分钟降至 6 分钟——因为 SRE 可直接拉取对应 inference version 的完整镜像，在本地复现问题，无需再手动拼凑“模型+预处理+配置”的混沌组合。

4. 实操过程：从本地 Jupyter 到千卡集群，一次完整的 inference-prediction 对齐实战

4.1 场景设定：构建一个实时新闻情感分析服务

业务需求：对用户提交的新闻标题（<100字符）实时返回情感极性（positive/negative/neutral）及置信度，要求 p99 latency ≤ 100ms，日均处理 5000 万请求。技术栈：Hugging Face Transformers（prediction logic），Triton Inference Server（inference runtime），Kubernetes（orchestration）。

4.2 Step-by-step 实操：如何让 prediction 逻辑安全落地为 production inference

Step 1：固化 prediction 逻辑，剥离环境依赖

首先在 Jupyter 中验证 prediction 数学正确性：

from transformers import AutoTokenizer, AutoModelForSequenceClassification import torch # ✅ Prediction-only 代码：专注数学正确性 tokenizer = AutoTokenizer.from_pretrained("cardiffnlp/twitter-roberta-base-sentiment-latest") model = AutoModelForSequenceClassification.from_pretrained("cardiffnlp/twitter-roberta-base-sentiment-latest") def predict_sentiment(text: str) -> dict: inputs = tokenizer(text, return_tensors="pt", truncation=True, max_length=64) with torch.no_grad(): outputs = model(**inputs) probs = torch.nn.functional.softmax(outputs.logits, dim=-1) label_id = probs.argmax().item() confidence = probs[0][label_id].item() labels = ["negative", "neutral", "positive"] return {"label": labels[label_id], "confidence": confidence} # 测试 print(predict_sentiment("Stock market crashes!")) # {'label': 'negative', 'confidence': 0.98}

注意：此代码绝不出现device=、batch_size=、onnx_export等 inference 相关参数，它是 pure prediction contract。

Step 2：导出为 inference-ready 格式（ONNX）

prediction 逻辑验证无误后，进入 inference 准备阶段。关键动作：固定输入 shape、消除动态控制流、量化精度。

# ✅ Export for inference: 生成可部署的 ONNX 模型 dummy_input = tokenizer( "dummy text", return_tensors="pt", truncation=True, max_length=64 ) # 注意：必须指定 dynamic_axes 以支持变长输入，但限定范围 torch.onnx.export( model, (dummy_input.input_ids, dummy_input.attention_mask), "sentiment_model.onnx", input_names=["input_ids", "attention_mask"], output_names=["logits"], dynamic_axes={ "input_ids": {0: "batch_size", 1: "sequence_length"}, "attention_mask": {0: "batch_size", 1: "sequence_length"}, "logits": {0: "batch_size"} }, opset_version=15, do_constant_folding=True )

实操心得：ONNX export 失败最常见的原因是模型中存在if len(x) > 0:这类 Python 控制流。解决方法是重写为torch.where或torch.nn.functional.pad—— 这正是 prediction 与 inference 的分界：prediction 可以用任意 Python 逻辑，inference 必须转为可图优化的 tensor 操作。

Step 3：编写 Triton inference server 配置

创建config.pbtxt，这是 inference 的“宪法”：

name: "sentiment_model" platform: "onnxruntime_onnx" max_batch_size: 32 # inference 层批处理能力，prediction 不关心 input [ { name: "input_ids" data_type: TYPE_INT64 dims: [ -1 ] # dynamic, but bounded by max_sequence_length }, { name: "attention_mask" data_type: TYPE_INT64 dims: [ -1 ] } ] output [ { name: "logits" data_type: TYPE_FP32 dims: [ 3 ] # fixed output size for 3 classes } ] instance_group [ [ { count: 2 # 每个 GPU 启动 2 个实例，提升并发 kind: KIND_GPU } ] ] # inference 特有优化 optimization { execution_accelerators : [ { gpu_execution_accelerator : [ { name : "tensorrt" } # 启用 TensorRT 加速 ] } ] }

Step 4：实现 inference endpoint（Python Backend）

Triton 支持自定义 backend，此处封装 prediction 逻辑：

# model.py import triton_python_backend_utils as pb_utils import numpy as np from transformers import AutoTokenizer class TritonPythonModel: def initialize(self, args): self.tokenizer = AutoTokenizer.from_pretrained( "cardiffnlp/twitter-roberta-base-sentiment-latest" ) self.labels = ["negative", "neutral", "positive"] def execute(self, requests): responses = [] for request in requests: # 1. Extract raw input (inference input) title = pb_utils.get_input_tensor_by_name(request, "title").as_numpy()[0].decode() # 2. Preprocessing (inference responsibility) inputs = self.tokenizer( title, return_tensors="np", truncation=True, max_length=64 ) # 3. Call underlying model (prediction execution) input_ids = pb_utils.Tensor("input_ids", inputs["input_ids"].astype(np.int64)) attention_mask = pb_utils.Tensor("attention_mask", inputs["attention_mask"].astype(np.int64)) # 4. Postprocessing (inference output shaping) inference_response = pb_utils.InferenceResponse( output_tensors=[ pb_utils.Tensor("label", np.array([self.labels[probs.argmax()]], dtype=object)), pb_utils.Tensor("confidence", np.array([probs.max()], dtype=np.float32)) ] ) responses.append(inference_response) return responses

Step 5：压测与调优——inference 层的黄金三参数

部署后，用 locust 进行压测，重点关注三个 inference 特有参数：

压测结果：QPS 从 1200（单实例）提升至 4800（3实例+dynamic batching），p99 latency 稳定在 87ms，满足 SLA。

4.3 关键配置参数详解：为什么这些数字不是拍脑袋定的？

Batch Size = 24 的计算依据：

• 模型显存占用（FP16）：约 1.2GB / instance
• GPU 总显存（A10）：24GB
• 系统预留：2GB（CUDA context + OS）
• 可用显存：22GB
• 最大实例数：22GB / 1.2GB ≈ 18
• 但每个实例需额外显存存放 batch tensor：batch_size=24 时，input_ids shape=(24,64) → 24×64×2bytes=3KB，可忽略
• 实际瓶颈是 KV Cache：RoBERTa 无 KV Cache，故 batch_size 主要受显存带宽限制
• 实测：batch_size=32 时，PCIe 带宽打满，p99 跳变；batch_size=24 时，GPU 利用率 78%，带宽占用 65%，最稳

Dynamic Batching Delay = 10ms 的依据：

• 业务容忍首字节延迟：≤ 15ms
• 网络 RTT（client to server）：平均 3ms
• 模型执行时间（batch_size=1）：平均 1.2ms
• 剩余缓冲：15 - 3 - 1.2 = 10.8ms → 取整 10ms
• 若设为 20ms，虽吞吐更高，但 10% 请求会超时

这些数字背后全是硬件实测数据，绝非理论估算。这也是为什么我说：inference 工程师必须懂 CUDA、懂 PCIe、懂 Linux 内存管理——否则你调的不是参数，是玄学。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在看 Grafana 的坑

5.1 “Prediction 准确率 99%，但线上 inference 全是错的！”——预处理不一致的幽灵

现象：离线评估 accuracy=0.992，线上 inference 返回的 label 与本地 predict() 完全不同，且错误呈现规律性（如所有 negative 都被识别为 neutral）。

排查路径：

1. 抓取线上 inference 的 raw input（用 logging middleware 记录request.title）
2. 在本地用完全相同的代码重放：predict_sentiment(grabbed_title)
3. 结果仍正确 → 问题在 inference pipeline
4. 检查 Triton 的 preprocessing：发现 tokenizer 被错误初始化为AutoTokenizer.from_pretrained("bert-base-uncased")，而非正确的 RoBERTa tokenizer
5. 根源：Triton backend 的initialize()方法中硬编码了错误模型名

避坑技巧：

• 所有预处理组件必须与 prediction 代码共用同一份配置文件（如config.yaml），禁止硬编码
• 在 inference 初始化时添加 checksum 验证：assert tokenizer.name_or_path == "cardiffnlp/twitter-roberta-base-sentiment-latest"
• 上线前必做“shadow run”：将线上流量复制一份，同时发给新旧 inference service，diff 输出结果

5.2 “GPU 显存用了 99%，但利用率只有 12%！”——内存带宽瓶颈的典型症状

现象：nvidia-smi显示 GPU-Util 10~15%，但显存占用 95%，inference latency 高且波动大。

根本原因：模型权重加载到显存，但计算 kernel 未充分利用 GPU core，数据搬运（host-to-device）成为瓶颈。常见于：

• 输入 tensor 过小（如 batch_size=1 的单条请求）
• 模型存在大量 small kernels（如逐元素操作），无法填满 GPU warp
• PCIe 带宽不足（如使用 PCIe 3.0 x8 而非 x16）

解决方案：

• 强制开启 dynamic batching（Triton 默认关闭）
• 使用torch.compile()（PyTorch 2.0+）融合小 kernel
• 升级硬件：从 T4（PCIe 3.0）换到 A10（PCIe 4.0），带宽翻倍

实操心得：不要迷信nvidia-smi的 GPU-Util。真正要看的是nvidia-smi dmon -s u中的sm__inst_executed（shader core 指令数）和dram__bytes_read（显存读取字节数）。当后者远高于前者，就是典型的 memory-bound。

5.3 “为什么同样的模型，A/B 测试中 group B 的 inference latency 高 3 倍？”——特征分布漂移引发的 inference 异常

现象：A/B 测试中，group B 的 p99 latency 是 group A 的 3.1 倍，但 prediction accuracy 相同。

深挖发现：group B 用户提交的新闻标题平均长度为 87 字符，group A 为 42 字符。而模型 max_length=64，导致 group B 大量样本被 truncation，且 truncation 策略（longest_first）引发不规则的 attention_mask pattern，破坏了 TensorRT 的 kernel 优化。

根治方案：

• 在 inference preprocessor 中添加 length-aware routing：短文本走 fast path（64-token model），长文本走 robust path（128-token model + 更强硬件）
• 监控输入分布：用 Prometheus 记录input_length_buckethistogram，设置告警rate(input_length_bucket_count{le="64"}[1h]) < 0.95
• prediction 评估必须包含 distribution shift 测试：用 production data distribution 采样测试集，而非随机 split

5.4 “Inference service 启动就 crash，日志只显示 ‘segmentation fault’”——C++ runtime 的经典陷阱

现象：Triton server 启动时报Segmentation fault (core dumped)，无有效堆栈。

终极排查法：

1. 用gdb --args tritonserver --model-repository=/models
2. (gdb) run
3. (gdb) bt查看崩溃点
4. 常见于：ONNX 模型中存在 unsupported op（如GatherElements），或 CUDA driver 版本与 Triton 编译版本不匹配

预防措施：

• 使用onnx.checker.check_model(model)验证 ONNX 模型
• 在 CI 中加入tritonserver --model-repository=/tmp/test --strict-model-config=false --log-verbose=1启动测试
• 固定 CUDA driver 版本：Triton 2.34 要求 driver ≥ 525.60.13，必须写入 Dockerfile

5.5 “Prediction 结果每天变，但模型权重没更新！”——时间戳泄露的隐形 bug

现象：模型权重和代码完全冻结，但线上 prediction 结果每天有微小波动（accuracy ±0.003）。

真相：预处理中使用了datetime.now()生成 salt 用于特征哈希，而 inference server 跨多个 timezone 部署，导致 hash 结果不一致。

教训：

• inference 中所有随机性必须可控：np.random.seed(42)，torch.manual_seed(42)
• 禁止在 preprocessing 中使用任何全局状态（time, random, global dict）
• 所有“动态”行为必须显式传入：preprocess(text, timestamp=None)，默认 None 表示 deterministic mode

6. 经验总结：一个 inference 工程师的自我修养

我在一线踩过的最大坑，不是模型不准，而是把 prediction 当 inference 用。记得第一个项目上线前夜，我信心满满地把 Jupyter 里的model.predict()封装成 Flask API，结果首波流量涌入，服务器内存直接爆掉——因为predict()每次都新建 tokenizer 和 model 实例，而我没做任何对象复用。那时我才真正明白：prediction 是学术语言，inference 是工程语言；prediction 关注 what，inference 关注 how, where, when, and at what cost。现在我的团队有条铁律：所有 PR 必须回答三个问题：1）这个改动影响 prediction 还是 inference？2）如果是 inference，它改变了哪个资源维度（CPU/GPU/内存/网络）？3）它的 failure mode 是什么？（OOM？timeout？silent corruption？）

最后分享一个私藏技巧：每次设计新 inference service，我都会画一张“inference boundary map”——用不同颜色标注哪些组件属于 prediction（蓝色）、哪些属于 inference（红色）、哪些是 shared（灰色）。比如 tokenizer：训练时是 prediction 组件（用于生成 dataset），部署时是 inference 组件（必须与 model 同步加载）。这张图贴在团队白板上，谁提需求先指图说话。三年下来，跨团队沟通效率提升 70%，因为大家终于说同一种语言了。

你现在的理解，是否已经和三个月前的自己不一样了？