前几天我带着一台Jetson AGX Orin去客户现场做演示到了才发现会场网络状况一塌糊涂云端大模型接口的延迟高到没法看整个demo差点翻车。还好我提前在设备上用llama.cpp部署了7B的Qwen模型断网状态下现场问答流畅到让客户以为我接了什么专线。从那以后“本地能跑就绝不依赖云端”就成了我做边缘AI项目的铁律。如果你也想在Jetson这类ARM设备上把开源大模型真正跑起来这篇文章大概率能帮你少走不少弯路。我会把llama.cpp部署大模型从环境准备、源码编译、模型量化、参数调优到服务化封装的全过程拆开来讲所有命令都是我在AGX Orin上实际敲过的照抄基本能跑。1. 为什么边缘推理首选llama.cpp三个绕不开的理由1.1 纯粹C实现带来的性能底气大模型推理框架有很多但llama.cpp在边缘设备上的地位很难被替代。最核心的原因就是它压根不依赖Python运行时整个项目用C写成直接把模型推理链路压到最底层。你在服务器上部署大模型Python带来的几十毫秒延迟通常不痛不痒但在Jetson这种内存带宽有限、CPU核心数也有限的设备上每一毫秒都要抠Python解释器的开销就变得不可接受了。llama.cpp另一个让人佩服的点是它把内存调度做到了极致。它支持mmap方式直接映射模型文件不需要一次性把整个模型读进内存而是按需加载。这是什么概念你用一个7B的Q4量化模型文件大小大概4GB左右如果你的开发板内存只有8GB用llama.cpp可以做到加载模型的同时还有富余空间跑系统服务换成其他某些框架光初始化就得吃满内存系统直接卡死。它的核心张量运算库GGML还针对不同硬件做了SIMD优化支持ARM NEON指令集、x86的AVX2/AVX512以及CUDA后端。这意味着同一个模型文件你在x86服务器上能跑到了ARM设备上也能跑代码不需要改重新编译一下就行。这种跨平台能力在边缘部署场景里太关键了。1.2 ARM架构和嵌入式设备的天然契合Jetson AGX Orin用的是ARMv8.2架构GPU是Ampere架构这和普通PC的x86CUDA环境有很大区别。很多大模型框架虽然支持CUDA但对ARM设备上的CUDA支持要么不完善要么安装流程极其繁琐。llama.cpp对ARM的支持算是刻在基因里的因为GGML从一开始就考虑了移动端和嵌入式设备CPU推理优先GPU加速作为可插拔后端。我在AGX Orin上编译llama.cpp时感受特别明显cmake一行命令就能把CUDA后端编进去自动识别架构不需要像某些框架那样手工配置一堆路径。Jetson设备上的内存是CPU和GPU统一寻址的这让llama.cpp的CUDA offload变得非常顺滑——你不需要去管显存够不够、需不需要做显存和内存的数据搬运模型层数按需往GPU上放就行。1.3 llama.cpp、vLLM、Ollama到底该用谁有很多人问我说怎么不用vLLM怎么不用Ollama。我的回答是看场景别跟风。这三者的定位其实差异很大。框架定位优势适合场景vLLM高并发推理服务通过PagedAttention实现高吞吐支持连续批处理多用户请求、高QPS的在线服务Ollama本地一键部署安装简单模型管理方便API兼容OpenAI桌面开发、快速体验、个人笔记本llama.cpp极致轻量的边缘推理依赖少、可嵌入式、量化支持全面、ARM优化好Jetson/树莓派/嵌入式设备、离线推理在AGX Orin上跑vLLM也不是不行但对Jetson的JetPack环境适配相对麻烦而且vLLM本身是为多卡、大规模吞吐设计的单机边缘设备用它是杀鸡用牛刀。Ollama虽然方便但它在Jetson上对CUDA的支持是最近才开始完善的底层其实也依赖llama.cpp的库。你要是做边缘项目直接在llama.cpp上掌握原理比套一层Ollama更可控。2. 在Jetson AGX Orin上从源码编译llama.cpp2.1 环境准备先确认JetPack版本和GPU算力Jetson设备的环境检查不能跳过很多人编译失败就是这一步没做好。AGX Orin出厂搭载的JetPack版本不同对应的CUDA版本也不同。我用的是JetPack 5.1.2自带CUDA 11.4。如果你用的是JetPack 6CUDA版本会升到12.x个别编译参数可能要跟着微调。确认环境的命令如下# 查看JetPack版本 cat /etc/nv_tegra_release # 查看CUDA版本 nvcc --version # 查看GPU算力 sudo /usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQueryAGX Orin的GPU算力是8.7属于Ampere架构。这个数字后面编译的时候要填进CMAKE_CUDA_ARCHITECTURES参数填错了GPU加速就编不进去虽然也能跑但速度会打折扣。deviceQuery的输出里有一行“Capability Major/Minor version string: 8.7”看到这个就说明GPU算力没问题。另外建议先给设备增加swap空间。Jetson的内存虽然够大但编译llama.cpp这种C项目链接阶段内存峰值很容易冲到10GB以上。我一开始没有配置swap编译到一半直接OOM后来加了16GB的swap才踏实。加swap的方法很多最简单的是创建一个swapfilesudo fallocate -l 16G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile如果想让开机自动挂载在/etc/fstab里加一行/var/swapfile none swap sw 0 0即可。2.2 编译命令与关键参数含义环境准备好之后拉取llama.cpp源码并编译。建议直接clone最新的release分支不要用master上太新的未稳定版本因为有些新特性可能会引入构建问题。git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp mkdir build cd build cmake .. -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES87 -DCMAKE_BUILD_TYPERelease make -j$(nproc) llama-cli llama-server llama-bench llama-quantize拆开讲几个关键参数-DGGML_CUDAON启用CUDA后端这样模型层可以offload到GPU上跑。-DCMAKE_CUDA_ARCHITECTURES87指定GPU算力为8.7。如果在其他设备上比如Orin Nano是8.6要改成86如果是桌面级RTX 4090是8.9改成89。-DCMAKE_BUILD_TYPERelease编译优化级别Release模式会开启O3优化推理速度差距明显。make的时候指定具体目标而不是全部编译能省不少时间。我只编了llama-cli、llama-server、llama-bench和llama-quantize这4个工具日常完全够用。如果要跑embedding模型还需要编llama-embedding。整个编译过程在AGX Orin上大约需要20到40分钟取决于你的JetPack版本和散热情况。如果你用的是Orin Nano这类入门级设备时间会更久建议make -j2降低负载避免过热降频导致编译变慢。2.3 编译完成后的第一轮验证编译结束后初始化验证这一步能帮你快速判断GPU后端有没有正确编进去。用llama-bench在纯CPU模式跑一下自带的测试模型然后再用GPU模式跑对比数据你就能看到加速效果。没有测试模型的话随手拿一个小的GGUF模型先跑llama-cli走个冒烟测试./llama-cli -m /path/to/model.gguf -p 你好介绍一下你自己 -n 64 --no-display-prompt如果输出正常说明整个推理链路是通的。接下来再用--n-gpu-layers 99参数把模型全部扔到GPU上跑一遍感受一下速度差异。以我的AGX Orin 64GB版本为例纯CPU模式下Qwen2.5-7B-Q4_K_M的生成速度大约是8到12 token/s开了GPU offload之后能到30到40 token/s差距非常明显。2.4 不想源码编译官方Release也能用如果你用的是x86的Ubuntu服务器直接下载官方Release即可里面有编译好的可执行文件省时省力。但Jetson这种ARM64设备我不建议直接用官方Release因为官方Release虽然提供linux-arm64版本但没有附带CUDA后端只能做CPU推理相当于白白浪费了Orin的GPU算力。也有像llama-cpp-python这类Python绑定方案能在pip安装时自动编译CUDA版本CMAKE_ARGS-DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES87 pip install llama-cpp-python这种方式适合你想在Python里直接调用推理接口的场景。不过既然都用到Jetson了我还是推荐掌握源码编译这条路毕竟对底层的掌控感不一样排查问题时你能知道问题出在编译参数还是运行参数。3. 模型选型与量化配置先选对模型格式再谈跑得快3.1 GGUF格式解决的是模型部署的“敏捷性问题”llama.cpp不能直接加载Hugging Face上的原始PyTorch格式模型它需要的是GGUF格式。GGUF是GGML团队设计的模型序列化格式它的核心优势有两个一是单文件分发所有权重、tokenizer配置、超参数都封装在一个文件里复制拷贝非常方便二是内存映射加载推理时可以直接从磁盘按需读取权重而不需要把所有权重一次性载入内存。早期的大模型部署有一个痛点就是模型加载时间太长。你启动一个服务光加载权重就要几十秒这在高频重启的场景下很难受。GGUF配合mmap机制首次加载时间大幅缩短因为操作系统会按需从磁盘读页实际用到的权重才真正进入内存。这对Jetson上的内存管理是友好的。3.2 从FP16到Q4_K_M量化等级怎么选GGUF支持多种量化精度最常用的是从Q2_K到Q8_0这一档。很多人一看到量化就担心模型“变笨”实际上对大模型来说4bit量化在多数任务上的损失很小但内存占用和推理速度的收益却是巨大的。量化等级单权重大小7B模型占用约推理速度质量损耗适用场景F162字节约14GB慢无有充足显存时Q8_01字节约7GB较快几乎无损质量优先且内存够Q6_K约0.75字节约5.5GB快极微小质量与速度均衡Q5_K_M约0.65字节约4.8GB快很小大众推荐Q4_K_M约0.55字节约4.1GB很快较小我实测最常用Q3_K_M约0.4字节约3.2GB很快明显应急、内存极紧Q2_K约0.3字节约2.5GB最快较大仅做测试这个表是根据我自己跑7B模型的实测整理的。Q4_K_M是我用得最多的档位内存占用和输出质量平衡得最好。AGX Orin 32GB版本上跑7B Q4模型上下文长度设到4096GPU offload全部层生成速度稳定在35 token/s左右体验非常流畅。有些场景我会用Q5_K_M比如做代码生成或者数学推理任务时Q4偶尔会暴露出逻辑瑕疵。如果你跟我一样需要兼顾落地效果和设备负载建议把Q4_K_M和Q5_K_M都下载下来用同一批问题测一遍肉眼判断哪个结果更满意再决定正式部署用哪个。3.3 动手转换自己的模型convert_hf_to_gguf.py与llama-quantize有时候你可能想在llama.cpp里跑自己微调过的模型而不是直接用别人转好的GGUF文件。llama.cpp官方提供了完善的转换工具链核心是两步先转格式再量化。第一步把Hugging Face格式的模型转成FP16的GGUFpython3 convert_hf_to_gguf.py /path/to/your-model --outfile /path/to/output-fp16.gguf --outtype f16这个脚本在llama.cpp仓库的根目录下。转换前需要确保你的模型目录里有config.json、tokenizer.json这些标准文件。转换过程中如果提示缺少某些依赖pip安装对应的transformers、sentencepiece即可。第二步把FP16的GGUF量化为目标精度./llama-quantize /path/to/output-fp16.gguf /path/to/output-q4km.gguf q4_k_m这里最后一个参数是量化类型填q2_k、q3_k_m、q4_k_m、q5_k_m、q6_k、q8_0都行。转换和量化比想象中快很多7B模型从FP16转Q4_K_M大概一分钟以内能完成。我自己第一次转换的时候犯过一个错误直接拿FP16 GGUF文件跑推理明明模型只有7B启动时系统却说内存不足。后来才反应过来FP16的7B模型光权重就要14GB加上KV Cache和系统占用32GB内存的设备直接吃紧。所以如果设备内存有限千万别跳过量化的步骤。3.4 结合Qwen系列与BGE模型的实测选型参考在Jetson这类边缘设备上跑模型参数量不是越大越好。我实测下来AGX Orin 32GB版最舒服的模型规模是7B到14B打底日常问答和文档摘要完全够用。如果非要上32B的大模型Q3_K_M量化勉强能跑但速度只有8到10 token/s体验就很吃力了只适合异步处理任务。Qwen系列和llama.cpp的兼容性一直很好。Qwen2.5-7B-Instruct配合GGUF格式在AGX Orin上用Q4_K_M量化不需要特殊改动就能正确处理中文包括角色设定和思维链输出。朋友那边做知识库项目用千问大模型做生成层、BGE-M3做embedding层同样跑在Jetson上llama.cpp的llama-embedding工具加载BGE-M3的GGUF版本384维度embedding的生成速度非常可观整套RAG流程完全本地化。需要注意的是下载模型文件时建议优先找量化好的GGUF版本省去自己转换的步骤。文件名里通常会带Q4_K_M这种标识一眼就能看出来。如果你用的模型后缀是-instruct或者-chat说明它带对话能力部署llama-server时可以不额外加模板如果是base模型chat模板需要自己配不然输出风格会很怪。4. AGX Orin实测定档关键参数与调优细节4.1 用llama-bench建立性能基线我上手一个新环境第一件事是先跑llama-bench把硬件的性能基线搞清楚。没有基线的调优都是瞎猜你不知道改参数后到底是变快还是变慢更不知道还有没有提升空间。./llama-bench -m /path/to/qwen7b-q4km.gguf -n 128 -ngl 99这个命令会输出多层数据包括prompt processing的token/s和generation的token/s。在我的AGX Orin上Qwen2.5-7B-Q4_K_M的实测数据大概是全GPU offload时prefill速度约450 token/sgeneration速度约35 token/s全CPU推理时prefill速度约80 token/sgeneration速度约9 token/s拿到基线数据后再改参数对比就容易了。比如我从-ngl 99改成-ngl 20如果速度下降明显说明大部分计算还是得靠GPU如果速度几乎没变说明GPU offload的层数已经够了瓶颈在别的地方。4.2 推理参数逐个拆解-ngl、-c、-t、-fa这些魔法数字llama.cpp的命令行参数看着复杂但真正影响实际体验的就几个。-nglnum layers offload是最重要的参数。它控制有多少层模型跑在GPU上。Jetson没有独立显存CPU和GPU共享内存所以理论上你可以把99层的7B模型全部offload到GPU。但如果你的模型特别大比如14B甚至32B全部offload会让内存瞬间见底这时候就需要手动设定一个合适的层数比如80层留一些内存给KV Cache和系统进程。-ccontext size指上下文长度。这个参数直接影响KV Cache的内存占用而且是平方级别的增长关系。以7B模型为例上下文从2048拉到8192KV Cache的内存占用大概会翻4倍。Jetson上没有大量内存余量我通常设4096既能覆盖多数对话场景又不会损失太多可用内存。如果你的知识库场景需要处理超长文档再考虑拉高到8192但要注意总内存是否扛得住。-tthreads是CPU线程数。AGX Orin有12核CPU但全开不一定最快。我实测在混合推理部分层GPU、部分层CPU时-t 8是最优配置开满12反而因为线程切换开销导致速度下降。如果全GPU推理-t就没那么大影响设默认值就行。-faflash attention是这两年最重要的优化项没有之一。FlashAttention能显著降低长上下文场景下的内存占用并加速注意力计算在llama.cpp里只需要加一个-fa参数就能启用。7B模型在4096上下文下开启-fa后KV Cache占用能减少约30%生成速度还有小幅提升几乎零成本优化。我给出一个完整的llama-cli调用示例适合在AGX Orin上跑7B模型./llama-cli -m /path/to/qwen7b-q4km.gguf \ -c 4096 \ -ngl 99 \ -t 8 \ -fa \ -n 128 \ -p 用三句话介绍紫金山4.3 功耗模式与散热Jetson特有的性能开关这是很多刚上手Jetson的开发者最容易忽略的地方。Jetson的GPU和CPU频率受功耗模式约束默认模式可能只释放了设备一小部分性能。AGX Orin的nvpmodel命令可以切换功耗档位常见的模式包括15W、30W、40W以及MAXN。# 查看当前模式 sudo nvpmodel -q # 切换到最大性能模式 sudo nvpmodel -m 0MAXN模式的GPU频率能跑满但发热也厉害。AGX Orin原装散热条件下跑7B模型几分钟后温度就会到80度以上接着触发降频token/s从35掉到25。如果要做长任务推理建议给设备加主动散热或者在nvpmodel里选一个功耗稍低的模式牺牲一点速度换取持续稳定的输出。我个人的经验是散热条件一般时用30W模式最稳温度控制在70度以内速度下降不到20%但长时间推理不会忽快忽慢。jetson_clocks脚本也值得一提它能强制把CPU和GPU频率锁到最高避免负载变化导致频率波动。官方推荐的用法是sudo jetson_clocks --fan--fan参数会把风扇开启到最大转速。这个脚本适合跑benchmark或者固定推理任务时使用日常服务不推荐一直开启功耗和发热都太大。4.4 真正的瓶颈往往不在模型本身很多人优化一圈token/s之后发现体感交互还是卡就开始怀疑模型太大。其实瓶颈往往在模型推理之外。Jetson上的tokenizer处理、输出解析、日志打印都可能成为被忽略的开销。llama-server默认会打印每次请求的完整日志包括prompt内容、输出内容、耗时统计在串行控制台上这些内容会阻塞推理主线程导致响应速度波动。建议运行服务时把日志输出重定向到文件避免终端I/O干扰推理进程。我在做知识库问答时还踩过一个坑前端等待响应时调用了/v1/models接口来轮询模型状态但llama-server处理这个请求也会占用进程时间在高频轮询下推理速度肉眼可见地下降。后来把轮询改成20秒一次问题就消失了。这类非推理开销的问题往往比模型参数更影响实际体验。5. 部署路上绕不开的坑完整排查链路记录5.1 跑一个70B模型直接卡死显存内存统一寻址的误判我第一次在AGX Orin上跑70B模型时果断用了Q2_K量化文件大小还不到30GB逻辑上32GB内存应该能装下。结果llama-cli启动后系统直接卡死连鼠标都不动了。排查链路是这样的先用free -h查内存发现可用内存只剩几百MB模型加载还没完成就触发了系统OOM Killer。问题出在Jetson是统一内存架构GPU offload占用的是同一块物理内存再加上KV Cache和系统本身的占用实际可用的内存远小于标称的32GB。解决方案是我把swap空间加大到24GB同时把-ngl从99调低到40让一部分层留在CPU侧。这样虽然速度慢一点但系统不会卡死。这里也想提醒大家Jetson上跑模型标称内存要打七折来规划别看文件大小小于内存就觉得一定跑得动。5.2 编译过程中OOMswap是我最后的温柔编译llama.cpp的报错信息五花八门最常见的是c: fatal error: Killed signal terminated program cc1plus。这个报错看起来像编译器崩了其实是内存不足系统把编译进程杀了。我当时在AGX Orin上并行执行make -j12链接阶段瞬间吃满内存OOM Killer按优先级把cc1plus进程杀了。排查时用dmesg | tail -20能看到明显的Out of memory日志。解决思路有三个维度一是加大swap给系统一个缓冲地带二是降低编译并行度-j4或-j2三是去掉Debug符号、只编译Release目标能减少链接期的内存峰值。我最终改成make -j4 llama-cli llama-server配合16GB swap编译稳定通过。5.3 输出一团乱码聊天模板的锅模型在llama.cpp里输出乱码通常不是模型损坏而是prompt没有按模型的chat template组织。Qwen系列要求使用特定的聊天模板如果你直接用“用户你好”这种raw文本塞进去模型的回复质量会非常差甚至出现标签、结束符混在正文里的情况。解决方法是尽量用带-instruct或-chat后缀的模型文件这类内置了chat模板。如果你使用llama-server它会根据模型元数据自动选择模板不需要手动干预。我的经验是在用llama-cli交互测试时加一个-cn-prompt或者直接用llama-server来聊绕开模板问题。5.4 越跑越慢温度墙与降频部署服务跑了一段时间后我发现模型生成速度从35 token/s逐步掉到20 token/s再掉到15 token/s一开始怀疑是内存泄漏反复重启服务也没解决。后来用tegrastats一看GPU温度到了84度频率降到了基准值以下。Jetson的硬件保护机制就是当温度到达阈值时自动降频这是很多人测试时跑分漂亮、实际部署却慢得离谱的最大原因。排查这类问题建议直接看温度和频率sudo tegrastats当看到GPU频率低于标称值同时温度接近85度时基本就可以确定是热降频。我的处理方法是给设备加了一个主动散热风扇并将nvpmodel调整到40W模式而不是MAXN让设备在发热和性能之间找到平衡点。散热条件好的话40W模式的稳定输出比MAXN模式的降频输出反而更高。5.5 常见异常现象的快速定位表异常现象可能原因排查优先级启动后系统卡死内存不足、swap过小、模型过大先看free -h和dmesg推理速度逐渐变慢热降频、后台占用资源先看tegrastats输出乱码、尽是标签chat template未适配、tokenizer文件缺失换instruct模型文件编译报Killed内存不足、并行度太高看dmesg、减-j参数加载模型失败GGUF损坏、路径错误、内存不够检查文件校验和与路径CUDA相关报错算力参数填错、JetPack版本不匹配检查nvcc和deviceQuery6. 从命令行到服务化让llama.cpp成为一个稳定可用的接口6.1 llama-server启动一个OpenAI兼容接口命令行跑模型只能自己玩真正落地还要靠服务化。llama.cpp自带的llama-server模块提供了OpenAI兼容的RESTful API这意味着你之前写的所有基于OpenAI接口的代码只需把base_url改成本地地址就能无缝切换到本地模型不需要改业务逻辑。启动命令非常简单./llama-server -m /path/to/qwen7b-q4km.gguf \ --host 0.0.0.0 \ --port 8080 \ -c 4096 \ -ngl 99 \ -t 8 \ -fa \ --alias qwen7b \ --rope-scaling yarn \ --rope-scale 8.0--host 0.0.0.0允许局域网内其他设备访问--alias给模型起一个自定义名称方便API调用时识别。--rope-scaling和--rope-scale是上下文长度不够时的扩展方案一般场景用不到但如果你需要处理超长上下文且不想增加-c的内存占用可以研究一下。6.2 用curl验证与代码调用示例服务启动后先用curl做一次最基础的验证curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen7b, messages: [ {role: user, content: 用一句话解释什么是大模型} ], temperature: 0.7, max_tokens: 256 }返回的JSON结构和OpenAI官方格式几乎一致包含choices、usage等字段。在Python里调用就更直接了用openai官方sdk就能连上from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keynot-needed ) response client.chat.completions.create( modelqwen7b, messages[{role: user, content: 写一段新年祝福}], temperature0.8 ) print(response.choices[0].message.content)这里api_key随便填一个非空字符串就行因为本地服务不需要鉴权。如果你的服务暴露在不可信的网络里建议在llama-server前面加一层Nginx做Basic Auth或者IP白名单不要直接把端口暴露到公网。6.3 接入Dify、ComfyUI等平台的踩坑与配置现在很多本地AI应用平台都支持接入自建模型比如Dify和ComfyUI。这类平台通常允许你配置自定义模型供应商填入API地址、模型名称、API Key后就能用。我实测下来Dify里配置llama-server时模型名称必须和启动时--alias设置的名称一致否则会报“model not found”之类的错误。另外Dify的很多工具如Agent、Workflow依赖工具调用能力而llama.cpp的API对function calling的支持还在持续完善中。如果你用的是Qwen系列基本没问题但如果用其他模型建议先在curl层面测一下tools参数是否生效再决定是否启用Agent功能。ComfyUI接入llama.cpp则是另一套玩法。ComfyUI做图像生成时可以用llama.cpp跑一个LLM来做prompt的智能改写或自动打标签效果比固定模板好很多。实现方式是在ComfyUI的自定义节点里调用llama-server的API接口把用户输入先交给LLM润色再交给图像模型处理。这个流程跑通后图像生成的质量上限会高不少。6.4 systemd守护与开机自启llama-server部署到生产环境后不能指望每次手动启动。写成systemd服务是一个标准的做法既能开机自启也能在服务崩溃后自动重启。以下是/etc/systemd/system/llama-server.service的参考配置[Unit] Descriptionllama.cpp server (Qwen7B) Afternetwork.target [Service] Typesimple Useryour-username WorkingDirectory/home/your-username/llama.cpp/build ExecStart/home/your-username/llama.cpp/build/llama-server -m /models/qwen7b-q4km.gguf --host 0.0.0.0 --port 8080 -c 4096 -ngl 99 -t 8 -fa Restartalways RestartSec10 EnvironmentGGML_CUDA_ENABLE_UNIFIED_MEMORY1 [Install] WantedBymulti-user.target写完配置文件后执行sudo systemctl daemon-reload sudo systemctl enable llama-server.service sudo systemctl start llama-server.serviceRestartalways是服务稳定性的关键模型推理进程偶尔会因为异常输入崩溃有了自动重启服务整体可用性会高很多。日志可以用journalctl -u llama-server -f来查看。我个人的项目经验是边缘设备的服务化部署有几个优先级先保证稳定再追求速度最后优化效果。很多人在第一步就翻车进程没有守护半夜一个异常请求直接打崩服务第二天早上才发现模型服务已经挂了几个小时。systemd这一套属于花10分钟配置、省一晚上觉的投入。最后一个建议模型文件的放置路径要统一不要在多个目录里来回复制GGUF文件。Jetson的存储空间相对金贵一个7B的Q4模型要占4GB14B要8GB32B要20GB磁盘规划和模型管理这块真的要想清楚再动手。