llama-server推理medgemma3 gguf模型 背景 有需求要用到 google 的 medgemma-27b-text-it 模型，但当前GPU服务器只有两卡 4090D 24G，显存很显然不够用，所以计划使用量化版模型 在 huggingface 上找到了gguf量化模型，由 unsloth 提供，其仓库地址为： unsloth/medgemma-27b-text-it-GGUF 根据模型大小分别下载了 medgemma-27b-text-it-Q4_1.gguf、medgemma-27b-text-it-Q4_K_M.gguf、medgemma-27b-text-it-Q8_0.gguf 几个版本到本地 尝试vllm启动 了解到 vllm 也是支持启动 gguf 模型的，那么首先尝试用该后端启动： vllm serve /data/Modules/medgemma-27b-text-it-GGUF/medgemma-27b-text-it-Q4_1.gguf -tp 2 --max-model-len 40960 注意使用本地模型的时候路径需要使用绝对路径，否则会认为需要通过 hf 来拉取模型 但以上命令启动失败，提示不支持 gemma3_text 模型 于是我指定了模型配置文件和tokenizer，并且覆盖了模型的architectures，使用以下命令启动 vllm serve /data/Modules/medgemma-27b-text-it-GGUF/medgemma-27b-text-it-Q4_1.gguf --trust-remote-code --hf-config-path unsloth/gemma-3-27b-it -tp 2 --max-model-len 4096 --tokenizer unsloth/gemma-3-27b-it --hf-overrides '{"architectures": ["Gemma3ForCausalLM"]}' 以上指定了 hf 的仓库，需要注册 hf 账号，并且在后台生成token，然后在本地使用 huggingface-cli login 即可拉取仓库文件了，全程需要代理 不过结果还是未启动成功，仍然是不支持的模型，接着我尝试升级了vllm版本、降低和升高了 transformers 的版本，也依然没有效果 至此尝试使用vllm来启动 medgemma3-27b-text-it gguf格式的模型失败 尝试llama.cpp启动 看了 unsloth/medgemma-27b-text-it-GGUF 页面，还是原版 google 页面的内容，并没有建议使用哪个后端启动gguf模型，既然 vllm 也无法有效使用，那还是考虑使用 llama.cpp 了 编译安装 首先拉取最新的仓库代码，地址: https://github.com/ggml-org/llama.cpp 使用如下命令编译二进制文件： cmake -B build -DGGML_CUDA=ON cmake --build build --config Release 需要使用参数 -DGGML_CUDA=ON 否则编译的版本只支持 cpu llama-server启动 进入到build/bin目录下，有 llama-cli 和 llama-server，启动 cli 是命令行交互使用，而 server 可以作为 api 服务，使用以下命令启动模型： CUDA_VISIBLE_DEVICES="0,1" ./llama-server -m /data/Modules/medgemma-27b-text-it-GGUF/medgemma-27b-text-it-Q4_1.gguf --port 8080 --host 0.0.0.0 -ngl 99 -dev cuda0,cuda1 -sm row -fa --jinja -c 50000 --no-context-shift 重点参数解析： -m 指定本地模型的路径 -ngl 允许将一些层卸载到 GPU 进行计算，以上值表示99层 -sm 表示使用row来切分所有层卸载到gpu，也可以使用其他方式如 layer -fa 开启 Flash Attention --jinja 表示使用嵌入在 GGUF 中的聊天模板（推荐） -c 表示允许的最大上下文长度 -n 表示允许生成的最大长度，默认-1表示无限制直到结束，建议指定 --no-context-shift 建议指定，具体作用查看参数说明 使用以上命令成功启动服务，并且使用通用api请求成功响应，如下： { "model": "/data/Modules/medgemma-27b-text-it-GGUF/medgemma-27b-text-it-Q8_0.gguf", "messages": [ { "role": "system", "content": "你是一个专业知识丰富的医疗助手" }, { "role": "user", "content": "埃博拉病毒和狂犬病哪个死亡率更高" } ], "temperature": 0.7, "top_p": 0.8, "chat_template_kwargs": { "enable_thinking": false }, "repetition_penalty": 1.05 } 疑难问题 但实际循环一批请求发现执行了一会儿之后总是会卡住，无法继续，等待了一个小时、甚至两个小时仍然没有结束 其他表现形式为：新增请求可以，但也无法结束，使用GET获取模型列表倒是可以正常返回 于是重新启动，开启了 -v 调试日志，发现运行一段时间后推理的内容就不太对了，如下: next token: 38 '' 也许一两个空字符是正常的，但以上 38 和 '' 几乎是刷屏的，也就是说后续一直都没有正常推理出内容了 更换量化模型 怀疑是 Q4 模型生成的质量可能有问题，于是更换为了 Q8 但持续测试后现象依旧 继续排查 因为每次出现问题的进度都差不多，所以在代码中请求之前打印了问题和列表，发现总是到固定问题的时候出现这个现象 重启服务后测试单独请求，结果必然复现，会持续输出大量的空字符，过了很久输出完毕后，下一个问题也变成输出空字符 由此可见，输出也许是有上限的，当然我也没有使用 -n 控制在一个合理的范围，更重要的问题是重复输出和影响后续问题的推理 柳暗花明 经过查找资料，发现近两天就有同样的问题出现，也是关于重复输出的问题，地址如下： https://github.com/ggml-org/llama.cpp/issues/14888 其中描述的现象，以及其他人回复的内容，跟我们的问题都非常符合，并且lcarrere进行了相关的分析，其中主要为： Investigating, we notice very abnormal repetitions when the KV cache size exceeds approximately 1024 tokens. This is occurring only with flash attention enabled, with swa on/off. This issue occurs regardless of whether vision tensors are used. 但此时还没有合适的解决办法，只能先尝试关闭 flash attention，看能否解决了 在移除fa的参数后启动，再次提交推理，此时顺利通过之前卡住的部分 CUDA_VISIBLE_DEVICES="0,1" ./llama-server -m /data/Modules/medgemma-27b-text-it-GGUF/medgemma-27b-text-it-Q4_1.gguf --port 8080 --host 0.0.0.0 -ngl 99 -dev cuda0,cuda1 -sm row --jinja -c 50000 20250730 根据帖子的最新回复内容，已经提交了针对这个问题的修改 但编译了 6019 版本，使用 -fa 参数的时候仍然无法正常响应

