尧图网页设计 
1. 从零手搓AI工程为什么我不建议你直接调包很多人一上来就想搞个大模型应用第一反应是找现成的API或者开源框架三行代码跑通一个对话机器人然后觉得自己已经入门了。我刚开始也这么干过结果呢线上流量稍微一波动延迟直接飙到十几秒账单翻了三倍排查问题的时候连瓶颈在哪都说不清楚。后来我花了整整两个月时间把整个链路从最底层重新实现了一遍才真正搞明白每个环节到底在干什么。ai-engineering-from-scratch这个方向核心不是让你重复造轮子而是让你具备“拆轮子”的能力。它解决的是一个非常具体的问题当现成方案不work的时候你有没有能力定位到根因并且自己动手改。适合谁看如果你已经会调API、会写Prompt但一遇到性能问题、成本问题、效果不稳定就束手无策那这篇内容就是给你准备的。我会从推理引擎的最小实现开始一路讲到服务化部署和监控把每个关键决策背后的“为什么”掰开揉碎。先泼一盆冷水从零实现不等于不用任何库。我的原则是核心链路的每一行代码我都要能解释清楚它在干什么辅助工具该用就用。比如矩阵运算我肯定用NumPy但推理调度逻辑我必须自己写。这个边界感很重要否则你要么陷入无意义的重复劳动要么永远停留在调包层面。2. 推理引擎的最小可行实现2.1 为什么从推理而不是训练开始训练一个模型动辄需要几十张卡、几天时间对个人开发者来说门槛太高。但推理不一样你可以在单张消费级显卡上跑通整个流程而且推理阶段暴露的问题更贴近实际生产环境——延迟、吞吐、显存占用、批处理策略这些都是工程化的核心。我建议的路径是先拿一个已经训练好的小模型比如TinyLlama或者Qwen的小尺寸版本把它的推理过程完整实现一遍理解每个张量是怎么流动的。具体来说你需要实现这几个模块模型加载权重解析和映射、前向计算Attention、FFN、LayerNorm、KV Cache管理、采样策略贪心、Top-k、Top-p。听起来很多但每个模块的核心代码其实不超过50行。关键是你要理解为什么需要KV Cache——没有它每生成一个token都要重新计算所有历史token的Key和Value计算量随序列长度平方增长。有了KV Cache每步只需要计算当前token的Key和Value然后拼接到缓存里计算量变成线性增长。2.2 手写Attention的避坑指南Attention的公式大家都知道softmax(QK^T/√d)V。但实际写代码的时候有几个细节特别容易翻车。第一个是维度对齐Q、K、V的head维度必须一致但序列长度可以不同。我见过有人把batch维度和head维度搞混结果训练能跑但推理结果完全不对。第二个是mask的处理decoder-only模型需要causal mask确保每个位置只能看到自己和之前的位置。这个mask矩阵的构造方式直接影响生成质量如果mask写错了模型会“偷看”未来token生成结果看起来通顺但逻辑混乱。第三个坑是数值稳定性。softmax在输入值很大的时候会溢出标准做法是先减去最大值。这个操作在训练框架里是自动处理的但你自己实现的时候如果忘了模型输出会变成NaN。我当时的排查过程是这样的先检查输入数据有没有异常值再逐层打印中间结果最后定位到softmax那一步。所以我的建议是每实现一个模块都写一个小的单元测试用已知输入验证输出是否符合预期。import numpy as np def softmax(x, axis-1): x_max np.max(x, axisaxis, keepdimsTrue) exp_x np.exp(x - x_max) return exp_x / np.sum(exp_x, axisaxis, keepdimsTrue) def attention(Q, K, V, maskNone): d_k Q.shape[-1] scores np.matmul(Q, K.transpose(0, 1, 3, 2)) / np.sqrt(d_k) if mask is not None: scores scores mask * -1e9 weights softmax(scores, axis-1) return np.matmul(weights, V)这段代码看起来简单但你要确保Q、K、V的shape是(batch, heads, seq_len, head_dim)。我第一次写的时候把heads和seq_len搞反了结果attention权重矩阵的形状完全不对生成出来的东西全是乱码。后来我养成了一个习惯在每个矩阵运算后面打印shape确认无误后再继续。2.3 KV Cache的内存管理策略KV Cache是推理加速的核心但它也是显存杀手。假设模型有32层每层有32个head每个head维度是128序列长度是2048batch size是8那么KV Cache的大小是2Key和Value× 32层 × 32头 × 128维 × 2048长度 × 8批次 × 2字节FP16 8GB左右。这还只是KV Cache加上模型权重和中间激活值显存直接爆炸。所以你需要实现一个缓存管理策略。常见的有两种一种是预分配固定大小的缓存池按需分配和回收另一种是分页管理类似操作系统的虚拟内存。我推荐先从预分配开始实现简单且足够应对大多数场景。具体做法是根据最大序列长度和最大batch size预先分配一块连续显存每个请求进来时分配一个slot请求结束后回收。这样避免了频繁的内存分配和释放性能更稳定。注意预分配的大小要留有余量但也不能太大否则浪费显存。我的经验是按照实际业务场景的P99序列长度来设定比如你的用户平均输入200token输出500token那最大序列长度设为1024就够用了没必要设成4096。3. 服务化部署的核心环节3.1 从单机推理到HTTP服务模型能在本地跑通之后下一步就是把它变成一个服务。很多人直接用Flask写个接口就上线了结果并发一上来就崩。问题出在哪Flask默认是同步阻塞的一个请求在处理的时候其他请求只能等着。你需要一个异步框架比如FastAPI加上uvicorn或者直接用Triton Inference Server。我选的是FastAPI因为它的生态好调试方便而且和Python的异步生态无缝集成。但光换框架还不够你还需要考虑请求的批处理。单个请求推理一次GPU利用率可能只有10%因为大部分时间都在等数据传输和kernel启动。解决办法是把多个请求攒在一起组成一个batch一起推理。这个攒批的过程需要设计一个调度器请求进来后先放到队列里调度器每隔几毫秒检查一次队列如果队列里有请求或者达到了最大等待时间就取出当前所有请求组成一个batch送给模型。import asyncio from queue import Queue class BatchScheduler: def __init__(self, max_batch_size8, max_wait_ms10): self.queue Queue() self.max_batch_size max_batch_size self.max_wait_ms max_wait_ms async def add_request(self, request): self.queue.put(request) if self.queue.qsize() self.max_batch_size: return await self.process_batch() await asyncio.sleep(self.max_wait_ms / 1000) return await self.process_batch() async def process_batch(self): batch [] while not self.queue.empty() and len(batch) self.max_batch_size: batch.append(self.queue.get()) # 调用模型推理 results await self.model_inference(batch) return results这个调度器的逻辑是请求进来先入队如果队列长度达到最大batch size立即处理否则等待一小段时间让更多请求进来。等待时间是个权衡设得太短攒不到batch设得太长用户延迟高。我实测下来10ms是个比较平衡的值既能攒到足够的请求又不会让用户感觉到明显延迟。3.2 动态批处理的参数调优动态批处理的核心参数有三个最大batch size、最大等待时间、最大序列长度。这三个参数互相制约需要根据你的硬件和业务场景来调。最大batch size受限于显存你可以通过实验找到临界点逐步增加batch size观察显存占用和吞吐量的变化当吞吐量不再增长或者显存接近上限时就是最佳值。最大等待时间影响延迟和吞吐的平衡。如果你的业务对延迟敏感比如实时对话那等待时间要设短一点比如5ms如果是离线批量处理可以设长一点比如50ms。最大序列长度决定了你能否处理长文本但也直接影响显存占用。我的做法是先统计业务数据的序列长度分布取P99值作为最大序列长度这样既能覆盖绝大多数请求又不会浪费太多显存。参数推荐值调整方向影响最大batch size8-32显存不足时调小吞吐量、显存占用最大等待时间5-20ms延迟敏感时调小延迟、吞吐量最大序列长度1024-4096长文本场景调大显存占用、覆盖范围3.3 流式输出的实现细节对话类应用必须支持流式输出否则用户等好几秒才看到第一个字体验极差。流式输出的原理很简单模型每生成一个token就立即返回给客户端而不是等全部生成完再返回。但实现起来有几个坑。第一个是SSEServer-Sent Events的格式每个事件必须以data:开头以\n\n结尾否则前端解析不了。第二个是背压处理如果客户端消费速度慢服务端不能无限往缓冲区写数据需要设置一个上限超过就暂停生成。第三个坑是流式输出和批处理的冲突。批处理是把多个请求攒在一起推理但流式输出要求每个请求独立返回。解决办法是在batch内部维护每个请求的状态每步推理后把每个请求新生成的token分别推送到对应的流式通道。这需要你的推理引擎支持按请求维度的输出切分实现起来稍微复杂一点但这是必须的。async def stream_generate(prompt, request_id): async for token in model.generate_stream(prompt): yield fdata: {json.dumps({id: request_id, token: token})}\n\n yield data: [DONE]\n\n提示流式输出的时候记得设置Content-Type: text/event-stream并且关闭Nginx的缓冲否则Nginx会把你的流式数据攒成一坨再发出去流式效果就没了。4. 性能监控与问题排查实录4.1 必须监控的四个核心指标服务上线之后没有监控就等于裸奔。我建议至少监控这四个指标首token延迟TTFT、每token延迟TPOT、吞吐量tokens/s、显存利用率。TTFT反映的是用户从发出请求到看到第一个字的时间直接影响体验TPOT反映的是生成速度决定了整体响应时间吞吐量反映的是系统整体处理能力显存利用率帮你判断是否有优化空间。这四个指标要分位数统计不能只看平均值。平均值会掩盖长尾问题比如P99延迟可能是平均值的十倍。我用的方案是Prometheus加Grafana在推理代码里埋点每次请求记录这几个指标然后通过Prometheus暴露出来。Grafana面板上同时展示P50、P95、P99三条线一眼就能看出长尾情况。4.2 常见问题速查表现象可能原因排查方法解决方案TTFT突然升高请求排队严重查看队列长度和GPU利用率增加batch size或扩容TPOT波动大显存碎片化监控显存分配日志使用预分配缓存池吞吐量上不去GPU利用率低查看kernel启动间隔增大batch size或使用CUDA Graph生成结果重复采样参数问题检查temperature和top-p调整采样策略显存溢出KV Cache过大统计序列长度分布限制最大序列长度或使用量化这个表格里的每一个问题我都实际遇到过。比如TTFT突然升高那次我查了半天代码没发现问题最后看监控发现GPU利用率只有30%请求全在队列里等着。原因是那段时间流量突增原来的batch size太小攒批效率低。把batch size从8调到16之后TTFT直接降了一半。4.3 一个真实的排查案例有一次线上服务突然开始返回乱码不是全部请求大概10%左右。我先检查了输入数据没问题又检查了模型权重也没问题。后来我把出问题的请求单独拿出来复现发现这些请求都有一个共同特点输入长度刚好是512的倍数。这就很蹊跷了为什么偏偏是512的倍数我顺着这个线索去查代码发现我在处理position embedding的时候对序列长度做了对齐操作但对齐的逻辑有个off-by-one的错误。当序列长度正好是512的倍数时对齐后的长度会多出1导致position embedding越界取到了未初始化的内存。修复方法很简单把对齐逻辑改成向上取整加1确保永远有多余的空间。这个问题花了我整整一个下午但收获很大边界条件测试必须覆盖所有临界值不能只测中间值。5. 从零实现的延伸价值5.1 什么时候该自己实现什么时候该用现成的这个问题我被问过很多次。我的判断标准是如果这个模块是你的核心竞争力那就自己实现如果不是那就用现成的。比如推理调度逻辑如果你的业务对延迟和成本极其敏感那自己实现可以针对性地优化但如果只是做个demo用vLLM或者TGI就够了。再比如模型本身你没必要自己训练一个LLM用开源的就行但你可以自己实现微调流程因为微调数据是你的核心资产。从零实现的最大价值不是让你在生产环境重复造轮子而是让你具备“降维打击”的能力。当你理解了KV Cache的原理你就能看懂vLLM的PagedAttention论文当你手写过attention你就能理解FlashAttention为什么能加速当你实现过批处理调度你就能根据业务特点调出最优参数。这种能力是调包调不出来的。5.2 后续可以扩展的方向如果你已经把推理链路跑通了接下来可以往这几个方向扩展。第一个是量化把FP16换成INT8或者INT4显存占用直接减半甚至减到四分之一代价是精度略微下降。第二个是投机采样用一个小模型快速生成多个候选token然后用大模型并行验证能在不损失精度的情况下提升2-3倍速度。第三个是分布式推理把模型切分到多张卡上支持更大的模型和更高的吞吐。我个人最推荐先搞量化因为收益最直接实现也相对简单。你可以从weight-only量化开始只量化权重不量化激活值精度损失很小但显存节省明显。我实测下来INT8量化能让显存占用降低40%左右生成速度提升20%而生成质量几乎看不出差别。5.3 我踩过的三个大坑第一个坑是过度优化。刚开始的时候我花了两周时间优化attention的kernel用CUDA重写了一遍结果性能只提升了5%。后来发现瓶颈根本不在attention而在数据预处理和tokenization。所以优化之前一定要先profile找到真正的瓶颈再动手。第二个坑是忽略冷启动。服务刚启动的时候第一次推理特别慢因为要加载权重、初始化CUDA context、编译kernel。如果你的服务是弹性伸缩的冷启动延迟会直接影响用户体验。解决办法是预热服务启动后先跑几个假请求把该初始化的都初始化好再开始接收真实流量。第三个坑是日志太多。我一开始在每个推理步骤都打日志结果日志文件一天涨了50GB磁盘直接写满。后来改成只记录关键指标和异常日志量降到了原来的百分之一。日志不是越多越好关键是要能帮你定位问题而不是制造问题。这三个坑说到底都是工程经验的问题看再多文档也不如自己踩一遍来得深刻。从零实现的意义就在于此你亲手搭建的每一个模块都会在出问题的时候成为你排查的线索。调包的人看到报错只能去搜issue而你知道代码的每一行在干什么这就是本质区别。 从零手搓AI推理引擎：避开调包陷阱的工程实践指南
1. 从零手搓AI工程为什么我不建议你直接调包很多人一上来就想搞个大模型应用第一反应是找现成的API或者开源框架三行代码跑通一个对话机器人然后觉得自己已经入门了。我刚开始也这么干过结果呢线上流量稍微一波动延迟直接飙到十几秒账单翻了三倍排查问题的时候连瓶颈在哪都说不清楚。后来我花了整整两个月时间把整个链路从最底层重新实现了一遍才真正搞明白每个环节到底在干什么。ai-engineering-from-scratch这个方向核心不是让你重复造轮子而是让你具备“拆轮子”的能力。它解决的是一个非常具体的问题当现成方案不work的时候你有没有能力定位到根因并且自己动手改。适合谁看如果你已经会调API、会写Prompt但一遇到性能问题、成本问题、效果不稳定就束手无策那这篇内容就是给你准备的。我会从推理引擎的最小实现开始一路讲到服务化部署和监控把每个关键决策背后的“为什么”掰开揉碎。先泼一盆冷水从零实现不等于不用任何库。我的原则是核心链路的每一行代码我都要能解释清楚它在干什么辅助工具该用就用。比如矩阵运算我肯定用NumPy但推理调度逻辑我必须自己写。这个边界感很重要否则你要么陷入无意义的重复劳动要么永远停留在调包层面。2. 推理引擎的最小可行实现2.1 为什么从推理而不是训练开始训练一个模型动辄需要几十张卡、几天时间对个人开发者来说门槛太高。但推理不一样你可以在单张消费级显卡上跑通整个流程而且推理阶段暴露的问题更贴近实际生产环境——延迟、吞吐、显存占用、批处理策略这些都是工程化的核心。我建议的路径是先拿一个已经训练好的小模型比如TinyLlama或者Qwen的小尺寸版本把它的推理过程完整实现一遍理解每个张量是怎么流动的。具体来说你需要实现这几个模块模型加载权重解析和映射、前向计算Attention、FFN、LayerNorm、KV Cache管理、采样策略贪心、Top-k、Top-p。听起来很多但每个模块的核心代码其实不超过50行。关键是你要理解为什么需要KV Cache——没有它每生成一个token都要重新计算所有历史token的Key和Value计算量随序列长度平方增长。有了KV Cache每步只需要计算当前token的Key和Value然后拼接到缓存里计算量变成线性增长。2.2 手写Attention的避坑指南Attention的公式大家都知道softmax(QK^T/√d)V。但实际写代码的时候有几个细节特别容易翻车。第一个是维度对齐Q、K、V的head维度必须一致但序列长度可以不同。我见过有人把batch维度和head维度搞混结果训练能跑但推理结果完全不对。第二个是mask的处理decoder-only模型需要causal mask确保每个位置只能看到自己和之前的位置。这个mask矩阵的构造方式直接影响生成质量如果mask写错了模型会“偷看”未来token生成结果看起来通顺但逻辑混乱。第三个坑是数值稳定性。softmax在输入值很大的时候会溢出标准做法是先减去最大值。这个操作在训练框架里是自动处理的但你自己实现的时候如果忘了模型输出会变成NaN。我当时的排查过程是这样的先检查输入数据有没有异常值再逐层打印中间结果最后定位到softmax那一步。所以我的建议是每实现一个模块都写一个小的单元测试用已知输入验证输出是否符合预期。import numpy as np def softmax(x, axis-1): x_max np.max(x, axisaxis, keepdimsTrue) exp_x np.exp(x - x_max) return exp_x / np.sum(exp_x, axisaxis, keepdimsTrue) def attention(Q, K, V, maskNone): d_k Q.shape[-1] scores np.matmul(Q, K.transpose(0, 1, 3, 2)) / np.sqrt(d_k) if mask is not None: scores scores mask * -1e9 weights softmax(scores, axis-1) return np.matmul(weights, V)这段代码看起来简单但你要确保Q、K、V的shape是(batch, heads, seq_len, head_dim)。我第一次写的时候把heads和seq_len搞反了结果attention权重矩阵的形状完全不对生成出来的东西全是乱码。后来我养成了一个习惯在每个矩阵运算后面打印shape确认无误后再继续。2.3 KV Cache的内存管理策略KV Cache是推理加速的核心但它也是显存杀手。假设模型有32层每层有32个head每个head维度是128序列长度是2048batch size是8那么KV Cache的大小是2Key和Value× 32层 × 32头 × 128维 × 2048长度 × 8批次 × 2字节FP16 8GB左右。这还只是KV Cache加上模型权重和中间激活值显存直接爆炸。所以你需要实现一个缓存管理策略。常见的有两种一种是预分配固定大小的缓存池按需分配和回收另一种是分页管理类似操作系统的虚拟内存。我推荐先从预分配开始实现简单且足够应对大多数场景。具体做法是根据最大序列长度和最大batch size预先分配一块连续显存每个请求进来时分配一个slot请求结束后回收。这样避免了频繁的内存分配和释放性能更稳定。注意预分配的大小要留有余量但也不能太大否则浪费显存。我的经验是按照实际业务场景的P99序列长度来设定比如你的用户平均输入200token输出500token那最大序列长度设为1024就够用了没必要设成4096。3. 服务化部署的核心环节3.1 从单机推理到HTTP服务模型能在本地跑通之后下一步就是把它变成一个服务。很多人直接用Flask写个接口就上线了结果并发一上来就崩。问题出在哪Flask默认是同步阻塞的一个请求在处理的时候其他请求只能等着。你需要一个异步框架比如FastAPI加上uvicorn或者直接用Triton Inference Server。我选的是FastAPI因为它的生态好调试方便而且和Python的异步生态无缝集成。但光换框架还不够你还需要考虑请求的批处理。单个请求推理一次GPU利用率可能只有10%因为大部分时间都在等数据传输和kernel启动。解决办法是把多个请求攒在一起组成一个batch一起推理。这个攒批的过程需要设计一个调度器请求进来后先放到队列里调度器每隔几毫秒检查一次队列如果队列里有请求或者达到了最大等待时间就取出当前所有请求组成一个batch送给模型。import asyncio from queue import Queue class BatchScheduler: def __init__(self, max_batch_size8, max_wait_ms10): self.queue Queue() self.max_batch_size max_batch_size self.max_wait_ms max_wait_ms async def add_request(self, request): self.queue.put(request) if self.queue.qsize() self.max_batch_size: return await self.process_batch() await asyncio.sleep(self.max_wait_ms / 1000) return await self.process_batch() async def process_batch(self): batch [] while not self.queue.empty() and len(batch) self.max_batch_size: batch.append(self.queue.get()) # 调用模型推理 results await self.model_inference(batch) return results这个调度器的逻辑是请求进来先入队如果队列长度达到最大batch size立即处理否则等待一小段时间让更多请求进来。等待时间是个权衡设得太短攒不到batch设得太长用户延迟高。我实测下来10ms是个比较平衡的值既能攒到足够的请求又不会让用户感觉到明显延迟。3.2 动态批处理的参数调优动态批处理的核心参数有三个最大batch size、最大等待时间、最大序列长度。这三个参数互相制约需要根据你的硬件和业务场景来调。最大batch size受限于显存你可以通过实验找到临界点逐步增加batch size观察显存占用和吞吐量的变化当吞吐量不再增长或者显存接近上限时就是最佳值。最大等待时间影响延迟和吞吐的平衡。如果你的业务对延迟敏感比如实时对话那等待时间要设短一点比如5ms如果是离线批量处理可以设长一点比如50ms。最大序列长度决定了你能否处理长文本但也直接影响显存占用。我的做法是先统计业务数据的序列长度分布取P99值作为最大序列长度这样既能覆盖绝大多数请求又不会浪费太多显存。参数推荐值调整方向影响最大batch size8-32显存不足时调小吞吐量、显存占用最大等待时间5-20ms延迟敏感时调小延迟、吞吐量最大序列长度1024-4096长文本场景调大显存占用、覆盖范围3.3 流式输出的实现细节对话类应用必须支持流式输出否则用户等好几秒才看到第一个字体验极差。流式输出的原理很简单模型每生成一个token就立即返回给客户端而不是等全部生成完再返回。但实现起来有几个坑。第一个是SSEServer-Sent Events的格式每个事件必须以data:开头以\n\n结尾否则前端解析不了。第二个是背压处理如果客户端消费速度慢服务端不能无限往缓冲区写数据需要设置一个上限超过就暂停生成。第三个坑是流式输出和批处理的冲突。批处理是把多个请求攒在一起推理但流式输出要求每个请求独立返回。解决办法是在batch内部维护每个请求的状态每步推理后把每个请求新生成的token分别推送到对应的流式通道。这需要你的推理引擎支持按请求维度的输出切分实现起来稍微复杂一点但这是必须的。async def stream_generate(prompt, request_id): async for token in model.generate_stream(prompt): yield fdata: {json.dumps({id: request_id, token: token})}\n\n yield data: [DONE]\n\n提示流式输出的时候记得设置Content-Type: text/event-stream并且关闭Nginx的缓冲否则Nginx会把你的流式数据攒成一坨再发出去流式效果就没了。4. 性能监控与问题排查实录4.1 必须监控的四个核心指标服务上线之后没有监控就等于裸奔。我建议至少监控这四个指标首token延迟TTFT、每token延迟TPOT、吞吐量tokens/s、显存利用率。TTFT反映的是用户从发出请求到看到第一个字的时间直接影响体验TPOT反映的是生成速度决定了整体响应时间吞吐量反映的是系统整体处理能力显存利用率帮你判断是否有优化空间。这四个指标要分位数统计不能只看平均值。平均值会掩盖长尾问题比如P99延迟可能是平均值的十倍。我用的方案是Prometheus加Grafana在推理代码里埋点每次请求记录这几个指标然后通过Prometheus暴露出来。Grafana面板上同时展示P50、P95、P99三条线一眼就能看出长尾情况。4.2 常见问题速查表现象可能原因排查方法解决方案TTFT突然升高请求排队严重查看队列长度和GPU利用率增加batch size或扩容TPOT波动大显存碎片化监控显存分配日志使用预分配缓存池吞吐量上不去GPU利用率低查看kernel启动间隔增大batch size或使用CUDA Graph生成结果重复采样参数问题检查temperature和top-p调整采样策略显存溢出KV Cache过大统计序列长度分布限制最大序列长度或使用量化这个表格里的每一个问题我都实际遇到过。比如TTFT突然升高那次我查了半天代码没发现问题最后看监控发现GPU利用率只有30%请求全在队列里等着。原因是那段时间流量突增原来的batch size太小攒批效率低。把batch size从8调到16之后TTFT直接降了一半。4.3 一个真实的排查案例有一次线上服务突然开始返回乱码不是全部请求大概10%左右。我先检查了输入数据没问题又检查了模型权重也没问题。后来我把出问题的请求单独拿出来复现发现这些请求都有一个共同特点输入长度刚好是512的倍数。这就很蹊跷了为什么偏偏是512的倍数我顺着这个线索去查代码发现我在处理position embedding的时候对序列长度做了对齐操作但对齐的逻辑有个off-by-one的错误。当序列长度正好是512的倍数时对齐后的长度会多出1导致position embedding越界取到了未初始化的内存。修复方法很简单把对齐逻辑改成向上取整加1确保永远有多余的空间。这个问题花了我整整一个下午但收获很大边界条件测试必须覆盖所有临界值不能只测中间值。5. 从零实现的延伸价值5.1 什么时候该自己实现什么时候该用现成的这个问题我被问过很多次。我的判断标准是如果这个模块是你的核心竞争力那就自己实现如果不是那就用现成的。比如推理调度逻辑如果你的业务对延迟和成本极其敏感那自己实现可以针对性地优化但如果只是做个demo用vLLM或者TGI就够了。再比如模型本身你没必要自己训练一个LLM用开源的就行但你可以自己实现微调流程因为微调数据是你的核心资产。从零实现的最大价值不是让你在生产环境重复造轮子而是让你具备“降维打击”的能力。当你理解了KV Cache的原理你就能看懂vLLM的PagedAttention论文当你手写过attention你就能理解FlashAttention为什么能加速当你实现过批处理调度你就能根据业务特点调出最优参数。这种能力是调包调不出来的。5.2 后续可以扩展的方向如果你已经把推理链路跑通了接下来可以往这几个方向扩展。第一个是量化把FP16换成INT8或者INT4显存占用直接减半甚至减到四分之一代价是精度略微下降。第二个是投机采样用一个小模型快速生成多个候选token然后用大模型并行验证能在不损失精度的情况下提升2-3倍速度。第三个是分布式推理把模型切分到多张卡上支持更大的模型和更高的吞吐。我个人最推荐先搞量化因为收益最直接实现也相对简单。你可以从weight-only量化开始只量化权重不量化激活值精度损失很小但显存节省明显。我实测下来INT8量化能让显存占用降低40%左右生成速度提升20%而生成质量几乎看不出差别。5.3 我踩过的三个大坑第一个坑是过度优化。刚开始的时候我花了两周时间优化attention的kernel用CUDA重写了一遍结果性能只提升了5%。后来发现瓶颈根本不在attention而在数据预处理和tokenization。所以优化之前一定要先profile找到真正的瓶颈再动手。第二个坑是忽略冷启动。服务刚启动的时候第一次推理特别慢因为要加载权重、初始化CUDA context、编译kernel。如果你的服务是弹性伸缩的冷启动延迟会直接影响用户体验。解决办法是预热服务启动后先跑几个假请求把该初始化的都初始化好再开始接收真实流量。第三个坑是日志太多。我一开始在每个推理步骤都打日志结果日志文件一天涨了50GB磁盘直接写满。后来改成只记录关键指标和异常日志量降到了原来的百分之一。日志不是越多越好关键是要能帮你定位问题而不是制造问题。这三个坑说到底都是工程经验的问题看再多文档也不如自己踩一遍来得深刻。从零实现的意义就在于此你亲手搭建的每一个模块都会在出问题的时候成为你排查的线索。调包的人看到报错只能去搜issue而你知道代码的每一行在干什么这就是本质区别。