一只用 AI Agent 搭副业产线的程序员你跑过一个 70B 模型吗Q4 量化后大概 40GB一张 A10080GB放得下。但生产环境的问题不是放不放得下而是一个请求只用了 2K 上下文为什么显存就不够处理第二个请求了答案是 KV Cache。传统方法预分配了太多永远用不到的显存空间。vLLM 的 PagedAttention 就是来解决这个问题的。这篇文章我们看它怎么把操作系统的虚拟内存管理思想搬到了 GPU 显存管理上。项目简介vLLMGitHub 40k Stars是 UC Berkeley 开源的 LLM 推理引擎核心贡献是PagedAttention——一种把 KV Cache 按页管理的算法。它把显存利用率从传统框架的 30-40% 提升到 90% 以上吞吐量提升 2-4 倍。现在被 LMSYSChatbot Arena和多家公司用于生产环境。架构全景┌──────────────────────────────────────────────────────────────┐ │ API 服务层 │ │ OpenAI-compatible: /v1/completions, /v1/chat, │ │ /v1/embeddings, /v1/models │ ├──────────────────────────────────────────────────────────────┤ │ 调度器Scheduler │ │ Continuous Batching — 不再等整批完成来一个处理一个 │ │ ┌─────────┐ ┌──────────┐ ┌───────────────┐ │ │ │ 请求队列 │→│ Prefill │→│ Decode 循环 │ │ │ └─────────┘ └──────────┘ └───────────────┘ │ ├──────────────────────────────────────────────────────────────┤ │ 块管理器Block Manager—— PagedAttention 核心 │ │ ┌──────────┐ ┌───────────┐ ┌─────────────┐ │ │ │ 物理块池 │ │ 块映射表 │ │ Copy-on-Write │ │ │ │ (Physical) │ │ (BlockTable)│ │ (beam search) │ │ │ └──────────┘ └───────────┘ └─────────────┘ │ ├──────────────────────────────────────────────────────────────┤ │ CUDA Kernel 层 │ │ PagedAttention · FlashAttention · FP8/INT8 量化 · TP/PP │ └──────────────────────────────────────────────────────────────┘先理解问题传统 KV Cache 为什么浪费显存LLM 推理时每生成一个 token都要拿当前的 query 去和之前所有 token 的 key/value 做 attention。为了避免重复计算程序把每一层的 K 和 V 张量存下来——这就是 KV Cache。传统框架FasterTransformer、TGI的处理方式请求 1上下文 2000 tokens → 预分配 (max_context4096) × K × V ≈ 2GB 请求 2上下文 500 tokens → 预分配 (max_context4096) × K × V ≈ 2GB 请求 3上下文 8000 tokens → 预分配 (max_context8192) × K × V ≈ 4GB ───────────────────────────────────────────────────────────── 总占用8GB但实际只用到了 (20005008000)/(409640968192) ≈ 64%两个问题预分配必须按最大可能长度分配绝大多数请求用不完。碎片化请求 1 结束后释放 2GB但紧接着来一个需要 3GB 的请求——那 2GB 的碎片用不上要 defrag 或者 OOM。核心问题KV Cache 是连续分配的。连续分配 外部碎片 浪费。关键设计一分页管理——显存版的虚拟内存vLLM 的答案是不按请求分配按块分配。每个块固定大小比如 16 个 token物理块池化请求通过块表引用物理块。# vllm/core/block_manager.py —— 块管理器的核心逻辑概念性重建fromtypingimportList,Optional,DictclassBlockTable:每个请求的虚拟块 → 物理块的映射表def__init__(self,block_size:int16):self.block_sizeblock_size# 每个物理块 16 个 tokenself.blocks:List[Optional[int]][]# 虚拟块号 → 物理块号classBlockAllocator:全局物理块池def__init__(self,num_blocks:int,block_size:int):self.free_blocks:List[int]list(range(num_blocks))# 空闲块列表self.block_sizeblock_sizedefallocate(self)-int:分配一个物理块返回块号ifnotself.free_blocks:raiseOutOfMemoryError(No free blocks)returnself.free_blocks.pop()deffree(self,block_id:int):释放物理块self.free_blocks.append(block_id)classBlockManager:全局块管理器——所有请求共享物理块池def__init__(self,num_gpu_blocks:int,block_size:int16):self.allocatorBlockAllocator(num_gpu_blocks,block_size)self.block_tables:Dict[int,BlockTable]{}# 请求 ID → 块表defappend_slot(self,seq_id:int)-Optional[int]:为一个请求追加一个 slot需要时分配新块block_tableself.block_tables[seq_id]# 计算需要几个块num_needed(len(block_table.blocks)*self.allocator.block_size)1# 如果最后一个块已满分配新块ifnum_neededlen(block_table.blocks)*self.allocator.block_size:new_blockself.allocator.allocate()block_table.blocks.append(new_block)# 返回最后一个物理块的地址returnblock_table.blocks[-1]这个设计的效果改前连续分配 请求A: ┌──────────4096 tokens──────────┬ 碎片 ┐ 请求B: ┌────2048 tokens────┬ 碎片 ┐ 改后分页分配块大小16 物理块池: [A1][B1][A2][空][B2][A3][空][空][A4][B3]... └── A 的块表: [0, 2, 5, 8] ──┘ └── B 的块表: [1, 4, 9] ──┘没有外部碎片了——因为所有分配都是固定大小的块。内部碎片最多 15 个 token最后一个块没装满在上下文的尺度下可以忽略不计。设计洞察这就是操作系统的分页思想直接搬到 GPU 显存管理。页表 物理页框池 按需分配。香不香香。新不新不新。但能把 60 年前的 OS 思想用到 LLM 推理里并做到生产可用——这就是工程的魅力。关键设计二Copy-on-Write——并行生成的零拷贝优化一个常见场景用户要求生成 3 个候选回复。怎么做朴素方案KV Cache 复制 3 份。一个 4K 上下文的请求 2GB KV Cache。3 份 6GB。PagedAttention 方案共享前缀部分的物理块只在分叉点复制块表指针。# vllm/core/block_manager.py —— Copy-on-Write forkclassBlockManager:deffork(self,parent_seq_id:int,child_seq_id:int):从父请求 fork 一个子请求beam search / parallel samplingparent_tableself.block_tables[parent_seq_id]# 子请求共享父请求的块表shallow copychild_tableBlockTable(block_sizeparent_table.block_size)child_table.blockslist(parent_table.blocks)# 引用相同的物理块self.block_tables[child_seq_id]child_tabledefappend_slot(self,seq_id:int)-Optional[int]:追加 slot——如果物理块被共享先 Copy-on-Writeblock_tableself.block_tables[seq_id]last_blockblock_table.blocks[-1]ifblock_table.blockselseNone# 检查最后一个块是否被多个请求共享iflast_blockisnotNoneandself._ref_count(last_block)1:# COW: 分配新物理块复制内容new_blockself.allocator.allocate()self._copy_block(last_block,new_block)self.allocator.free(last_block)# 减少旧块的引用计数block_table.blocks[-1]new_block# 剩下的逻辑跟普通 append 一样...这个优化让 parallel sampling生成 n 个候选回复的显存开销从 O(n) 降到 O(1)只额外花在分叉后产生差异的 token 上。设计洞察Copy-on-Write 的通用性极高——fork 进程用它、Redis 的 BGSAVE 用它、vLLM 的 parallel sampling 也用它。理解一个模式能用一辈子。关键设计三Continuous Batching——请求级别的流水线传统批处理Static Batching等到一批请求全部完成再处理下一批。请求A200 tokens→ ████████████████████ 请求B50 tokens → █████ → 等 A 完成 → 空闲 请求C10 tokens → ██ → 等 A 和 B 完成 → 空闲Continuous Batching一个请求完成立即踢出把空出来的计算资源给等待队列的下一个。# vllm/core/scheduler.py —— 调度器的核心逻辑概念性重建classScheduler:defschedule(self)-SchedulerOutput:running:List[SequenceGroup][]preempted:List[SequenceGroup][]# Step 1: 从等待队列拉请求直到显存不够whileself.waitingandself.block_manager.can_allocate():seq_groupself.waiting.pop(0)self.block_manager.allocate(seq_group)running.append(seq_group)# Step 2: 为每个运行中的请求生成一个 tokenforseq_groupinrunning:seq_group.generate_one_token()# Step 3: 把完成的请求踢出释放块forseq_groupinrunning:ifseq_group.is_finished():self.block_manager.free(seq_group)running.remove(seq_group)# Step 4: 剩余请求继续下一轮调度returnSchedulerOutput(scheduledrunning,preemptedpreempted,num_waitinglen(self.waiting),)调度的核心在 Step 1“能分配就分配”。不等到最佳批次大小而是只要显存有空就拉新请求。这个设计的关键收益短请求不用等长请求。50 个 token 的请求生成完立刻释放 KV Cache 块给下一个请求腾空间。在混合长短请求的场景下吞吐量提升最明显。核心代码拆解PagedAttention 的 CUDA Kernel 是怎么读取 KV Cache 的把 KV Cache 分页之后attention 计算就不能用连续的矩阵乘法了——K 和 V 分散在不同物理块里。vLLM 为此写了一个定制的 CUDA kernel// vllm/csrc/attention/paged_attention.cu —— 简化逻辑 __global__ void paged_attention_kernel( float* output, // [num_tokens, num_heads, head_size] const float* query, // [num_tokens, num_heads, head_size] const float* key_cache, // [num_blocks, num_heads, block_size, head_size] const float* value_cache,// [num_blocks, num_heads, block_size, head_size] const int* block_table, // [num_requests, max_num_blocks] const int* context_lens, // [num_requests] int num_heads, float scale, int block_size ) { int tid threadIdx.x; int seq_idx blockIdx.x; // 每个请求一个 block int head_idx blockIdx.y; // 每个 head 一个…嗯另一个 block int num_blocks (context_lens[seq_idx] block_size - 1) / block_size; for (int block_idx 0; block_idx num_blocks; block_idx) { // 关键通过块表把虚拟块号转成物理块号 int physical_block block_table[seq_idx * max_num_blocks block_idx]; // 用物理块号去读 K 和 V // key_cache[physical_block * block_stride head_idx * block_size * head_size ...] int block_offset physical_block * block_stride head_idx * block_size * head_size; // 计算这个 token 和当前块里所有 token 的 attention score for (int t 0; t block_size; t) { float score 0; for (int d 0; d head_size; d) { score query[q_offset d] * key_cache[block_offset t * head_size d]; } scores[block_idx * block_size t] score * scale; } } // softmax weighted sum跟标准 attention 一样 ... }kernel 的核心只有一行physical_block block_table[seq_idx * max_blocks block_idx]。这一行就是 PagedAttention 的全部魔法——其余部分都是在做普通的 attention 运算。代价只是一次额外的全局内存读取读块表在已经在做 O(n^2) 的 attention 运算面前可以忽略。你可以抄的作业1. 分页思路不只属于操作系统任何大块连续分配会碎片化的场景都能用分页。你要做个内存池管理游戏对象分页。管理网络数据包的缓冲分页。只要分配单元不固定且碎片化严重固定大小的块 映射表就是标准答案。2. Copy-on-Write 的通用模式fork 共享读取 写时复制。vLLM 的 block fork 和 Linux 的 fork() 系统调用本质上是一回事。理解 COW你就多了一个优化同源并行操作的武器。3. Continuous Batching 就是能进就进Pipeline 优化的本质不是凑满批次而是不要等。任何批处理系统——ETL 管道、消息队列消费者、API Gateway——都可以用这个思路有空闲资源就拉做完立刻放不等。4. 好的优化 好的数据结构 老的计算机思想PagedAttention 没有发明新数学它只是选了正确的数据结构页表和正确的资源管理策略按需分配 COW。“创新很多时候就是把别处已经验证过的思想搬到你的领域”。最后vLLM 的故事跟很多学术项目变成工业标准的故事一样不是算法有多新而是工程优化做得够深。PagedAttention 把显存利用率从 30% 拉到 90%靠的不是一篇论文、一个公式而是一个完整的系统设计——块管理、调度器、CUDA kernel 三者协同工作。理解 vLLM 不只是学一个推理框架更是学如何把一个孤立的算法优化做成系统级的解决方案。下一讲拆 Dify。一个低代码 AI 应用平台是怎么设计插件系统让 100 个模型和工具能无缝接入的本文拆解的 vLLM 版本v0.6.x。源码地址github.com/vllm-project/vllm 一只用 AI Agent 搭副业产线的程序员全平台同名虾哥不加班 | 源码GitHub - lobster-bujiaban需要定制 AI 工具来聊聊 → lob_ai
拆解 vLLM：PagedAttention 怎么把显存利用率拉到 90%
一只用 AI Agent 搭副业产线的程序员你跑过一个 70B 模型吗Q4 量化后大概 40GB一张 A10080GB放得下。但生产环境的问题不是放不放得下而是一个请求只用了 2K 上下文为什么显存就不够处理第二个请求了答案是 KV Cache。传统方法预分配了太多永远用不到的显存空间。vLLM 的 PagedAttention 就是来解决这个问题的。这篇文章我们看它怎么把操作系统的虚拟内存管理思想搬到了 GPU 显存管理上。项目简介vLLMGitHub 40k Stars是 UC Berkeley 开源的 LLM 推理引擎核心贡献是PagedAttention——一种把 KV Cache 按页管理的算法。它把显存利用率从传统框架的 30-40% 提升到 90% 以上吞吐量提升 2-4 倍。现在被 LMSYSChatbot Arena和多家公司用于生产环境。架构全景┌──────────────────────────────────────────────────────────────┐ │ API 服务层 │ │ OpenAI-compatible: /v1/completions, /v1/chat, │ │ /v1/embeddings, /v1/models │ ├──────────────────────────────────────────────────────────────┤ │ 调度器Scheduler │ │ Continuous Batching — 不再等整批完成来一个处理一个 │ │ ┌─────────┐ ┌──────────┐ ┌───────────────┐ │ │ │ 请求队列 │→│ Prefill │→│ Decode 循环 │ │ │ └─────────┘ └──────────┘ └───────────────┘ │ ├──────────────────────────────────────────────────────────────┤ │ 块管理器Block Manager—— PagedAttention 核心 │ │ ┌──────────┐ ┌───────────┐ ┌─────────────┐ │ │ │ 物理块池 │ │ 块映射表 │ │ Copy-on-Write │ │ │ │ (Physical) │ │ (BlockTable)│ │ (beam search) │ │ │ └──────────┘ └───────────┘ └─────────────┘ │ ├──────────────────────────────────────────────────────────────┤ │ CUDA Kernel 层 │ │ PagedAttention · FlashAttention · FP8/INT8 量化 · TP/PP │ └──────────────────────────────────────────────────────────────┘先理解问题传统 KV Cache 为什么浪费显存LLM 推理时每生成一个 token都要拿当前的 query 去和之前所有 token 的 key/value 做 attention。为了避免重复计算程序把每一层的 K 和 V 张量存下来——这就是 KV Cache。传统框架FasterTransformer、TGI的处理方式请求 1上下文 2000 tokens → 预分配 (max_context4096) × K × V ≈ 2GB 请求 2上下文 500 tokens → 预分配 (max_context4096) × K × V ≈ 2GB 请求 3上下文 8000 tokens → 预分配 (max_context8192) × K × V ≈ 4GB ───────────────────────────────────────────────────────────── 总占用8GB但实际只用到了 (20005008000)/(409640968192) ≈ 64%两个问题预分配必须按最大可能长度分配绝大多数请求用不完。碎片化请求 1 结束后释放 2GB但紧接着来一个需要 3GB 的请求——那 2GB 的碎片用不上要 defrag 或者 OOM。核心问题KV Cache 是连续分配的。连续分配 外部碎片 浪费。关键设计一分页管理——显存版的虚拟内存vLLM 的答案是不按请求分配按块分配。每个块固定大小比如 16 个 token物理块池化请求通过块表引用物理块。# vllm/core/block_manager.py —— 块管理器的核心逻辑概念性重建fromtypingimportList,Optional,DictclassBlockTable:每个请求的虚拟块 → 物理块的映射表def__init__(self,block_size:int16):self.block_sizeblock_size# 每个物理块 16 个 tokenself.blocks:List[Optional[int]][]# 虚拟块号 → 物理块号classBlockAllocator:全局物理块池def__init__(self,num_blocks:int,block_size:int):self.free_blocks:List[int]list(range(num_blocks))# 空闲块列表self.block_sizeblock_sizedefallocate(self)-int:分配一个物理块返回块号ifnotself.free_blocks:raiseOutOfMemoryError(No free blocks)returnself.free_blocks.pop()deffree(self,block_id:int):释放物理块self.free_blocks.append(block_id)classBlockManager:全局块管理器——所有请求共享物理块池def__init__(self,num_gpu_blocks:int,block_size:int16):self.allocatorBlockAllocator(num_gpu_blocks,block_size)self.block_tables:Dict[int,BlockTable]{}# 请求 ID → 块表defappend_slot(self,seq_id:int)-Optional[int]:为一个请求追加一个 slot需要时分配新块block_tableself.block_tables[seq_id]# 计算需要几个块num_needed(len(block_table.blocks)*self.allocator.block_size)1# 如果最后一个块已满分配新块ifnum_neededlen(block_table.blocks)*self.allocator.block_size:new_blockself.allocator.allocate()block_table.blocks.append(new_block)# 返回最后一个物理块的地址returnblock_table.blocks[-1]这个设计的效果改前连续分配 请求A: ┌──────────4096 tokens──────────┬ 碎片 ┐ 请求B: ┌────2048 tokens────┬ 碎片 ┐ 改后分页分配块大小16 物理块池: [A1][B1][A2][空][B2][A3][空][空][A4][B3]... └── A 的块表: [0, 2, 5, 8] ──┘ └── B 的块表: [1, 4, 9] ──┘没有外部碎片了——因为所有分配都是固定大小的块。内部碎片最多 15 个 token最后一个块没装满在上下文的尺度下可以忽略不计。设计洞察这就是操作系统的分页思想直接搬到 GPU 显存管理。页表 物理页框池 按需分配。香不香香。新不新不新。但能把 60 年前的 OS 思想用到 LLM 推理里并做到生产可用——这就是工程的魅力。关键设计二Copy-on-Write——并行生成的零拷贝优化一个常见场景用户要求生成 3 个候选回复。怎么做朴素方案KV Cache 复制 3 份。一个 4K 上下文的请求 2GB KV Cache。3 份 6GB。PagedAttention 方案共享前缀部分的物理块只在分叉点复制块表指针。# vllm/core/block_manager.py —— Copy-on-Write forkclassBlockManager:deffork(self,parent_seq_id:int,child_seq_id:int):从父请求 fork 一个子请求beam search / parallel samplingparent_tableself.block_tables[parent_seq_id]# 子请求共享父请求的块表shallow copychild_tableBlockTable(block_sizeparent_table.block_size)child_table.blockslist(parent_table.blocks)# 引用相同的物理块self.block_tables[child_seq_id]child_tabledefappend_slot(self,seq_id:int)-Optional[int]:追加 slot——如果物理块被共享先 Copy-on-Writeblock_tableself.block_tables[seq_id]last_blockblock_table.blocks[-1]ifblock_table.blockselseNone# 检查最后一个块是否被多个请求共享iflast_blockisnotNoneandself._ref_count(last_block)1:# COW: 分配新物理块复制内容new_blockself.allocator.allocate()self._copy_block(last_block,new_block)self.allocator.free(last_block)# 减少旧块的引用计数block_table.blocks[-1]new_block# 剩下的逻辑跟普通 append 一样...这个优化让 parallel sampling生成 n 个候选回复的显存开销从 O(n) 降到 O(1)只额外花在分叉后产生差异的 token 上。设计洞察Copy-on-Write 的通用性极高——fork 进程用它、Redis 的 BGSAVE 用它、vLLM 的 parallel sampling 也用它。理解一个模式能用一辈子。关键设计三Continuous Batching——请求级别的流水线传统批处理Static Batching等到一批请求全部完成再处理下一批。请求A200 tokens→ ████████████████████ 请求B50 tokens → █████ → 等 A 完成 → 空闲 请求C10 tokens → ██ → 等 A 和 B 完成 → 空闲Continuous Batching一个请求完成立即踢出把空出来的计算资源给等待队列的下一个。# vllm/core/scheduler.py —— 调度器的核心逻辑概念性重建classScheduler:defschedule(self)-SchedulerOutput:running:List[SequenceGroup][]preempted:List[SequenceGroup][]# Step 1: 从等待队列拉请求直到显存不够whileself.waitingandself.block_manager.can_allocate():seq_groupself.waiting.pop(0)self.block_manager.allocate(seq_group)running.append(seq_group)# Step 2: 为每个运行中的请求生成一个 tokenforseq_groupinrunning:seq_group.generate_one_token()# Step 3: 把完成的请求踢出释放块forseq_groupinrunning:ifseq_group.is_finished():self.block_manager.free(seq_group)running.remove(seq_group)# Step 4: 剩余请求继续下一轮调度returnSchedulerOutput(scheduledrunning,preemptedpreempted,num_waitinglen(self.waiting),)调度的核心在 Step 1“能分配就分配”。不等到最佳批次大小而是只要显存有空就拉新请求。这个设计的关键收益短请求不用等长请求。50 个 token 的请求生成完立刻释放 KV Cache 块给下一个请求腾空间。在混合长短请求的场景下吞吐量提升最明显。核心代码拆解PagedAttention 的 CUDA Kernel 是怎么读取 KV Cache 的把 KV Cache 分页之后attention 计算就不能用连续的矩阵乘法了——K 和 V 分散在不同物理块里。vLLM 为此写了一个定制的 CUDA kernel// vllm/csrc/attention/paged_attention.cu —— 简化逻辑 __global__ void paged_attention_kernel( float* output, // [num_tokens, num_heads, head_size] const float* query, // [num_tokens, num_heads, head_size] const float* key_cache, // [num_blocks, num_heads, block_size, head_size] const float* value_cache,// [num_blocks, num_heads, block_size, head_size] const int* block_table, // [num_requests, max_num_blocks] const int* context_lens, // [num_requests] int num_heads, float scale, int block_size ) { int tid threadIdx.x; int seq_idx blockIdx.x; // 每个请求一个 block int head_idx blockIdx.y; // 每个 head 一个…嗯另一个 block int num_blocks (context_lens[seq_idx] block_size - 1) / block_size; for (int block_idx 0; block_idx num_blocks; block_idx) { // 关键通过块表把虚拟块号转成物理块号 int physical_block block_table[seq_idx * max_num_blocks block_idx]; // 用物理块号去读 K 和 V // key_cache[physical_block * block_stride head_idx * block_size * head_size ...] int block_offset physical_block * block_stride head_idx * block_size * head_size; // 计算这个 token 和当前块里所有 token 的 attention score for (int t 0; t block_size; t) { float score 0; for (int d 0; d head_size; d) { score query[q_offset d] * key_cache[block_offset t * head_size d]; } scores[block_idx * block_size t] score * scale; } } // softmax weighted sum跟标准 attention 一样 ... }kernel 的核心只有一行physical_block block_table[seq_idx * max_blocks block_idx]。这一行就是 PagedAttention 的全部魔法——其余部分都是在做普通的 attention 运算。代价只是一次额外的全局内存读取读块表在已经在做 O(n^2) 的 attention 运算面前可以忽略。你可以抄的作业1. 分页思路不只属于操作系统任何大块连续分配会碎片化的场景都能用分页。你要做个内存池管理游戏对象分页。管理网络数据包的缓冲分页。只要分配单元不固定且碎片化严重固定大小的块 映射表就是标准答案。2. Copy-on-Write 的通用模式fork 共享读取 写时复制。vLLM 的 block fork 和 Linux 的 fork() 系统调用本质上是一回事。理解 COW你就多了一个优化同源并行操作的武器。3. Continuous Batching 就是能进就进Pipeline 优化的本质不是凑满批次而是不要等。任何批处理系统——ETL 管道、消息队列消费者、API Gateway——都可以用这个思路有空闲资源就拉做完立刻放不等。4. 好的优化 好的数据结构 老的计算机思想PagedAttention 没有发明新数学它只是选了正确的数据结构页表和正确的资源管理策略按需分配 COW。“创新很多时候就是把别处已经验证过的思想搬到你的领域”。最后vLLM 的故事跟很多学术项目变成工业标准的故事一样不是算法有多新而是工程优化做得够深。PagedAttention 把显存利用率从 30% 拉到 90%靠的不是一篇论文、一个公式而是一个完整的系统设计——块管理、调度器、CUDA kernel 三者协同工作。理解 vLLM 不只是学一个推理框架更是学如何把一个孤立的算法优化做成系统级的解决方案。下一讲拆 Dify。一个低代码 AI 应用平台是怎么设计插件系统让 100 个模型和工具能无缝接入的本文拆解的 vLLM 版本v0.6.x。源码地址github.com/vllm-project/vllm 一只用 AI Agent 搭副业产线的程序员全平台同名虾哥不加班 | 源码GitHub - lobster-bujiaban需要定制 AI 工具来聊聊 → lob_ai