docker守护进程停止期间保持容器运行 需求背景 默认情况下，当docker守护进程终止时，它将关闭正在运行的容器。比如修改daemon.json的配置、服务异常终止等，这些都会导致docker进程终止或者重启，同时导致所有容器停止或重启，这显然不是我们需要的运维方式和异常处理情况 知道了以上问题的缺陷，那是否有解决方法呢？答案是有的，我们可以配置docker守护进程，使得守护进程不可用时保持容器继续运行。这种功能称为实时恢复，有助于减少由于守护进程崩溃、计划中断或升级而导致的容器停机时间 如何配置 官方参考文档：https://docs.docker.com/engine/daemon/live-restore/ 具体配置方法： 修改配置文件 /etc/docker/daemon.json 增加内容: { "live-restore": true } 重载 docker 使得配置生效 systemctl reload docker 检查配置是否成功 docker info ｜ grep -i live 此时可以重启docker进程而容器不再跟随重启 service docker restart 群晖7.1.1 仅针对群晖7.1.1的配置方法，未在其它版本配置不能确定是否有效 群晖的配置文件不是在 /etc/docker/daemon.json 所以配置这里是不生效的 实际有效的配置文件是 /var/packages/Docker/etc/dockerd.json 修改的内容是一致的，然后重载生效 systemctl reload pkg-Docker-dockerd

esxi命令升级系统版本的问题 升级错误 使用 esxcli vib update 升级小系统版本的时候出现如下错误内容: [DependencyError] VIB VMware_bootbank_esx-base_6.7.0-1.25.xxxxxxx requires esx-update &gt;= 6.7.0-1.25, but the requirement cannot be satisfied within the ImageProfile. VIB VMware_bootbank_esx-base_6.7.0-1.25.xxxxxxx requires esx-update &lt;&lt; 6.7.0-1.26, but the requirement cannot be satisfied within the ImageProfile. Please refer to the log file for more details 解决方案 参考文档： https://knowledge.broadcom.com/external/article?legacyId=56145 具体解决方案如下： # To get a list of available profiles within a path use the command below: esxcli software sources profile list -d <location of ZIP file> # Run this command to update the host: esxcli software profile update -p <profile name> -d <location of ZIP file> # Run this command to update the host: esxcli software vib install -n <vibname1> -n <vibname2> ... -d <location of ZIP file>

DELL Lifecycle Controller问题 异常问题 idrac页面显示Lifecycle Controller固件Not Available 尝试解决 经过排查，可能是idrac中没有启用LCC，所以重启至idrac中开启 重新boot，F10处显示 system services disable 重新boot，CTRL+E进入idrac配置页面，设置LCC为 enable 再次boot，F10处显示 Lifecycle Controller update required 已经配置启用了LCC，并且开机显示要求更新，但进入 idrac 页面仍然显示 Not Available，查看其他配置项和这里都无关联，问题还未解决 排查过程 经过检索资料，有几个可能性，固件损坏、与idrac版本不兼容、配置加载不正确等，所以使用了如下过程来尝试解决： 从idrac页面重置idrac，无效果 放电（把电源线、网线等拔掉后长按开机键30秒，然后再等3分钟开机），无效果 在idrac后台更新上传最新的Linux版本lcc包尝试更新，但报错，idrac6不支持 在idrac后台更新上传最新的lcc repair包（sc格式），支持这样操作，但是结果失败 尝试使用WinPE安装最新版本的win格式lcc，但WinPE执行EXE失败（内存不能为read），估计是依赖不够 了解到官方的centos live镜像 OMSA71-CentOS6-x86_64-LiveDVD.iso（内含OMSA账号密码root/dell）是专门用于升级固件的live系统，开始尝试使用官方live版本恢复/升级（配置ip后网络也可以正常使用） 尝试live安装Linux版本的最新LCC，但提示不兼容 尝试live升级最新bios成功 再次尝试live安装Linux版本最新LCC，但提示不兼容 最终解决 基于以上现象的汇总，怀疑是idrac和lcc版本不兼容，还是应该从修复入手，但仅显示 lcc 不可用，而没有显示具体版本，于是下载了历史多个版本usc修复文件分别尝试，最后使用低版本修复成功。 所以推测是修复的版本要和之前的一致，在修复完成后成功显示版本并且可以在live中继续升级固件版本

