如果把 PCB 布线和 LLM 放到同一个句子里很多人第一反应是“营销号标题”。但这次不用怀疑这个话题已经在 EDA 工具链和 AI Agent 交叉领域热了很长时间。简单说LLM PCB Routing 研究的是能不能让大语言模型理解电路连接关系、设计规则和布线约束然后像人类工程师一样给出可落地的布线决策甚至直接调用布线引擎完成一部分工作。这个项目最值得关注的不是“AI 自动布完整块板”而是“LLM 能不能把资深工程师的经验转成可执行的规则和决策逻辑”。今天这篇文章就围绕这个方向展开梳理 LLM 在 PCB 布线里的定位、数据链路、环境准备、验证方法以及如果你想自己搭一套最小的 LLM PCB Routing 实验环境应该从哪里下手。文章会覆盖以下几个方面LLM 在 PCB 布线流程中能承担什么角色、如何把原理图/网表/规则喂给模型、本地部署 LLM 时怎么控制显存占用、如何用 Python 封装一个调用 LLM 的布线辅助接口以及批量处理多个网络节点时的任务设计思路。1. 核心能力速览先给一个快速判断表方便你确认这个方向值不值得深入了解。下面的参数基于当前 LLM Agent EDA 工具链的常见实践具体以你所选模型和框架为准。能力项说明项目类型LLM Agent 在 EDA/PCB 设计领域的垂直应用研究核心技术LLM 推理 规则转译 布线工具调用 DRC 验证反馈主要功能布线策略生成、设计规则解释、布线冲突分析、基于 LLM 的辅助布线决策是否支持 CPU 推理是但速度明显下降建议 GPU 加速推荐硬件4G 显存可跑 7B 级量化模型12G 以上更从容纯 CPU 也可跑但响应慢是否支持 50 系显卡取决于推理框架版本新版本逐步适配支持平台Windows / Linux 均可Linux 下显存管理和并发更稳定启动方式Python 命令行启动 / API 服务启动 / 本地 Web 对话界面是否支持 API支持通过 HTTP 或 OpenAI 兼容接口暴露是否支持批量任务支持可对多个网络或多个布线区域做批量推理与结果汇总适合场景自动化布线决策辅助、规则学习、教育培训、PCB 设计工具智能化改造2. LLM 在 PCB 布线流程里到底能干什么PCB 布线不是单纯的“连线游戏”。它要同时满足电气连接、信号完整性、EMC、热设计、生产工艺和成本约束。资深工程师的经验很大程度体现在“如何在互相冲突的约束中做取舍”。传统算法布线工具擅长在给定约束下搜索路径但它不理解“为什么这么走”。LLM 的价值恰恰在这里它能理解工程师用自然语言描述的约束比如“电源线要加宽”“晶振下方不能走其他信号线”“USB 差分对内等长控制在 5mil 内”然后把这些约束转成结构化规则辅助生成布线策略甚至在遇到 DRC 报错时给出修改建议。从技术链路上看LLM 在 PCB Routing 中有这样几个可落地的角色。2.1 设计规则知识库问答把公司内部的设计规则手册、IPC 标准、工程师经验文档灌入向量数据库然后用 LLM 做检索增强生成。工程师问“6 层板层叠怎么设计”“2A 电流走线宽度应该多少”模型给出带依据的回答。这是最容易落地、也是门槛最低的应用。2.2 布线约束转译工程师用自然语言表达设计意图LLM 负责将其转成 EDA 工具的约束格式例如 KiCad 的规则文件、Allegro 的约束表格或者自定义的 JSON 规则集。这个环节数据量不大但能极大减少工程师手工配置规则的工作量。2.3 布线方案建议与冲突分析当某个区域布线密集、DRC 报错时LLM 可以结合网表、布局位置和规则集给出备选路径、换层方案或调整器件位置的建议。2.4 布线结果检查把布线完成后的数据导出成文本化描述交给 LLM 做初步审查检查有没有明显违反规则的地方。这相当于一个会读规则的 AI 助理。需要提醒的是这里说的“LLM 自动布线”和“算法自动布线”不是替代关系而是互相配合。LLM 擅长理解和决策算法擅长精确搜索路径。现在行业里更受认可的做法是用 LLM 做感知、拆解、决策用传统布线引擎做最终路径生成。3. 本地部署 LLM 的环境准备与前置条件如果你想实际跑一个 LLM PCB Routing 辅助系统第一步是准备一个可用的 LLM 推理环境。下面给出一套通用实验环境清单具体版本以实际安装为准。3.1 硬件层面显卡NVIDIA 显卡优先显存 4G 以上可以跑量化后的 7B 模型12G 以上可以跑更大参数模型或加更大上下文。内存16G 起步32G 更稳。LLM 推理时 KV Cache 会额外占用显存和内存。磁盘模型文件动辄几个 GB预留至少 20G 空间。如果只有 CPU也可以运行但推理速度会明显变慢。作为规则问答这种低频场景还够用大批量布线分析就不太现实。3.2 软件层面Python 3.10 或 3.11。CUDA Toolkit 和 cuDNN版本要与 PyTorch 对应。推理框架任选其一Transformers、vLLM、Ollama、llama.cpp。向量数据库Milvus、Chroma 或 FAISS用于存储 PCB 规则文档。EDA 工具KiCad开源、嘉立创 EDA 或你日常使用的工具用于导出网表和格式转换。3.3 端口占用检查启动 API 服务前先检查端口是否被占用例如 8000、8080、7860 是常见冲突点。# Linux / macOS lsof -i :8000 # Windows netstat -ano | findstr :80003.4 通用环境准备命令下面是通用模板实际需要按你选择的推理框架调整。# 创建独立虚拟环境 python -m venv llm_pcb_env source llm_pcb_env/bin/activate # Windows 用 llm_pcb_env\Scripts\activate # 安装 PyTorch请根据官网选择对应 CUDA 版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装推理相关依赖 pip install transformers accelerate sentencepiece # 安装文档检索相关依赖 pip install chromadb pypdf4. LLM PCB Routing 系统架构与启动流程一套最小可用的 LLM PCB Routing 辅助系统通常包含四个模块模块作用技术选型数据接入层读取网表、原理图、Gerber、规则文件Python 脚本解析规则知识库存储设计规则和工程师经验Chroma / FAISSLLM 推理层理解问题并生成决策建议Ollama / vLLM / Transformers工具调用层将 LLM 输出转成具体操作Python EDA 脚本接口4.1 推理服务启动以 Ollama 为例先下载一个 7B 级模型然后启动服务。# 拉取模型 ollama pull qwen2.5:7b # 启动服务默认端口 11434 ollama serve启动后可以用 curl 验证服务是否正常。curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: PCB 布线中2A 电流的电源走线宽度应该怎么估算, stream: false }如果返回包含回答内容说明推理服务已经可用。4.2 规则知识库构建把 PCB 设计规则文档转换成文本块写入向量数据库。流程如下from chromadb import PersistentClient client PersistentClient(path./pcb_rule_db) collection client.get_or_create_collection(namepcb_rules) # 以列表形式写入规则片段 rules [ 电源走线宽度需要根据载流能力计算2A 电流在 1oz 铜厚下建议不小于 0.5mm。, 差分信号对内等长误差通常控制在 5mil 以内。, 晶振下方禁止铺铜和走线避免寄生电容影响。 ] for i, rule in enumerate(rules): collection.add( documents[rule], ids[frule_{i}] )查询时从知识库检索相关内容作为 LLM 回答的上下文。results collection.query( query_texts[电源线宽度怎么算], n_results2 ) print(results[documents])4.3 主程序封装将推理、检索和布线建议整合到一个 Python 类中方便后续封装 API。class LLMPCBRouter: def __init__(self, model_name: str, collection): self.model_name model_name self.collection collection def ask_route_advice(self, question: str) - str: # 检索相关规则 docs self.collection.query( query_texts[question], n_results3 )[documents] context \n.join(docs[0] if docs else []) # 构造提示词 prompt f你是一名资深 PCB 布线工程师。请根据以下设计规则和问题给出专业、可执行的布线建议。 设计规则 {context} 问题{question} 请从走线宽度、间距、层叠、器件布局等方面给出具体建议。 # 调用本地推理服务 import requests resp requests.post( http://127.0.0.1:11434/api/generate, json{model: self.model_name, prompt: prompt, stream: False}, timeout120 ) return resp.json()[response]4.4 启动入口python main.py --host 127.0.0.1 --port 7860启动后看到类似 “Uvicorn running on http://127.0.0.1:7860” 的输出说明服务已经就绪。5. 功能测试与效果验证部署完成后需要逐项验证系统能力。这个方向的核心功能可以按下面几个维度来测。5.1 规则理解测试向系统提问“在 6 层板设计中电源层和地层应该怎么安排”预期结果系统能结合知识库中的规则文档给出层叠顺序、参考平面、阻抗控制等建议。判断成功标准是回答中是否包含具体的层叠结构描述而不是泛泛而谈。如果回答太笼统通常是知识库检索到的文档片段太少需要增加规则文档数量或者调整切分长度。5.2 布线约束转译测试给 LLM 一段自然语言约束看它能否正确转成结构化 JSON。输入USB 2.0 差分对走线要求对内等长 5mil尽量走顶层远离晶振。预期输出{ net_pair: USB_DP/USB_DM, length_matching_tolerance_mil: 5, preferred_layer: TOP, keepout_components: [CRYSTAL] }这一步可以手工比对也可以写脚本验证 JSON 是否能被 EDA 脚本正常解析。5.3 冲突分析测试模拟一个场景某个 BGA 区域的布线空间不足规则要求走线间距 4mil但实际空间只能容纳 3mil。提问系统怎么处理。预期结果系统能给出至少两种备选策略例如缩小局部间距后做阻抗补偿、换层走线、调整过孔位置等。判断成功标准是系统能意识到“多个约束不可同时满足”的冲突本质。如果系统只给出单一回答可以在提示词中增加“请给出 3 个方案并说明取舍”。这属于提示词工程层面的改进。5.4 批量任务测试在批量模式下准备一份包含多个网络布线问题的 JSON 文件用脚本循环调用 LLM并记录每次推理耗时和输出结果。import json import time tasks [ {net: VCC_3V3, question: 3.3V 电源网络布线建议}, {net: I2C_SCL, question: I2C 时钟线布线注意事项}, {net: UART_TX, question: UART 发送线布线建议} ] for task in tasks: start time.time() advice router.ask_route_advice(task[question]) elapsed time.time() - start print(f{task[net]} 耗时 {elapsed:.2f}s) print(advice)批量任务的重点是稳定性。如果中途出现超时需要增加请求超时时间或加入重试机制。5.5 输出质量评估LLM 输出质量不稳定是正常现象。建议建立一套简单的评分标准从准确性和可执行性两个维度评估。准确性看规则引用是否正确可执行性看建议是否具体到线宽、层数、元件编号级别。6. 接口 API 与批量任务设计如果要把 LLM PCB Routing 能力接入到已有工具链中必须封装成 API 服务。下面给出一个最简的 FastAPI 服务示例。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class RouteQuery(BaseModel): question: str net: str board_id: str app.post(/api/route-advice) def route_advice(query: RouteQuery): # 创建 Router 实例并调用这里的 collection 需要从全局获取 advice router.ask_route_advice(query.question) return { net: query.net, question: query.question, advice: advice, status: success }启动服务uvicorn api_server:app --host 0.0.0.0 --port 8000调用示例curl -X POST http://127.0.0.1:8000/api/route-advice \ -H Content-Type: application/json \ -d {question: 电源线走线宽度如何确定, net: VCC_5V}6.1 批量任务目录设计批量场景建议按“一个网络一个任务”拆分输入和输出都用目录隔离。./batch_input/ task_001.json task_002.json task_003.json ./batch_output/ task_001_result.json task_002_result.json task_003_result.json每个任务文件建议包含以下字段{ task_id: task_001, net: VCC_3V3, constraints: { current_a: 2, copper_thickness_oz: 1, max_length_mm: 50 }, question: 请为 VCC_3V3 网络生成布线建议 }6.2 失败重试建议LLM 推理服务偶尔会因为显存不足、超时返回错误。批量处理时必须加重试机制。常见做法是失败任务写入failed队列间隔 5 秒重试最多重试 3 次超过 3 次记录日志待人工处理。import time def run_with_retry(func, max_retries3, delay5): for attempt in range(max_retries): try: return func() except Exception as e: if attempt max_retries - 1: raise time.sleep(delay)7. 资源占用与性能观察方法这个方向最常见的性能瓶颈在 LLM 推理层。下面给出几个实用的观察方法具体数值以你本机测试为准。7.1 显存占用观察模型推理时会动态申请显存。Linux 下可以用nvidia-smi实时查看Windows 下可以用任务管理器或nvidia-smi的 Windows 版本在命令行里运行nvidia-smi重点看两个指标Memory-Usage和GPU-Util。启动服务前显存占用接近 0加载模型后显存会明显上升。推理过程中显存波动属于正常现象。如果显存占用超过显卡总容量的 95%推理时会报CUDA out of memory。这时需要换成更小的模型、开启量化或者把上下文长度调小。7.2 CPU 推理与 GPU 推理的差异CPU 推理不是不能用只是慢。同一个 7B 模型、同样的问题GPU 几秒内返回结果CPU 可能要几十秒甚至更长。如果只是做规则问答、低频使用CPU 方案可以接受。如果做批量布线分析GPU 几乎是必需的。7.3 影响推理速度的参数下面几个参数对性能和效果影响最大参数影响上下文长度越长占用越多显存推理越慢采样步数/生成长度回答越长越慢并发请求数超过资源上限会导致排队甚至崩溃量化精度4bit 比 8bit 省显存效果轻微损失7.4 降低显存占用的方法如果显存紧张可以按顺序尝试以下方案换更小参数量模型例如从 13B 换到 7B。开启 4bit 量化加载Transformers 和 Ollama 都支持。限制生成最大长度布线建议控制在 300 token 以内。降低并发数服务端做请求排队。7.5 避免端口冲突与进程残留反复调试容易出现端口冲突。启动前检查端口结束后清理进程。# 查找占用 8000 端口的进程 PID lsof -i :8000 # 结束进程Windows 下用 taskkill /PID pid /F kill -9 pid如果服务异常退出Python 进程没有及时释放显存可以重启终端或手动结束残留进程再重新启动。8. 常见问题与排查方法实际部署过程中最可能遇到下面这些问题。问题现象可能原因排查方式解决方案服务启动后页面打不开端口被占用或服务未启动检查日志和端口更换端口或重启服务模型加载时报 CUDA out of memory显存不足查看 nvidia-smi 占用换小模型、开启量化、限制上下文推理速度很慢使用 CPU 推理查看 GPU-Util改用 GPU 或降低模型规模回答内容与 PCB 规则不符知识库检索不到相关内容检查向量库写入增加规则文档或人工校核API 调用超时模型生成时间过长查看日志耗时增大超时时间、限制生成长度批量任务中途卡住并发超限或网络问题查看日志和资源占用加入重试机制、降低并发输出 JSON 格式非法模型生成不稳定查看原始输出增加 JSON 输出校验和修正逻辑规则检索结果为空文档切分或写入失败查询向量库条数重新执行文档写入流程8.1 依赖安装失败Python 依赖冲突是最常见的问题。建议所有项目都使用独立虚拟环境不要全局安装依赖。如果 PyTorch 安装失败优先从官网复制对应 CUDA 版本的安装命令而不是用默认 pip 源。8.2 模型文件缺失Ollama 会自动下载模型Transformers 会在首次加载时从 Hugging Face 拉取权重。如果网络不稳定建议提前手动下载模型文件到本地再通过本地路径加载。不要编造不存在的模型文件名以你实际选择的模型为准。8.3 输出质量不稳定LLM 生成结果天然有随机性。排查顺序是先看知识库检索是否命中正确规则再看提示词是否把任务描述清楚最后才是换模型。温度参数 temperature 不要调太高一般 0.2 到 0.5 之间可以让输出更稳定。9. 最佳实践与使用建议把这个方向落地到实际工作中有几个工程化建议值得保留。9.1 第一次先小参数测试不要一开始就上大批量任务。先用 3 到 5 个典型问题验证链路是否通畅确认推理服务、检索服务和 API 封装都没问题再扩大测试范围。这样可以避免在错误的方向上浪费大量时间。9.2 规则文档要分目录管理PCB 设计规则文档按类别存放通用设计规范、电源布线规范、高速信号布线规范、EMC 规范、生产工艺规范。这样在向量化入库时可以按类别打标签检索时也能限定范围提升命中率。./rules/ general/ power/ high_speed/ emc/ manufacturing/9.3 保留一套最小可运行配置把基础环境、模型路径、规则库路径、API 端口等写成一个配置文件方便在任何机器上快速复现。llm: model_name: qwen2.5:7b base_url: http://127.0.0.1:11434 temperature: 0.3 max_tokens: 500 knowledge_base: db_path: ./pcb_rule_db rule_dirs: - ./rules/general - ./rules/power api: host: 0.0.0.0 port: 8000 batch: input_dir: ./batch_input output_dir: ./batch_output max_retries: 3 timeout_seconds: 1209.4 批量任务必须加日志和失败重试LLM 服务不是 100% 稳定批量任务必须记录每个任务的开始时间、结束时间、耗时、输出摘要和错误信息。日志文件建议用task_id命名方便任务级定位问题。9.5 接口服务要限制访问范围如果 API 服务绑定了0.0.0.0局域网内其他机器也能访问。如果只是本机测试建议绑定127.0.0.1。如果确实需要远程访问至少要加一个简单的 Token 校验不要裸奔到公网。9.6 版权与数据安全边界PCB 设计文件是高度敏感的企业资产。涉及网表、原理图、Gerber 文件时必须确认数据有没有授权可以交给外部模型处理。使用云端 API 时要确保数据不出机房优先使用本地部署的模型。涉及客户项目的设计数据时不建议直接上传到公有 AI 服务进行分析。这个方向的目标是辅助工程师不是替代工程师。LLM 给出的布线建议必须经过人工复核和 DRC 验证才能进入生产流程。任何自动化布线决策都不能绕过最终的设计评审和制造审查环节。10. 总结与下一步LLM PCB Routing 的核心价值不在于让模型学会画线而在于让模型理解“为什么要这么画线”。从规则知识库问答到布线约束转译再到基于 DRC 反馈的冲突分析LLM 在 PCB 设计流程中承担的角色越来越接近一个有经验的助理工程师。如果你想快速验证这个方向最先应该做的是把设计规则文档整理成知识库跑通“问规则 - 检索 - LLM 生成建议”这条链路。这条链路不需要复杂的 EDA 集成也不需要写布线引擎脚本门槛最低收益却最直观。跑通之后再考虑把网表格式、Gerber 解析结果接入进来让 LLM 直接处理电路连接数据。最容易踩的坑是过早追求“LLM 自动布线”忽略了对 PCB 设计规则的结构化和知识库建设。没有规则库支撑的 LLM 就是一个通用聊天机器人给出的建议没有工程约束力。只有先把规则库做扎实后续的 Agent 化和工具调用才有意义。后续可以扩展的方向包括用 LLM Agent 结合开源的 PCB 设计工具做规则约束自动配置、将 DRC 报告回流给模型形成自监督闭环、用 RAG 架构把公司历史布线案例变成经验库。这些方向可以串成一套完整的 AI 辅助 PCB 设计工作流也是这个项目最有想象力的地方。先把规则库建起来让模型先看懂规则再谈让它动手布线。 LLM+PCB布线：让大语言模型读懂设计规则，辅助布线决策
如果把 PCB 布线和 LLM 放到同一个句子里很多人第一反应是“营销号标题”。但这次不用怀疑这个话题已经在 EDA 工具链和 AI Agent 交叉领域热了很长时间。简单说LLM PCB Routing 研究的是能不能让大语言模型理解电路连接关系、设计规则和布线约束然后像人类工程师一样给出可落地的布线决策甚至直接调用布线引擎完成一部分工作。这个项目最值得关注的不是“AI 自动布完整块板”而是“LLM 能不能把资深工程师的经验转成可执行的规则和决策逻辑”。今天这篇文章就围绕这个方向展开梳理 LLM 在 PCB 布线里的定位、数据链路、环境准备、验证方法以及如果你想自己搭一套最小的 LLM PCB Routing 实验环境应该从哪里下手。文章会覆盖以下几个方面LLM 在 PCB 布线流程中能承担什么角色、如何把原理图/网表/规则喂给模型、本地部署 LLM 时怎么控制显存占用、如何用 Python 封装一个调用 LLM 的布线辅助接口以及批量处理多个网络节点时的任务设计思路。1. 核心能力速览先给一个快速判断表方便你确认这个方向值不值得深入了解。下面的参数基于当前 LLM Agent EDA 工具链的常见实践具体以你所选模型和框架为准。能力项说明项目类型LLM Agent 在 EDA/PCB 设计领域的垂直应用研究核心技术LLM 推理 规则转译 布线工具调用 DRC 验证反馈主要功能布线策略生成、设计规则解释、布线冲突分析、基于 LLM 的辅助布线决策是否支持 CPU 推理是但速度明显下降建议 GPU 加速推荐硬件4G 显存可跑 7B 级量化模型12G 以上更从容纯 CPU 也可跑但响应慢是否支持 50 系显卡取决于推理框架版本新版本逐步适配支持平台Windows / Linux 均可Linux 下显存管理和并发更稳定启动方式Python 命令行启动 / API 服务启动 / 本地 Web 对话界面是否支持 API支持通过 HTTP 或 OpenAI 兼容接口暴露是否支持批量任务支持可对多个网络或多个布线区域做批量推理与结果汇总适合场景自动化布线决策辅助、规则学习、教育培训、PCB 设计工具智能化改造2. LLM 在 PCB 布线流程里到底能干什么PCB 布线不是单纯的“连线游戏”。它要同时满足电气连接、信号完整性、EMC、热设计、生产工艺和成本约束。资深工程师的经验很大程度体现在“如何在互相冲突的约束中做取舍”。传统算法布线工具擅长在给定约束下搜索路径但它不理解“为什么这么走”。LLM 的价值恰恰在这里它能理解工程师用自然语言描述的约束比如“电源线要加宽”“晶振下方不能走其他信号线”“USB 差分对内等长控制在 5mil 内”然后把这些约束转成结构化规则辅助生成布线策略甚至在遇到 DRC 报错时给出修改建议。从技术链路上看LLM 在 PCB Routing 中有这样几个可落地的角色。2.1 设计规则知识库问答把公司内部的设计规则手册、IPC 标准、工程师经验文档灌入向量数据库然后用 LLM 做检索增强生成。工程师问“6 层板层叠怎么设计”“2A 电流走线宽度应该多少”模型给出带依据的回答。这是最容易落地、也是门槛最低的应用。2.2 布线约束转译工程师用自然语言表达设计意图LLM 负责将其转成 EDA 工具的约束格式例如 KiCad 的规则文件、Allegro 的约束表格或者自定义的 JSON 规则集。这个环节数据量不大但能极大减少工程师手工配置规则的工作量。2.3 布线方案建议与冲突分析当某个区域布线密集、DRC 报错时LLM 可以结合网表、布局位置和规则集给出备选路径、换层方案或调整器件位置的建议。2.4 布线结果检查把布线完成后的数据导出成文本化描述交给 LLM 做初步审查检查有没有明显违反规则的地方。这相当于一个会读规则的 AI 助理。需要提醒的是这里说的“LLM 自动布线”和“算法自动布线”不是替代关系而是互相配合。LLM 擅长理解和决策算法擅长精确搜索路径。现在行业里更受认可的做法是用 LLM 做感知、拆解、决策用传统布线引擎做最终路径生成。3. 本地部署 LLM 的环境准备与前置条件如果你想实际跑一个 LLM PCB Routing 辅助系统第一步是准备一个可用的 LLM 推理环境。下面给出一套通用实验环境清单具体版本以实际安装为准。3.1 硬件层面显卡NVIDIA 显卡优先显存 4G 以上可以跑量化后的 7B 模型12G 以上可以跑更大参数模型或加更大上下文。内存16G 起步32G 更稳。LLM 推理时 KV Cache 会额外占用显存和内存。磁盘模型文件动辄几个 GB预留至少 20G 空间。如果只有 CPU也可以运行但推理速度会明显变慢。作为规则问答这种低频场景还够用大批量布线分析就不太现实。3.2 软件层面Python 3.10 或 3.11。CUDA Toolkit 和 cuDNN版本要与 PyTorch 对应。推理框架任选其一Transformers、vLLM、Ollama、llama.cpp。向量数据库Milvus、Chroma 或 FAISS用于存储 PCB 规则文档。EDA 工具KiCad开源、嘉立创 EDA 或你日常使用的工具用于导出网表和格式转换。3.3 端口占用检查启动 API 服务前先检查端口是否被占用例如 8000、8080、7860 是常见冲突点。# Linux / macOS lsof -i :8000 # Windows netstat -ano | findstr :80003.4 通用环境准备命令下面是通用模板实际需要按你选择的推理框架调整。# 创建独立虚拟环境 python -m venv llm_pcb_env source llm_pcb_env/bin/activate # Windows 用 llm_pcb_env\Scripts\activate # 安装 PyTorch请根据官网选择对应 CUDA 版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装推理相关依赖 pip install transformers accelerate sentencepiece # 安装文档检索相关依赖 pip install chromadb pypdf4. LLM PCB Routing 系统架构与启动流程一套最小可用的 LLM PCB Routing 辅助系统通常包含四个模块模块作用技术选型数据接入层读取网表、原理图、Gerber、规则文件Python 脚本解析规则知识库存储设计规则和工程师经验Chroma / FAISSLLM 推理层理解问题并生成决策建议Ollama / vLLM / Transformers工具调用层将 LLM 输出转成具体操作Python EDA 脚本接口4.1 推理服务启动以 Ollama 为例先下载一个 7B 级模型然后启动服务。# 拉取模型 ollama pull qwen2.5:7b # 启动服务默认端口 11434 ollama serve启动后可以用 curl 验证服务是否正常。curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: PCB 布线中2A 电流的电源走线宽度应该怎么估算, stream: false }如果返回包含回答内容说明推理服务已经可用。4.2 规则知识库构建把 PCB 设计规则文档转换成文本块写入向量数据库。流程如下from chromadb import PersistentClient client PersistentClient(path./pcb_rule_db) collection client.get_or_create_collection(namepcb_rules) # 以列表形式写入规则片段 rules [ 电源走线宽度需要根据载流能力计算2A 电流在 1oz 铜厚下建议不小于 0.5mm。, 差分信号对内等长误差通常控制在 5mil 以内。, 晶振下方禁止铺铜和走线避免寄生电容影响。 ] for i, rule in enumerate(rules): collection.add( documents[rule], ids[frule_{i}] )查询时从知识库检索相关内容作为 LLM 回答的上下文。results collection.query( query_texts[电源线宽度怎么算], n_results2 ) print(results[documents])4.3 主程序封装将推理、检索和布线建议整合到一个 Python 类中方便后续封装 API。class LLMPCBRouter: def __init__(self, model_name: str, collection): self.model_name model_name self.collection collection def ask_route_advice(self, question: str) - str: # 检索相关规则 docs self.collection.query( query_texts[question], n_results3 )[documents] context \n.join(docs[0] if docs else []) # 构造提示词 prompt f你是一名资深 PCB 布线工程师。请根据以下设计规则和问题给出专业、可执行的布线建议。 设计规则 {context} 问题{question} 请从走线宽度、间距、层叠、器件布局等方面给出具体建议。 # 调用本地推理服务 import requests resp requests.post( http://127.0.0.1:11434/api/generate, json{model: self.model_name, prompt: prompt, stream: False}, timeout120 ) return resp.json()[response]4.4 启动入口python main.py --host 127.0.0.1 --port 7860启动后看到类似 “Uvicorn running on http://127.0.0.1:7860” 的输出说明服务已经就绪。5. 功能测试与效果验证部署完成后需要逐项验证系统能力。这个方向的核心功能可以按下面几个维度来测。5.1 规则理解测试向系统提问“在 6 层板设计中电源层和地层应该怎么安排”预期结果系统能结合知识库中的规则文档给出层叠顺序、参考平面、阻抗控制等建议。判断成功标准是回答中是否包含具体的层叠结构描述而不是泛泛而谈。如果回答太笼统通常是知识库检索到的文档片段太少需要增加规则文档数量或者调整切分长度。5.2 布线约束转译测试给 LLM 一段自然语言约束看它能否正确转成结构化 JSON。输入USB 2.0 差分对走线要求对内等长 5mil尽量走顶层远离晶振。预期输出{ net_pair: USB_DP/USB_DM, length_matching_tolerance_mil: 5, preferred_layer: TOP, keepout_components: [CRYSTAL] }这一步可以手工比对也可以写脚本验证 JSON 是否能被 EDA 脚本正常解析。5.3 冲突分析测试模拟一个场景某个 BGA 区域的布线空间不足规则要求走线间距 4mil但实际空间只能容纳 3mil。提问系统怎么处理。预期结果系统能给出至少两种备选策略例如缩小局部间距后做阻抗补偿、换层走线、调整过孔位置等。判断成功标准是系统能意识到“多个约束不可同时满足”的冲突本质。如果系统只给出单一回答可以在提示词中增加“请给出 3 个方案并说明取舍”。这属于提示词工程层面的改进。5.4 批量任务测试在批量模式下准备一份包含多个网络布线问题的 JSON 文件用脚本循环调用 LLM并记录每次推理耗时和输出结果。import json import time tasks [ {net: VCC_3V3, question: 3.3V 电源网络布线建议}, {net: I2C_SCL, question: I2C 时钟线布线注意事项}, {net: UART_TX, question: UART 发送线布线建议} ] for task in tasks: start time.time() advice router.ask_route_advice(task[question]) elapsed time.time() - start print(f{task[net]} 耗时 {elapsed:.2f}s) print(advice)批量任务的重点是稳定性。如果中途出现超时需要增加请求超时时间或加入重试机制。5.5 输出质量评估LLM 输出质量不稳定是正常现象。建议建立一套简单的评分标准从准确性和可执行性两个维度评估。准确性看规则引用是否正确可执行性看建议是否具体到线宽、层数、元件编号级别。6. 接口 API 与批量任务设计如果要把 LLM PCB Routing 能力接入到已有工具链中必须封装成 API 服务。下面给出一个最简的 FastAPI 服务示例。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class RouteQuery(BaseModel): question: str net: str board_id: str app.post(/api/route-advice) def route_advice(query: RouteQuery): # 创建 Router 实例并调用这里的 collection 需要从全局获取 advice router.ask_route_advice(query.question) return { net: query.net, question: query.question, advice: advice, status: success }启动服务uvicorn api_server:app --host 0.0.0.0 --port 8000调用示例curl -X POST http://127.0.0.1:8000/api/route-advice \ -H Content-Type: application/json \ -d {question: 电源线走线宽度如何确定, net: VCC_5V}6.1 批量任务目录设计批量场景建议按“一个网络一个任务”拆分输入和输出都用目录隔离。./batch_input/ task_001.json task_002.json task_003.json ./batch_output/ task_001_result.json task_002_result.json task_003_result.json每个任务文件建议包含以下字段{ task_id: task_001, net: VCC_3V3, constraints: { current_a: 2, copper_thickness_oz: 1, max_length_mm: 50 }, question: 请为 VCC_3V3 网络生成布线建议 }6.2 失败重试建议LLM 推理服务偶尔会因为显存不足、超时返回错误。批量处理时必须加重试机制。常见做法是失败任务写入failed队列间隔 5 秒重试最多重试 3 次超过 3 次记录日志待人工处理。import time def run_with_retry(func, max_retries3, delay5): for attempt in range(max_retries): try: return func() except Exception as e: if attempt max_retries - 1: raise time.sleep(delay)7. 资源占用与性能观察方法这个方向最常见的性能瓶颈在 LLM 推理层。下面给出几个实用的观察方法具体数值以你本机测试为准。7.1 显存占用观察模型推理时会动态申请显存。Linux 下可以用nvidia-smi实时查看Windows 下可以用任务管理器或nvidia-smi的 Windows 版本在命令行里运行nvidia-smi重点看两个指标Memory-Usage和GPU-Util。启动服务前显存占用接近 0加载模型后显存会明显上升。推理过程中显存波动属于正常现象。如果显存占用超过显卡总容量的 95%推理时会报CUDA out of memory。这时需要换成更小的模型、开启量化或者把上下文长度调小。7.2 CPU 推理与 GPU 推理的差异CPU 推理不是不能用只是慢。同一个 7B 模型、同样的问题GPU 几秒内返回结果CPU 可能要几十秒甚至更长。如果只是做规则问答、低频使用CPU 方案可以接受。如果做批量布线分析GPU 几乎是必需的。7.3 影响推理速度的参数下面几个参数对性能和效果影响最大参数影响上下文长度越长占用越多显存推理越慢采样步数/生成长度回答越长越慢并发请求数超过资源上限会导致排队甚至崩溃量化精度4bit 比 8bit 省显存效果轻微损失7.4 降低显存占用的方法如果显存紧张可以按顺序尝试以下方案换更小参数量模型例如从 13B 换到 7B。开启 4bit 量化加载Transformers 和 Ollama 都支持。限制生成最大长度布线建议控制在 300 token 以内。降低并发数服务端做请求排队。7.5 避免端口冲突与进程残留反复调试容易出现端口冲突。启动前检查端口结束后清理进程。# 查找占用 8000 端口的进程 PID lsof -i :8000 # 结束进程Windows 下用 taskkill /PID pid /F kill -9 pid如果服务异常退出Python 进程没有及时释放显存可以重启终端或手动结束残留进程再重新启动。8. 常见问题与排查方法实际部署过程中最可能遇到下面这些问题。问题现象可能原因排查方式解决方案服务启动后页面打不开端口被占用或服务未启动检查日志和端口更换端口或重启服务模型加载时报 CUDA out of memory显存不足查看 nvidia-smi 占用换小模型、开启量化、限制上下文推理速度很慢使用 CPU 推理查看 GPU-Util改用 GPU 或降低模型规模回答内容与 PCB 规则不符知识库检索不到相关内容检查向量库写入增加规则文档或人工校核API 调用超时模型生成时间过长查看日志耗时增大超时时间、限制生成长度批量任务中途卡住并发超限或网络问题查看日志和资源占用加入重试机制、降低并发输出 JSON 格式非法模型生成不稳定查看原始输出增加 JSON 输出校验和修正逻辑规则检索结果为空文档切分或写入失败查询向量库条数重新执行文档写入流程8.1 依赖安装失败Python 依赖冲突是最常见的问题。建议所有项目都使用独立虚拟环境不要全局安装依赖。如果 PyTorch 安装失败优先从官网复制对应 CUDA 版本的安装命令而不是用默认 pip 源。8.2 模型文件缺失Ollama 会自动下载模型Transformers 会在首次加载时从 Hugging Face 拉取权重。如果网络不稳定建议提前手动下载模型文件到本地再通过本地路径加载。不要编造不存在的模型文件名以你实际选择的模型为准。8.3 输出质量不稳定LLM 生成结果天然有随机性。排查顺序是先看知识库检索是否命中正确规则再看提示词是否把任务描述清楚最后才是换模型。温度参数 temperature 不要调太高一般 0.2 到 0.5 之间可以让输出更稳定。9. 最佳实践与使用建议把这个方向落地到实际工作中有几个工程化建议值得保留。9.1 第一次先小参数测试不要一开始就上大批量任务。先用 3 到 5 个典型问题验证链路是否通畅确认推理服务、检索服务和 API 封装都没问题再扩大测试范围。这样可以避免在错误的方向上浪费大量时间。9.2 规则文档要分目录管理PCB 设计规则文档按类别存放通用设计规范、电源布线规范、高速信号布线规范、EMC 规范、生产工艺规范。这样在向量化入库时可以按类别打标签检索时也能限定范围提升命中率。./rules/ general/ power/ high_speed/ emc/ manufacturing/9.3 保留一套最小可运行配置把基础环境、模型路径、规则库路径、API 端口等写成一个配置文件方便在任何机器上快速复现。llm: model_name: qwen2.5:7b base_url: http://127.0.0.1:11434 temperature: 0.3 max_tokens: 500 knowledge_base: db_path: ./pcb_rule_db rule_dirs: - ./rules/general - ./rules/power api: host: 0.0.0.0 port: 8000 batch: input_dir: ./batch_input output_dir: ./batch_output max_retries: 3 timeout_seconds: 1209.4 批量任务必须加日志和失败重试LLM 服务不是 100% 稳定批量任务必须记录每个任务的开始时间、结束时间、耗时、输出摘要和错误信息。日志文件建议用task_id命名方便任务级定位问题。9.5 接口服务要限制访问范围如果 API 服务绑定了0.0.0.0局域网内其他机器也能访问。如果只是本机测试建议绑定127.0.0.1。如果确实需要远程访问至少要加一个简单的 Token 校验不要裸奔到公网。9.6 版权与数据安全边界PCB 设计文件是高度敏感的企业资产。涉及网表、原理图、Gerber 文件时必须确认数据有没有授权可以交给外部模型处理。使用云端 API 时要确保数据不出机房优先使用本地部署的模型。涉及客户项目的设计数据时不建议直接上传到公有 AI 服务进行分析。这个方向的目标是辅助工程师不是替代工程师。LLM 给出的布线建议必须经过人工复核和 DRC 验证才能进入生产流程。任何自动化布线决策都不能绕过最终的设计评审和制造审查环节。10. 总结与下一步LLM PCB Routing 的核心价值不在于让模型学会画线而在于让模型理解“为什么要这么画线”。从规则知识库问答到布线约束转译再到基于 DRC 反馈的冲突分析LLM 在 PCB 设计流程中承担的角色越来越接近一个有经验的助理工程师。如果你想快速验证这个方向最先应该做的是把设计规则文档整理成知识库跑通“问规则 - 检索 - LLM 生成建议”这条链路。这条链路不需要复杂的 EDA 集成也不需要写布线引擎脚本门槛最低收益却最直观。跑通之后再考虑把网表格式、Gerber 解析结果接入进来让 LLM 直接处理电路连接数据。最容易踩的坑是过早追求“LLM 自动布线”忽略了对 PCB 设计规则的结构化和知识库建设。没有规则库支撑的 LLM 就是一个通用聊天机器人给出的建议没有工程约束力。只有先把规则库做扎实后续的 Agent 化和工具调用才有意义。后续可以扩展的方向包括用 LLM Agent 结合开源的 PCB 设计工具做规则约束自动配置、将 DRC 报告回流给模型形成自监督闭环、用 RAG 架构把公司历史布线案例变成经验库。这些方向可以串成一套完整的 AI 辅助 PCB 设计工作流也是这个项目最有想象力的地方。先把规则库建起来让模型先看懂规则再谈让它动手布线。