接课题的那个秋天
2025年秋，一个做深空任务论证的预研课题组接到一份任务书：为一次小行星伴飞探测概念任务完成轨道方案设计，六个月内交出从地球出发、借力行星引力、与目标小行星交会并安全返回的完整轨迹方案，附带推进剂预算和发射窗口分析。组里三个年轻人，一台服役四年的台式机，外加一个所里排队才能轮上的公共集群账号。
任务书里的每一个词都透着天问二号的影子。2025年5月29日凌晨，长征三号乙遥一百一十运载火箭在西昌把天问二号送入地球至小行星2016HO3转移轨道，开启中国首次小行星伴飞、采样与返回之旅；采样返回舱分离后，主探测器还要借助地球引力弹弓转向，远征主带彗星311P，整个任务周期超过十年。国家航天局公布的工程目标里，小推力转移轨道设计被列为要突破的关键技术之一。课题组要做的，正是这类任务的地面预演。
这个方向在高校里有清晰的学科坐标。南京航空航天大学航天学院的研究生培养目录中，深空探测轨道力学与控制是机械工程硕士的固定研究方向，博士培养目录里航天器轨道设计与优化、航天器任务规划分列在不同导师团队名下。轨道设计早已从航天器总体设计里分化成一门独立学问，而它背后的计算量，正在悄悄重塑课题组的硬件清单。
第一个月：先把问题翻译成数学
任务初期不需要重火力。课题组第一步是建立基线：假设地球和目标小行星都在圆轨道上，用经典的霍曼转移估算能量下限——两次脉冲、半椭圆过渡轨道，地火尺度的霍曼转移耗时约260天，发射窗口每26个月才出现一次。这类计算在圆锥曲线拼接模型下几秒钟就能完成，单条轨迹的传播耗时以毫秒计，普通台式机绰绰有余。
真正花时间的是窗口扫描。工程上要在发射日期—到达日期平面上绘制能量等高线图，也就是常说的pork-chop图，逐日计算最小能量转移的双脉冲速度增量。扫描一年的窗口、几十个目标年份，背后是数万次轨道传播，串行跑要一个晚上。这一步暴露了台式机的短板：单核性能决定每次传播的耗时，内存决定能同时铺开多少并行任务。星历加载加上数十万条中间状态记录，内存占用被推到了十几GB。
结论很清楚：高主频入门工作站足够应付前期调研与小算例，但窗口扫描这种靠数量取胜的任务，已经开始呼唤更多核心与更大内存。
第三个月：当问题从二体变成三体
基线方案交上去，评审意见很快回来：化学推进直连方案推进剂预算超标，要求评估借力方案。课题复杂度由此上了一个台阶。
引力弹弓不是免费的午餐
借力飞行，也就是引力弹弓，是利用行星引力改变探测器速度方向、甚至净增速度的经典手段。旅行者一号、二号正是靠着木星和土星的两级加速，才获得访问外行星乃至飞出太阳系的速度。天问二号返回舱分离后，主探测器同样要借地球引力完成转向，踏上奔赴311P的六年航程。把借力写进优化模型，意味着轨道传播从解析的二体公式变成数值多体积分：每一代设计变量都要完整传播整条借力链，单次耗时从毫秒涨到秒级。
弱稳定边界的诱惑与代价
评审的另一个要求是评估低能转移通道。这类轨道利用的是三体动力学中Hill区域边界附近的弱稳定边界现象，顺着不稳定流形滑行，能用极少的推进剂完成转移。代价是轨迹对初值极端敏感：相邻的两个出发时刻，一条能抵达目标、一条会永远迷失在混沌区里。设计方案变成一场对初始条件空间的网格化搜索，积分步长要压到足够小以捕捉流形结构，传播次数呈数量级上涨。
优化器是台喂不饱的机器
把借力序列、出发时刻、每段轨道的速度增量一起交给优化器，问题变成一个高维非线性优化。课题组选了差分进化算法：400个个体的种群连续演化200代，总计约八万次完整轨道传播。种群天然并行——每个个体独立传播、互不通信，是并行计算里最理想的结构。算力需求第一次具体地摆在桌面上：八万次传播、每次数秒，串行要二十天，64核并行可以压到一天以内。
第五个月：机器连续跑了十九天
真正的大规模计算比预想更凶猛。优化跑到中期，评审又要求补充入轨精度评估：对最优方案做两千条蒙特卡洛打靶，给每条轨道叠加导航误差、机动执行误差和星历不确定性，统计末端散布。蒙特卡洛是另一种天然并行的负载，但单次传播需要更高精度的积分器与更密的采样点，两千条打靶在公共集群上排队三天、又跑了四天。
公共集群的排队时间成了项目最大的不可控因素。经费申请报告里因此多了一行字：需要一台课题组自己的高性能工作站。理由很直白：轨道设计类任务的中断成本极高——优化跑到第190代中断，重启的不是一次求解，而是整个种群的演化历史；蒙特卡洛打靶断在1800条，损失的是三天排队换来的起步时间。自有机器意味着随时可跑、随时可续、结果文件留在本地，不用在共享文件系统里和别的课题组抢存储带宽。
结果分析阶段的瓶颈又换了一茬：多方案对比图、敏感性分析、推进剂预算表，每个方案几十页文档，每改一轮设计变量就要重写相关章节。三个人写报告写到凌晨，是常态。
为什么把大模型请进实验室
报告地狱是课题组决定自建大模型本地服务的直接原因，这个决定背后还有三条更深层的考量。
一是数据出不去。轨道根数、发射窗口、测控弧段安排都属于任务级敏感数据，交给云端API意味着数据离开可控边界，在航天系统内的课题里几乎不可接受。二是环境进不来：外场联试、测控站值守、出差评审的路上网络时好时坏，报告起草和文献问答不能依赖在线服务。三是长期账算不过来：一个中等规模课题组每年要产出几十份论证文档，高频调用云端大模型的费用累积起来足够买一台能跑开源模型的工作站，而权重一次下载、长期可用，还能注入轨道力学语料做领域定制。
模型选型落在两款真实开源模型上。Qwen3-14B是阿里2025年4月开源的稠密模型，148亿参数，支持128K超长上下文，做任务数据助手很顺手：星历参数表问答、轨道根数格式转换、GMAT脚本排错、积分器步长参数解释，这些高频小问题不用再翻半天手册。GLM-4.5是z.ai在2025年7月28日开源的旗舰模型，总参数3550亿的混合专家架构，每次推理激活约320亿参数，128K上下文，长文档与多轮工具调用能力更强，适合轨道设计报告生成这类要通读几十页技术文档再动笔的任务。
显存账必须先算清楚。估算口径很直接：所需显存约等于参数量乘以量化字节数再乘1.2的余量系数，FP16每参数2字节、Q8为1字节、Q4为0.5字节。按此口径，Qwen3-14B在FP16下约需28GB，Q8约15GB，Q4约9GB，一块16GB以上显存的显卡即可舒适运行；GLM-4.5要特殊对待——混合专家架构的显存按总参数计算、不按激活参数，Q4量化后也要约213GB，单张消费级显卡完全装不下，需要多张大显存专业卡的平台。这也解释了消费级部署为什么默认选Q4：显存占用压到FP16的四分之一，精度损失在报告起草和知识问答类任务上几乎不可感知。
速度与微调是另外两笔账。CPU纯内存推理通常每秒只有几个token，写一段话要等几分钟；单张显卡推理能到每秒几十至上百token，大模型平台才真正可用。微调方面，LoRA这类轻量化方法给14B模型做领域适配，显存增量只有3到5GB；全参数微调是另一个物种，7B模型的全参数微调就需要80GB以上显存，GLM-4.5级别的全参数微调属于数据中心的任务，单机工作站不必强求。
课题组由此定下调子：Qwen3-14B立刻上入门工作站，GLM-4.5列入平台升级规划。这个结论，直接决定了后面配置方案的档位划分。
工具链：从天价商业软件到开源全家桶
深空轨道设计的软件生态远比外人想象的丰富。任务规划的行业标准是AGI的STK，从场景构建、可见性分析到轨道机动设计一气呵成，但授权费用让多数课题组望而却步。NASA开源的GMAT是事实上的替代品，脚本驱动、功能完整，从二体传播到高精度多体积分都有覆盖，国内很多预研课题的基线模型都是用它搭的。
底层动力学引擎，开源阵营还有Orekit和Tudat：前者是Java写的航天动力学库，欧洲航天任务里用了多年；后者是代尔夫特理工大学主导的工具包，C++内核加Python接口，适合做方法研究。Python生态的Poliastro适合教学和小算例，真正量产还得靠自研代码。星历数据用JPL发布的DE440，覆盖1550到2650年，文件本身有数GB，加载进内存后供所有传播调用共享，这也是内存需求的重要来源。
优化与统计分析环节基本靠自研：差分进化、粒子群、贝叶斯优化可借助pymoo、DEAP这些现成库，但借力序列这类离散与连续混合的变量往往要自己写编码和约束处理。并行化的路径很清晰：种群级并行用进程池，蒙特卡洛打靶按轨迹分片，有多少核就能铺开多少条传播。值得注意的是，STK和GMAT的传播模块大多只吃单核或少量核，真正能把多核吃满的，恰恰是课题组自己写的那部分代码——硬件选型要向多核高频加大内存倾斜，而不是盲目堆显卡。
课题组最终配置方案
从算法原理到代码实现，中间隔的是编程能力；从代码实现到按期交出结果，中间隔的往往就是硬件配置。回顾这五个月，课题组的算力需求经历了三次跳变：前期调研要单核性能，优化打靶要多核并行，报告生成要本地大模型平台。基于前面分析的负载特征，最终方案按三个档位落地，供类似的预研课题组对照参考。
方案A：前期论证与个人开发者
适用场景：圆锥曲线拼接估算、窗口扫描、单条轨迹传播验证，附带Qwen3-14B Q4量化的任务数据助手。
推荐机型：A350 153128-MCT
- CPU：Intel Ultra9 285K（24核，8P核5.6GHz）+水冷
- GPU：RTX 5090D v2 24GB+水冷
- 内存：128GB DDR5
- 存储：4TB NVME + 8TB SATA
- 显存：24GB
- 显存带宽：1.34 TB/s
- 注：CPU频率为UltraLAB全核超频实测优化频率。
方案B：课题组主力计算
适用场景：多体借力链数值积分、差分进化全局优化、千条级蒙特卡洛打靶的日常量产，承接课题组大部分CPU密集任务。
推荐机型：EA650 230256-MCX
- CPU：2×AMD霄龙7773X（128核，3.0GHz，2×768MB缓存）+水冷
- GPU：RTX 5060Ti 16G
- 内存：256GB DDR4
- 存储：4TB NVME + 8TB SATA
- 显存：16GB
- 显存带宽：448 GB/s
- 注：CPU频率为UltraLAB全核超频实测优化频率。
方案C：全流程平台与自建大模型本地服务完整形态
适用场景：优化与打靶并行共用、多人同时接入，本地同时部署Qwen3-14B与GLM-4.5，覆盖报告生成、任务数据问答与长文档论证。
推荐机型：GX660M 227512-MD4E
- CPU：2×Xeon金牌6530（64核，2.7~4GHz）
- GPU：4×RTX 6000D 84G
- 内存：512GB DDR5
- 存储：8TB NVMe
- 显存：336GB
- 显存带宽：4×1.57 TB/s
- 注：CPU频率为UltraLAB全核超频实测优化频率。
常见问题
深空轨道设计和近地星座仿真对硬件的要求差别大吗？
差别不小。近地星座仿真面对大量规则轨道，传播可以用平均根数模型批量外推，瓶颈常在数据读写和管理；深空轨道设计要在多体引力场里做高精度积分，单次传播贵得多，优化和打靶又会把传播次数放大到十万量级。前者像仓库管理，后者像解一道每算一步都要重算全太阳系引力的数学题，CPU多核和高内存带宽是硬指标。
不采购商业软件，开源工具链能撑起正式论证吗？
能，而且有先例。NASA的GMAT、欧洲的Orekit与Tudat、JPL的DE440星历都是成熟的开源资产，很多工程预研的基线模型完全建立在它们之上。商业STK的优势在场景可视化、协同工作流和厂商支持，正式立项后的工程化阶段值得采购，概念论证阶段开源链足够。省下的授权预算，挪到硬件上更划算。
优化跑了一周还在原地踏步，该加内存还是加核？
先查瓶颈再花钱。差分进化这类算法的典型瓶颈是单次传播太慢，也就是单核性能不足；只有当机器开始频繁读写虚拟内存、或者星历加载后剩余内存装不下整个种群状态时，内存才是瓶颈。一个简单判别法：跑任务时看内存占用是否长期顶满，顶满先加内存，否则先换高主频多核平台。
本地大模型生成的轨道报告能直接用吗？
不能直接交付，但能省掉一半以上的力气。实测的经验是：让模型负责章节框架、语言润色、术语一致性和图表说明文字，人负责所有数值结果、公式推导和结论判断。所有数字必须从求解器输出文件里抄，不允许模型凭记忆生成——这条纪律写进了课题组的大模型使用规范。
多人共用一台工作站怎么避免互相拖垮？
靠调度不靠自觉。把优化、打靶这类长任务丢进队列系统按核数分配，交互式的小任务保留固定份额；大模型推理服务单独绑定显卡，不和CPU任务抢资源。方案C的多卡结构就是为这种计算、推理、可视化三线并行的场景准备的。
预算只够一台机器，先保CPU还是保GPU？
轨道设计负载的答案明确：先保CPU和内存。整条工作流里，商业软件和自研传播代码都以CPU为主战场，GPU的用武之地在蒙特卡洛批量传播加速和本地大模型推理。预算紧张时，一台多核大内存的机器搭配一块能跑Qwen3-14B的显卡，比反过来配置实用得多。
结语
六个月后，课题组按时交出论证报告：三个候选方案中，借力链最优方案比化学直连省了四成推进剂，蒙特卡洛打靶给出了入轨精度的置信区间，三百页配套文档有一半在本地大模型辅助下完成。回首全程，轨道设计这门纸面功夫，算力底线被三体动力学、全局优化和智能报告生成一次次抬高。探测器的每一条轨迹，最终都是从地面机房里算出来的——先把算力底座打好，再谈星辰大海。
工作站配置选型欢迎咨询~
微信号：maxftxwx
fuyiqin@xasun.com