raid性能问题和建议 起因 研究这个问题的起因是需要在ESXI机器分配一台高IO的虚拟机做数据库，但实际测试性能完全没有达到测试预期 本想着5块ssd硬盘做raid5，性能肯定没有问题，但分配硬盘后测试发现，4k随机读取iops有500k，符合甚至超出预期，但4k随机写入iops仅11k左右，不仅与我理想中的40k+相差甚远，甚至比我我预期单盘4k随机写入iops（20k）都相差甚远 推测和排查 根据这个结果，我认为是ESXI限制了其性能的发挥，于是找了一些资料，其中可能的问题包括如下： esxi版本比较低，其存储驱动可能有瓶颈 阵列卡驱动可能较低，达到瓶颈 ESXI低版本固有的性能问题 于是我分别从这三个问题入手，尝试升级驱动，也新增了一台高版本ESXI虚拟机（3块SSD硬盘raid5），结果读iops与之前差不多，写iops也与之前差不多，这似乎说明并非ESXI的问题 为了印证不是虚拟化影响的性能，接着我又把ESXI物理机直接更换为centos，跳过所有虚拟化的性能影响，仍保持3块SSD硬盘raid5，结果读写iops与之前仍然相似 至此，问题变成了raid本身的性能问题 RAID级别 我们通常接触的raid级别有raid0、raid1、raid10、raid5、raid6，还有一些更高级的raid50、raid60基本上不太常用，其要求的硬盘位较多，接下来我们从安全性、空间、性能分别分析一下常用的几种raid的特点 raid0 空间：N，raid0拥有最大的空间，他跟jbod有点类似，把所有的硬盘空间叠加 性能：把数据条带化分布到每块硬盘，那么其性能也是最高的，可以是所有硬盘的叠加 安全性：安全性最低，因为所有数据分布在不同硬盘，如果一块硬盘损坏，那么所有数据不可用 raid1 空间：2，raid1因为需要保持镜像，所以空间利用率为50% 性能：写入的时候需要写入两份数据，所以写入性能会下降，读取策略如果每块硬盘都可以参与，那么示有性能提升的 安全性：安全性适中，允许损失一块硬盘 raid10 空间：N/2，可以看做是多块硬盘两两组合成raid1之后再组成raid0，所以空间利用率为50% 性能：写入的时候会先写入两个raid0，再同步两个raid1，理论上是有提升的。读取性能肯定会有提升 安全性：允许两个raid1各丢失一块硬盘，最多丢失两块硬盘，但不能允许单个raid1中丢失两块硬盘 raid5 空间：N-1，数据会被条带化为硬盘数量-1，如果有5块硬盘，那么数据会被条带化为4份数据+1份(条带数据异或)奇偶校验值，如果数据甚至小于条带大小，那么只有第一块硬盘会存储完整数据，其他硬盘则存储填充值 性能：写入的时候需要做奇偶计算，性能有所下降，读取时会分布式读取不同硬盘，性能有所提升 安全：允许丢失任意一块硬盘 raid6 空间：N-2，数据会被条带化为硬盘数量-2，如果有4块硬盘，那么数据会被条带化为2份数据+2份数据的奇偶校验，如果数据甚至小于条带大小，那么只有第一块硬盘会存储完整数据，其他硬盘则存储填充值 性能：写入的时候需要生成两份奇偶计算数据，性能有所下降，读取时会分布式读取不同硬盘，性能有所提升 安全：允许丢失任意两块硬盘（与raid10的差别） 基于以上特性，我们一直使用的 raid5、raid6的模式，因为不挑损坏的硬盘，比如raid10和raid6都是4块硬盘，但raid10不能一组raid1同时损坏，而raid6可以损坏任意两块，在安全性上更高 raid选择 根据数据安全、可用容量、性能等特性，raid5写入性能比较差，raid6理论上会更差，raid建议如下： 对于性能要求较高的场景，考虑使用raid10的方式来均衡性能和权限，但同时安全性要通过监控+到期更换的方式来弥补 对于安全要求保障较高的场景，建议raid6，其空间在超过4盘时优于raid10 对于空间要求较高的场景，建议raid5