之呈文 所筑何物
寻路助手，乃边缘对齐、高效通行的市政交通共驾之辅，实时生态影响之仪表盘也，以Gemma 4所筑也极重后端架构之优化，低延迟之管路效能，及离线之韧性。
施以生产级后端工程之原则，如语义Redis缓存，上游速率限制之防护，及解耦微管路。，此系统弥合了原始物理车票与即时智能交通路线之隙。通勤者上传实体车票之影，未及二秒，即得量身定制之行程，并辅以视觉温室气体抵消之图示。
核心之困
凡AI驱之交通或导航之术，多罹三重根本之窒碍：
- 不可接受之迟滞：运行原始图像于繁重多模态视觉模型，需时逾八秩，此于奔波于喧嚣地铁闸机者，实不可行。复上传同一车票于异时，必再唤API，是增迟滞而费计算也。
- ：连通性与：可用性跌宕。：云间API于深地隧道之中或API速率拥塞甚重之时，竟全然失效。
- 冗余计算：重行昂贵之大语言模型查询于同途之常客，致迟滞益增，API之费亦随之。
其解：优化之后台架构
为解此弊，吾辈设计寻汝之路环周一模块、解耦之後台，以速如闪电应答：
-
一令容器化部署：全後台生態系統（FastAPI、EasyOCR管線及Redis緩存）皆已完全面向Docker。一令(
docker compose up --build)即可於任一機器上啟動全堆疊，使部署瞬息且可重現。 - 解耦之輸入管線：非恃云视之API，乃依地设高速EasyOCR之流，以取票文之素，其文由正则之站符器于~1.6息解析之。
-
高性能Redis缓存：同途之行者，遇典则
source:destination键入记忆。系统调取预计算路线洞见。不足一毫秒，得 blazing-fast warm-cache API 之迅捷应答约一秒有八分之十七（全然规避大语言模型之迟滞） - 双模边缘回退&API防护：若云API遭遇速率限制或延迟骤增，则后端自动于五百毫秒内切换至本地Ollama实例，该实例运行Gemma 4 E2B于边缘设施，务使通行指引无有中断。
- 低内存配置优化：藉由运用定制Ollama运行参数，本地Gemma 4 E2B 之模型，行于寻常开发之笔记本电脑及低内存配置，使离线边缘部署甚为可行。
- 生机盎然之生态分析仪表盘：前端React Native元素，取速捷洁净之JSON负载，以呈交互式、基于SVG之生态足迹指标（所存之树、所减之碳），及未来地铁时刻表与车厢拥挤热力图。
示范
码
寻路之途
人工智能驱动之多元公共交通协同助手&生态影响仪表盘
寻路之途乃为公车之副导，司票之 OCR、路之导引、缓存之务，并较生态之影响。其用 Google 之Gemma 4之模型，
Redis所载之缓存，及应时之仪表盘。
- 扫描实体票券之图像。
- 以OCR预处之法，提取并规整站点之详。
- 以Gemma 4之助，生成路径之导引。
- 较碳之影响与行旅之费，于他种交通之选。
- 当在线API访问不可用时，使用本地Ollama备选方案。
graph TD
A[Physical Ticket Upload] -->|react-native-image-picker| B[OCR Extraction Pipeline]
B -->|FastAPI Preprocessing| C[Station Extractor / Normalization]
C -->|Check Redis Cache| D{Cache Hit?}
D -->|Yes: sub-second| E[Render UI Response]
D -->|No: Cache Miss| F[Gemma 4 31B Dense Primary]
F -->|API Congestion/Failure| G[Gemma 4 e2b Local Fallback]
F -->|Generate Route Markdown| H[Store in Redis Cache]
G -->|Generate Route Markdown| H
H --> E
速成之始
- 先决条件：Docker，Docker Compose，及或……
吾如何用Gemma 4
吾等所择之架构&何哉
为驱策吾辈实时通勤之共御，吾等设此混智路由系统藉二主要Gemma 4架构
-
主脑：Gemma 4 31B 密集(
google/gemma-4-31b-it:free）- 职司高通量云推理引擎。
- 何故契合：制行旅之程，需精微之思辨，多端而审慎。Gemma 4 31B Dense善读原始之JSON数据库，明铁路之脉络相接，且将指令以雅致之短句markdown格式之，便行旅于途中览之。
-
：备用之Gemma 4 E2B：(Gemma 4 E2B)
gemma4:e2b- ：职分：以Ollama韧性边缘部署。
- 何其契合。：E2B之故。之模，精于局域或离线部署于限制之硬件（若站务售票机或局域节点）。其思辨之效至高，而内存之占甚微，使纵地下之站，公网之连若断，则本地之备亦发，于五百毫秒之内，引行旅安抵。
管弦之流
工程之艰 & 顿悟之奇
妨碍一：地存之阻（8GB RAM之限）
- 难题：当于地测试时，系统常会僵滞，致发内存溢出之崩。Ollama难与Docker、VS Code及众开浏览器标签同运。
-
其解：初，吾辈须闭诸背景应用与标签，方使Ollama得存。察此非善用户体验，遂研而施以低内存配置。
gemma4-lowmem).
挑战二：Docker 容器网络& Redis 配置
- 难题：以 Docker Compose 协调 FastAPI 后端与 Redis 缓存时，屡现连接失败，后端于启动之际无法触及 Redis 容器.
-
解决之法：初以
localhost/127.0.0.1配Redis，然不效，盖因各Docker容器独运故也。后更Redis主为redis (REDIS_HOST=redis)，去密码之设，并更新Docker之配置，使后端得正接Redis。
应用之像！
