- 博客(823)
- 资源 (15)
- 收藏
- 关注
RSS订阅原创 MLOps 超全详解
DevOps 让普通软件工业化，MLOps 让人工智能模型工业化；没有 MLOps，AI 只能做Demo、做试点；有了 MLOps，AI 才能真正规模化落地到生产业务。
2026-05-06 21:07:10
232
原创 端侧推理：全面解析与深度洞察
本质：将AI计算从云端数据中心下沉到离用户/数据源最近的终端设备，实现"数据不出设备"的智能处理闭环。本地执行：模型推理在终端硬件上完成，无需数据上传至云端服务器资源受限：运行环境通常有CPU/GPU算力、内存、存储和功耗的严格限制轻量高效：需通过模型优化适配端侧硬件，平衡精度与性能实时响应：消除网络传输延迟，实现毫秒级决策。
2026-05-03 15:45:39
355
原创 vLLM 全部8种部署方式（按从简单到企业级排序，附适用场景+最简命令）
适用：本地开发、调试、二次开发、嵌入RAG/Agent项目。特点：张量并行TP、流水线并行PP，拆分模型到多卡/多机。适用：快速搭OpenAI兼容接口、临时测试、内网小服务。适用：70B、110B、MoE大模型，单张GPU放不下。能力：流量分发、限流、熔断、接口统一域名、隐藏后端实例。适用：线上高并发、多GPU节点、自动扩缩容、灰度发布。特点：集群化管理、故障自愈、负载均衡、多模型统一调度。适用：单机GPU服务器、私有化部署、环境统一隔离。适用：政务、金融、涉密内网，不能联网。
2026-05-02 17:51:43
185
原创 vLLM全解析：定义、用途与竞品对比
vLLM（Very Large Language Model inference） 是由加州大学伯克利分校LMSYS团队于2023年6月开源的高性能大模型推理与服务引擎，专注解决大模型部署中的显存效率低、吞吐量瓶颈、延迟高三大核心问题。核心技术创新PagedAttention（分页注意力）：借鉴操作系统虚拟内存管理思路，将KV缓存分割为固定大小的块，内存浪费控制在4%以内，支持动态分配与释放，单卡可服务更多请求。
2026-05-02 17:20:22
264
原创 大模型部署全流程深度解析
准备阶段：明确业务需求→选择模型→规划硬件→搭建环境优化阶段：量化（INT4/INT8）→并行策略（TP/PP）→推理引擎选择（vLLM/TensorRT-LLM）→KV缓存配置服务化阶段：封装API→配置负载均衡→设置扩缩容规则→接口测试部署阶段：容器化（Docker）→编排（K8s）→灰度发布→全量上线运维阶段：监控指标→日志分析→告警处理→性能优化→版本迭代。
2026-05-02 17:07:26
427
原创 大模型训练框架全景解析（2026最新）
大模型训练框架生态呈现分层化、专业化趋势：通用框架（PyTorch/TensorFlow/JAX）提供基础能力，分布式专用框架（DeepSpeed/Megatron/FSDP）解决超大规模训练痛点，集成框架（NeMo/PyTorch Lightning）降低工程化门槛。选型核心原则：小规模模型选易用性，大规模模型选性能，超大规模模型选混合方案。同时需考虑团队技术栈、硬件环境与项目阶段，灵活组合不同框架优势，实现高效训练与快速迭代。
2026-05-02 16:21:52
405
原创 一文看懂大模型有哪些架构
大模型架构围绕Transformer三大基础范式扩展，形成多元生态。选择架构应匹配任务：理解优先选Encoder-Only，生成优先选Decoder-Only，转换任务选Encoder-Decoder，复杂场景选MoE或混合架构，超长序列考虑Mamba等新兴架构。
2026-05-02 15:52:42
347
原创 RAG全面解析:从原理到应用场景
Chroma等（向量库）+ BGE/M3E（嵌入模型）+ 通义千问/GLM（大模型）凑在一起，就是一套标准极简 RAG 系统。
2026-05-01 16:22:41
209
原创 claude-context 本地部署方案
本文介绍了一种完全离线的本地化解决方案，用于对接本地部署的Claude-Code。该方案采用全本地架构，包括本地Milvus向量数据库、Ollama开源嵌入模型、本地构建的MCP索引服务和本地Claude-Code客户端，无需依赖任何云端API。安装过程包括配置Docker、Node.js、pnpm和Ollama环境，启动本地Milvus向量库和嵌入模型，构建Claude-Context服务，并进行本地代码库索引。通过配置本地MCP服务，用户可以在断网环境下使用本地Claude-Code检索项目代码。该方案
2026-04-26 12:08:33
415
原创 claude-context -- 让AI 能深度理解和检索代码库
claude-context是Zilliz开发的开源MCP插件，为AI编程助手提供语义代码搜索能力。它通过将代码库转化为向量数据库索引，实现自然语言查询代码功能，解决AI处理大型代码库时的关键痛点：上下文窗口限制、手动传递低效、代码理解不全和跨模块协作难。核心技术包括代码AST解析、向量嵌入、混合搜索和智能分块。提供多个变体版本满足不同场景需求，适用于大型项目开发、代码重构、Bug调试等场景，显著提升开发效率并降低40%+Token成本，是AI编程助手的"代码理解增强器"。
2026-04-26 11:34:03
339
原创 OpenClaw新会话记忆加载过程
在 OpenClaw 里，新会话刚启动时，记忆不是一次性全塞给模型，而是走一套非常固定、轻量的初始化加载 + 按需召回流程。下面用最清晰、最贴近源码逻辑的方式讲：新会话开始时，记忆的完整使用流程。
2026-04-24 22:20:43
237
原创 OpenClaw记忆系统
OpenClaw记忆系统采用文件即真相的设计理念，以纯Markdown文件为核心存储，配合SQLite+向量数据库的混合索引，实现持久化、可检索、可管理的AI记忆能力。核心是三层记忆架构与智能检索-召回机制，确保模型只“记住”写入磁盘的内容，无隐藏状态。
2026-04-24 22:15:50
373
原创 一文读懂人工智能，机器学习，深度学习，神经网络，Transformer
定义：让机器具备感知、推理、决策、理解、创造等类人智能的技术总称。包含内容传统人工智能（非机器学习）符号推理、规则系统、专家系统、搜索算法、博弈算法知识图谱（规则推理）、自动逻辑证明现代人工智能（机器学习方向）传统机器学习深度学习其他分支模糊控制、进化算法（遗传算法）、机器人控制、多智能体AI：范围最大机器学习：AI里“靠数据学习”的路线深度学习：机器学习里“用深层神经网络”的路线神经网络：深度学习的模型本体：神经网络中，当前大模型的核心底座。
2026-04-17 22:26:48
2017
2
原创 AI agent中的skill
在AI Agent（智能体）领域，Skill（技能） 可以直白理解为：智能体为了完成具体任务，所具备的标准化、可直接调用的执行能力单元。
2026-03-23 20:54:08
113
原创 主流AI Agent
以下是按商业产品、开源框架、特定领域应用分类的主流AI Agent汇总，覆盖通用助手、开发协作、企业自动化等场景，信息截至2026年3月。
2026-03-23 20:47:49
476
原创 OpenClaw与Claude Code的Skill比较
两者的Skill系统在核心设计理念、基础结构与使用体验上几乎一致，共享Agent Skills的技术基因，是AI智能体能力扩展的标准化解决方案。差异主要体现在执行效率、扩展自由度与生态定位上，用户可根据需求选择更适合的平台，而无需重新学习技能开发范式。需要我整理一份SKILL.md的最小兼容模板（包含必要元数据与触发示例），让你能快速写出同时适配两者的技能吗？
2026-03-18 21:13:21
342
原创 OpenClaw与Claude Code相似之处
两者虽定位有别（Claude Code专注编程专家，OpenClaw偏向通用智能体），但在技术基础、交互范式与核心能力上高度一致，均代表AI辅助开发的重要方向。OpenClaw可视为Claude Code的社区扩展版，提供更灵活的部署与定制选项，而Claude Code则具备官方支持与更稳定的企业级特性。
2026-03-18 21:01:50
268
原创 OpenClaw与大模型通信过程：详细图文教程（2026最新）
完整通信链路：用户指令→渠道适配→网关调度→模型思考→MCP工具调用→技能执行→结果反馈→模型优化→最终回复→用户。核心结论：通过三层架构+MCP协议+Agent循环，OpenClaw与大模型实现“理解→规划→执行→反馈→优化”的全链路通信，把自然语言指令转化为本地可执行操作。下面用可视化图表+实操示例，完整拆解每一步通信细节。{“role”: “system”, “content”: “你是文件管理助手，可调用file-manager技能”},“图片”: [“jpg”, “png”, “webp”],
2026-03-13 21:46:56
730
原创 MySQL Group Replication (MGR)选主中是如何保证数据不丢失的
所以，你提到的“数据最新程度”之所以是第三优先级，是因为在它之前，底层共识协议已经保证了所有进入待选池的节点数据都是一致且完整的。但在MGR的机制中，数据一致性有更底层的保底设计，不会因此而丢失数据。因此，如果一个高权重的节点数据略微落后，而一个低权重的节点数据最新，按照标准流程，那个高权重但数据稍旧的节点会被选中。虽然选出的节点可能不是数据最新的，但它一定是数据一致的。· 在选主时，这些数据落后的节点会被自动排除在候选名单之外，它们没有资格参与竞选。· 集群会忽略它的高权重，等待真正数据完整的节点竞选。
2026-02-27 21:34:14
404
原创 MySQL Group Replication (MGR)选主策略
在 MySQL Group Replication (MGR) 的单主模式中，当主库发生故障时，剩余的节点会自动触发新的主库选举。选举过程遵循一套严格的优先级规则，确保选出数据最完整且符合配置策略的节点。· 若集群中存在低于 MySQL 8.0.17 的节点，选举会优先考虑主版本号较低的节点（例如 5.7 节点优先于 8.0），因为低版本节点无法作为从库复制高版本的数据。综上所述，MGR 的新主选举是一个层层筛选、数据优先的过程，在保证集群可用性的前提下，最大限度地避免数据丢失，并兼顾了管理员的可控性。
2026-02-27 21:24:27
332
原创 在MySQL中，出现Executed_Gtid_Set 乱序增长的场景
由于各事务提交速度不同，后面的可能先执行完，导致Executed_Gtid_Set在尾部出现暂时不连续。并行复制导致的尾部临时空洞通常无需干预，而因手动跳过、参数误操作或主机崩溃导致的永久性不一致，则需要通过重建同步或数据校验来处理。在MySQL中，Executed_Gtid_Set 乱序增长通常指的是该集合中出现非连续的区间（即“空洞”）。若之前已执行到N，跳过N+1，集合会变成 1-N : N+2-M，形成永久空洞。从库记录的GTID集合因此多于重启后的主库，这种不一致在集合中表现为“多余的区间”。
2026-02-17 17:35:37
174
原创 MySQL主从库复制中，主库如何查找对应日志文件位置
GTID 自动定位：从库告诉主库“我有什么”，主库自己计算“你需要什么”，并通过内置的“索引”（Previous_gtids_log_event）智能地找到从哪里开始提供。在基于 GTID 的复制中，从库发送已执行的 GTID 集合后，主库查找对应日志文件位置的过程，本质上是一个 “智能计算” 而非简单的“文件指针跳转”。这个过程的核心，就是主库利用二进制日志中特殊标记（Previous_gtids_log_event）的索引功能，快速定位到从库缺失事务的起始点。⚙️ 主库的“三步定位法”
2026-02-17 17:25:40
343
原创 轻量级容器环境Colima
Colima是一个在macOS（和Linux）上运行容器的最小化设置工具，它通过在虚拟机中运行容器，为开发者提供了一个轻量级的本地容器环境。
2026-02-10 20:03:16
488
原创 UnicodeDecodeError: ‘charmap‘ codec can‘t decode byte 0x81 in position 17: character maps to ＜undefi
摘要：MySQL查询结果解析出现UnicodeDecodeError错误，主要原因是字符编码不匹配。解决方案包括：1)连接MySQL时指定utf8mb4字符集；2)Python脚本中正确设置连接参数；3)检查系统环境编码；4)调整MySQL服务器配置。预防措施建议统一使用utf8mb4编码，并在MySQL配置文件和Python环境中进行相应设置。错误排查发现，连接MySQL 8时使用'utf-8'参数是导致该问题的原因。
2026-01-25 10:30:27
841
原创 MySQL 中的 utf8 vs utf8mb4 区别
MySQL中utf8和utf8mb4的核心区别在于：utf8仅支持3字节编码（BMP平面字符），是"阉割版"UTF-8；而utf8mb4支持4字节编码，能完整表示所有Unicode字符（包括表情符号和生僻字）。utf8mb4会占用更多存储空间（比utf8多33%），但对现代应用更友好。建议新项目一律使用utf8mb4，排序规则推荐utf8mb4_unicode_ci，并注意调整索引长度限制（早期版本VARCHAR需≤191字符）。MySQL 8.0已默认采用utf8mb4，未来版本中ut
2026-01-25 10:23:53
696
原创 golang中使用 sort.Interface 实现复杂多级排序
本文展示了两个使用Go语言sort.Interface实现多级排序的示例。第一个例子对学生成绩进行排序，先按分数降序，分数相同时按姓名升序。第二个例子对员工信息进行三级排序：先按部门升序，部门相同时按工资降序，最后按工号升序。两个示例都通过实现Len()、Swap()和Less()方法来自定义排序规则，其中Less()方法通过条件判断实现多级排序逻辑。这种模式可以灵活应用于各种需要多条件排序的场景。
2026-01-25 10:00:57
193
原创 2025年度总结
年终总结：成长与展望 这一年总体给自己打80分，工作、读书和生活都有所收获。工作上参与多个高可用项目，学会平衡质量与速度，善用AI工具提升效率，并将困难视为成长机会。读书方面，坚持阅读并记录笔记，从《活法》等书籍中获得启发。生活中更注重战略思维培养、自我认知提升和身体健康管理。展望未来，将持续关注AI科技发展，保持学习与实践，迎接新时代的机遇与挑战。
2026-01-18 20:48:20
387
原创 MySQL主从复制底层网络通信过程
摘要：MySQL主从复制通过CHANGE MASTER TO和START SLAVE命令实现，包含5个关键阶段：1)配置阶段保存主库信息；2)建立TCP连接和MySQL协议握手；3)身份验证；4)获取主库binlog状态；5)持续传输二进制日志事件。整个过程采用滑动窗口机制控制数据流，支持断点重连和GTID模式。网络参数如重试间隔、心跳周期等可配置，通过状态变量可监控复制延迟和连接状态。该机制确保主从数据高效同步，同时提供故障恢复能力。
2026-01-16 20:59:17
802
原创 (MySQLdb._exceptions.OperationalError) (2013, ‘Lost connection to MySQL server during query‘)“,)
摘要： MySQL 2013错误表示查询执行期间连接中断，常见原因包括： 大结果集：需分页查询或使用流式游标 超时设置：调整net_read_timeout等参数 资源不足：内存/磁盘耗尽或CPU过载 网络问题：不稳定或中间设备超时 服务器异常：崩溃或锁等待超时 排查建议：检查错误日志、系统资源、查询优化，并适当调整连接参数（如max_allowed_packet）。代码层推荐使用流式游标处理大数据。
2026-01-16 20:24:22
472
原创 (MySQLdb._exceptions.OperationalError) (2006, ‘MySQL server has gone away‘)
MySQL 2006 "Server has gone away"错误表示客户端与服务器的连接意外断开。主要成因包括：连接超时（wait_timeout参数）、数据包过大（max_allowed_packet限制）、查询执行时间过长、服务器崩溃/重启、网络不稳定、连接池配置不当等。解决方法需根据具体原因调整相关参数或优化查询，如启用连接验证、增大数据包限制、优化长时间查询等。建议检查MySQL日志、监控连接生命周期，并在SQLAlchemy等框架中配置pool_pre_ping=True
2026-01-16 20:11:53
525
原创 (MySQLdb._exceptions.OperationalError) (2003, “Can‘t connect to MySQL server on ‘10.0.0.106‘ (110)
MySQL 2003错误（连接超时）常见原因包括：网络不通、防火墙阻止、MySQL服务未启动、绑定地址限制、端口配置错误、云服务器安全组限制或用户权限不足。排查时需依次检查网络连通性（ping/telnet）、服务状态、防火墙设置、MySQL配置文件的bind-address参数、端口监听情况及用户权限。对于内网地址10.0.0.106，还需检查容器网络配置。
2026-01-16 20:05:26
361
原创 做事情的正确方式
摘要：高效做事需要四个维度的系统配合：1）态度层面需保持敬畏、担当与专注；2）策略层面要善用系统规划、工具杠杆和灵活应变；3）执行阶段强调敏捷启动、节奏把控和资源整合；4）闭环阶段注重复盘评估、反馈内化和持续迭代。真正的高手能将严谨态度与灵活策略结合，在定力与智慧间找到最优路径，形成可迭代的方法论体系。（149字）
2026-01-03 22:15:32
511
原创 在MySQL中，使用物理备份工具 xtrabackup备份扩容从库，从库上的gtid_executed和gtid_purged变化过程
摘要：本文详细介绍了使用Percona XtraBackup扩容MySQL从库时GTID状态的变化过程。XtraBackup会在备份时记录GTID信息到xtrabackup_binlog_info文件。恢复阶段需要先重置master，然后设置gtid_purged为备份中的GTID集合，此时gtid_executed会自动同步为相同值。配置复制时应启用MASTER_AUTO_POSITION=1，确保从库从备份结束点后的事务开始同步。文章还提供了自动化脚本示例和常见问题解决方法，强调了设置gtid_purg
2025-12-08 22:40:19
532
原创 在MySQL中，gtid_purged 的初始化和更新机制
摘要：MySQL的gtid_purged变量记录已提交但被清除事务的GTID集合，其计算遵循gtid_purged = gtid_executed - 当前二进制日志中的GTID。初始化时通过扫描二进制日志确定，更新时机取决于服务器角色和配置：主库和开启log_slave_updates的从库在清理日志时更新，未开启的从库在事务提交时实时更新。该变量在复制环境搭建、备份恢复中起关键作用，错误配置可能导致复制中断。理解其机制对MySQL运维至关重要，特别是在处理GTID复制故障时。
2025-12-07 23:17:20
978
原创 服务器异常崩溃，GTID 是否会出现在 mysql.gtid_executed 表但不在 binlog 中
摘要： MySQL事务提交时，sync_binlog参数决定了GTID是否可能仅存于mysql.gtid_executed表却丢失于binlog。当sync_binlog=1时，每次提交强制刷盘，确保binlog与GTID严格一致；若设为0或N>1，崩溃可能导致已提交事务的binlog未持久化，但InnoDB通过redo log恢复事务后，GTID仍被记录到系统表，造成数据不一致。此现象会影响主从复制、备份恢复等场景，建议生产环境主库配置sync_binlog=1以保证数据安全。（149字）
2025-12-07 22:50:21
807
原创 mysql.gtid_executed 表的初始化和更新机制
MySQL 5.7引入的mysql.gtid_executed表是GTID持久化存储的核心机制。该表记录服务器执行的所有GTID事务，确保重启后能准确恢复GTID状态。初始化时结合表加载和binlog扫描，主库在binlog切换时更新表，从库则实时更新。表更新会压缩GTID区间以提高效率，并通过后台线程定期优化。该设计解决了MySQL 5.6中GTID仅存内存的问题，实现了数据一致性与恢复效率的平衡，为高可用架构提供可靠基础。关键特性包括持久化价值、差异化更新策略和压缩机制。
2025-12-06 23:49:02
771
原创 MySQL半同步复制下KILL写入操作的原理、风险与应对
MySQL半同步复制环境中执行KILL命令需谨慎，核心风险是可能破坏主从数据一致性。KILL通过设置标志而非立即终止操作，线程需运行到检查点才会停止。最危险的情况是在主库等待从库ACK时执行KILL，可能导致主库提交而从库未收到数据。建议操作前评估风险，优先使用KILL CONNECTION，并密切监控复制状态。若怀疑数据不一致，需准备备份恢复等修复方案。理解事务提交流程并做好检查监控是规避风险的关键。
2025-12-01 22:43:00
695
原创 MySQL offline_mode：安全隔离流量，高效完成数据库维护
MySQL的offline_mode是用于数据库维护的重要配置，开启后仅允许管理员连接，普通用户连接会被拒绝或断开。它不会影响复制线程，确保主从同步不受干扰。该功能适用于服务器升级、数据备份等维护场景，需配合CONNECTION_ADMIN和SYSTEM_VARIABLES_ADMIN权限使用。使用时需注意：会立即中断业务连接，建议在维护窗口期操作，并确保应用连接池能正常恢复。通过SET GLOBAL offline_mode=ON/OFF可快速切换状态，为数据库维护提供安全环境。
2025-12-01 22:31:44
1077
原创 MySQL中，binlog文件开头的Previous_gtids_log_event是如何计算的
Previous_gtids_log_event是MySQL二进制日志文件开头的关键事件，记录当前文件之前所有已执行的GTID集合。其主要作用包括：确定复制起点确保数据同步准确性、保证GTID连续性验证数据完整性，以及作为binlog清理的依据。该事件的计算遵循"当前文件Previous_gtids=上一文件Previous_gtids+上一文件所有GTID"的规则。可通过mysqlbinlog工具查看，但需注意其与executed_gtid_set不完全等同，因为不记录binlog的事
2025-11-29 23:22:17
1011
原创 MySQL 机器重启后，gtid_executed 是如何初始化的
MySQL启动时通过两个步骤初始化gtid_executed：首先从mysql.gtid_executed表加载持久化存储的GTID集合，然后扫描所有binlog文件验证并补充未持久化的GTID。最终gtid_executed是两者的并集，确保事务记录的完整性。基于此，gtid_purged通过集合差运算得出，表示已清除binlog中的事务。这种设计兼顾效率与数据安全性，快速加载表数据的同时通过binlog扫描保证准确性。
2025-11-27 22:37:10
653
深入理解linux内核 第三版 Daniel P. Bovet &Marco Cesati 勘误
2011-03-07
sqlite嵌入式编程实例
2012-06-20
ndiswrapper 最新版本下载 ndiswrapper-1.57.tar.gz
2012-03-07
Spreadsheet-ParseXLSX-0.16.tar.gz
2014-11-26
Linux下使用USB转串口获取GPS数据
2012-03-01
Linux下sqlite3编程实例
2012-06-20
git post-update
2017-07-30
rt5370驱动
2012-03-20
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人